W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

Re: [ratholes, reification, risk] poison-URIref testcases

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 3 Apr 2002 13:40:07 -0600
Message-Id: <p05101513b8d1063ee147@[65.217.30.94]>
To: Dan Brickley <danbri@w3.org>
Cc: w3c-rdfcore-wg@w3.org
>On Mon, 25 Mar 2002, Graham Klyne wrote:
>
>>  At 12:29 PM 3/25/02 +0000, Jan Grant wrote:
>>  >This is, surprise, going down a rathole fast, so this is my last pulic
>>  >post on the topic...
>
>don't say I didn't warn you :-/
>
>I don't want to slow down RDF Core process, but do want to get to the
>bottom of this. Maybe www-rdf-interest or -logic unless we suddenly all
>agree on something?
>
>Any further discussion here should probably be couched in terms of
>proposed changes to our Working Draft text, and associated with an open
>issue. The closest I can find in the Issue Tracking document is
>http://www.w3.org/2000/03/rdf-tracking/#rdfms-assertion
>
>See below for a draft addition to the MT spec.
>
>>  >A better bet (I think) is to just do something Herbrandish - that is,
>>  >keep the current definition of "interpretation"; if you _do_ wind up
>>  >with one of Dan's problematical graphs (that is, one with a URI-labelled
>>  >node with no "meaning", ie, which doesn't denote anything*), you don't
>>  >really hurt yourself by letting it denote some mathematical figment that
>>  >doesn't collide with anything else.
>>
>>  That sounds very like what I was trying to say.
>
>I think we have some notion of a "Web-sanctioned interpretation"
>underlying our thought on this. There are certainly
>interpretations (alice-in-wonderland ones, for eg.) where poison-URIs
>denote. The concern is that there may be no Web-sanctioned ones, ie.
>when we buy into the global meaning of the urirefs, we waive our
>right to make up arbitrary mappings. The MT does acknowledge that
>urirefs have global meaning imposed by our shared Web understanding
>of these node labels.

Does that W-si idea amount to something more than a vanilla 
interpretation of (possibly hypothetical) merge of all the 
information on the Web (about the concept in question, maybe) ? Or is 
it an entirely different kind of thing altogether?

For example, consider a URL. As far as RDF is concerned it is simply 
an identifier, but the Web uses it as global file locator. Which of 
these is the 'global meaning' ?

>
>I would be happy with the Herbrandish workaround, so long as there
>could be Web-sanctioned interpretations of a 'poisoned' graph. The
>Web-sanctioned interpretations of a graph, as I introduce the phrase,
>are those that are respectful of the public meaning of each uriref.
>For those, we must defer to specs beyond RDF's (eg. URI2396, TAG work
>etc.).
>
>There are perhaps 'hybrid' interpretations in which 'good' URIs denote
>things in the world (fixed by Web/TAG conventions for meaning of urirefs

Are there any such conventions for fixing the worldly referents of 
uris? I would be amazed to find any. I don't really see how there 
could be any, or how they could be stated if there were any.

>), while
>'poison' ones denote (some figment of our choice). I'm nor sure that
>is a very clear partition, since it is those same Web/TAG/2396 conventions
>that determine whether a uriref has public meaning. It might be good enough.
>Below is an attempt at characterising such a 'hybrid' interpretation
>(without imposing it). I don't think the MT can go any further than that.
>
>We should be wary of trying to make the MT do work that MTs aren't
>designed for. But we should also be wary of leaving a gap in our account
>of the meaning of RDF/XML documents.
>
>Does the following work for anyone?

Not for me. I'd rather not get into this territory at all, except 
maybe to put up warning flags.

>
>[[
>Note: urirefs, as referring expressions, have their meaning fixed through
>a number of social, legal and technical mechanisms. The RDF MT does not
>itself impose any particular interpretation on an RDF graph. An
>interpretation for an RDF graph in which the denotation of uriref labels
>is fixed by the public meaning of urirefs is termed a <em>Web-sanctioned
>interpretation</em>. It is beyond the scope of the MT to provide a
>detailed discussion of Web-sanctioned interpretations.

Damn right :-)

>At this time, it is
>not clear whether the Web's use of uriref identifier syntax allows us to
>assume that all urirefs denote. We do not know whether the Web
>architecture guarantees that every RDF graph has a <em>Web-sanctioned
>satisfying interpretation</em>.

Well, any RDF graph, no matter how large (it can even be infinite), 
does have a satisfying interpretation, so...

>  An interpretation for an RDF graph in
>which the denotation of uriref labels is fixed by the public meaning of
>urirefs, augmented by the assumption that each uriref denotes, is termed
>an <em>augmented Web-sanctioned interpretation</em>. This notion
>allows us to discuss the ascription of propositional content to RDF graphs
>that contain nodes and edges labeled with urirefs, without concern for
>whether a public ("Web") meaning is assigned for each uriref. 
>Without making this
>additional assumption, there may be RDF graphs whose (publically
>meaningless) uriref labels ensure that there are no satisfying
><em>Web-sanctioned</em> interpretions for the graph, because nodes are
>labeled with non-referring urirefs. This notion is particularly relevant
>to Web applications that exchange RDF graphs employing the RDF Core
>reification vocabulary (ie. Statement/predicate/subject/object)
>since nodes will often be labelled with uriref data from untrusted
>sources.
>]]
>
>Or we could leave this for version 2... I was just trying to draft a
>'health warning' flag to stick outside the rathole... (and something we
>could point the TAG or URI CG at).
>
>Dan


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 3 April 2002 14:40:08 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:47:20 EDT