W3C home > Mailing lists > Public > uri@w3.org > April 2001

Re: Tag syntax (was Re: Proposal: 'tag' URIs)

From: Sean B. Palmer <sean@mysterylights.com>
Date: Sat, 28 Apr 2001 18:08:13 +0100
Message-ID: <003201c0d005$f1494a60$04dc93c3@z5n9x1>
To: "Tim Kindberg" <timothy@hpl.hp.com>
Cc: <uri@w3.org>
> As Sandro has thanked Michael (which I second), I'd also
> like to thank you for your thoughtful comments.

Well, I really like this idea; I liked it when I first saw the TANN
proposal, and I like it even more now that it has moved onto "tag".
This is an excellent solution to the Semantic Web identification and
vancing problem, and I really can't wait to start implementing it,
which is why I'd like to help as much as possible without getting it
the way [always a danger] :-) There's an odd balance here of getting
it done quickly, and getting it done properly... sometimes if one
dwells upon something too much, it can still end up being "wrong", so
sometimes it's best to go with the gut instinct. For example,
cognitively I prefer "tann:" to "tag:" because of the fact that "tag"
is quite a common word, but I much prefer "tag" to "tann"
phenomically. It just sounds better... "minting a tag". Also, I'd
rather give a concept a "tag" than a "tann": "tag" just sounds right
for the task. It is somewhat unfortunate that the syntactic details of
new URI schemes are always the hang-up.

> Now we can go back to diagreeing....:)

I disagree.

> tag://champignon.net;9/fred
> and
> http://champignon.net:9/fred

Well, if people take tags to be synonymous with HTTP URIs, then they
aren't really understanding the nature of URI schemes. The only thing
that you can deduce from a URI that you do not know the scheme of is
what you can tell from the URI RFC, *not* from how it looks compared
to other URIs; that is a very dangerous practice, IMO. The added value
that you get with the "//" is that the following piece is an
"authority component". Coupled with the fact that ";" indicates a
parameter, you can take tag://champignon.net;9/fred as being comprised
of the following components:-

   "tag://champignon.net;9/fred" is a URI
   "champignon.net;9" is an authority component (ac)
   "champignon.net" and "9" are parameters of the ac

Which is correct, is it not? Any other semantics that people try to
deduce from it will be erroneous. For example, what does:
blargh:TheEiffelTower identify? If you take it as meaning "the Eiffel
Tower in Paris" just by looking at the string, then you are taking an
enormously large gamble - URI strings are fully opaque until you know
their particular semantics by looking at the specification.

> The 'authority' part of such a URI is supposed to be a server
> (emphatically not so in our case) or a 'registry' -- and we're
> never told what semantics that is supposed to have.

In that case, all that one can deduce from the URI RFC is the meaning
of the words "authority component". It seems pretty clear to me that
"champignon.net;1" is a delegation of the authority for this
particular URI. However, you would have to look at the specification
to know that this means "this responsibility for this URI is delegated
to the person or persons who own the domain name champignon.net on the
1st January 2001".

> Is 'champignon.net;1' a 'registry' under some reasonable
> interpretation? No -- a registry is where you store stuff,
> and nothing is stored at champignon.net;1 (except,
> conceptually, a list of all tags minted so far -- so the assignees
> don't accidentally 're-mint' a tag).

I take this as being a slight loophole in the URI RFC in that it does
not fully enumerate a list of authority component types. It does not
say that "server/registry" is a full enumeration (well, it does, but
it doesn't tell us what they *mean*)... one thing about RFCs is that
you can't issue an erratum after you publish it: you have to release
an update, which is never worth it for very small errors.

If anyone asked, I'd suggest that the authority component of the
"tag:" URI scheme is a conceptual registry that is identified by time
and space, rather than a database of information stored on some
computer. Of course, this is one of the major advantages of the "tag:"
URI scheme!

> Formally, tags seem to me to have more in common with URNs
> than with those 'generic URIs': they're designed to be of the form
> tag:nameSpace:specificID, where nameSpace happens to be
> constructed from an existing notion of an authority.

I like the idea of making tags a subset of URNs, because I think of
them as uniquely naming a particular concept, which is what URNs were
set out to do. However, I also think that you'd lose some of the
advantages obtained from making it a stand-alone URI scheme that I
have listed above, in that more of the syntactic details will be
covered by the specification for tags rather than the URI RFC.
Cognitively I'd go with a URN, but instinctively I'd go with a new URI
scheme.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Saturday, 28 April 2001 13:09:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:02 UTC