[microformats-discuss] Re: [Geowanking] geo microformat BOF
session at Where 2.0
Ryan King
ryan at technorati.com
Thu Jul 7 11:26:02 PDT 2005
On Jul 7, 2005, at 8:59 AM, Bud Gibson wrote:
> On Jul 7, 2005, at 10:38, Ryan King wrote:
>
>> I think we are. However, its seems that we need to make
>> accomodations for #2, as well as #1.
>
> Let me challenge this. My main observation is that there is a
> difference with a tension. #1 is providing a systematic interface
> for humans and #2 is providing precise geo coordinates (street
> addresses or "geometric" per the Tantek sense). Would we be better
> off with a divide and conquer strategy? That's the question I mean
> to raise.
I don't think we need to divide this effort at this point, for
several reasons:
1. Most people who are interested in one, will be interested in both
2. They have implications for each other.
3. Implementors will want to implement both of them.
4. They're trying to solve the same problem.
Of course, I may be wrong..
>>> The google maps search interface as one of the referents for the
>>> location microformat. Should we study in closer detail how that
>>> interface works?
>>
>> I'm not sure what you're talking about. Are you talking about the
>> search interface? or the new Google maps api?
>
> I'm talking about the search interface. I think there is a lot to
> learn there because that is what lots and lots of real users use.
> It's how these people express location, or at least one semi-
> systematic way here in the US.
>
> Given this last observation, why couldn't I have a microformat for
> expressing location that is like this:
>
> 1. A tagging method based on the reltag standard, perhaps with an
> extra "geo" class attribute value or some other way of indicating
> we are talking about tagging a location.
> 2. Tag values that are equivalent to search terms that produce
> unique results in any one of a set of commercial search services.
This idea has come up several times before and was actually my
original idea (in f2f conversations with Tantek and Kevin). It has
also come up as a current practice on http://microformats.org/wiki/
location-formats and come up during the BOF.
Here are the outstanding issues with it:
1. Is there a common url scheme we can use?
2. Are the urls parseable in a reasonable manner?
> Let's call this geotag, or if that name is taken, bdgeotag (brain
> dead geotag).
Geotag is being used by the flickr geotaggers and possibly by others.
> That way, bumpkisses like me who are generally aware of city and
> sometime street (almost always place name) would have a chance of
> producing data that could go in there. We could check whether we
> had a legal value by using a search service. You could even make a
> geotag creator that had people do searches and once they were
> satisfied slide the search term as a valid tag value into the geotag.
Yes, I very much like the idea. I think one of the reasons that rel-
tag has done better than meta keywords is something I call "one-click
verifiability." RelTag does well by being visible, but it also does
well because you can click on the link and see what it is (in a
loose, general sense) that the person means by that tag. Also, the
author can verify that they've done things correctly (otherwise 404
errors and such).
> Some might object to the idea of using commercial search services.
> Well, why not some interface to the Tiger database
>
> http://www.census.gov/geo/www/tiger/
vendor neutrality++
However, it would be great if someone could still link to google or
yahoo or webmapper or mapquest. To do this, though, they'd all need
to support some common url scheme (or someone would have to write a
proxy).
With Tiger, I don't think there's any way we can link to a map page.
Anyone know otherwise?
> Like reltag, geotag could apply to the whole blog post or some
> portion thereof as delineated by enclosing elements.
Right.
>>> I expect that this is the level of detail most people are going
>>> to be able to give on their location.
>>
>> Yes. That is the majority case, but the minority case is large
>> enough to be supported.
-ryan
More information about the microformats-discuss
mailing list