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

At 10:13 AM 9/14/00 +0100, Dan Brickley wrote:
>For eg: take the authors/Persons/Documents example. We can say
>domain(author,Document).
>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?

Natasha