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

On 8/28/07, Williams, Stuart (HP Labs, Bristol) <skw@hp.com> wrote:
> Hello Chimezie,
>
> Probably  couple of obtuse questions...
>
> - How do "RDF URI" differ from URI in general?

I tried to cover some of this in the following Wiki:
http://esw.w3.org/topic/RDFSemiotics

This is mostly a rehash from http://www.w3.org/TR/rdf-mt/ (so I hope
Pat will slap me on the hand when I'm chatting rubbish), but
generally, RDF URIs are 'symbols' which denote things in an
interpretation (a 'theory').  The expressions in which the RDF URIs
are used describe a set of conditions that must be met to satisfy the
interpretation.  The end-game (goal, if you wish) is "to provide a
technical way to determine when inference processes are valid, i.e.
when they preserve truth."

The main difference is that the domain of discourse is a superset of
what Web architecture is primarily concerned with: information
resources and their representations.  Whereas in a model-theoretic
language, the 'semantics' are determined from the expressions which
make use of the RDF URIs, Web architecture is (or it seems that way
from the specific best practices in AWWW) primary concerned with the
consumption of information resources to meet a different goal: a user
browsing a page, or a web crawler browsing pages to create indices for
subsequent searching.

In addition, outside of the consumption of information resources,
there is no 'formal' mechanism to follow to 'interpret' or infer
'meaning' from web resources (other than specific representation
formats - which are primarily concerned with syntax not 'semantics' )

> - How would a recognise that a given URI is an "RDF URI"?

By the context of its use.
http://metacognition.info/profile/webwho.xrdf#chime is the URI I've
'minted' to represent me.  When used as a link in an HTML document, it
is simply a (typed) link to my FOAF document.  When parsed by an RDF
'agent' - from that FOAF (RDF) document - it is understood to 'denote'
Chimezie Ogbuji (me).  So, the expressions which make use of this URI
are the constraints which apply in order to meet the interpretation
expressed in that FOAF graph.

>
> 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 18:21:20 UTC