Re: [TF-ENT] Review of the Entailment regime document, 2009-12

Hey Birte,

On 2010-1-7 17:45 , Birte Glimm wrote:
[snip]
> 
>> 1- Section 6.2: if one goes outside the OWL DL circles then the
>> Functional Syntax for axioms is not really known and well readable. (I
>> must confess that I also 'see' OWL statements in Turtle and not in FS.)
> 
> I must confess that I am a total FSS person. For OWL Direct Semantics

No surprise there:-) We come from different background in this sense, so
the mix is good:-)

> I think using both consistently is good because Direct Semantics is so
> closely related to FSS and the semantics is defined in terms of OWL
> objects that directly correspond to the FSS. Turtle/triples is
> absolutely SPARQL, so it also has to be there. I tried to consistently
> give examples in both syntaxes and I went once again over the section
> to find the places where I wasn't consistent.
> 

Having a quick look at the text I like what I see...

>> I wonder whether we should not consider the approach we took in the OWL
>> documents, where the examples were all available in various syntaxes and
>> people could choose which one they would use. It is a little bit of
>> extra work, but we have got extremely positive feedbacks on this, it was
>> worth the trouble. For this document I think having the examples in FS
>> and in Turtle would be enough (the OWL documents also had M'ter syntax
>> and RDF/XML).
> 
> That's used in the Primer as far as I can tell. The structural spec
> and the direct semantics uses FSS throughout. 

Actually... that is not true! The FSS has the buttons at the start to
choose between FSS or Turtle (yes, FSS is the default). That was an
important point: FSS is the definition of OWL as a whole, not only for
DL/Direct Semantics and it was important to get all the examples in
Turtle, too, so that RDF users could use that document, too...


>                                                I like the way it is
> done in the primer though. For a later publication, I'll consider such
> buttons to choose the example syntax.
> 

Yes, let us postpone this. If there are only a few examples than it may
not be worth the trouble.

>> Again: this is _not_ for this release, the publication can and should
>> happen without it!
> 
> Good ;-)
> 
>> 2- Section 6.1.1: "These restrictions require that blank nodes are only
>> connected in a tree-like way": a short example of what this means would
>> be helpful (or a reference of such example). Lambda RDF users may not
>> really understand what you mean here...
> 
> I added a link to the relevant section in the OWL spec now, which
> includes an example.
> 

Yes, that sounds good. Thanks.

>> 3- Section 6.1.3 and elsewhere: we should try to make the Turtle/SPARQL
>> mapping more readable, and really making use of its syntactic
>> possibilities. Eg, the first example could be written as
> 
> That's all due to my limited Turtle skills ;-) I went through the
> document now and tried to improve to the best of my knowledge. I
> mainly write and think in FSS and then I go to the OWL mapping to RDF
> spec and use that to get to the Turtle ;-) 

As I said, we come from different schools:-) I understand the FSS, in
many cases, once I see it in RDF. I really 'think' in Turtle...

Let many flowers bloom:-)

>                                              That's not nice Turtle as
> you can tell. You examples below really helped too!
> 
>> ex:Peter a [
>>    a owl:Restriction ;
>>    owl:onProperty ex:hasSon ;
>>    owl:maxCardinality "1"^^xsd:nonNegativeInteger .
>>  ] .
>>
>> the second could be
>>
>> ex:Peter a [
>>     a owl:Class ;
>>     owl:complementOf [
>>       a owl:Restriction ;
>>       owl:onProperty ex:hasSon ;
>>       owl:minCardinality ?n .
>>     ]
>>  ]
> 
> both done.
> 
>> Which I do fine more readable. This is even more visible for the example
>> in 6.1.5. The axiom in Turtle could be:
>>
>> ex:Peter a [
>>    a owl:Restriction ;
>>    owl:onProperty ex:dp ;
>>    owl:qualifiedCardinality "2"^^xsd:nonNegativeInteger .
>>    owl:onDataRange [
>>      a rdfs:Datatype ;
>>      owl:onDatatype xsd:int ;
>>      owl:withRestrictions (
>>        [ xsd:minExclusive "5"^^xsd:int ]
>>        [ xsd:maxExclusive "8"^^xsd:int ]
>>      )
>>    ]
>> ]
> 
> Much better. I didn't even know that you can use the round brackets
> and write the facet list like that.
> 

Yeah, most of the time when one really uses Turtle's facilities then the
triple syntax becomes really much readable!

>> Let us not make the RDF version more cryptic than necessary!
> 
> Thanks a lot!

Thanks to you!

As far as I am concerned, we are ready to publish!

Cheers

Ivan

> Birte
> 
>> Cheers
>>
>> Ivan
>>
>>
>>
>>
>>
>> On 2010-1-5 18:21 , Birte Glimm wrote:
>>> Ivan, Axel, others,
>>> a new version of the document is now checked in, see
>>> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml. Axel, the
>>> Direct Semantics section is now up to date, so can review it. I'll
>>> start implementing your changes for the RDF(S) part now.
>>> I comment on the changes to address Ivan's review below.
>>> Thanks for the very useful reviews,
>>> Birte
>>>
>>> 2009/12/18 Ivan Herman <ivan@w3.org>:
>>>> Birte, all
>>>>
>>>> here are my review comments on the document. All in all, none of the
>>>> comments seem to constitute a show-stopper in my view, ie, with those
>>>> changes done, I think the document is read to be published. Actually, my
>>>> comments on section 2.5 may require more work but, if those are
>>>> postponed for the next release, it is fine with me to publish without
>>>> that change.
>>>>
>>>> Ivan
>>>>
>>>>
>>>> (Slightly more) substantial:
>>>>
>>>> Abstract, last sentence
>>>> -----------------------
>>>>
>>>> I would actually drop the "Time permitting," at the beginning. On the
>>>> one hand, it is clearly the case that those will happen:-) and I suspect
>>>> that this document would not be accepted for final publication without
>>>> those items anyway...
>>>
>>> Dropped.
>>>
>>>> Section 1.1.3, triple patterns are defined by:
>>>> ----------------------------------------------
>>>>
>>>> (RDF-T union V) x (I union V) x (RDF-T union V),
>>>>
>>>> but 'I' is not defined in the sequel. I presume you mean IRI-s (as
>>>> defined in 12.1.1 of the original SPARQL doc)
>>>
>>> Added the definition.
>>>
>>>> Editorial note at the end of 2.2.1
>>>> ----------------------------------
>>>>
>>>> I regard editorial notes as places where we, essentially, put
>>>> alternatives and let the community react if those alternatives are
>>>> considered to be better. However, most of this editorial note (up until
>>>> "A consequence of not requiring...") is more an
>>>> informative/clarification note on the current definition. I think it is
>>>> valuable for the reader and I would consider moving that into the main
>>>> text as an informative section.
>>>
>>> Mentioned part of the note is now in an informative section.
>>>
>>>> Section 2.5, definition of Direct Semantics entailment, point 3.a
>>>> -----------------------------------------------------------------
>>>>
>>>> I presume the usage of sk(O(SG)) here is necessary for the _:y case
>>>> described in the preliminary text. If so, then sk has to be defined in
>>>> the sequel, to make the definition of the entailment regime's condition
>>>> self-contained.
>>>
>>> It is and sk(O(SG)) is defined now.
>>>
>>>> Section 2.5 generally
>>>> ---------------------
>>>>
>>>> This is not a trivial editorial issue, hence I put it here. In the
>>>> RDF(S) cases the text carefully took the restrictions (C1) and (C2) and
>>>> gave examples with a clear reference to the restrictions and showing why
>>>> they were there. And that is fine. I think the issues and descriptions
>>>> for 2.5 should follow the same structure to make the text more readable
>>>> (Which does not exclude having additional info, of course.)
>>>>
>>>> For example, the first part of section 2.5.2, referring to top property
>>>> is not, as far as I could see, referring to any of the restriction in
>>>> the entailment definition but rather to a restriction defined by OWL 2.
>>>> On the other hand, the second half of the same section describes (I
>>>> guess) 3.b. Ie, this should be editorially separated in my view. 2.5.3
>>>> refers to restrictions 1.
>>>>
>>>> I see no explanation/example for 3.c and 3.d. I must also admit that I
>>>> do not understand the necessity of 3.d. I thought that non-logical
>>>> axioms are, sort of, comments for the direct semantics, so why asking
>>>> for a structurally equivalent axiom? What does that mean?
>>>
>>> The Direct Semantics section is restructured now. I hope the
>>> conditions are now clearer stated, similar as for RDF(S) and the
>>> sections following the table for the Direct Semantics entailment
>>> regime now go through each condition explaining the underlying
>>> intention.
>>>
>>>> General comment
>>>> ---------------
>>>>
>>>> I would put, somewhere, an editorial note that the WG is looking to
>>>> describe available entailment regimes in terms of service descriptions,
>>>> and that this may also involve giving a reference to EL and QL. Getting
>>>> comments from the community for that would be good...
>>>
>>> I added that at the end of the introduction. Each entailment regime
>>> now includes the URI for that regime and for the profiles that are
>>> already described (DL, EL, QL) I added sections that mention the URI
>>> that can be used to describe the input restrictions for systems that
>>> just handle a profile.
>>>
>>>> =================================================
>>>>
>>>> Editorial:
>>>>
>>>> Abstract, 1st paragraph:
>>>> ------------------------
>>>> "What correct answers to a SPARQL query are"
>>>> ->
>>>> "What the correct answers to a SPARQL query are"
>>>
>>> done
>>>
>>>> "The first version of SPARQL [SPARQL/Query 1.0] was defined only for
>>>> simple entailment, but it defines"
>>>> ->
>>>> "The first version of SPARQL [SPARQL/Query 1.0] was defined only for
>>>> simple entailment, but it defined"
>>>
>>> done
>>>
>>>> "The goal of this document is to specify conditions such that SPARQL can
>>>> be used with entailment regimes other than simple entailment."
>>>> ->
>>>> "The goal of this document is to specify conditions such that SPARQL can
>>>> be used with some other entailment regimes beyond simple entailment."
>>>>
>>>> (for the latter: the original sentence suggests that this document
>>>> defines how to use sparql with _any_ entailment regimes, which not the case)
>>>
>>> Agreed and changed.
>>>
>>>> Introduction, 1st paragraph
>>>> ---------------------------
>>>>
>>>> "In this document, we specify how SPARQL can be used with entailment
>>>> regimes other than simple entailment."
>>>> ->
>>>> "In this document, we specify how SPARQL can be used with some other
>>>> entailment regimes beyond simple entailment."
>>>>
>>>> (same issue as above...)
>>>
>>> Done.
>>>
>>>> Introduction, bulleted list of references
>>>> -----------------------------------------
>>>>
>>>> I am not 100% about that, but I wonder whether it is not better to list
>>>> the 1.1 documents for all items, rather than a mixture of the two...
>>>> (realizing, however, that the current 1.1 draft does not contain yet the
>>>> parts from the old SPARQL...) An alternative is to make this issue
>>>> explicit. I just want to avoid misunderstandings that this draft is not
>>>> relevant to SPARQL Query 1.1...
>>>
>>> I removed the SPARQL 1.0 reference and now use the latest version URIs
>>> (with the short names) everywhere so as soon as the documents are
>>> published the UR should point to the then complete 1.1 spec.
>>>
>>>> Section 1.2, paragraph after the SELECT example
>>>> -----------------------------------------------
>>>>
>>>> varaibles -> variables
>>>  Done.
>>>
>>>> Section 1.3, first sentence
>>>> ---------------------------
>>>>
>>>> "...matching to other entailment regimes and SPARQL 1.0 says:"
>>>> suggest removing "and SPARQL 1.0 says:"
>>> Done.
>>>
>>>> Section 2.1.1, penultimate paragraph
>>>> ------------------------------------
>>>>
>>>> "...sk(G) C1 is satisfied" -> "...sk(G), C1 is satisfied"
>>> Added.
>>>
>>>> Section 2.1.2, first paragraph
>>>> ------------------------------
>>>>
>>>> "The following example illustrates mainly the use of condition C2."
>>>> ->
>>>> "The following example mainly illustrates the use of condition C2."
>>> Done.
>>>
>>>> Section 2.2, first paragraph
>>>> ----------------------------
>>>>
>>>> inconsistet  -> inconsistent
>>> Done.
>>>
>>>> Section 2.5.2,  ultimate paragraph
>>>> ----------------------------------
>>>>
>>>> are return -> are returned
>>> Done.
>>>
>>>> Section 2.5.4.2, first paragraph
>>>> --------------------------------
>>>>
>>>> annotaated -> annotated
>>> Done.
>>>
>>>> Section 2.5.4.2, last paragraph
>>>> -------------------------------
>>>>
>>>> "Apart from the annotations and annotation axioms itself"
>>>> ->
>>>> "Apart from the annotations and annotation axioms themselves"
>>> Done.
>>>
>>>>
>>>> Section 2.5.5, first paragraph
>>>> ------------------------------
>>>>
>>>> Smeantics -> Semantics
>>> Done.
>>>
>>>> Appendix, CVS history
>>>> ---------------------
>>>>
>>>> Empty? That looks odd. Either you do not use CVS comments (in which case
>>>> it is fine to remove this appendix) or fill it with meat:-)
>>>
>>> Now I added that CVS log command and it is not empty any more. Should
>>> I manually add all the previous comments that where not added
>>> automatically?
>>
>> --
>>
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF   : http://www.ivan-herman.net/foaf.rdf
>> vCard  : http://www.ivan-herman.net/HermanIvan.vcf
>>
>>
> 
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf