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

[Tantek Ç elik]

On 4/25/06 1:39 PM, "Bruce D'Arcus" <bdarcus.lists at gmail.com> wrote:

> On 4/25/06, Tantek Çelik <tantek at cs.stanford.edu> wrote:
>> On 4/25/06 12:01 PM, "Xiaoming Liu" <liu_x at lanl.gov> wrote:
>> 
>>> First hopefully we all agree on the problem to be addressed here, I think
>>> it is "a microformat for indicating something *is* an identifier", and I
>>> will presume there are three possible solutions: URL, UID, URI.
>>> 
>>> URL is good and I agree we should choose to resolvable URLs if possible.
>>> However URL identifies a resource via a network location, thus limits its
>>> scope,
>> 
>> This isn't a limitation, this is a deliberate preference.  We *want*
>> resources that can be identified by network location and thus a system that
>> shows a bias *for* that is a *good* thing.
>> 
>> In short, it's a feature, not a bug. ;)
> 
> That all depends on the context. In the context that Xiaoming and I
> are talking (where uris are used to identify abstract concepts), I'd
> call it a bug.

Then we'll have to agree to disagree.

We prefer resources that can be identified by location.


>> We don't actually need to solve that problem in the scope of the microformat
>> design. That is something that we may leave up to implementations instead.
>> In other words, I see no reason to solve this problem at the format level.
>> 
>> The requirement that we are looking at is: globally unique, that is, two
>> *different* events/contacts don't end up using the same UID.  That's it.  If
>> the same event in two places uses different UIDs, that is actually ok.
>> That's something that implementations can actually deal with.
> 
> So what we will end up with is that forward-looking people will use
> standardized uris of these sorts, but may call it something else: a
> broader concept called "uid"?

That's fine.  I would expect most UIDs to evolve to be URIs if not URLs.


>>> UID might be good in their original scope (vcard and iCalendar), but I am
>>> afraid it is not sufficient for a wider scope, both semantically and
>>> syntactically.
>> 
>> The original scope was the global exchange of contact and event information.
>> The scope for hCard and hCalendar is the same.  The scope has not changed.
> 
> But you suggested using this in more general contexts, so it's
> perfectly reasonable to raise the question of scope.

Right, but there hasn't been any difference in raised in terms of contacts,
and events, vs. everything else.  Thus IMHO the scope hasn't changed.


>>> similarly, in an "identifier microformat" you may also want to
>>> encourage standard value to be used to allow interoperability. While UID
>>> allows *any* text value, there are good practices of URI schemes and
>>> specifications.
>> 
>> Hence we are suggesting that a good UID is actually a URL, which is an even
>> stronger statement than just URI.
> 
> It may be stronger, but it's problematic in many cases.

Then we postpone those cases and focus on the ones that work now.


>>> I believe the syntax issue is rather important, because without clear
>>> specification, all kinds of things can be stuffed in, therefore defeating
>>> the purpose of interoperability, as illustrated by DOI/ISBN examples in
>>> [1].
>> 
>> It does not defeat the purpose, it merely allows the market to select the
>> better scheme.  Those that use poor identifiers are more often ignored by
>> the market.  We don't need to solve this problem at the format level.
> 
> So then for dates, it's unimportant to say that they must conform
> (when encoded in title attributes) to any standardized date
> representation; just let the market decide?

ISO8601 is fairly well accepted.  The battle is over.  So we pick the
current winner and go with it.

Whereas, as you point out, the market for abstract ids, whether ISBN,
pubmed, or whatever is still churning away, so we let it continue to churn.

Tantek