Re: ISSUE-58: Scalability of URI Access to Resources

>Pat, thanks for calling out this overlap with the ongoing discussion.
>One point of clarification is *all* the discussion in that particular
>thread has to do with RDF URIs specifically.

True, but the RDF specs don't distinguish between RDF URIs and other 
URIs, which is why I thought there might be an overlap. HTTP-range-14 
also rears its head, of course...

>  The difference may be a
>little more than subtle, considering ISSUE-58 and the URNs Namesapces
>and Registries finding address URIs in general and not URIs in RDF
>specifically .
>
>The concerns (as I see it) have more to do with automated machine
>interaction and not human interation.

But even in RDF, many people expect that URIs will deliver some 
human-readable information when asked to do so. And issues like 
uniqueness or canonicity of URIs as resource names take on extra 
urgency in some RDF-like contexts. I know both the TAG and the specs 
all say that URIs aren't canonical names,. but many communities want 
to use them this way; or at any rate, if they can't use them this 
way, they want to use something else that can be so used.

All these issues seem interrelated in ways that I cannot myself 
articulate. Good luck :-)

Pat

>  It dips into both the URNs
>Namespaces and Registries finding as well as with ISSUE-58.  The key
>point which links the two is the suggestion that (even when used
>within RDF graphs) HTTP URIs should be preferred generally.  Below are
>my comments to Norm's response:
>
>1. http: != dereference
>
>Yes, this is very clearly stated in the URNs Namespaces and Registries
>finding.  However, we cannot have our cake and eat it too.
>Specifically, there seems to be a bit of a conflict with: 1) The
>prominent suggestion that HTTP URIs should be used pervasively, 2) The
>equally prominent suggestion that it is a good idea to provide
>representations for these URIs, 3) ISSUE-58 and 4) The 'qualifier'
>above that the use of the HTTP scheme does not mandate dereference.
>
>As Noah suggests, the qualifier can be interpreted by the author as a
>suggestion that providing representations is not necessary.  In
>addition, it can be interpreted by the consumer as a suggestion to not
>bother attempting to (arbitrarily) dereference these URIs (many
>don't).  If a little bit of ambiguity was the only price being paid,
>it wouldn't be much of a concern, however, ISSUE-58 clearly identifies
>the cost as much more than ambiguity alone.
>
>I believe the appropriate recommendation, guideline, etc.. would be
>one which includes a clearly articulated set of scenarios which
>demonstrate when 'arbitrary' HTTP dereference (though not mandated) is
>useful for automatons/agents and when it might not be so useful (XML
>namespaces, for example).
>
>2. The dereference problem is scheme independent
>
>The second part of this particular point assumes there will
>*inevitabely* be a need to dereference these (insert your favorite
>other scheme here) URIs.  This is not always true, especially when the
>URIs in question are RDF URIs.  RDF URIs and their use have a
>model-theoretic mechanism for making claims about the world.  In most
>cases, these claims (very mathematical in nature) are meant to be much
>more authoritative than what representation you might get from
>dereferencing the URIs themselves especially when the claims are
>subject to much more fine-grained constraints through the use of a
>formal (OWL) ontology.
>
>The only caveat might be where the representations retrieved describe
>the very OWL ontologies which capture these constraints.  In this
>case, and with ISSUE-58, as a backdrop it would seem prudent to review
>current practice in this regard or (perhaps) suggest some best
>practices.  However, again this is specific to RDF and ISSUE-58
>applies to all usage of URIs.  RDF URIs have a different usage pattern
>than the typical Web scenario and the literature should consider this
>divergence.
>
>In addition, the dereference problem is not entirely scheme
>independent.  Actually, it *only* applies to those URI schemes which
>are (formally) associated with a transport protocol (ironically, the
>same scheme(s) which are the subject of suggestion for their pervasive
>use).
>
>-- Chimezie


-- 
---------------------------------------------------------------------
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 Wednesday, 22 August 2007 21:58:46 UTC