Re: [MMSEM] Music Use Case & FOAF

Dear Yves,

Thanks for your answers.

> In fact, I think there is a misunderstanding here. MO is a RDF-schema,
> not a full-fledged DL ontology.

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

> But the point of MO was to dump *huge* repositories in RDF
> (musicbrainz, cc databases...), and we did not want to make the
> "ontology" too complex, to finally have multiple rdf sources
> expressing the same thing in a lot of different ways, and making the
> assumption that either the RDF provider (which is not feasable for
> this amount of data) or the "consumer" can cope with that. Well,
> that's ok, but you make a strong assumption on its capabilities.

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 :-)

> Finally: anyone can add a more complete OWL
> layer on top of it.

Yes, and this is exactly what will happen, which I think is a shame given the the great
job you did.
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 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.

> I don't see why not defining inverses for all properties
> in a particular ontology goes against it. It is an open-world, as you
> say: so everyone is free to just write a small RDF document:
> mo:has_track owl:inverseOf myDLmo:is_in_album
> and publish it on the web.

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.

> (Shameless plug: you should take a look at the Linking
> Open Data project of SWEO [1]).

Thanks, this is indeed a very interesting link.

> And I don't think FOAF has a foaf:is_known_by property:-) We are here
> in the same sort of case.

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.

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

> (Btw, what do you mean by "forward chaining at querying time"?

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.

>  * It has the inverse of most of its properties, but marked as
> unstable, as well as anything OWL inside it (look at the section
> "DL-candies" in the RDFS file:-) )

Hummm, I miss that. Is there a named property in MO, inverse of "mo:has_track"?
This is all I 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 Thursday, 29 March 2007 09:11:09 UTC