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

[Bruce D'Arcus]

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.

> > many well-established identifiers are not based on URL. e.g. In a
> > typical library application, we really want to identify the books in
> > Amazon and local catalog are referencing same thing,
>
> Ah, you just introduced a new requirement, and perhaps that is where the
> disconnect is.
>
> You are assuming that we need to design into the format a way to identify
> that two *different* references to a book are the *same* thing.

There are MANY contexts in which there's a need to identify abstract
things, which by definition cannot have fixed locations. That's what
ASIN, ISBN, ISSN, pubmed ID, etc., etc., etc. all do. Books are just
one simple example.

> 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"?

> > 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.

[...snip...]

> > 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.

> > 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?

Bruce