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: Thu, 29 Mar 2007 20:01:21 +0100
Message-ID: <82593ac00703291201r688db46esdd3abc56c1bc4925@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

Hello!

Sorry for the delay - Internet was down today at my place:-(

Well, let's get back to the debate (I really like this one:-) )

> I understood that ... but not that now RDFS has model-theory semantics, there is not
> much difference, just less entailment rules.

Just a small point:
I don't think OWL can be defined just by "entailment rules" - it is
far more than that! I am not an OWL expert though. But my personal
experience was that I tried large scale reasoning with a lot of
different reasoners. None of them was scalable enough (yes - it was
two years ago, so it might have changed by now). So, as I thought like
you at this time "it is just a bunch of entailment rules", I took my
XSB Prolog engine (yes, I am kind of a Prolog geek:-) ), which handles
tabling, and started coding my own reasoner (I think if you google for
"xsbowl" you might find it, but I have not maintained it since quite a
while...) - well, after two months of hard work, I thought that
throwing my head against the wall would be less painful (actually, it
was:-) ). It is not that easy, and the reasoning mechanisms are quite
complex. The model-theoretic semantics does not state anything about
the complexity of the reasoning process!!



> I think I understand that, and I have the same argument, but with a different
> conclusion. Because I don't want to make the ontology "complex", I don't want to impose
> a single way to express things. And I don't make assumptions about what the RDF provider
> or consummer should cope with, I let the SemanticWeb taking care of that. The tools are
> here, the complexity is not high, there are no technological challenges, we have just to
> use them :-)

I definitely have lower expectations than you about what "is" the
semantic web:-)

But, in fact, I still really don't understand your overall point. The
user wants to express this track is on this album - why should it be
more difficult for him to say "album mo:has_track track"??? It is
exactly the same "complexity" to write this triple instead of "track
mo:on_album album"! If he bothers to take a look at MO and see how to
express this, he won't care about which triple to write! he just want
to write not too much triples!

And I think it is much more confusing for a user to take a look at an
ontology, and find two ways of expressing one particular thing! Which
one should I choose? Which form is the most popular - because, really
often, I cannot say "the semantic web will solve this problem for me"!



> Yes, and this is exactly what will happen, which I think is a shame given the the great
> job you did.

I have nothing against someone adding statements about the URIs we
define in MO - this is the purpose of the semantic web:-) But I think
our small OWL stuff should be enough for a while, for most of the
people.


> I have never claimed that we _should_ have inverse properties for everything, just when
> it is useful, and in this case, it seems so natural ! Because we are talking about
> songs, tracks, the point of interest of many applications ! In your situation, I need to
> describe an album for knowing its track. But if I don't care about the other tracks, it
> is a quite non natural way of describing the knowledge.

I won't argue on what is natural and what is not - Ivan talked about
it on the MO mailing list, and I think his conclusion was that it
mostly depends on your language (based on passive or active forms).

>
> I will put you the problem in the other way around. Properties are directed in RDF: you
> specify a domain and a range. When you define a property (and its way) you make a
> modeling decision according to the common use of this property in your
> domain/application. For example, you will either decide that: ex:bag ex:contains
> ex:object OR ex:object ex:is_contained ex:bag
> If both the domain and the range classes are equally used/important in your domain, then
> you should better defined both properties, marked as inverse. I think the Semantic Web
> Best Practices Working Group has written a note about that.
>

Not heard of it! Do you have a reference?
But really it would surprise me... Again, it is exactly the same thing
to write a triple or its inverse.

a p b.
is equally a statement on a and on b. a is no more important or relevant than b.



> You're right, and this is what will happen. But then you reduce the usability of your
> ontology, because you almost force people (at least us) to define this inverse property
> where we would prefer that this property would be defined in the MO namespace.

If you define an "inverse", you will refer to MO, so I don't see why
you "reduce" its usability - you just extend it. It is like saying "I
commited a piece of code to Jena, so I reduce its usability from the
point of vue of its developers" :-)


> Well not really. It depends on your application. What is the most important: the persons
> you know, or the persons that know you?
> FOAF considers that the first one is more important. If they were equally important,
> then it certainly worth to have both properties.
> In your case, I strongly believe that BOTH the albums and the tracks are first class
> objects, equally important, and that you should be able to provide statements on them
> without the other.

Again:
album mo:has_track track
is *equally* a statement about the album and about the track. I don't
see what's wrong with that!
A subject is not at all more important than an object! There are both
as relevant (and needed, otherwise there will be no statement:-) )

>
> > In most large-scale available rdf repositories, there is no reasoning.
>
> Well, here I disagree. About which (large-scale) RDF repositories you're talking ?
> Sesame 1, 2, JENA, SWI-Prolog, OWLIM, KAON, RDFSuite, rdfDB, Redland, etc ... all have
> RDF+RDFS reasoning support ...

Yes - but inverseOf is OWL:-)



> I just mean the reasoning is performed during the query and not by saturating your
> knowledge base when you upload new data as it is usually the case for optimization.
> SPARQL does not do forward chaining.

mmm... it seems closer to prolog-style backtracking than forward
chaining. Forward chaining (RETE?) is actually done when you upload
new data.


> Hummm, I miss that. Is there a named property in MO, inverse of "mo:has_track"?
> This is all I want :-)

Well, in fact, this is the only property I am not entirely sure:-)
I'll have to check it. But as I said, I still don't see the point:-)
It seems like you really think a subject is more important than an
object in a RDF statement!

In fact, I think you have a real `metadata' approach (id3, mpeg7,
...): a central object, and other objects gravitating around it -
thus, you think that a subject is more important in a RDF statement. I
am not saying this is wrong, this is just not my approach:-) So, if I
am right (we don't have the same approach), we can keep on arguing
forever!


(Btw, we use DL a lot in the EASAIER project, but not for this sort of
thing (because, yes, we thought it was useless, and just adding
complexity for nothing) - we use it to merge several RDF sources,
using functional/ivfunctional properties.)


Best regards,
Yves
Received on Thursday, 29 March 2007 19:01:26 GMT

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