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

Hi Peter,

here is the second part of my answer to your review comments! This is still not my last mail, since I will also answer to your other mail concerning those semantic conditions having an existentially quantified variable in it.
 
Peter F. Patel-Schneider wrote on September 03, 2008:

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

The reason for "= IR" is that "<= IR" would cancel out some DL
entailments from Full:

  G1 := { 
    ex:w rdf:type owl:Thing
    ex:C rdf:type owl:Class
    ex:w rdf:type ex:C
  }

  G2 := {
    ex:w rdf:type owl:NamedIndividual
    ex:C rdf:type owl:Class
    ex:w rdf:type ex:C
  }

Under the OWL 2 DL semantics, these both RDF graphs are semantically equivalent, since "ex:w rdf:type owl:NamedIndividual" reverse-maps to a declaration, so this triple is not even interpreted by the DL-Semantics. But in OWL 2 Full, if the class extension of owl:NamedIndividual is not required to be the whole universe, then interpretations exist where the first graph is true, and the second graph is false: Take an interpretation which maps the class extension of owl:NamedIndividual to a proper subset of IR, and then let ex:w denote an individual in the complement of ICEXT(IS(owl:NamedIndividual)). Thus, G1 |= G2 holds under OWL 2 DL Semantics, but would not hold under OWL 2 Full Semantics.

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

The main problem with the above semantic conditions (or more generally: with n-ary datatypes in OWL 2 Full) is that it requires to have n-tuples as instances of the class c:

  "<z1,...,zn> in ICEXT(c)"

This isn't supported by RDFS, and at least not yet by OWL 2 Full. An n-tuple is not an individual in the universe (just as a binary tuple in the property extension of some property is not an individual), and therefore cannot be a member of the class extension of some class.

What probably needs to be done is to come up with a new sort of extension: A "nary-datarange extension" IDEXT_n(.), which allows to state:

  "<z1,...,zn> in IDEXT_n(c)"

Fortunately, it is not a problem in RDF to assign different kinds of extensions to the same individual, and these extensions do not even need to have to be related with each other (e.g.: for some class/property-individual w ICEXT(w) does not be related to IEXT(w)). 

However, there will still be a few problems:

  * Until now, the range of someValuesFrom and allValuesFrom was IC. Now the range would also need to cover all individuals, which have some nary-datarange extension for arbitrary n.

  * The above semantic conditions should be more specific by entailing that c is an n-ary datarange. 

Datatype complements are hit by this problem, too.

I have done the following: I added your proposed semantic conditions to the Restrictions table, and removed the separate table. Further, I added comprehension principles to the "Comprehension Principles for Restrictions" table. I also added an editor's note to the beginning of the document, which explains the problem. I will deal with this problem after the WD submission, because I will need some time to think about it.

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

I thought about this, too, but decided against, for several reasons:

(1) This would go beyond what OWL 2 DL provides. OWL 2 DL only has a means to express /sub/ property chains, not the more general property chains. In OWL 1, OWL Full did not have any major language features that OWL DL did not have. I don't want to change this in OWL 2, too.

(2) I see no reason to require for each sub property chain the existence of a property (an individual!), which has IEXT(p1)o...oIEXT(pn) as its property extension. The current semantic condition does not introduce a property of this kind (also see point (3)!), and this is sufficient to compete with the DL semantics regarding semantic expressivity.

(3) In the current RDF syntax

  x rdfs:subPropertyOf q 
  x owl:propertyChain (p1...pn)

it is not necessarily the case that x stands the chain property. x is only intended to be the root node of the axiom, as in other cases, like negative property assertions, too. In fact, x happens to be a property, but this is simply for the reason that it is the LHS of a sub property axiom (first triple). To make this clearer, let's change the RDF syntax slightly into:

  x owl:subPropertyChainAxiom 
  x owl:superProperty q
  x owl:propertyChain (p1...pn)

I would give the same semantic conditions to this construct as to the original one. In this case, one probably would not come to the idea that x stands for the chain property. And as I said above, the current semantics do not even demand that there exists such a chain property in every case. The fact that the current RDF syntax makes x into a sub property of the property q is a confusing semantic artifact, which I would like to see removed from OWL 2.

(4) The possibility to be able to define such a semantic condition for property chains largely depends on the chosen RDF syntax. For example, with the following alternative RDF syntax, it would not be possible:

  q owl:subsumesPropertyChain (p1,...,pn)

Let me say that I prefer this single-triple RDF syntax over the current one, since it doesn't introduce an artifact sub property of q. I am considering raising an issue.

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

Yes, now that annotations on annotations exist, there needs to be some change. I have taken your proposed introductory text as is, with the slight exception that I removed the "some" in "for some axiom annotations" (I did not understand the "some", so please tell me what it means, then I will put it in again).

I also exchanged the semantic condition by the two you propose above. But I am not really happy with having two semantic conditions, and with having the typing triples for owl:Axiom and owl:Annotation in their LHS. So I would like to discuss this with you, because I believe that my original one is sufficient (we can defer this discussion a bit, I added an EdNote.)
 
>- 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.

I will answer your other mail, which contains concrete proposals. I will also cc this mail to Jie, who asked this question, too. I will send my mail later this day, or tomorrow morning at latest. 

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