Re: Minimal dataset semantics

On 24 Aug 2012, at 16:58, Pat Hayes wrote:

> 
> On Aug 23, 2012, at 2:43 PM, Richard Cyganiak wrote:
> 
>> On 23 Aug 2012, at 19:02, Pat Hayes wrote:
>>>>> b) to define a minimal version of a "truth-based"/"entailment-based" semantics (where [[ :i1 { G } ]] entails [[ :i1 { G' } ]] if graph G entails graph G').
>>> 
>>> Which means that the "name" refers to the entailment closure of the graph, rather than the graph itself. Right? 
>> 
>> I'm not sure what you mean by "refers to".
> 
> refers to = denotes (= names, anywhere outside the W3C :-)

Okay. But then the "name" does *not* denote the entailment closure of the graph, in the same sense that a predicate IRI does *not* denote a binary relation. A predicate IRI denotes a resource (known as a "property") that has a property extension that is a binary relation. A graph IRI denotes a resource (known as a ... g-box? RDF space? graph source? RDF data source?) that has a graph extension that entails the graph.

>> Regarding the formal mechanism of associating IRIs with their respective graphs, I've started to like the idea that Alan mentioned the other day: Dataset interpretations contain a mapping from resources to graphs, called the graph extension. This mapping associates graphs with (some) resources. A name-graph-pair (a.k.a. abstract named graph) <i,G> satisfies a dataset interpretation I if the graph extension in I of I(i) entails G.
> 
> I am cool with that, although it does have some consequences that y'all might find odd when you try mixing it with owl:sameAs. Do you want this:
> 
> :a owl:sameAs :b
> { :a { :this :is :graph}}
> 
> to entail 
> 
> {:b {:this :is :graph}}

Well, at the start of this WG I would have said that this would be an atrociously bad idea, but now it seems logical to me. If :a and :b denote the same thing, then of course this will hold.

>> If I'm not messing up, then this mechanism works the same as the property extension and class extension mechanisms that already exist in RDF Semantics.
> 
> Its in the same spirit, one might say, yes. The difference is that property and class extensions are kind of abstractions, so it is (maybe with a slight forcing, but one gets used to it) OK to say in those cases that the resource *is* the class or property; but in this case, I think that to identify the resource with the graph would be too much of a stretch (and would negate the intended use cases, in any case). So its not *exactly* similar, in practice. 

Ok, yeah.

>> So, the graph IRI then *denotes* a resource (one that is in the domain of the class extension function). And in the abstract syntax, the graph IRI is "associated" or "paired" with a certain RDF graph.
> 
> The IRI or the resource is paired with it? I think its the denoted resource, yes?

The abstract syntax of RDF datasets contains <iri,graph> pairs. SPARQL calls them "named graphs". So, trivially, it is correct to say that in the abstract syntax, *IRIs* are *paired* with *graphs*, because they appear in the same <iri,graph> tuple. That is all. (That does not make the IRI denote the graph.)

(s/class/graph/ in what I wrote above.)

>> I don't know if one can say that the IRI "refers to" the entailment closure of the graph.
>> 
>> Does this make any sense?
> 
> Yes, it makes good sense. I would avoid saying that the IRI denotes the graph, in this case.

Right. If I said that, I misspoke. The IRI denotes a ... g-box? RDF space? graph source? RDF data source? Information resource? Some kind of resource anyways.

> ITs rather that there is relation beween them, we need a name for it, lets say that the IRI "indicates" the graph. That is, I indicates G whern I denotes X associated with G

Right. This relation is the one that holds between the graph IRI and the graph in a <iri,graph> pair in a SPARQL named graph. I guess the term you're looking for here, e.g., "indicates", would only show up in the formalization of the semantics. It would take some careful explaining that the relationship is not "naming" despite the <iri,graph> pair being called a "named graph" and the IRI often being called a "graph name" or "graph IRI".

> Why do you want to have entailment closures rather than graphs? Bear in mind that a simple bug in a graph can make the RDFS or OWL entailment closure be infinite. I think precision outweighs convenience here. 

Basically, because I'm interested in explaining various useful RDF operations as semantic extensions.

Consider an entailment regime where we add a semantic condition that the "graph extension" mapping must be the dereference+parse function. Boom, we have formally described a dataset that contains the entire web of data. So we can explain follow-your-nose as a semantic extension, and we have a theoretical foundation for all sorts of work around provenance, access control, and the like.

Or consider an entailment regime where I can say things like ":g1 ex:isUnionOf (:g2 :g3 :g4)" in the default graph. Can we define a semantic extension that makes it so that the graph indicated by :g1 is now equivalent to the union of those graphs?

Or formalize owl:import as a semantic extension? If :g1 owl:imports :g2, then an interpretation of the graph indicated by :g1 must also satisfy :g2 (or must satisfy the union or merge of :g1 and :g2).

Maybe I'm wrong, but these kinds of semantic extensions don't seem to be possible with closed-graph semantics, because we already have said that the triples explicitly included in the named graphs are all there is.

With open-graph semantics on the other hand, it seems possible to "make additional triples show up" in the named graphs via entailment, and it seems possible to combine multiple of these semantic extensions without them stepping on each others toes too much.

(All of the above may seem far-fetched without additional explanations. I'll try to expand on at least one of these later.)

Summary: My (possibly dead wrong) impression is that the closed-graph semantics provides no useful entailments and cannot be usefully extended; it provides nothing of interest that isn't already in the abstract syntax. The open-graph semantics on the other hand provides at least *some* interesting entailments, and seems to provide many opportunities for extensions that are interesting and useful.

Maybe my underlying assumption -- that open-graph semantics is more friendly to semantic extensions -- is wrong; in that case I'd have to re-evaluate my position of preferring open-graph semantics.

Best,
Richard

Received on Friday, 24 August 2012 19:09:48 UTC