"uid" microformats? (was Re: [uf-discuss] ISBN mark-up)

Wed Apr 26 09:11:30 PDT 2006

On 4/25/06 10:13 PM, "Joe Andrieu" <joe at andrieu.net> wrote:

> 
> Hello.  I'm new to microformats and a bit confused on how one
> disambiguates microformat names. It seems to be somewhat related to the
> UID/URI issue. 

Welcome Joe!

> I'm not sure I understand all of the subtleties between the spec and
> proposals around these concepts, so I may misuse some of these terms.
> I'll use UID to mean a unique name, independent of how it my be located.
> 
> It appears to me that UID/URIs/URNs have the potential to appear in at
> least four ways in relation to a microformat and I'm unclear about how
> the four work in current plans.
> 
> 1. UID/URI that identifies the microformat (class), e.g. vCard, vCoupon

URL to an XMDP profile in the profile attribute of the <head> element.

See http://gmpg.org/xmdp/ and also
http://microformats.org/wiki/profile-uris

> 2. UID/URI that identifies the content which /is/ embedded in this
> particular microformat (instance)

This hasn't been used as much, except perhaps "permalink" in hReview and
hAtom, which is again, a URL.

http://microformats.org/wiki/hreview
http://microformats.org/wiki/hatom

> 3. UID/URI that identifies the singular thing which this microformat is
> about (primary reference)

This is the semantic of the UID property in hCard and hCalendar and is under
consideration as a more elemental microformat for reuse in other
microformats.

http://microformats.org/wiki/hcard
http://microformats.org/wiki/hcalendar

Incidentally your email points out a very good distinction, which is that
URI (or URL for that matter) merely is a *type* of data.  What that data
*means* to the microformat still needs additional semantics, and that's why
we need a property name like UID (even if it is defined to be of type URI or
URL) which specifies this particular semantic.  I will add your
clarification to uid-brainstorming.

http://microformats.org/wiki/uid-brainstorming

> 4. UID/URI that identifies some feature or element of this microformat
> (aditional references)

This is the semantic of the URL property in hCard, hCalendar, and hReview
(URLs for these specs are above).

> As an example, here is an mythical hCoupon that uses ISBN as #3, its own
> UID "vCoupon" as #1, a UID for this particular coupon as #2 (a GUID),
> and URLs to vendors as examples of #4.

<snip>

BTW, if you can find examples of such content being published on the Web,
then the example becomes much more relevant.

If you do find such real world examples, feel free to start the page
coupon-examples and document it there.

http://microformats.org/wiki/coupon-examples

> In thinking about this example, it comes to mind that relying on a
> simple text name like "hCoupon" as the distinguishing name of a
> microformat is a bit dangerous.
> 
> If we are looking at the long picture, across decades and cultures, it
> is easy to see hCoupon being overwritten by somebody or something in a
> particular domain.  For all we know, this could be happening right now.
> vCard is well entrenched, but hCoupon???

We are solving this problem by using profile URLs to define root and
property class names (such as "vcard", "vevent", "hreview", etc.) for
microformats.

> Microformats seem to be of limited use if they can only be applied to
> items that are based on formal standards. I know that a principle of
> microformats is to "reuse building blocks from widely adopted standards"
> but if microformats are going to take off, shouldn't there be a way to
> disambiguate inevitable conflicts?

Profile URLs are there to disambiguate.

And, btw, the conflicts are not inevitable IMHO.  That's part of the
*social* function of microformats.org, and the larger Web as a whole.

10 years ago, two people wanting to do research on a data format for hCoupon
could easily not find each others' work, and invent the same thing twice,
albeit somewhat differently.

At this point, with search engines that index the web reasonably
comprehensively (Google, Yahoo, MSN Search), and those that index the "real
time web" of blogs and other sources up to the minute (Technorati), it is
much easier to *expect* that two people working on a standard who do their
research would at least find each others work on it and thus have much less
excuse to not to collaborate.

> How do microformats scale?

That's a long question, and could do well for some face to face discussion.

In short, they can theoretically scale because of profile URLs.  However,
there is also a desire to keep the overall number of "common" microformats
down to a small set.  Once we have defined microformats for the 80% of
common content publishing needs on the Web, it's not clear if we should do
any more.  We may just decide to stop at that point.

> As microformats gain momentum, won't there be competing microformats?

Only by those that don't wish to interoperate.  For those that do wish to
interoperate, the expectation is that they'll find microformats.org and do
so.

> How does one say "I mean /that/ version of hCoupon"?

XMDP

> Alternatively, who is to say which version of hCoupon is valid?

Multiple versions could be valid.  The community at microformats.org can
hopefully play a role in determining which is preferred by bringing
interested folks together in one place and helping them resolve that
question.

> Who is the registrar?

Currently we have profile URLs at http://gmpg.org/ and http://w3.org/

> In a similar pattern, with XML, you always state the DOCTYPE as the
> first line of the document.
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> 
> By my interpretation that has both a format UID and a locator URI for
> that format.  Shouldn't there be a similar disambiguation for the
> microformat class one is using?

Yep, XMDP profiles solves this for microformats.

Thanks for your questions (several of which should be written up as FAQs
IMHO).

http://microformats.org/wiki/faq

Tantek