[microformats-discuss] adr and geo microformats finally written up

[Tantek Ç elik]

On 9/24/05 12:44 AM, "Danny Ayers" <danny.ayers at gmail.com> wrote:

> On 9/23/05, Tantek Çelik <tantek at cs.stanford.edu> wrote:
> 
>> By separating geo out from hCard, we also enable other structures to use it
>> as a building block.
> 
> It would be helpful to have a practical example or two.

Agreed.  

Numerous such examples were discussed during the Geo BOF, but I don't think
any of them were actually written up.  I'll put a place in the specs for
them, and hopefully some of the geo/adr experts will speak up.  For now I'll
ask this:

What websites currently publish "plain" (i.e. unnamed) address or lat/long
information? 

(in addition to the geocaching exmaple provided by Chris Hibbert.  Thanks
Chris!)


> Say the blog
> post was a restaurant review (using hReview).
>  How would my software
> determine that the location was that of the restaurant,

A restaurant is a business.

Reviews of businesses SHOULD (I'm considering making this a MUST) use an
hCard to describe the business.  If the location of the restaurant is given,
it MUST be indicated by the adr and/or geo of that hCard.


> rather than
> the place where the blog post was made

See the blog-post-formats and blog-post-brainstorming wiki pages for
discussions about microformats for blog posts.

  http://microformats.org/wiki/blog-post-formats
  http://microformats.org/wiki/blog-post-brainstorming

If you want to make explicit where the blog post was made, start with
helping answer these questions:

* How do current examples of blog post content on the web publish the
location where the blog post was made?  Add the answer to blog-post-formats
in the section for the tool(s) you analyzed.

* How do current blog post formats define the location where the blog post
was made?  Again, add the answer to the blog-post-formats page.

Based on that research, if you have suggestions for how to solve this for
the microformat for blog-posts, please add them to the
blog-post-brainstorming page.


> or where the person posting
> lived?

The reviewer of the hReview SHOULD (I'm considering making this a MUST) be
represented using an hCard.   If the location of the reviewer is given, it
MUST be indicated by the adr and/or geo of that hCard.


In general, any other adr or geo you happen upon is literally just a mention
of an address or a lat/long.  For now, all you have is that context.  That
an address or lat/long was mentioned.  If it was inside the contents of the
hReview then you know that somehow that location had something to do with
the hReview.  That's it.


And I want to take your question up to a higher level and question it a bit:

> How would my software
> determine

We are deliberately NOT boiling the ocean of trying to specify what software
should do with each and every piece of data nor how to determine each and
every detail of each and ever piece of data.  That's a rathole that once you
dive into, you will never emerge from (IMHO this one of the things that
"RDF" methods/philosophies of solving information representation problems
are vulnerable to, and have repeatedly succumbed to).

What the microformats community is doing is simply providing an evolutionary
improvement from the current state of published information on the Web
today, where addresses and lat/long aren't even marked up as such, and thus
you don't even know that they are there (certainly not without a bunch of
very unreliable AI text parsing heuristics).

The theory is that once you know that some structures are there, then other
implicit structures become more obvious with actual usage in the wild.  Then
we can specify microformats for those additional structures.  Etc.  The
process is therefore adaptive to actual human use.

The whole process is one of iterative, evolutionary improvement that eschews
solving all possible problems (i.e. complete a-priori definition of all
structures) in favor of incremental improvement of existing practice (i.e.
defining structures that are already humanly-obvious in the content).


>>> plus what's the rationale behind the flipover
>>> between div and span?
>> 
>> Partially to demonstrate that the element name doesn't matter (which seems
>> to be a common misconception by "XML experts" when they first encounter
>> microformats, e.g. Norm Walsh's post), and partially to demonstrate that you
>> can use it as a cheap form of block/inline layout, since the semantics of
>> div and span are essentially the same - the semantic of not having any
>> semantic.  You could use all spans or divs as well.
> 
> Sorry, I'm not entirely clear on this - would e.g. <p class="adr">,
> still be acceptable?

Yes. 

That's what I meant by "the element name doesn't matter" in terms of the
microformat semantics.

Web authors *should* of course choose the most semantic XHTML element they
can for each case, but that's fairly orthogonal from the microformat
representation.

Thanks,

Tantek