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

Hello Chimezie,

Probably  couple of obtuse questions... 

- How do "RDF URI" differ from URI in general? 
- How would a recognise that a given URI is an "RDF URI"? 

Thanks,

Stuart Williams
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Chimezie Ogbuji
> Sent: 22 August 2007 22:27
> To: www-tag@w3.org
> Subject: 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.  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.  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
> 
>

Received on Tuesday, 28 August 2007 14:46:30 UTC