Re: CURIEs: A proposal

>      Just to clarify, to me Roy seems to be saying that "all URIs *can*
>become dereferencable (although perhaps in a nonstandard manner) - which
>is true,

True, but vacuous. Compare to: any word *could* be made into a large 
bronze casting and mounted on the side of a building. Therefore, 
linguistics is best conducted in a metal foundry.

>  but then is following it up with saying that any _Web
>architectural knowledge_ encoded in a scheme *should* be dereferencable.
>
>>>  All URI schemes become dereferenceable as soon
>>>  as someone can map any representation associated with the resource to
>>>  a mechanism that accepts a string and returns a representation.
>>>  That doesn't change the principle that namespace names should be
>>>  dereferenceable *because* Web architectural knowledge should be
>>>  grounded in the Web.
>Given the fact that any scheme *can* become capable of dereference, it
>makes little sense to argue that namespace names of anything should use
>a scheme whose purported advantage (like URN) is their
>non-dereferencability. Instead, given that one can dereference anything
>in theory, one should at least use a URI with a dereferencing mechanism
>that is standardized and widely deployed *in practice* like http.   By
>underlining "Web architectural knowledge" - anything that's important to
>the Web as a whole, like MIME types,  should obey the informal "Follow
>Your Nose" principle and have its description be found on the Web, not
>just in say, a book somewhere or a spec with no connection to a URN :)
>That's sensible.

Well, its the most sensible idea, *given* that the URI has to be 
dereferenceable to *something* But maybe they shouldnt all be. The 
most sensible rule, seems to me, is that the names used in ontologies 
shouldnt even be required to be dereferenceable; or if they just are, 
because they are URIs, then what they dereference to should be 
assumed to be irrelevant to their meaning and use, unless there is 
good reason to think otherwise (eg as in an owl:imports, or if when 
you dereference it you find something that tells you unambiguously 
what the intended referent is, using some yet-to-be-invented Web 
protocol for saying what names refer to, e.g. a named RDF graph.) 
What they mean is determined by the totality of assertions that are 
made using them, and there is no way to access all of that by any 
kind of dereferencing. The idea that a single URI can locate an 
'authoritative' or 'defining' piece of (say) OWL or RDF which is the 
single best source for what the URI means, is unsupported by any of 
the SW specs, false in many widely deployed cases (FOAF, Dublin 
Core), at odds with the open nature of the Web, and IMO harmful.

>  >   Similarly, most of the uses of URIreferences in semantic web
>>  formalizations are at best tangential to this principle, since their
>>  intended Web functionality has nothing to do with dereferencing, and
>>  allowing them to be dereferenced has only produced difficulties and
>>  controversy, and adds nothing to their utility
>Pat and Noah are correct here - turning into a rule instead of good
>practice would be overkill, as URIs are often used for names without an
>obvious dereferencing function. The question is - if one had a a
>namespace URI or a SemWeb URI, and did dereference *something* at the
>end of it, does this help?

Im sure it can often help, but a problem arises when someone insists 
that there *must* be something there, because there are going to be 
many cases where it is hard to impossible to provide anything useful, 
so what will be provided will in fact not be useful, but providing it 
will nevertheless absorb a lot of effort, the cost of which is a 
brake on development and deployment.

>Re the SemWeb, right now it does seem to be
>causing more trouble and confusion than good, but we recently put a
>workshop on to see if anything good could come out of this, and Pat has
>some interesting slides, as well as Steve Pepper available from the
>website [1].
>
>There is a cost-benefit trade-off function when dealing with creating
>representations for the numbers of Semantic Web URIs and namespace
>documents, and part of the whole problem is that there's no clear
>standard for best practice for namespace documents or what a Semantic
>Web URI could return, much less tools to make the creation of such
>things trivial as to make the benefit higher than the cost.

Exactly. And it seems to me that even the idea that there has to be a 
'practice' here is often a source of needless cost.

>  > Why 'must' this 'principle' be stated or even used?
>It helps  to make the Web be "self-describing", although the notion of
>"self-describing" is something I think is another notion that could
>really use some inspection.

I'd sure like know what it means, myself :-)  Can you elaborate?

Pat

>
>[1] http://www.ibiblio.org/hhalpin/irw2006/
>
>--
>		-harry
>
>Harry Halpin,  University of Edinburgh
>http://www.ibiblio.org/hhalpin 6B522426


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 27 June 2006 22:08:58 UTC