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

Danny Ayers danny.ayers at gmail.com
Mon Sep 26 05:12:06 PDT 2005

On 9/24/05, Tantek Çelik <tantek at cs.stanford.edu> wrote:

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

Heh, my blog for a start, but to be honest I've no idea where I found
the suggestions to add the following to my home page:

<meta name="geo.position" content="44.15000;10.38890" />
<meta name="ICBM" content="44.15000 10.38890" />

> 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.

Ok, I can see the rationale.

> 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.

Ok, that's fair enough. "something to do with" can be a very useful
relationship (c.f. hypertext links).

> 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).

Hmm, yes maybe there is a philosophical difference between us there. I
don't see it as ocean-boiling to make pieces of information as
explicit as possible and hence machine-processable. That being
orthogonal to what a piece of software that encounters the data
actually does with it. Minimising ambiguity regarding what's been said
strikes me as been generally a Good Thing.

> 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).

Ok, fair enough, I'm sure such an approach will have its benefits. Not
having to have all the structures defined in advance has certainly
shown benefit in the context of RDF, where, incidentally, something
like "reviews of businesses SHOULD use an hCard to describe the
business" would come across as shockingly rigid ;-)

> > 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, clear now.




More information about the microformats-discuss mailing list