Re: Are you planning to use the Dataset Semantics?

Sorry, a correction, at ***:

On Sep 26, 2012, at 2:19 PM, Pat Hayes wrote:

> 
> The basic tension we have is between two (maybe three, but lets leave http aside for now) different notions of what it means for a URI be a 'name'. The semantic idea is that naming is denotation, and RDF content is normatively required to respect this. Existing dataset use-pragmatics, however, often distinguishes graph/name pairing in a dataset from denotation, which makes everything more complicated, as we now have two different notions of what a URI might be understood to refer to, so URIs have become systematically ambiguous. We need some way to resolve this ambiguity: when I see a URI in some RDF, and that URI denotes (say) a time-interval directly, but is linked to a graph in a dataset, is this occurrence of the URI supposed to refer to the time or to the graph? How can I tell? There are several possible ways we might answer this, and it seems to me that we still have not decided on an answer to this question, which is the most fundamental of them all. 
> 
> 1. If the containing RDF is labelled "metadata" in some way, or is located in a special place reserved for metadata (eg the default graph?), then the URI refers to the graph; otherwise it refers to the time. This could be done purely pragmatically (Sandro's recent emails) or more formally, eg based on the graph-extension construction in the "minimal" semantics. 

> ***(A potential problem with this is that the diambiguation applies to a whole RDF graph, so it rules out using the same URI to refer to the graph in some triples but to the time (or whatever) in other triples in the same graph. I can see why this might be an issue. The second idea allows finer-grained distinctions.)
> 
> 2. If the triple in which the URI occurs has a property which is from a "metadata" namespace, then it refers to the graph, otherwise it refers to the time. 
> 
> 3. If the URI is asserted to be a graph, then it refers to the graph and only the graph, i.e. it is not ambiguous. (Sandro's <n> a graph). This does not really disambiguate, but it allows one to assert that a given use is unambiguous. 
> 
> 4. If the URI occurs in a context which defines graph URIs as denoting the graphs they "name", then it refers to the graph, but in other contexts it refers to the time. (This requires extending RDF with contexts which can affect the denotations of URIs.)(Which is easy to do, let me emphasize.) 
> 
> 5. We simply reject the ambiguity, say that the naming URI must always refer to the graph (so metatheoretic RDF is just vanilla RDF) and introduce some other convention to handle the ambiguity-creating pragmatic cases, such as having an extra triple to relate the graph to the time-interval or other 'context'. For example
> 
> :graph22 {  < > rdf:trueIn :interval26.  #some triples }
> 
> or
> 
> {... graph22 rdf:trueIn :interval26 ....}
> :graph22 { #some triples }
> 
> rather than
> 
> :interval26 { #some triples }
> 
> This has the problem that it deprecates some current use styles, but it has the advantage that it means that datatstore syntax will provide a way to actually name a graph, which is likely to be of wider utility (for example, this is what the Provenance WG seem to need.) 
> 
> The meaning of rdf:trueIn will need some extensions to the RDF semantics, but nothing too serious. Basically it says that the object of the property is an extra parameter for all triples in any graph denoted by the subject. I would be happy to revize the 2004 semantics to handle this. Or we could just punt on this and leave all notions of "context" outside the model theory. We should provide an RDF vocabulary term for this, though. 
> 
> Pat
> 

------------------------------------------------------------
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, 26 September 2012 21:50:09 UTC