Re: Monotonicity of semantic extensions

Warning: this email contains stuff that are not related to the dataset 
semantics per se. There are digressions that you don't have to read if 
you're busy.

Le 12/09/2012 17:19, Richard Cyganiak a écrit :
> Hi Antoine,
> This is no longer about the minimal dataset semantics, but it's a
> topic that I'm interested in, so let's go on if you don't mind.
> As usually, I'm learning this stuff as I'm going along, and I'm
> probably just clueless about what it means for Y to be a proper
> semantic extension of X.

I don't know if the phrase "proper semantic extension" is standard, but 
I guess it maps to something defined by logicians.

What I consider a "proper" semantic extension X of an entailment regime 
Y has to satisfy the following property:

  "For any dataset D1 and D2, if D1 X-entails D2, then D1 Y-entails D2."

> On 11 Sep 2012, at 22:11, Antoine Zimmermann wrote:
>> I realise that we, and others, may not have the same idea of what a
>> proper semantic restriction is. For me, a semantic restriction is,
>> for instance, what RDFS is to RDF, what D-entailment is to RDFS and
>> what OWL Full is to D-entailment.
> For me too.


>> With the direct graph semantics you propose, it is a non-monotonic
>> extension because when you switch this semantics on, the
>> entailments you could do with the "minimal" semantics are not valid
>> anymore. I don't think that's how people think of an extension.
>> They probably do not expect that extensions make you lose what you
>> had before.
> Well, yes, there are cases where the minimal semantics says that A
> entails B, and the “direct graph” semantics says that A contradicts
> B.
>> It also means that people who do not use the extension get
>> conclusions contradicting those who use the extension. This is not
>> the case with RDFS, OWL, etc. If you do not use D-entailment, you
>> are not going to get any conclusions that contradicts those who use
>> it. And those who switch the D-entailment semantics on do not lose
>> anything they could conclude without it.
> Is this so?

Yes it is.

> It seem to be not quite true. Example:
> :p rdfs:range xsd:integer. :s :p "aaa"^^xsd:integer.
> Under RDFS-entailment, I can conclude from that graph:
> "aaa"^^:xsd:integer a xsd:integer.

This is not an RDF triple, you cannot conclude things that are not in 
the language. But I'll assume this is allowed for the sake of the 

> But when we switch on D-entailment, that triple is now a
> contradiction, I believe. So what used to be an entailment is now a
> contradiction.

A contradiction is a characteristic of an RDF graph. An entailment is a 
relationship between two graphs. Your example is a 
D-entailment-contradiction, but it does entail:

"aaa"^^:xsd:integer a xsd:integer.

because everything is entailed by a contradiction.

> Contrast that with my direct graph example:
> { :g1 a rdf:Graph } :g1 { :s :p :o }
> Under simple-dataset-entailment, this entails
> :g1 { :p :p [] }
> Under simple-dataset-plus-direct-graph-entailment, that becomes a
> contradiction. So it seems equivalent to the situation above?

Under simple-dataset-plus-direct-graph-entailment,

{ :g1 a rdf:Graph } :g1 { :s :p :o }

is not a contradiction and does not entail

:g1 { :p :p [] }

So one entailment that existed without the extension is now a 
non-entailment. It does not mean that there is a fundamental "bug" in 
the extension. It just means that it does not have the property that I'd 
expect, and I guess that it is a desirable property.

> There's obviously some subtle distinction here that I'm missing. Can
> you formally state the conditions that a semantic extension of
> E-dataset-entailment has to meet in order to be considered a proper
> semantic extension?

See above (again, the word "proper" is mine, it's not necessarily used 
in logician circles).

> I can't quite figure out what these conditions are just from reading
> RDF Semantics. The “general monotonicity lemma” [2] seems relevant,
> but is phrased as a result of something being a semantic extension,
> rather than as a condition on semantic extensions.

Well, the lemma, which I was not aware of, seems to say that the 
semantic extensions defined by RDF semantics are satisfying the property 
that I mentioned (modulo the use of RDF graphs instead of datasets). But 
it does not define in general a condition on semantic extensions.

I don't think RDF Semantics 1.0 specifies what's a "proper" semantic 
extension and does not require that any future extension must be 
monotonic. And even though it did say so about extensions of RDF 
semantics, it would not apply to the semantic of dataset, which does not 
deal with a set of triples alone.

> It also seems to
> fold various separate issues into one lemma, making it hard to
> understand. There's also [3] but I don't know how that translates to
> the case of E-dataset-entailment.

Normally, monotonic apply to a single logic. In our case, we are 
defining only monotonic logics, even the 
simple-dataset-plus-direct-graph-entailment is monotonic. But it does 
not extend "monotonically" the "minimal dataset semantics".

> By the way, do we agree that RDF Semantics should be very clear and
> specific about what it means to define semantic extensions to the
> various entailment regimes? I think making that normatively crystal
> clear is part of why that spec exists. And in fact, one way how one
> can conform to RDF Semantics is by defining a “conforming semantic
> extension of XYZ-entailment”, IMO.

Why not, but first we have to agree that we want to prescribe extensions 
that do not extend monotonically (I want to avoid the phrase 
"non-monotonic extension" which can have a different meaning). Perhaps 
there are some cases where it makes sense to do so (e.g., define an 
extension for working on closed databases). Personnaly, I'm in favour of 
restricting all normative extensions to be monotonical extension.


> Best, Richard
> [2] [3]
>> I understand that you wrote this merely as an example, and it
>> indeed proves that such semantics can be defined as a semantic
>> extension of our "minimal" proposal. I provided similar things
>> myself already [1]. But even when I was writing this, I was not
>> convinced by the utility. I only used it as a proof that it can be
>> done, formally.
>> [1]
>> --AZ
>>>> If I had to directly talk about a graph in a named graph, I
>>>> would do it like this:
>>>> :g  a  sd:Graph; :validityTime  "1998-09-11"^^xsd:date; ... :g
>>>> { :bob  :employedBy  :ibm }
>>>> It works, as long as I am using an agreed upon, explicit
>>>> specification of a shared conceptualisation, a.k.a. an
>>>> ontology.
>>> Yeah, and that's exactly the example I gave, except I called it
>>> rdf:Graph instead of sd:Graph, and formalized the implicit
>>> assumption that :g actually denotes { :bob :employedBy :ibm } as
>>> opposed to some other graph. You can't do that just by defining
>>> an ontology.
>>> The benefit of formalizing this is that, for example, if I define
>>> a Turtle datatype then it will just work, and I can infer
>>> { :g owl:sameAs ":bob :employedBy :ibm"^^xxx:Turtle }
>>> from the dataset above, modulo namespace declaration.
>>> Best, Richard
>>>> AZ.
>>>> Le 11/09/2012 11:46, Richard Cyganiak a écrit :
>>>>> On 10 Sep 2012, at 17:30, Richard Cyganiak wrote:
>>>>>> Two other things that I'd quite like to see before we can
>>>>>> call the proposal complete:
>>>>>> 1. Some thinking on how it addresses our graph use cases.
>>>>>> (Do we have an “official” list of those? I've lost track
>>>>>> with all the various documents.)
>>>>>> 2. Some examples for semantic extensions, in order to show
>>>>>> that various other proposed semantics can actually be done
>>>>>> as proper semantic extensions of this minimal dataset
>>>>>> semantics.
>>>>> I've worked a bit on this item and made attempts to
>>>>> formalize three semantic extensions:
>>>>> * owl:imports (formally explains how owl:imports works in
>>>>> RDF datasets) * web datasets (formally defines that stuff
>>>>> published on the web is asserted) * direct graph semantics
>>>>> (permits "literal" immutable graphs)
I'm not proposing that we should standardize any of this; the intention 
is merely to explore how flexible/extensible the semantics proposed on 
that page is.
>>>>> Again, I'm not really good at this formal semantics stuff,
>>>>> so this might all be spectacularly wrong.
>>>>> 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
>> -- 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

Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66

Received on Wednesday, 12 September 2012 17:47:55 UTC