- From: Natalya Fridman Noy <noy@SMI.Stanford.EDU>
- Date: Thu, 14 Sep 2000 17:27:52 -0700
- 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
>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
Received on Thursday, 14 September 2000 20:28:01 UTC