W3C home > Mailing lists > Public > public-xg-mmsem@w3.org > March 2007

Re: [MMSEM] Music Use Case & FOAF

From: Yves Raimond <yves.raimond@elec.qmul.ac.uk>
Date: Wed, 28 Mar 2007 19:00:30 +0100
Message-ID: <82593ac00703281100v6ba32f06kdbbef3a825303114@mail.gmail.com>
To: "RaphaŽl Troncy" <Raphael.Troncy@cwi.nl>
Cc: "Oscar Celma" <ocelma@iua.upf.edu>, "Michiel Hildebrand" <Michiel.Hildebrand@cwi.nl>, public-xg-mmsem@w3.org

Hi!


> Please, correct me if I'm wrong but, the point is that mo:has_track is a
> property between a mo:Record and a mo:Track. (a mo:Record being a
> mo:MuscialManifestation). We would like to have the inverse property because
> sometimes you want to describe an individual song (mo:Track) and say from
> which album (mo:Record) it comes from.

Mmmm... What you say is really similar to what some people said on the
MO mailing list.

So I'll just try to develop a bit my point of vue (I hope it is not
too off-topic:-) ):

I still don't understand why we need the inverse here. For me:
album mo:has_track track.
and
track mo:is_on_album album.

are exactly expressing the same statement, therefore I don't know why
we should allow both. And one of the point of RDF is to defocus data,
so it is not relevant (at least, to me) to  allow focusing on the
Track, or on the Album, or any particular concept.

As described in [1], when you dereference the uri of a track, you
should get all the statements in which a the track is the subject, but
also every statements in which it is the object.
For example, you can try:
$curl -v -H "Accept: application/rdf+xml"
http://purl.org/dbtune/resource/magnatune/track/1001

You will access {album mo:has_track track} as well, which is
expressing what you want.


> Defining an inverse property will certainly not add complexity to the model
> (nor from the point of view of reasoning) so I don't see where there is a
> tradeoff ... if people don't need it, they don't use it.
> >From  the query side, the complexity will not be higher, both with or
> without OWL/RDF(S)/RDF reasoning.

On the query side you will have to do something like (sorry if it's
not exactly that, I am not at all a sparql expert:-) ):

SELECT ?t ?a
WHERE
{
?a a mo:Album.
?t a mo:Track.
{
{
?a mo:has_track ?t.
}
UNION
{
?t mo:is_on_album ?a.
}
}
}
because you don't know how this particular statement is described in
the store. Did the owner of the data choose to focus on the Album? or
on the Track?

And this is indeed a bit more complex than:
SELECT ?t ?a
WHERE
{
?a a mo:Album;
    ?a mo:has_track ?t.
}

(all of that is true in the case we don't have reasoning in the store)


Best regards,
Yves

[1]http://www.w3.org/DesignIssues/LinkedData.html
Received on Wednesday, 28 March 2007 18:00:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:21 GMT