On Aug 18, 2007, at 4:02 AM, Booth, David (HP Software - Boston) wrote:
From: Bijan Parsia
On 9 Aug 2007, at 10:32, Xiaoshu Wang wrote:
[ . . . ]
What kind of difference does it
make to an agent for the following two resources.
a) http://404/a/b/c - returns a 404
b) lsid:404:a:b:c - non-dereferenciable
Clearly it marks a difference in intent. It allows me, the term
coiner, to communicate the fact that I don't intend for you to find
information directly by GETting that uri [ . . . ]
If you never intend to make your URI dereferenceable then there
certainly is no point in making it an http URI. You might as well
use a
non-dereferenceable URN.
Please note that in the above exchange, IIRC, we were merely
discussing whether there *was* a difference (to an agent) between a
404 and a non-dereferanceable one.
However, the purpose of this discussion is to come up with community
recommendations on minting URIs.
Sure. But there's a bit of a leap from "Use StudlyCaps in your local
names for classes" and "Set up a web server before making up any
names". Recommendations that 1) vary widely from reasonable practice
and 2) cost effort are generally idle recommendations.
As such:
- They will be recommendations, not requirements.
Yes, but you want them to have uptake :)
- They should be designed to best benefit the community as a whole.
That's tendencious. (Do you mean as summed? on average? with a high
median? or some sort of qualitative notion? Are you trying to grow
the community? or make its overall costs lower? or...)
It seems clear that any such recommendations should be designed to
best
facilitate the publication and re-use of URIs by others,
This is one benefit. The other is to make them easy to mint. Naming
is hard.
and making URIs
dereferenceable to useful metadata is certainly one convenient way to
help do so.
Really? The point of these examples is that there are a variety of
cases which for a variety of reasons it's not so convenient
(actually, either for the minter or the discoverer). So the
recommendation can say, "When its convenient and helpful, use http
uris, otherwise, don't" But that's not so great a recommendation.
In short, I think your example has nicely illustrated the fact that a
particular URI owner could still have good (or bad) reasons *not* to
make its URIs dereferenceable, and hence may choose to use URNs.
And presumably there are good and bad ways to do that.
That
is its prerogative. But that does not mean that our *recommendations*
should encourage such practice.
Why not, if the good reasons out weight the bad? I mean, what more
would that be than saying, "eww, if you have to for a variety of
excellent reasons not be in our HTTP club, well, ok, but you're still
ICKY"?
That's not super community building :)
Presumably there's things people can do which will make their URNs or
non-dereferencable URIs more or less accessible for reuse. Publishing
a term index at an HTTP dereferencable URI is just one example.
Cheers,
Bijan.
