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

[Tantek Ç elik]

On 4/24/06 7:56 PM, "Etan Wexler" <ewexler at stickdog.com> wrote:

>> Third, I actually see disadvantages in using URIs as a basic unit rather
>> than URLs.
> 
> All URLs are URIs. What have I missed?

The opposite.  The fact that not all URIs are URLs.  That's the point.  You
can infer things about a URL in general that you can't necessarily infer
about a URI in general.

>> Thus as a pattern we should use URLs in microformats, not URIs.
> 
> If you mean that we should use URIs with authoritative
> location/retrieval semantics, I agree. If you mean that we should use
> URIs whose location/retrieval semantics include broad network
> accessibility, I agree. Goodbye, ³file² scheme! Goodbye, ³tag² scheme!

Yes.  That is more precision which I agree with.


>> OTOH, an opaque UID which asserts nothing but "globally unique identifier"
>> (see above) is both quite simple, and much more "backwards compatible" with
>> use of UID in vCard/iCalendar applications today.
> 
> How are people publishing ³UID² properties in vCards today?

The problem hasn't been with people publishing UID properties, the problem
has been with applications consuming them.

Thus that has spurred some folks to want to publish them, and ask for advice
for how to do so.

The closest thing to UIDs that current publishers of hCards are publishing
are their unique URLs within their sites (e.g. Upcoming and Eventful venues
and events).

Thus my proposal essentially allows these publishers to reuse what they are
already doing (going to the effort of picking unique permalinkable URLs for
each instance of contact info or event), as UIDs so that consuming
applications that depend on such info can have it.

Tantek