- From: Yves Raimond <yves.raimond@elec.qmul.ac.uk>
- Date: Wed, 28 Mar 2007 19:00:30 +0100
- 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 UTC