- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 12 Sep 2012 21:16:09 -0500
- To: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Cc: Richard Cyganiak <richard@cyganiak.de>, public-rdf-wg@w3.org
On Sep 12, 2012, at 12:47 PM, Antoine Zimmermann wrote:
> 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.
Actually, the term "semantic extension" is not standard textbook logic at all, but was invented for the 2004 RDF standard. We needed some way to talk about the relationship between all the different kinds of entailment. and this was invented to do that job. It is therefore an idea which may have some odd corners which are not fully thought through (yet). And, on the positive side, if the WG wants to modify it, it is ours to modify.
>
> 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."
That was certainly part of the original idea, yes. (See http://www.w3.org/TR/rdf-mt/#MonSemExt )
>
>
>> 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.
>
> Good.
>
>>
>>> 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.
Indeed, 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 discussion.
Use bnodes to make it legal.
>
>
>> 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.
Yes, exactly. You have to remember that a contradiction entails everything, which keeps the monotonicity "working" when everything goes pear-shaped.
>
>
>>
>> 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
It does not, no.
> and does not require that any future extension must be monotonic.
Actually, the term is not precisely defined, I must confess. Certainly what I had in mind was that semantic extensions would be monotonic, and all the ones we had considered at the time were.
> 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.
Putting a semantic condition of entailment into the semantic truth conditions does make for a very unusual semantics which might have all sorts of odd properties. I havnt seen any obvious problems yet, but when I read that condition it made the hairs on my neck stand up. (More on this in another mailing.)
>
>> 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 agree, but it is not easy to make this sharply, mathematically, clear while also being as general as one would want it to be. We would probably need to use category theory or something similarly algebraic to do a proper job, but this would take it well beyond the comprehension level of most RDF readers (and past my level of competence, though Antoine may feel differently.)
>> 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.
Terminology is delicate at this point. One could imagine a monotonic semantic extension of a monotonic logic which itself is nonmonotonic.
Pat
>
>
> AZ
>
>
>>
>> Best, Richard
>>
>>
>> [2] http://www.w3.org/TR/rdf-mt/#MonSemExt [3]
>> http://www.w3.org/TR/rdf-mt/#glossMonotonic
>>
>>>
>>> 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] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Dataset-semantics
>>>
>>> --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)
>>>>>>
>>>>>> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics#Possible_Semantic_Extensions
>>>>>>
>>>>>>
>>>>>>
>>>
>>>>>>
> 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 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/
>>>
>>
>>
>
> --
> 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/
>
>
------------------------------------------------------------
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 Thursday, 13 September 2012 02:16:51 UTC