Re: Minimal dataset semantics

On Aug 24, 2012, at 11:15 AM, Antoine Zimmermann wrote:

> Sorry, I wasn't clear and I did not get the proposal exactly right. Now it makes sense, I think.
> 
> However, we could as well make the graph extension be a function from IRIs to RDF Graphs

How is that different from the usual interpretation function? Arent you in effect having one name (IRI) name two things at once? So this is punning, right? 

> (let us call it IRI-GEXT) instead of a function from resources to RDF Graphs (let us call it RES-GEXT).

The only practical difference between the two is how they behave with equality. If you use the RDF single-denotation-plus-mappings model (your RES-GEXT) then equality "works" on these entities, ie if
 :a owl:sameAs :b 
then :a and :b can be substituted for one another and still work as graph names in the same way. If you use punning (your IRI-GEXT) then they don't (unless you add some more conditions, which will probably make the two models simply mathematical variations of one another.)

> 
> With RES-GEXT, the following:
> 
> <ex:bob>  owl:sameAs  <eg:bob> .
> <ex:bob> { <ex:bob> <name> "Robert Doe" .
>           <x>  owl:sameAs  <y> }
> <eg:bob> { <eg:bob> <name> "Robert Doe" .
>           <x>  owl:differentFrom  <y> }
> 
> is inconsistent. The problem is, perhaps ex:bob and eg:bob really refer to the same thing, and the dataset is using the scheme "graph IRI denotes primary topic" which we agreed is an acceptable scheme. Yet, here, the semantics with RES-GEXT does not allow to separate the inferences of the two graphs.
> This problem does not occur with IRI-GEXT.

Quite. And in all other respects they produce identical entailments, I believe. Certainly for what one might call 'straightforward' entailments. (There might be some OWL corners involving cardinalities where they diverge.) 

Pat

> 
> 
> --AZ.
> 
> 
> 
> PS: here is a possible formalisation of this.
> Let us assume an entailment regime E.
> A dataset-interpretation is an E-interpretation I plus a function GEXT from the set of IRIs to the set of RDF Graphs.
> For a dataset D = (DG,(n1,G1),...,(nk,Gk)),
> - for an IRI n and a graph G, I(n,G) is true iff there exists a graph G' such that (n,G') is in GEXT and G' E-entails G;
> - if I(G) is false, then I(D) is false;
> - if I(ni,Gi) is false for some i, then I(D) is false;
> - I(D) is true otherwise.
> 
> Nice, concise, and achieve essentially the same as my initial dataset semantics.
> 
> Le 24/08/2012 13:23, Richard Cyganiak a écrit :
>> On 24 Aug 2012, at 11:48, Antoine Zimmermann wrote:
>>> Is it the resource denoted by the IRI, or is it the IRI that is
>>> associated with the graph?
>> 
>> Please be precise what you mean by "associated".
>> 
>> In the abstract syntax, we have <i,G> pairs. So i and G are paired in
>> a named graph (as per existing SPARQL terminology). Resources do not
>> exist in the abstract syntax.
>> 
>> In the semantics, the pair <i,G> says that the IRI denotes some
>> resource, and that resource has some graph as its graph extension,
>> and that graph entails G.
>> 
>> Or if you want less formal, informative language: In the named graph
>> <i,G>, G is a claim about the state of the resource denoted by i.
>> 
>>> Consider the following, IMHO realistic, example:
>>> 
>>> ex:url1 and ex:url2 are the URLs RDF Documents found on the Web.
>>> The dafult graph is used to put mappings between different graphs.
>>> 
>>> # EXAMPLE BEGINS # ex:url1  owl:sameAs  ex:url2 . ex:url1 { ex:url1
>>> foaf:mbox  <mailto:frank@sinatra.net>} ex:url2 { ex:url2  foaf:mbox
>>> <mailto:frank@sinatra.net>} # EXAMPLE ENDS #
>>> 
>>> (I don't want to hear that this incorrect according to httpRange14.
>>> httpRange14 is not part of RDF and, in any case, this example shows
>>> something that happens on the Web for real.)
>>> 
>> 
>>> Now, if it's the resource that is associated with the graph, then
>>> we have a resource associated with two graphs.
>> 
>> Please be precise what you mean by "associated".
>> 
>> In the abstract syntax, we have two different IRIs paired with two
>> different named graphs. No ambiguity.
>> 
>> In the semantics, assuming OWL entailment, the dataset states that
>> ex:url1 and ex:url2 both denote some resource, and that graph has
>> some graph as its graph extension, and that graph entails the two
>> graphs you showed. No ambiguity.
>> 
>> Less formal wording of the semantic situation: We have two named
>> graphs that both make claims about the state of the same resource.
>> The claims don't contradict, so all is fine. No ambiguity.
>> 
>>> Why not, but then it becomes ambiguous when you talk about the
>>> graph associated with a resource. Which graph? Do you talk about
>>> both graphs all the time.
>> 
>> I never talked about associating graphs with resources. I talked
>> about associating graphs with IRIs, in the sense of "pairing them in
>> a named graph as per existing SPARQL terminology".
>> 
>>> I think that, in conversation, when we say "the graph associated
>>> with ex:url1", we tend to mean whatever is in the curly brackets
>>> after the IRI rather than an RDF graph that is supposed to be
>>> attached to a thing in the world.
>> 
>> I agree.
>> 
>>> We can put IRIs in the interpretation, because IRIs are not only
>>> part of the syntax, they are also made part of the semantics by
>>> being the literal values of literals with datatype IRI xsd:anyURI.
>> 
>> Yes, but I'm not sure what this has to do with anything.
>> 
>>> Anyway, this idea of having <i,G> pairs in the interpretation
>>> should be formalised as it may be a solution that avoids putting
>>> several RDF interpretations into one Dataset interpretation.
>> 
>> +1
>> 
>> Richard
>> 
>> 
>> 
>>> 
>>> 
>>> --AZ.
>>> 
>>> 
>>> Le 23/08/2012 21:43, Richard Cyganiak a écrit :
>>>> 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".
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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. I don't know if one can say that the IRI "refers to"
>>>> the entailment closure of the graph.
>>>> 
>>>> Does this make any sense?
>>>> 
>>>> Best, Richard
>>>> 
>>> 
>>> -- Antoine Zimmermann ISCOD / LSTI - Institut Henri Fayol École
>>> Nationale Supérieure des Mines de Saint-Étienne 158 cours Fauriel
>>> 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03
>>> Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/
>>> 
>> 
>> 
>> 
> 
> 
> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 83 36
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
> 
> 

------------------------------------------------------------
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 Friday, 24 August 2012 21:30:18 UTC