Thanks for pointing me that out. It’s interesting to see that there is an effort in that direction.

I scanned the brainstorming page and found this question from Xiaoming:

“Xiaoming proposed leaving UID intact in hcalendar and hcard, because whatever written in rfc2426/rfc2445 and their examples cannot be easily changed, and they seem to work well with hcalendar/hcard. Instead a new “URI” microformat should be established for the purpose of indicating something *is* an identifier in general.In this case you can easily reference URI RFC and no further elaboration about persistence, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.

and the answer from Tantek:

“The problem with “just use URI” 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. Thanks to Joe Andrieu for asking the questions which lead to this clarification. – Tantek”

Would it be possible to clarify Tantek’s answer? In my humble opinion, if a URI is a *type* or data, a UID is one too. There is probably a little semantic difference between the two (in fact could you redirect me to your definition of a UID (in microformats?)?)

If I check the “Uniform Resource Identifier (URI): Generic Syntax” document, I can read:

”A URI is an identifier consisting of a sequence of characters matching the syntax rule named in Section 3. It enables uniform identification of resources via a separately defined extensible set of naming schemes (Section 3.1). How that identification is accomplished, assigned, or enabled is delegated to each scheme specification.”

Do you agree that a microformat instance is a resource? In that case, why not using URI to identify them?

Thanks for clarifying that point because my mind is a little bit confuse.

Take care,

Salutations,

Fred

Certainly I can. I’ll illustrate it with two examples:

1- I would like to do a review (using hReview) of a book. I would like to give it a URI such as anyone who talk-about/review it could refer to the same book. I would also like to refer to a place where I could buy it: on Amazon.com for example. But one could like Amazon, but another one could like B&B, so the URL to the book’s Amazon page is not a good unique identifier. The perfect URI to refer to a book would be: “isbn:140190131X” that is a valid URI and not a HTTP URL.

2- As I said, I could want to use the URL property of the hCard to describe my new personal website. But what happen is, for example, my old personal website was “frederickgiasson.com” and that I change it for “fgiasson.com” 5 years later. What I would like to do is changing the URL in my hCard profile for “fgiasson.com” but I would like to use “frederickgiasson.com” as the URI that refer to me. That way, all the stuff a produce that describe that resource (me) will continue, over time, in a consistent way.

Are these two examples convincing enough to show how URIs describing resources are essentials in my point of view?

Salutations,

Fred

Your first comment: you got it right, I totally forgot that little detail that change everything

Your second comment: yes, you are right, however the problem is that a URL is a URI but a URI is not a URL. So, what happen is I don’t want to use a URL as a URI? Or what happen is I want to use the URL field with a URL but describe the resource with another URI? This is the problem I see.

Thanks for your comments!

Salutations,

Fred

If you’d look a bit closer, you’d find that a number of microformats have URLs associated with them. hCards can have URLs, hReviews can review URLs or people who have URLs, hCalendar events can have URLs, etc.

I performed a search on the microformat Wiki with the term “URI”: 0 results.

That’s acutally a MySQL thing – it won’t do fulltext matches on words less than 4 characters long.