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

[Tantek Ç elik]

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

> 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" />

Wow, I knew about ICBM, but I've never heard of geo.position.  Talk about
somebody (not sure which, maybe both?) reinventing something for no good
reason.

And not only that, but the metadata is invisible, which makes it
substantially less useful, and vulnerable to becoming useless should such a
format actually gain significant adoption.

 http://tantek.com/log/2005/06.html#d03t2359


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

If you amend that slightly to "as explicit as captured/entered by a human",
then I agree.  Any precision more than that is both artificial and tends to
be deceptive.

> and hence machine-processable.

I think we are agreed there.

> That being
> orthogonal to what a piece of software that encounters the data
> actually does with it.

Yes.

> Minimising ambiguity regarding what's been said
> strikes me as been generally a Good Thing.

I think when it can be minimized without introducing false details, then I
agree.  When minimizing ambiguity forces you to do imply/infer arbitrary
details about the data, then that's Not a Good Thing.  Too many formats
don't allow for the state of "not knowing" something.


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

Interesting.  Good to know.


> where, incidentally, something
> like "reviews of businesses SHOULD use an hCard to describe the
> business" would come across as shockingly rigid ;-)

There seems no need to reinvent hCard, thus it seems reasonable to build
upon it.


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

Cool.

Danny, you're not the only smart person to have gotten this mis-impression
of whether element names matter in microformats, and if so then how much.

Now that this concept is clear to you, can you think of a better way of
explaining it in the specs than we have so far that may help avoid this
confusion better in the future?  That would be a big help.

Thanks,

Tantek