Re: contexts, graph names and so on

We have several examples:

1/ It is the place (graph container) where the graph came from.  This is 
very common. Yes, it can lead to problems.

2/ It is the name of the graph
   2a/ computed from the location
   2b/ some safely generated IRI [1]

3/ It is the primary topic of the graph
    (This one has come up in the discussions
     I confess I never considered doing that)

4/ Others .... http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC

The reality is that this is our starting point - different uses of the 
4th slot exist.  A proposal is not going to get consensus that means 
change to the existing practice.  Indeed, I think there is a good chance 
the community will by and large ignore any proposal that invalidates 
common practice such as (1).

(2) may be ideal but the overhead to use it for (1) is significant; 
that's why people cut straight to (1).

The issue is, for me, how to do this is a principled way. Pat's 1-3 are 
principles of IRIs and should work.

[2] (telecon item) touches on a minimal model, and documenting best 
practice.

[3] (wiki proposal, RDFdatasets) is a way to do this.  It says nothing 
semantically about the relationship of 4th slot and the graph.

-------------------------

Indirection:

:g { :s :p :o }

:g ---> X ---> graph

:g is related to something and something is related to the graph

X can be the graph name, and the X--->graph is "denotes"

":g ---> X" is the step from 4th slot to graph name. Call this g2x; it's 
a property; it is different for different RDF datasets.

It might be "GETt'ed from" (in which case we have (1) above; it's 
similar to log:semantics except the object is a resource, not a graph 
literal).

Ideally, it would be written down somewhere what g2x is.

One place is in the default graph of the datasets, using it as a place 
to keep a manifest of the (iri,G) pairs. ("In-Band" in [4])

Another place is with the VoID description of the dataset.  This 
includes in the SPARQL service description. ("Out-of-Band" in [4])

Pat-1 is a way to trip up; using the IRI used in the 4th slot in a 
triple which actually needs either the property of the triple to be 
defined to take the indirection into account.  This is where the "local 
context" needs to slip in.

	Andy

[1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0148.html
[2] 
http://www.w3.org/2011/rdf-wg/wiki/Meetings:Telecon2011.11.02#Named_Graph_issues
[3] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
[4] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Options#Loose_Association

On 02/11/11 17:04, Pat Hayes wrote:
 > 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.
 >

Received on Thursday, 3 November 2011 16:27:15 UTC