[uf-discuss] UID, URL, live microformats (was: Microformat auto-discovery WAS: Plazes & Microformats)

[Tantek Ç elik]

First of all, welcome Pieter!

I've been a fan of Plazes for quite some time, had a great time chatting
with Stefan and Felix at ETech, and I'm very happy to see you here!

Regarding auto-discovery, I just had a very good in person discussion with
the Live Clipboard folks (especially with Matt Augustine in particular) last
week about what to do about UID in hCard which may help solve this problem.

Before that Gordon of Upcoming had also asked me what is the proper way to
use UID with hCards, and I realized that we had not yet addressed that
question.

Clearly there is an intersection of questions and interests here.

One thing I very much want to avoid is an explosion of rel values - i.e. one
for each microformat, a rel-vcard a rel-vevent etc. etc.  This to me seems
like a very bad design pattern.  An antipattern if you will.

OTOH a UID is *supposed to* uniquely identify the contact or event,
globally.

Interestingly enough, on the Web, that's just what URLs do.

On the Web, many (most?) contacts and events also have a canonical or
authoritative URL.

So there is the straw proposal:

In addition to marking up the authoritative/canonical URL for a
contact/event with class name of URL, why not also use that URL for the UID?

I bounced this idea off the Live Clipboard folks last week, and folks from
Upcoming and EVDB as well at the recent Mashpit event in San Francisco (it's
often a good idea to get in person feedback from colleagues on ideas, as you
can read not only their words, but their tone as well to see if they really
think it is a good idea or not).

As far as I can tell, this should work perfectly to answer the question of
"What do do about UID?".

The really cool thing is, a parser *knows* if the UID of an hCard or
hCalendar event is *also* marked up as a URL for that contact/event.  In
that case, it can treat that URL as an authoritative source for that
contact/event.

This is how this would work with the example that Pieter gave:

  <li class="vcard">
    <a rel="contact friend" class="url uid fn"
href="http://beta.plazes.com/plaze/cd21e1717f61ba9cf9df9006038da172/">
      fiahless
    </a>
  </li>

This "URLish" treatment of UID would obviously require treating UID parsing
similar to that of URL (and PHOTO etc.).  Since it certainly seems like
people will (are already) using URLs as unique ids, it only makes sense for
us to make that easier to publish and parse. I've made the necessary mods to
both hCard and hCard parsing (and I believe Brian Suda is in the process of
updating X2V to parse UID this way as well).

 http://microformats.org/wiki/hcard
 http://microformats.org/wiki/hcard-parsing


The *combination* of URL and UID however is what gives us two very nice
semantics, each of which support the obvious applications that people have
been asking for.

1. Mention vs. Define.  It allows you to publish a minimal hCard as a
mention, say, on your blog, with a UID URL that points to a more detailed
hCard on a separate page.  The combined UID URL semantic communicates the
meaning that the hCard is more thoroughly defined at that URL.
  a. Auto-discovery of definitive contacts and events.  More often than not,
people mention other people and events rather than define them.  These
mentions could link to the definitive descriptions via URL UID and thus
parsers could auto-discover definitive contacts and events.
  b. Auto-discovery of web page to person.  Combined with <address>, this
clearly supports the need for auto-discovery of who a web page is associated
with.  The <address class="vcard"> on blog or home page can contain a URL
UID that points to a separate page with the more detailed hCard.

2. Live Microformats.  This is the *really* interesting bit IMHO.  As the
Atom folks have explicitly designed with rel="self", when a chunk of data
indicates where to get the latest version, you get self-contained
syndication.  Even "static" copies of the data contain the necessary info to
*subscribe* to an update of the data.

URL and UID indicate the semantic as defined above, and the one word FN
implies the nickname per the Implied "nickname" Optimization.

http://microformats.org/wiki/hcard#Implied_.22nickname.22_Optimization

Given that it could make sense to provide updates to any type of microformat
data (as Brian hints at), I want to strongly consider reusing "uid" from
hCard and hCalendar as an elemental microformat which can be used with *any*
microformat in combination with class name "url" to indicate the specific
instance, as well as where to get updates.

Thoughts?

Tantek


On 4/19/06 7:25 AM, "brian suda" <brian.suda at gmail.com> wrote:

> We have talked before about auto-discovery of microformatted data[1],
> and about describing vcards at the other end of a link. Here is the
> notes so far, it hasn't been talked about in awhile, so feel free to
> read-up and add your notes.
> 
> There is also an article about "Authoritative Metadata"[2] which details
> the fallbacks of where the browser/server is first suppose to gather
> data about the resources, then where too look next if it fails. This is
> important because we can start sticking things in rel="vcard" or
> possibly use the 'a' element TYPE attribute[3]. So you could have:
> 
> <a href="http://example.org/my.vcf" rel="something here vcard me"
> class="something here maybe" type="text/x-vcard">my vcard</a>
> 
> This doesn't always work because the TYPE attribute has to describe the
> resource, but hCards are embedded in HTML, so you couldn't cite them
> directly unless your link was to a web service that transformed the HTML
> to a vCard.
> 
> I hope this helps the discussion about auto-discovery, because this
> could be used across all microformats, hAtom, hReview, hCalendar, etc.
> 
> Thanks,
> -brian
> 
> [1] - http://microformats.org/wiki/hcard-brainstorming#Auto-Discovery
> [2] - http://www.w3.org/2001/tag/doc/mime-respect.html
> [3] - http://www.w3.org/TR/REC-html40/struct/links.html
> 
> David Janes -- BlogMatrix wrote:
>> That's exactly the idea. Note that we're just discussing this right
>> now (literally!) -- it isn't part of any spec at this point. I
>> certainly would like to here TC's opinion on this though, of course,
>> fortune favors the brave :-)
>> 
>> Regards, etc...
>> 
>> Pieter Walsweer wrote:
>>> David Janes wrote:
>>>> <a class="vcard" rel="vcard" href="/profile/fiahless/"><span
>>>> class="fn nickname">fiahless</span></a>
>>>> 
>>>> To indicate that not only is this a vcard, but a better or
>>>> "reference" vcard is available at the other end of the link.
>>> 
>>> That sound like a good idea, 'cause we're going to use these "short
>>> versions" of the hCards on our xfn-enabled friendslist, too. So it
>>> would look like this:
>>> 
>>> <ul>
>>>   [...]
>>>   <li>
>>>     <a class="vcard" rel="contact friend vcard"
>>> href="http://beta.plazes.com/plaze/cd21e1717f61ba9cf9df9006038da172/">
>>>       <span class="fn nickname">fiahless</span>
>>>     </a>
>>>   </li>
>>>   [...]
>>> </ul>
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss