contexts, graph names and so on

As I will be away from the next three telecoms (back on the 19th) , here are my basic notes on the constraints that apply to using IRIs as graph names/identifiers. 

1. When an IRI is used inside an RDF triple, then the truth of the triple depends on what the IRI denotes, and only on that. If the IRI is being 'used' in some other way (ie other than being a denoting name) for some other purpose, then that is fine, but the truth of any RDF triple containing the IRI is not related in any way to that other thing. 

2. IRIs have global scope. There is no provision in the RDF semantics for a single IRI to denote one thing in one place and a different thing in another place. In particular, the scope of an IRI is not restricted to a single RDF graph. There is no notion of "local context" in RDF. 

3. Naming a graph gives the graph a name, ie imposes a semantic restriction to the effect that the IRI-name of the graph denotes that graph in all interpretations. (That is what "naming" cashes out as in model theory.) It does not affect the meanings of any IRIs which happen to occur inside the graph. It does not create any kind of "local context". 

4. This means that, for example, if a URI ex:fred denoting a person is used as a graph label, then an RDF triple 

ex:fred rdf:type :SpecialGraph .

asserts that Fred, the person, is in this class, not that the labeled graph is. Put less 'semantically': suppose some other graph somewhere (correctly) asserts that 

ex:fred rdf:type :HumanBeing .

then (since the IRI ex:fred has global scope) if these two graphs are both true, then their merge is also true. So it would follow that there is something which is both a HumanBeing and a SpecialGraph:

_:x rdf:type :HumanBeing .
_:x rdf:type :SpecialGraph .

(One might argue that nobody will ever actually make this merged graph so it doesn't matter. However, the semantics doesn't go into that level of pragmatics. The semantic fact is, this would be a valid conclusion to draw, if anyone were to decide to draw it.)

------

All of the above refers to the **current** way that the RDF semantics is defined. We could modify this in various ways, but any of them would be a substantial change to the core semantics of RDF and might have unforseen consequences. 

One way to would be to change (2) to allow a form of punning, ie to explicitly allow IRIs to have several different denotations at the same time (as OWL2 does for  classes being individuals.) This is possible but people might find it to be overkill, and it would complicate all inference rules. (The problem is that in order to draw conclusions one has to be able to tell 'which' meaning is being used in all the different ways an IRI might occur in some expression and be certain that all ambiguities are resolved.)  However, to emphasize, this will be a substantical change to the RDF semantics, requiring a complete re-write of the semantics document and introducing quite a few new ideas. 

Another would be to introduce an explicit notion of context-of-use. This would be essentially a generalization of the SPARQL assumption of a kind of inner space within which the query engine and the RDF store can talk privately, using their own naming conventions, without this poisoning the global use of those names 'externally'. I actually strongly dislike this idea, as it seems to completely undermine the reason for having RDF in the first place, but it could be done.

I did have another thought, arising from Dan B's email of a couple of weeks ago, but I will put that in another thread as it might not be directly relevant.

Pat

PS. BTW, apologies to the WG for my having been rather inattentive to emails and other things for a few weeks., I have been rather ill for a while and not firing on all cylinders. Better now.  

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 2 November 2011 17:07:32 UTC