Summary: Recapping some issues for Chimezie - may not be of interest
to those who have been following the discussion already.
Bottom line: If you are interested in URI issues, please talk to
Jonathan Rees who is responsible for editing the recommendations
documents that we (HCLS) have agreed to produce. (he tries to keep up
with the list, but doesn't always manage to)
On Aug 6, 2007, at 9:08 AM, Chimezie Ogbuji wrote:
On Sun, 2007-08-05 at 01:25 -0400, Alan Ruttenberg wrote:
I don't think it is likely that the HCLS recommendations will suggest
using INFO uri's.
Is the 'recommendation' of a particular URI scheme over others on
the agenda? I would hope not. I've yet to understand the
motivation for considering the use of a particular URI scheme over
another as a 'best practice' (the most common such suggestion being
HTTP).
First, I should correct an error that Jonathan pointed out to me -
that an info: scheme URI is not a URN. I don't think that changes the
message though.
Second, the view offered was my own and was perhaps too strongly
stated. But I made it because I saw that recommendations were being
made about decisions related to URIs and because I felt that given
that we have an ongoing activity to work together to come up with
some recommendations, that although we haven't come to a decision
about exactly what the recommendations will say, it certainly is the
case that URI schemes have been part of the discussion. I felt Egon
needed to know about this - I don't know how long he has been
following the list.
I'm quite happy that, as a result of that, you've chimed in,
Chimezie. I'd say that the starting point for the recommendations
will be a set of principles that we agree are important for our
domain (they may be important for other domains, but our scope is
deliberately the hcls community). It may or may not turn out that as
a consequence of these principles we may recommend that certain
schemes not be used, and recommend that others better serve those
principles. Please connect with Jonathan to make sure that he has a
good idea of what you think is important so that the recommendations
can reflect your views.
Note that the recent TAG finding [1] in this regard made a
(guarded) argument for how HTTP schemes can facilitate location
independence, persistence, etc.. This should not be confused for a
recommendation *for* HTTP as the a preferred URI scheme. I would
consider such recommendations as dangerous and perhaps a
misunderstanding of AWWW and the URI mechanism: the fact that the
URI syntax allows for the use of arbitrary URI schemes is a feature
not a bug.
It would be surprising if we misunderstand the AWWW. We've said
before that we think it doesn't do well on a number of issues. That
the possibility that there be other URI schemes, I consider a
feature. However we are talking about a specific use - HCLS/Semantic
Web, and I don't conclude from anything that I've seen that this
makes it obligatory that we are neutral wrt/ schemes. We want to find
something that works well for this community.
They haven't been championed by anyone, urn schemes are generally
discouraged by the W3C TAG,
Where exactly?
I can't find you references right now, as I'm on a plane, but I'll
try to get to get some for you. Certainly in discussions I've had
with them they have discouraged the use of new URN schemes for the
reason I mentioned.
and in our discussions thus far haven't seen any advantages to
using them while noting difficulties.
I don't think URI schemes were meant to be thought of that way (as
mutually exclusive)
Perhaps URI schemes in general were not, but we aren't talking about
URI schemes in general.
Too many URN schemes lead to difficulties on the part of clients,
Not true, especially if the intent of a particular scheme has more
to do with identity management than network resolution (LSIDs are
still useful even without a resolution mechanism, mostly because it
has a very precise identification scheme - non-collidable UUIDs,
etc.).
If you consider LSIDs without resolution then I don't think they have
any value over any other URI scheme. They are simply strings and any
old scheme will do. As an aside, I don't know what you mean about
them having a precise identification scheme (any more so than any
URI) or what you mean by "non-collidable UUIDs". Could you say a bit
more?
Consider that you can perform inference over an RDF graph which
consists of a merge of *both* ABox assertions (and other instance-
level data) and TBox assertions (ontology assertions) without the
need of a resolution mechanism. Being able to build such a merged
graph "on-the-fly" (i.e., "Follow-your-nose") makes such an RDF
Graph Hypertext-Web friendly but this is not a necessary criteria.
I think follow-your-nose is unworkable for the sort of work we mostly
do, but because of the rest of web usage, we have thus far considered
it a goal to enable the sort of discovery that it commonly expected.
Personally, I consider it a matter of courtesy to give people a way
to find out more.
If one is only interested in doing local computation with RDF/OWL,
then the URI scheme doesn't matter - the reasoners don't typically
dereference anything. But we have been assuming that the usage we are
targeting is sharing names of resources and facts about those
resources with a wider community. For this purpose more is required.
The HTTP scheme (as I understand it) is made for the Hypertext-Web,
That is a misunderstanding. The HTTP scheme is explicitly (e.g.
httpRange-14) being recommended for purposes other than for hypertext
- range-14 talks about the fact that some things identified by HTTP
URIs are not information resources.
not every information space maps well to the Hypertext-Web
We're looking for concrete examples of this. If you have any it would
be very helpful if you could share the information.
and for those where resolution is not a necessary component, it is
(a bit) redundant.
I agree that in cases it may be redundant. But it doesn't need to be
expensive and I take the word of web types outside of HCLS that it
would considered quite helpful if it did. Not to mention that if we
expect to do scholarly work in which we use URIs it would be helpful
to be able to publish them and have people find out a little more
about them in the usual way.
which is why there is still a lot of discord about LSIDs,
Most of which seems to follow the tone of the URN Registries finding
Indeed.
(i.e., some of the problems solved by URN schemes can be solved
with the HTTP scheme - once again this should not be confused as
recommendation for a URI scheme monopoly)
I'm still waiting for an example that *can't* be solved using a HTTP
scheme. Do you have any? So far the best I have is that LSIDS point
to two "forks", the data and the metadata (meaning of these not
clear, btw). However I've already given an existence proof, in the
way of a proposed implementation (in another thread on this list)
that can accomplish the same thing.
Hope this commentary is considered helpful. In any case, please do
contact Jonathan so that he can make sure your views are represented.
Regards,
Alan
which are certainly in line before INFOs. Finally, there are
better alternatives.
Just a heads up.
-Alan
[1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html
--
Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
[EMAIL PROTECTED]
===================================
Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2007).
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.
Confidentiality Note: This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law. If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If
you have received this communication in error, please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy. Thank you.
