W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Re: RDF-Based Semantics and n-ary dataranges

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 01 Apr 2009 17:09:34 -0400 (EDT)
Message-Id: <20090401.170934.176234297.pfps@research.bell-labs.com>
To: schneid@fzi.de
Cc: public-owl-wg@w3.org
From: "Michael Schneider" <schneid@fzi.de>
Subject: RE: RDF-Based Semantics and n-ary dataranges
Date: Wed, 1 Apr 2009 21:44:54 +0200

>>-----Original Message-----
>>From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org]
>>On Behalf Of Ian Horrocks
>>Sent: Wednesday, April 01, 2009 8:47 PM
>>To: W3C OWL Working Group
>>Subject: RDF-Based Semantics and n-ary dataranges
>>
>>We didn't manage to conclude this discussion.
>>
>>Summary of (my understanding of) the discussion so far:

[...]

>>* the structure of n-ary restrictions is defined in SS&FS, but
>>(hopefully) only the unary case can occur in conforming ontologies
>>(as above)
>>* Michael believes that as a result the RDF-Based semantics is broken
> 
> Yes, it is _syntactically_ broken. It essentially contains an expression of
> the form
> 
>   "<x1,...,xn> in S"
> 
> where "S" is defined to denote a subset of the object domain. 

I still don't understand why this can be considered to be syntactically
or semantically or even pragmatically broken. 

It is entirely possible to have an OWL 2 Full interpretation
	I = <IR, IP, IEXT, IS, IL, LV>
where LV and thus IR contains not only things like the integers but
also things like pairs, triples, quads, quints, ... over the integers
(or over reals, or over complex numbers, or even over elements in
IR-LV).

However, even if LV only contains "standard" data values there is
nothing wrong with asking whether LV contains a tuple.  This is a
perfectly well-formed question even in this case, it is just that the
answer is then always false.  (Which is, of course, the expected and
desirable answer.)

> If something like this would be written in the Direct Semantics, you would
> certainly be horrified. 

Why?  Again, the answer would just be false.  

> And so you should be for the RDF-Based Semantics as
> well. 

I'm certainly not horrified, and I don't see why anyone would be horrified.

> Because this has nothing to do with the distinction between the Direct
> Semantics and the RDF-Based Semantics. It only has to do with what can be
> written syntactically in the set theory that underlies both our semantics.

There is nothing in even set theory that requires that the atomic set
elements not have some internal structure.

> (There are other problems as well, but I think this is the simplest one to
> acknowledge.) 

I don't see this problem, nor can I think of any other problems.

> The problem is: Interpretation function under the semantics of RDF are
> restricted to interpret names by individuals (instances of the domain IR).
> In addition (in RDFS), there are two functions that allow me to /indirectly/
> talk about subsets of the domain IR (the class extension function
> "ICEXT()"), and subsets of the product IRxIR (the property extension
> function "IEXT()"). But there is not yet such a function (or a collection of
> functions) that allow me to talk about subsets of the products IR^n for
> arbitrary n. 

I don't follow this reasoning at all.  Certainly there is nothing (so
far) that requires tuples to be present in IR, but there is also nothing
(so far) that forbids tuples from being present in IR. 

> So the underlying logic may allow me to write statements as above, at least
> for an "S" representing a set of n-ary tuples. The problem is that I do not
> reach this functionality of the underlying logic from within the current
> framework of the RDFS semantics. So I need to extend this framework. This is
> what I suggest to do (before April 15th...).

Again, I don't think that any change is required.  As far as I can see,
the RDF-Based Semantics is currently entirely coherent.

>>* Peter doesn't agree.

Yep.

>>Comments?
>>
>>Ian
>>

> Cheers,
> Michael

peter
Received on Wednesday, 1 April 2009 21:07:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 April 2009 21:07:54 GMT