Re: Urgent! Semantic question about rdfs:domain.

From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 04/25/01


I have appended an email with some useful pointers relating to the
earlier discussion.

Ian

On April 25, Lynn Andrea Stein writes:
> This was the subject of some discussion within the pre-DAML RDF community as
> well.  I believe that what was settled on, for RDF, at least, was what you call
> "restriction from above" for both domain and range.  I thought some statement to
> this effect was going to be made.  On the other hand, RDF/S as originally written
> clearly says restriction from below on domain.
> 
> Perhaps Ralph remembers this round?
> 
> Lynn
> 
> 
> pat hayes wrote:
> 
> > Checking thru the walk-thru.  The section which introduces properties
> > is worded in a way that suggests a different semantics from the one
> > given in the model theory.
> >
> > The example says that the domain of hasParent is #Animal, and this
> > clearly suggests that the intention is that this should mean that
> > every animal has a parent, ie that hasParent applies to the entire
> > domain class (in contrast to the range specification.) I wrote the
> > following 'explanation' before realising that it might not be true:
> >
> > "The range specification restricts the property from 'above', ie it
> > specifies a class into which the value of the property must fit,
> > while the domain restricts it from 'below', ie it specifies a class
> > which must be included in the class of things that the property can
> > be applied to. "
> >
> > Is this correct??  Because if so, the semantics is wrong at this point. It says
> >
> > <rdfs:domain,?P,?C>    means:    if <x,y> in IR(?P) then x in IC(?C)
> >
> > but if the above is correct then it ought to say:
> >
> > <rdfs:domain,?P,?C>    means:   if x in IC(?C) then for some y, <x,y> in IR(?P)
> >
> > If the semantics is correct, however, then the example in the
> > walkthrough is rather misleading, and we will need to correct against
> > any potential misunderstanding. Also, in this case, HOW does someone
> > give a 'lower' bound to the domain of a property? Eg how can one say
> > that hasParent applies to *any* animal? (If both domain and range
> > restrict from above, then it would be consistent to give all
> > properties empty domains and ranges.)
> >
> > I await clarification from the Semantic Gurus, and will write
> > appropriate prose for the walkthru when clarity is restored to my
> > mind.
> >
> > Pat Hayes
> >
> > PS. A related question. If
> >     <rdfs:domain,?P,?D>
> >     <rdfs:range,?P,?R>
> >     <inverseOf,?P,?S>
> > does it follow that
> >     <rdfs:domain, ?S,?R>
> >     <rdfs:range,?S,?D>
> > ??
> >
> > PPS. The only way to really learn something is to try teaching it to
> > other people :-)
> >
> > ---------------------------------------------------------------------
> > IHMC                                    (850)434 8903   home
> > 40 South Alcaniz St.                    (850)202 4416   office
> > Pensacola,  FL 32501                    (850)202 4440   fax
> > phayes@ai.uwf.edu
> > http://www.coginst.uwf.edu/~phayes
> 

------- start of forwarded message -------
From: Jeen Broekstra <jbroeks@cs.vu.nl>
To: oil-con@cs.vu.nl
Date: Mon, 25 Sep 2000 13:19:55 +0200 (CEST)
Subject: Discussion on rdfs:range semantics on W3C RDF list
Envelope-to: ihorrocks@mailhost.cs.man.ac.uk
Delivery-date: Mon, 25 Sep 2000 12:20:24 +0100


Hello all,

as promised earlier, some pointers to the discussion that has
taken place (it seems to have died out a bit now) on the RDF
interest mailinglist about the semantics of rdfs:domain and
rdfs:range. As some of you may know, this was especially of
interest to us, since we have argued before[1] that the
definition as it is now is flawed, most particularly the
restriction that only one range statement is allowed.

http://lists.w3.org/Archives/Public/www-rdf-interest/

is the archive of the www-rdf-interest mailinglist.


http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0107.html

is the message by Tim Berners-Lee which states that the current
semantics of rdfs:range are flawed. The message contains pointers
to a paper by Wolfram Conen and Reinhold Klapsing about the
logical interpretation of RDFS. The ensuing discussion between
TBL and Dan Brickley is interesting.


http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0132.html

is the message by me, Michel and Ian that explains the OIL-view
on the semantics of domain and range. Most of the following
discussion can be found in this thread. Especially the
contributions of Guha, Dan Brickley and Nataly Fridman Noy are of
interest.


Quick summary: TBL's claim (with which Michel, Ian and I
agree) is that the current semantics of domain and range are
flawed. The model should allow for multiple range restrictions,
and multiple restrictions should be interpreted using
intersection semantics. 

At first I thought Guha disagreed with this view, but it seems
that I misinterpreted his posting. What he says is: "Allowing
multiple rdfs:domain/rdfs:range with disjunctive semantics is a
bad idea because it makes the system non-monotonic. Conjunctive
semantics are fine and possibly useful."

I first interpreted this as a rebuttal of our approach where
he accidentally mixed up conjunctive (intersection) and
disjunctive (union) semantics. Now I realize that his point is
probably meant in support of our claim.

Anyway, the discussion is interesting for us OIL-people to read
and where possible contribute. The issue is important in the
sense that in a very short time a revised CR of the RDF Schema
spec will be published, and all requests for change should be in
by then.

Regards,

Jeen

[1] See http://www.ontoknowledge.org/oil/papers/extending-rdfs.html
-- 
                               Vrije Universiteit, Faculty of Sciences
Jeen Broekstra              Division of Mathematics & Computer Science
jbroeks@cs.vu.nl                                    de Boelelaan 1081a
http://www.cs.vu.nl/~jbroeks        1081 HV Amsterdam, the Netherlands
------- end of forwarded message -------


This archive was generated by hypermail 2.1.4 : 04/02/02 EST