Re: [MMSEM] Music Use Case & FOAF

Hi Yves,

This is definitively not off-topic, and I'm happy to jump in this discussion.
I understand your arguments, but I think you miss something, which is really in
the root of Knowledge Representation: the descriptive aspect!

> 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.

Given that the signature of these properties have been correctly defined, then
you're right, these statements indeed express the same thing. But this is exactly
the point of the Semantic Web. Contrary to a normal database where you want that
people enter the data according to a specific schema, you_don't_want that in the
Semantic Web. People should be free to express that an album has a track OR that a
track is in an album. And this is because behind you have the power of the formal
semantics, that the machine is able to cope with both representation and establish
the equivalence.
>From a pure descriptive point of view, you should therefore allow both.

> 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.

Exactly ! And this argument should tell you that you don't have to impose a way of
describing the world. You could make the same analogy with children/parents (both
properties are necessary even though they might be considered inverse)

> 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.

Nope ... you have a database vision. The knowledge of the world might not be
complete. On the semantic web, the knowledge can be distributed, and partially
unavailable at one moment and you have to cope with that.

> 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.

But here you make assumptions on where and how to access to this data ...
something you can't make on the Web.

> > 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?

No you don't necessarily need the union, if the 2 properties are stated as
inverse.
The reasoning can be made at uploading time (what you call reasoning on your
store) or at query time (forward chaining).

In conclusion, you should seriously think to add this property, and let people use
it if they want.
Best regards.

    Raphaël

--
Raphaël Troncy
CWI (Centre for Mathematics and Computer Science),
Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
Tel: +31 (0)20 - 592 4093
Fax: +31 (0)20 - 592 4312
Web: http://www.cwi.nl/~troncy/

Received on Wednesday, 28 March 2007 20:31:39 UTC