W3C home > Mailing lists > Public > www-archive@w3.org > March 2004

Re: Named graphs etc

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 10 Mar 2004 10:22:39 -0600
Message-Id: <p06001f3cbc74ee6a9c7e@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: "Pat Hayes" <phayes@ihmc.us>, <www-archive@w3.org>, <chris@bizer.de>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>

>On Mar 09, 2004, at 18:43, ext Jeremy Carroll wrote:
>>A few comments ...
>>>>Publication of a graph, or an RDF/XML instance, should not equate to
>>>I don't think that follows. And in any case, its too late to try to
>>>change this now, seems to me.
>>Some published RDF/XML docs are asserted, some are not (e.g. WG test cases).
>>We dropped the sections of RDF Concepts that presumed that
>>publishing=asserting, partly because there was no consensus.
>OK. Good. I wasn't hallucinating in my recollections.
>Given the latest discussions, I'm more of the opinion that publishing
>an RDF/XML instance should not be presumed to equate to asserting the
>graph it serializes.
>Either there should be a bootstrapping vocabulary (easier to introduce
>since it's disjunct from the existing specs) or some attribute on the
><rdf:RDF> element to explicitly define assertion.

Or something. I really don't see how this can possibly be done just 
by using vocabulary, however. (What gets that vocabulary asserted?? 
If we stipulate this semantically by saying that the vocabulary is 
self-asserting, then we are going outside the RDF spec in any case.)

>Some applications may wish to presume that graph serialized in
>some RDF/XMl instance is asserted, but social liability will
>most likely depend on explicit statements of assertion (similar
>to "uttering a statement" which is subject to debate whether
>the statement was asserted versus "making a statement under oath"
>where the contextual "machinery" makes it clear that the statement
>was in fact asserted).
>>>Asserting isn't a kind of logical sentence, it's a speech act. It
>>>stands outside the logical semantics.
>>English works both to carry content and speech acts, I think the suggestion
>>is that RDF can carry its own speech act status,
>>and the bootstrapping is in
>>the user perceptions (the trust layer).
>If we consider that trust layer grounded in a specialized bootstrapping
>vocabulary, or alternatively, special attributes in the serialization,
>then I agree.
>One other benefit to the vocabulary approach is that it is independent
>of serialization, thus it is immediately usable with RDF/XML, N3, Turtle,
>TriX, all the various query expression dialects, etc.

True, good point. I tend to forget about them, I have to admit.

>The tricky part (or maybe it's easy) and what I'd like Pat to comment
>on is how hard (or even possible) it is to constrain the interpretation
>of a particular property to the graph in which the statement occurs.

That can be done, though it requires tweaking the MT in 
unconventional ways. I did this for the OWL imports vocabulary but 
the WG decided that it was too complicated and 'weird' to put in the 
spec, so they gave it an 'operational'  spec outside the MT.

But I really don't think we should do this. Allowing a graph to 
assert another graph is potentially very useful and natural. Don't 
think of 'being asserted' as a property of graphs: think of it as a 
relationship between something and a graph. If I assert your graph, I 
havnt done anything to you or your graph except borrow your RDF. I 
could have gotten the same effect by importing your graph into a 
blank one of mine and then asserting it.

Also the real semantic issues are the one on how to get asserting 
done at all, which can't be done in ANY truth-functional model theory 
(since it doesn't talk about asserting, only about truth)

>I.e. given some special property (partially) defined as follows:
>    x:specialProperty rdfs:domain x:Graph .
>    x:specialProperty rdf:type x:GraphQualificationProperty .
>Then both of the following graphs are valid
>:G { :G x:specialProperty ?object . }
>:H { x:thisGraph x:specialProperty ?object . }
>the first because the subject of the statement is the same graph
>as that containing the statement, and the second because the
>subject automatically denotes the graph containing the statement
>yet the statement in the following graph
>:K { :G x:specialProperty ?object . }
>has no interpretation because (a) the subject of the statement is
>not the same graph as the graph containing the statement, and (b)
>no equivalence (owl:sameAs) can be determined based on statements
>in the graph itself.
>I.e., the interpretation of any member of x:GraphQualificationProperty
>is made against the graph itself, irrespective of any other statements
>in any other graph -- and any statements made about any other graph
>using such a property simply have no interpretation.
>If, however, we had the graph
>:K { :G x:specialProperty ?object . :G owl:sameAs :K }
>or the graph
>:K { :G x:specialProperty ?object . :G owl:sameAs x:thisGraph }
>then the statement would be valid and have an interpretation
>in terms of the graph in which it occurs. But
>:K { :G x:specialProperty ?object . }
>:W { :G owl:sameAs :K }
>doesn't make the statement in graph :K have any interpretation
>because the interpretation of any x:GraphQualificationProperty
>is limited to the particular graph alone in which it occurs.
>It's a little more complicated than an XML attribute, but has
>that great advantage of being immediately compatible with all
>RDF serializations

It might be syntactically compatible, but it plays hell with the 
semantics (though we could fudge round that in an acceptable way, to 
be honest). And it still requires that the published documents be 
edited: whereas allowing A to assert B means that we can get existing 
graphs asserted without changing them at all.


>(and no'one can really expect any changes
>to RDF/XML, N3, etc. just to experiment with this stuff...)
>Patrick Stickler
>Nokia, Finland

IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 10 March 2004 11:22:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:25 UTC