W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

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

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Thu, 7 Jan 2010 16:45:30 +0000
Message-ID: <492f2b0b1001070845o4cedcb5dt10fb367f8beecfe7@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Axel Polleres <axel.polleres@deri.org>, W3C SPARQL Working Group <public-rdf-dawg@w3.org>
2010/1/6 Ivan Herman <ivan@w3.org>:
> Birte,
>
> First of all, thanks, you have indeed covered all my comments.

Great!

> However... (I know, I am a pain in the neck), re-reading the text, I
> have the following (minor) additional comments. My apologies if it was
> already present in the previous version and I missed it... That being
> said: _none of these are critical_. In other words, I am happy to
> publish the document as is in this round, and possibly address these
> comments in the next release only. This is especially true for entry #1
> below.

I am quite happy about such feedback. It really helps to make the
document better!
See http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml for the
improved version and my comments below:

> 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
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.

> 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. 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.

> 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.

> 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 ;-) 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.

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

Thanks a lot!
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
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Thursday, 7 January 2010 16:46:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT