Re: The <id> element

["Sean B. Palmer" <sean@xxxxxxxxxxxxxxxxx>]

[On "tag:" URIs; BCC'd to Sandro and TimK.]

> > won't be picked up until a) sandro or TimK have
> > the time and motivation to pick it up again
>
> Do you think this is going to happen anytime soon?

Given that the last draft was submitted in 2002-10 and that Sandro at
least feels little personal motivation for having tag: URIs anymore,
I'd say it's unlikely. I haven't heard from TimK about it in months or
years.

> Doesn't the members of this list have (time and)
> motivation to pick it up?

I'm not sure what the IESG issues were, so it's not possible for me to
answer that question.

Sandro, Tim: what are the issues keeping it back?

[and now for the permathread URI issues...]

> > HTTP URIs probably make for good enough IDs.
>
> The problem with URIs are that they too often get
> confused with URLs, [...] When people see a URL
> (or a URI that looks like a URL), they have an
> undescribable urge to plunge it into a browser.

URLs are a subset of URIs. As far as I know, the definition of a URL
is, loosely, any URI that is tightly coupled to a resolution protocol
in common social convention. So I presume that you're saying that if
you use an easily resolvable URI as an ID, people will start resolving
it? Then the questions are: for what purpose(s) will they resolve it?
Will applications break if the resolution returns a Not Found?

Which feeds nicely into link vs. id...

> if <id> is a URL, we don't need <link>.

[For anyone just entering into this: see PostIdAndPermaLinkRequired
and EntryIdentifier on the Atom wiki first.]

I don't buy the overlap argument: if you're publishing the same
article at /science/entry and /technology/entry, I think that using
/science/entry for the ID and then having /science/entry and
/technology/entry as <link>s or <also-at>s is fine. But if you really
feel that the context difference between the two is a problem, give it
another uri, /all-entries/entry, and use that as the ID.

When it comes to names and addresses, I'm (currently) a pragmatist. I
believe that having a name (<id>, PUBLIC, URNs) and a link (<link>,
SYSTEM, URLs) is almost always redundant. So I think that there MUST
be one canonical id for an entry which is a URI that SHOULD be
resolvable [1], and there MAY be optional extra references to the same
content.

Cheers,

[1] Tightly bound to a resolution protocol.

--
Sean B. Palmer, <http://purl.org/net/sbp/>
"phenomicity by the bucketful" - http://miscoranda.com/