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

On Fri, Sep 12, 2008 at 5:08 AM, Michael Schneider <schneid@fzi.de> wrote:
> 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.
>
What in my mind is that some pictorial representation of the relations
between basic sets. I attached one I used in a seminar talk. Please
forgive its ugliness and over-simplification. My suggestion is meant
to add something like this.

> 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.
>
I think we don't need to visualize semantic conditions at all. I
agreed that 2nd example in the RDF semantics is a little scary to many
beginners (including myself at certain time). We won't have figures of
that level.

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

you are right, my mistake.
>
>    "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".
>
yes

>    "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)).
>
agree

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

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

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

>   Interpretations:
>   """
>   Add "where ''P'' means powerset" after IEXT definition.
>   """
>
> Agreed. Added.
>
thanks

>   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).
>
agree now.

> 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 :-)).
>
agree now

> 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.
>
That's helpful. A minor suggestion is to use bold font or else to
highlight the word "convention".

> 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").
>
Right. But explicitly mention this fact again at table 4.7 will make
it even more clear, e.g., saying "Please note that x in
ICEXT(IS(owl:Restriction)) in all following conditions."

>   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?).
>
Em, I tend to agree with you now. For example,
IEXT(IS(owl:onProperties))  is also used many times, but introducing a
name for it may go too far. IAD in OWL 1 maybe an extreme of this - it
is used only once after definition, I think.

> 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 see the point. I checked again and saw actually the type information
of the list can be obtained from other tables, e.g., Table 4.12 for
owl:AllDisjointClasses.

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

>   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.
>
Same as the above

>   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.
>
Same as the above

>   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)).
>
I got the point now
>   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.
>
Addressed earlier

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

>   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.
>
In fact, I support your Editor's Note before current Table 4.17, i.e.,
removing the typing triples. This will allow annotations in OWL full
on any triples. So far I don't see a problem without the  typing
triples in inference.


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

*Finally* we will add "informative" and "normative" to each section's
title, following RDF and OWL 1 traditions.

>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.
>
I need to dig more to fully understand this. I'm reading this now

Carroll, Jeremy; Turner, Dave. The Consistency of OWL Full. Technical
Reports HPL-2008-58 . HP Lab, 2008.
http://www.hpl.hp.com/techreports/2008/HPL-2008-58.html

BTW, will it be a proper citation to the discussion in section 6?

Thank you again Michael, my questions are well addressed!

Jie

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



-- 
Jie
http://www.cs.rpi.edu/~baojie