Part I of my answers to PFPS' review of the RDF-Based Semantics [RE: Initial comments on OWL 2 Full Semantics]

Hi Peter!

I have splitted my answer to your review comments into two parts. In this
mail, I will answer to those points which have been easier to deal with. My
next mail will address the remaining review comments.

Peter F. Patel-Schneider wrote on Wednesday, September 03, 2008 3:11 AM:

>Here are my comments on the OWL 2 Full Semantics.    I haven't made
>review comments because I read the document while I was not connected to
>the web, and thus couldn't edit the document.
>
>
>In general I think that the document is quite good.  

Many thanks!

>I have a number of minor changes listed here.
>
>I also have a comment that is more general than the document itself:
>
>- owl:distinctMembers should be deprecated, as its function is handled
>  by owl:members
>
>Initial comments on the document:
>
>- Vocabulary changes
>  xsd:short - add to list of datatypes
>  xsd:anyURI - replace owl:anyURI by xsd:anyURI
>  owl:NAryDatatype - remove
>  owl:datatypeArity - remove
>  owl:Annotation - add as class, subset of IR

Agreed. I can see that a few things have been changed since I last checked
the DL-Syntax and the RDF Mapping. I have updated the list of datatypes and
the vocabulary list accordingly. For owl:NAryDatatype, owl:datatypeArity and
owl:Annotation I had to update other parts of the document, too.

>- "owlV" is not used after being defined.  I suggest removing it from
>  the definition of the OWL 2 Full vocabulary.

Agreed. I have removed it.

>- The deprecation of owl:DataRange should say
>    The URI reference rdfs:Datatype SHOULD be used instead.

Agreed. I have changed the text that way.

>- Definition 3.2 should also require that the datatype and facet names
>  of D be in V.

Agreed. I have changed D 3.2, 3.3 and 3.4 accordingly.

>- Definition 3.2 should read  "... let V be a vocabulary that includes
>  ...".

Agreed. And I have changed the text for the 3.3 and 3.4, too. 

Before LC, I will ask some native speaker to check the document for proper
grammar and style (added a note in my "Final Tasks" list).

>- What are the "constraints in this section" referred to in Definition
>  3.2?  I don't see any.

Yes, this was wrong. I only wanted to refer to the semantic conditions
defined in this document. I have changed the text accordingly.

>- Definition 3.3 and 3.4: Satisfaction of RDF graphs is not defined in
>  this document.  If this means some RDF satisfaction, then you need to
>  point there.  If not, you need to define satisfaction.

Ok, I have added some text directly before Def. 3.1. Please have a look and
tell me if you think this is sufficient or not. 

I just want to give a hint there to readers that trueness of an RDF graph
under some interpretation is defined in the context of the semantic
conditions that have to be met by that interpretation. For
D-interpretations, it's those semantic conditions given in the RDF Semantics
document. And later, def. 3.2 sais that an OWL 2 Full Interpretation has to
meet the semantic conditions given in the OWL 2 Full document. Hence it
should be clear for a reader that trueness (and therefore satisfaction) of a
graph is given in the context of those semantic conditions. Do you think
that more has to be said here? Trying to be precise about the term
"satisfaction" easily leads to gory technical and even philosophical issues.
:)

>- Definition 3.3:  Q is not used.

True. Fixed.

>- The semantic conditions are additions to also the D-entailment
>  conditions, I think.  The first sentence of Section 4 should be
>  changed accordingly.	

Agreed. Added.

>- ICEXT(owl:NamedIndividual) = IR is probably incorrect, there are only
>  countably many named individuals, but potentially uncountably many
>  resources.  Should be <= IR.

Deferred to part II of my answer.

>- Table 4.1 - add column for description, e.g., Domain of discourse /
>  Literal Values / Ontologies / Classes / Datatypes / ...

Yes, most wanted by all reviewers. :) Added.

>- owl:NAryDatatype is no longer in the RDF mapping
>  owl:datatypeArity is no longer in the RDF mapping

Yes, I have updated the document.

>- Replace "<= empty set" with "= empty set" in several places.

Fair enough. :) Changed for owl:Nothing and both
owl:Bottom(Object|Data)Property.

>- IEXT(IS(owl:object)) <= ICEXT(IS(owl:Axiom)) x IR is wrong, as it
>  states that annotated annotations are axioms.  It should be IR x IR.
>  Similarly for owl:predicate and owl:subject.  (This may be because the
>  document does not yet handle annotations on annotations.)

Indeed. Now that owl:Annotation is supported, too, I have changed the
domains of the OWL reification URIs.

>- owl:allValuesFrom should be <= owl:Restriction x IC.
>
>- owl:TopDataProperty has wrong domain.  It should be = IR x ILV.

Thanks, these two were very bad typos. Fixed!

>- Table 4.7 needs to be augmented with the conditions for nary some/all
>  as follows:
>  if l is the sequence p1,...,pn in IDP
>  - <x,c> in IEXT(IS(owl:someValuesFrom))
>    <x,l> in IEXT(IS(owl:onProperties))
>    then
>    ICEXT(x) = { y | exists z1, ..., zn  <y,zi> in IEXT(pi) for each
>  1<=i<=n
>                                         and <z1,...,zn> in ICEXT(c) }
>  - <x,c> in IEXT(IS(owl:allValuesFrom))
>    <x,l> in IEXT(IS(owl:onProperties))
>    then
>    ICEXT(x) = { y | forall z1, ..., zn  <y,zi> in IEXT(pi) for each
>  1<=i<=n
>                                         imply <z1,...,zn> in ICEXT(c) }
>
>- The above change removes the need for Table 4.9.

Both points: Deferred to part II of my answer.

>- The last part of the paragraph before Table 4.10 should read something
>  like:
>    Note that only the additional semantic conditions are given here and
>    that the other RDFS conditions on this vocabulary are retained.

Yes! Even, my original text was not correct: Reflexivity and transitivity of
rdfs:subClassOf are actually inferred by the IFF semantics. I have changed
the text in a form similar to your proposal.

>- There is no definition of sequence.

(As there hasn't been any in OWL 1 Full. :-)) Agreed, I have added a
paragraph on "conventions" to the beginning of the "Semantic Conditions"
section. This paragraph contains a definition for expressions of this sort.

>- Semantic conditions should be provided for property chains directly,
>  as in:
>
>  Table 4.11: Property Chains
>   if l sequence of p1,...,pn in IR
>   then
>      <x,l> in IEXT(IS(owl:propertyChain))
>   IFF
>     x,p1,...pn in IP
>     IEXT(x) = IEXT(p1) o ... o IEXT(pn)

Deferred to part II.

>- The x,y,z in Table 4.15 should be explicitly quantified over IR in
>  the RHS of the table.

I take this as a more general comment about all tables (for example table
4.14 on inverse properties has the same problem).

In comparison, the OWL 2 DL semantics /do/ add quantifiers, but do in most
cases /not/ say "in Delta_Int". In my opinion, quantifiers are a good thing,
but having "in IR" in all cases might be a bit too much. Instead, I have
added some text to the "conventions" paragraph at the beginning of the
"Semantics Condition" section, which tells what it means if the scope of a
bound variable is missing. Please tell me if this is fine for you or not. If
not, I will add the missing "in IR"s everywhere. 

>- I believe that Table 4.16 should have x in CEXT(c), y in CEXT(c).
>  Also Table 4.16 is missing quantifiers for the zi.  I believe that
>  they should be existentially quantified.

Yes. This was an embarrassingly heavy error. Thanks, fixed!

I have also changed the form of that semantic condition to be a bit closer
to the DL Semantics. The semantic condition for Easy Keys is the most
complex one in the document, and it shouldn't look too different in both
Semantics, I think. This means that I use an all quantifier for the (z_i)
instead of an exist quantifier, applying the equivalence:

  ( forall x: (A(x) -> b) ) <==> ( (exists x: A(x)) -> b ) 

>- Table 4.18 is missing a membership symbol.

Thanks. Fixed.

>- Table 4.18 already almost handles annotations on annotations, I think,
>  provided that the domain of the OWL reification properties are changed
>  as suggested.  However, I think that it would be better to change
>  Table 4.18 and its introduction as follows:
>
>    Table 4.18 lists the semantic conditions for the OWL vocabulary used
>    for some axiom annotations and for annotations on annotations.  Both
>    these kinds of annotations employ a reified version of a triple
>    representing either the annotated axiom or the annotated annotation.
>    The semantic conditions below recovers the triple itself from the
>    reified version.
>
>     Table 4.18: Reified Axioms and Annotations
>
>     - if x in ICEXT(IS(owl:Axiom))
>          <x,u> in IEXT(IS(owl:subject))
>          <x,p> in IEXT(IS(owl:predicate))
>          <x,w> in IEXT(IS(owl:object))
>       then <u,w> in IEXT(p))
>     - if x in ICEXT(IS(owl:Annotation))
>          <x,u> in IEXT(IS(owl:subject))
>          <x,p> in IEXT(IS(owl:predicate))
>          <x,w> in IEXT(IS(owl:object))
>       then <u,w> in IEXT(p))

Deferred to part II.

>- There needs to be a section on the differences from OWL 1 Full
>  semantics, talking about comprehension principles, at least.

Agreed. But I would like to wait with this untill LC. Also, such a section
should be there for all our technical documents (a common policy on how
these sections should look like would be a good idea, I think). For the
moment, I have added a stub section to the document, and put a review mark
in it, listing a few points to be considered.

>- Why is there a partial comprehension principle for propertychains and
>  subpropertyof (in Table 4.11)?  See suggestion for Table 4.11 above.
>
>- Why do AllDifferent, AllDisjointClasses, and AllDisjointProperties
>  have partial comprehension principles?  I suggest removing second half
>  of Table 4.13 or moving it to Section 6.
>
>- Why are there comprehension principles for negative property
>  assertions?  I suggest removing second half of Table 4.17 or moving it
>  to Section 6.

Deferred to part II.

>- I have not examined Section 6 closely.
>
>
>I am thinking about the comprehension principles and how to best handle
>them.  I may have a proposal for further changes in this area.
>
>Peter F. Patel-Schneider
>Bell Labs Research

Many thanks for your very valuable feedback so far! You will get the second
part of my answer within the next few days.

Cheers,
Michael

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

Received on Thursday, 11 September 2008 14:17:02 UTC