Re: Part II of my answers to PFPS' review of the RDF-Based Semantics

I'm just responding to any remaining open points.  I'm fine with the
responses to my other points.

From: "Michael Schneider" <schneid@fzi.de>
Subject: Part II of my answers to PFPS' review of the RDF-Based Semantics [RE: Initial comments on OWL 2 Full Semantics]
Date: Sun, 14 Sep 2008 20:15:14 +0200

[...]

> Peter F. Patel-Schneider wrote on September 03, 2008:

[...]

Nary datatypes:

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

Well, you can consider this either a problem or a feature.  :-)

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

Hmm.  Not really.  RDF and RDFS "support" lots of things in the domain,
including n-tuples, sets, philosophical attitudes, etc., all of which
can perfectly easily belong to classes.  Of course, RDF and RDFS don't
require any of these kinds of things to be in the domain, nor to be in
any particular 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)).

I don't see that there is any reason in RDF or RDFS that the class
extension of some datatypes and data ranges cannot be tuples.  Thus I
don't see any need to introduce another semantic extension function.

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

As above, I don't see any reason to not allow datatype classes whose
class extensions have tuples in them.

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

Yes, probably.

> Datatype complements are hit by this problem, too.

I don't see a particular problem.

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

Having an editor's note for n-ary datatypes is fine by me.


Annotations:

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

Only some annotations need this reification.  Annotations on entities
and annotations on certain axioms (the few that have their own main
blank node) do not need the reification process.

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

This can be deferred.

[...]

> Regards,
> Michael

peter

Received on Monday, 15 September 2008 13:30:11 UTC