My answers to Jie Bao's review of the Full Semantics

Hi Jie,

many thanks for your review comments. Below are my answers.

    Introduction:
    """
    In the RDF Semantic documents, there are some nice diagrams 
    to visualize interpretations. It may be better to have similar 
    diagrams in this document.
    """

I do not intend to add such figures. Being only examples, they are purely informative, and thus would rather be something to put in the Primer, not in the technical spec. Remember that we had a general discussion at F2F2 on not having too many examples in the technical documents. 

Further, the diagrams in the RDF Semantics show simple examples of interpretations, and by that are valid for the OWL 2 Full Semantics, too. OWL 2 Full puts further constraints on such interpretations by means of the OWL 2 Full semantic conditions. Trying to visualize this would probably lead to more complicated figures. Already the second figure in the RDF Semantics document, which visualizes an RDF interpretation, looks a bit complicated to me. It also wouldn't be clear to me which of the possible situations in OWL 2 Full should be visualized and which not. Maybe that's the reason why the RDF Semantics document does not provide any figures showing RDFS interpretations.

     Introduction:
     """
     I believe in OWL 1 semantics, IOOP <= IP, but not identified, 
     and, also, IODP, IOAP and IOXP are are subsets of IP. 
     In this document, IP represents only the extension of 
     all object properties, i.e., ICEXT(IS(owl:ObjectProperty)). 
     However, in both RDF and OWL 1 Full semantics, 
     IP=ICEXT(IS(rdf:Property)). People that are familiar 
     with RDF or OWL 1 may assume IP was still the extension 
     of rdf:Property if they do not pay enough attention, 
     which is, likely. Sorry for being picky, but keeping 
     naming backward compatible with the RDF document 
     may minimize possible confusions.
     """

There are several points here, which I will address piece by piece.

     "I believe in OWL 1 semantics, IOOP <= IP, but not identified,"

The OWL 1 Full semantics explicitly specifies that IOOP and IP (or P_I) are /identical/, see the table in sec. 5.3 ("OWL Full") of the S&AS. 

    "and, also, IODP, IOAP and IOXP are subsets of IP."

Indeed. In OWL 2 Full, you can find the same relationships by looking into table 4.1 ("Basic Sets"). The only difference is (or was) that I use(d) different names for the sets: "IODP -> IDP", "IOAP -> IAP", "IOXP -> IXP".

    "In this document, IP represents only the extension of 
     all object properties, i.e., ICEXT(IS(owl:ObjectProperty)).
     However, in both RDF and OWL 1 Full semantics, 
     IP=ICEXT(IS(rdf:Property))."

IP=ICEXT(IS(rdf:Property)) is intended to be true in the OWL 2 Full document, too. However, I did not say this explicitly in the tables (the information was implicitly contained in section 3 on "Interpretations"). I have now added an entry for this relationship in table 4.3 ("Classes"). I have also added entries for IC=ICEXT(IS(rdfs:Class)) and IR=ICEXT(IS(rdfs:Resource)).

    "keeping naming backward compatible with the RDF document 
     may minimize possible confusions."

That was just my intention, when I renamed the sets. In OWL 1 Full, there was no "IP" but "P_I". But I haven't been perfectly consequent, and invented a new naming scheme for all the "basic sets". I hereby change the naming policy to a more conservative one:

  1) The names used in the RDF Semantics 
     take precedence over the names used in OWL 1 Full.

  2) OWL 1 Full names, which have no counterpart 
     in the RDF Semantics, keep as they are.

You can see all the new (or better: the old) names in table 4.1 on "Basic Sets".

I also plan to add a section on changes to OWL 1 Full to the document. One of the points there will be the explanation of the new naming scheme. However, due to lack of time, I only added a stub section with an Editor's Note for the moment.

   Introduction:
   """
   May be explicit that those sub parts are not necessarily disjoint.
   """

Agreed, but I am addressing this in a slightly different manner. I have added text that an individual may play different "roles". A similar text is contained in section 3.1 of the RDF Semantics.

   Introduction, RFC 2119:
   """
   negated forms? is it a typo?
   """

Agreed, the text may be confusing. I changed the sentence to explicitly enumerate all words, now containing "MUST NOT", "SHOULD NOT" and "MAY NOT".

   Interpretations:
   """
   Add "where ''P'' means powerset" after IEXT definition.
   """

Agreed. Added.

   Semantic Conditions, Intro:
   """
   I found many conditions in this section are defined 
   as comprehension rules (usually in the "iff" form). 
   Will it be better to move all the comprehension ones 
   into section 6, together with existing comprehension conditions?
   """

I will give an answer to this question, when dealing with Peter's review comments (he even had a separate mail on this specific topic). I am dropping this comment, since Peter's review comment on this is more detailed. 

   Semantic Conditions, Intro:
   """
   Editorial suggestion: this is a very long section. 
   For better readability, I would like to suggest to 
   add some subsection titles. For example, 
   table 4.1-4.4 are "Classes and Properties", 
   4.5-4.7 are class construction, etc.
   """

Originally, I /had/ such subsections. But I then decided against having them for the following reasons: First, I think the tables themselves are quite good as replacements for subsections. They all have a title and a short intro, and there is not much cross referencing within the section. Second, in OWL Full it is not so clear as in OWL DL what grouping one should choose (there are not really "class expressions", for example).

Nevertheless, I will leave this review comment in the document for external reviewers to comment on it.

   Table "Basic Sets":
   """
   A note column will be helpful (as in OWL Semantics).
   """

Agreed. Done.

   Table "Convenient Abbreviations":
   """
   The definitions of IFAV and IFAEXT seem rather informal.
   """

Agreed. But I have to think about this in more depth, and probably won't find time before WD publication. So I leave your review comment in the document.

   Semantic Conditions for Restrictions:
   """
   Shall IOT and IOR be also kept? For example, in table 4.7, we can be more precise that y\in IOT and x\in IOR.
   """

I eventually decided against using these abbreviations. In OWL 1 Full, IOT meant the same as IR (see again the table in sec. 5.3 of the S&AS). IOR was just a short form for "CEXT_I(S_I(owl:Restriction))", so it is redundant. And explicitly writing "CEXT_I(S_I(owl:Restriction))", while being a bit longer, does not require people to know or lookup the meaning of the abbreviations. I regard this as an advantage for newbies and occasional readers, while for day by day readers it simply doesn't make a difference (btw, I believe that occasional readers will be in the vast majority :-)). 

Regarding your argument of being more precise, this is not really true. "y in IOT" means exactly the same as "y in IR", as argued above. Currently, there is only "{y|...". One could say "{y in IR|..." instead. However, what I have done to address this concern is to add some text on "conventions" at the beginning of the section on "Semantic Conditions". Please have a look and tell me whether you think that this is sufficient.

The other point, "x in IOR", or, equivalently, "x in ICEXT(IS(owl:Restriction))", does not need to be stated on the RHS of the entries in the "Restrictions" table, since this fact already follows from table 4.4 ("Properties"). For example, see the first entry for "owl:allValuesFrom". For owl:SelfRestriction, you can find the relevant information in table 4.3 ("Classes").

   Semantic Conditions, ICEXT(IS(owl:Restriction))
   """
   as ICEXT(IS(owl:Restriction)) is used many (currently 14) times, 
   how about give it a name IOR, same as in OWL 1 semantics, 
   and save some repetition?
   """

As I said above, I do not plan to bring back these abbreviations. We have now more than 70 URIs in the OWL vocabulary, not counted those in RDF, RDFS, and XSD. Should we have a short form for the class or property extension of each of them? If not, what is the criterion for having an abbreviation for some and not for others? The number of characters in their local name? Don't forget that a name, such as "owl:Restriction", already *is* an abbreviation for some much longer URI, so we would effectively introduce an abbreviation for an abbreviation. Or should the criterion be the number of uses in the document, as you seem to propose above? But then, what number? Note that the RDF Mapping document refers to the URI "owl:Restriction" many times, too, and there is also no abbreviation for it. I suppose, having one would rather be confusing to readers then helpful, and it would put the burden on occasional readers to look up the abbreviations to understand the mapping rules in the RDF Mapping, and the semantic conditions in the Full Semantics. I myself had to look up the abbreviations in OWL 1 Full again and again in the past, for example I never got it right what "IAD" was (do you know without looking it up?). 

I allow myself to drop this review comment, and to move on with my strategy on "few abbreviations", unless someone really insists on more abbreviations.
 
   Semantic Conditions, owl:members
   """
   Can we make its domain more explicit? 
   to be the union of {ICEXT(IS(E)) where E is 
   owl:AllDisjointClasses or owl:AllDisjointProperties 
   or owl:AllDifferent
   """

This is a similar question which Zhe put for ILIST. My answer there was that I don't want to have too complex sets in the "axiomatic triples". Think about how to state this in triple form! The better way to handle this would be to define an upper class for all the different "All*" classes. But that's a matter of the OWL 2 RDF Syntax, OWL 2 Full shouldn't try to fix around too much here.
 
I am addressing your comment by putting a statement to both the "Classes" and the "Properties" table which explicitly says what a "simple" axiomatic triple is (please see there!). So one can at least see that there is some design principle around.
 
   Semantic Conditions, OWL Reification
   """
   I believe its domain should be the union of {ICEXT(IS(E)) 
   where E is owl:Axiom or owl:Annotation}, as well as for 
   owl:predicate and owl:subject. I checked with the current 
   mapping to RDF document, owl:Axiom and owl:Annotation 
   are the only two cases in which owl:object is used
   """

Again, as for "owl:members". If there would be a common "owl:AbstractAnnotation" class, which has both classes as sub classes, then I would make this the domain of the OWL Reification properties. But class unions are too complex in my opinion. Again addressed by explicitly stating what a "simple" axiomatic triple is.

   Semantic Conditions, ILIST
   """
   I'm not quite sure if it is necessary: 
   as the above table also means to give axiomatic triples, 
   when we use ILIST, shall we make it explicit that it is 
   a list of individuals (e.g., owl:oneOf), 
   classes (e.g., owl:disjointUnionOf) or properties 
   (e.g., owl:onProperties)?
   """

This is exactly the same question which Zhe put before. See my answer there. Beyond that, this is again addressed by the "simple axiomatic triple" statement. And further, I am now dropping the abbreviation "ILIST" and replace it by "ICEXT(IS(rdf:List))" everywhere.

   Semantic Conditions, Enumerations
   """
   Maybe I miss something, but why one is defined 
   as "if" and the other "iff" 
   (using comprehension conditions, right?) ? 
   I *think*, as comprehension principles are given 
   later anyway, here the two cases may be defined 
   in the same way, i.e., "if" semantics.
   """

This is not related to comprehension principles. The reason for the ONLY-IF semantics in the first semantic condition is simply that the other direction already follows from the second semantic condition: If c in IDC, and l is a sequence of u1,...,un in ILV (would be the common precondition in an iff condition), and ICEXT(c) = { u1,...,un } (would be part of the RHS in an IFF condition), then c is in IC (because IDC <= IC), and l is a sequence of u1,...,un in IR (because ILV <= IR). And this would trigger the RHS of the second semantic condition, which would lead to <c,l> in IEXT(IS(owl:oneOf)). 

   Semantic Conditions, Restrictions
   """
   restrictions using owl:onProperties are not defined.
   """

Yes, I already have an Editor's Note on this. So I can remove this review comment. Also, Peter has mentioned this too, and provided a proposal how to deal with this problem. 

   Semantic Conditions, formulae in tables.
   """
   Add y,z? IR to all of them?
   """

All three reviewers had a comment in this direction, although with a somewhat different focus each. In general, having "forall x" or {x|" means that x is unconstrained, so "x in IR". In order to address this review comment, while keeping the formulae compact, I have added text explaining this convention at the beginning of the "Semantic Conditions" section.

   Semantic Conditions, N-ary
   """
   I don't see a difference between owl:distinctMembers and owl:members. Why keep both?
   """
  
This is not an OWL 2 Full specific question. Both URIs exist in the RDF syntax, and therefore OWL 2 Full has to support them both appropriately. Peter has suggested to deprecate owl:distinctMembers. Nevertheless, as in the case of owl:DataRange, OWL 2 Full must still give semantics to owl:distinctMembers. So I cannot do anything to address this review comment.

   Semantic Conditions, Axiom Annotations
   """
   add x in ICEXT(IS(owl:Axiom)) union ICEXT(IS(owl:Annotation))
   """

Here, I don't understand whether the LHS or the RHS of the semantic condition is meant. For the RHS, this would be against the strategy behind this semantic condition, which is explained in the document. The purpose of this particular semantic condition is exclusively to "recover" the original s-p-o triple, if it has been reified in an annotation. No "semantic artifacts" should be created by this semantic condition. 

For the LHS, I am still thinking about whether to have two semantic conditions, one with "x type Axiom" and one with "x type Annotation", or to keep the current semantic condition. In any case, I will /not/ add a complex premise of the form you propose above, for a similar reason given for the "simple axiomatic triples" cases discussed above.

I am removing your comment, since there is a review comment by Peter on this, too.
 
   Relationship to OWL 2 DL
   """
   Is this section normative or informative? 
   I believe in OWL 1 Full, comprehension conditions are normative.
   """
   
The role of the comprehension principles has changed in the current draft of OWL 2 Full, but this doesn't make them simply "informative". What is true is that it is not necessary for an OWL 2 Full interpretation, as defined in sec. 3, to meet all the comprehension principles (I have added some text on this in the introductory text now). Actually, this is not even possible, which was the scope of ISSUE-119 (recently closed). In OWL 2, the purpose of the comprehension principles is to allow to proof the correspondence theorem between OWL 2 DL and OWL 2 Full based on comparing which entailments are produced by both semantics. The problem is that OWL 2 DL and OWL 2 Full interpret the same RDF graph slightly differently, and this makes an entailment-based comparison approach a bit problematic. The comprehension principles allow to "balance" these differences to some degree. 

Of course, with ISSUE-119, such a proof using the comprehension principles is, in fact, trivial, since OWL 2 Full including the comprehension principles will make every RDF graph entailed by the empty RDF graph. A better way to compare the two languages would probably be to directly compare the semantic (set-theoretical) meanings of each graph under the two semantics. I believe that one can do something in this direction, since both DL and Full use (hopefully :)) the same set theory for interpreting the language constructs of OWL. If it turns out that for each DL-valid RDF graph the set-theoretic meaning given by DL logically follows from the set-theoretic meaning given by Full, I would regard it to be justified to say that OWL Full is semantically more expressive than OWL DL. But this would be a completely different approach to compare the two semantics, which would probably go too far for this working group, I guess.

Best regards,
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