dereferenceability (was Re: Announcement: The "info" URI Scheme)

> I heard you say that tag: might be not a good idea becouse it puts
> metadata inside an uri (a date for example or the email)

Hm.  If I said anything like that, I misspoke and I'm sorry.  My only
objection to tag: URIs is that they are not dereferenceable.  And when
I'm living on the same planet as Tim Bray, which is most of the time,
I think it's silly to use any URI which is not dereferenceable.

That's really a key point.  With tag: URIs, unlike with HTTP URIs,
there is no right or wrong answer about what content might be
returned, if anything, if you attempt some sort of retrieval operation
don't give any additional context.  It just names something; it
doesn't name something as as seen a particular way.

I think the URN Working Group thought of URNs as being
dereferenceable.  Leslie Daigle and Mike Mealling, as I recall, had an
"ah-ha!" moment about tag: URIs when Tim Kindberg and I made the point
that they are, by definition, not dereferenceable.  I think it was at
that point that they agreed tags should NOT be urn:tag:.

I think the doi: folks imagine doi: URIs to be dererenceable.  I think
the info: folks imagine info: URIs to, like tag: URIs, *NOT* be
referenceable.  Am I right?

The test case here is simple.  If you heard about two users who
entered the same URI into their super-modern browsers and one got a
page which said some meeting was in October and the other got a page
saying it was in November, would you think some computer systems was
acting badly or would you think that someone had published an
incorrect page?  With non-dereferenceable URIs like tags, it's like
asking Google: even when the computers are working perfectly, you can
get very different answers if people have told the computer different
things.  So with non-dereferenceable URIs, determining which answer is
right is not about following the RFCs and using URI itself correctly;
you need other mechanisms.

    -- sandro

Received on Friday, 3 October 2003 12:05:44 UTC