W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2000

Re: Some thoughts on the semantics of domain and range (was: Re: RDFS bug "A property can have at most one range property")

From: Natalya Fridman Noy <noy@SMI.Stanford.EDU>
Date: Thu, 14 Sep 2000 17:27:52 -0700
Message-Id: <>
To: Dan Brickley <Daniel.Brickley@bristol.ac.uk>, Guha <guha@guha.com>
Cc: www-rdf-interest@w3.org
At 10:13 AM 9/14/00 +0100, Dan Brickley wrote:
>For eg: take the authors/Persons/Documents example. We can say
>Someone else might subsequently grumble that this was a bad bit of
>modelling, since (say) Songs can also have an author. Now if they want
>to re-use the 'author' relation on some resource of type Song, it'll
>(with conjunctive semantics) imply that their song is also a document.
>And for sake of this exammple, people don't like that. So they go create
>a new similar-but-not-the-same property s2:songAuthor. Since this was
>before rdfs:subPropertyOf, this was seen as a bad thing, so we weakened
>(voided) the semantics of rdfs:domain to encourage property re-use at
>the expense of supporting inference.

I am sorry, but I don't quite see how having rdfs:subPropertyOf solves the 
problem. Could you please elaborate?

Suppose, we indeed declare songAuthor to be a subproperty of author:

         rdfs:subPropertyOf(songAuthor, author)

And suppose we have

         domain(author, Document).

Now, what we would like to say is:

         domain(songAuthor, Song)

Suppose now we have mySong as an instance of Song:

         rdf:type(mySong, Song).

We can then say

         songAuthor (mySong, me)

However, since songAuthor is a subproperty of Author, we can infer that

         author (mySong, me)

Therefore, we are back to square one: mySong has to be a Document.

So, how did having rdfs:subPropertyOf changed anything with regards to 
Songs (or at least songs that have authors) having to be Documents?

Received on Thursday, 14 September 2000 20:28:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:25 UTC