Re: [MMSEM] Music Use Case & FOAF

Hi!


> This is definitively not off-topic, and I'm happy to jump in this discussion.

Great:-)

> I understand your arguments, but I think you miss something, which is really in
> the root of Knowledge Representation: the descriptive aspect!

Well - I don't really see why not putting inverse properties
everywhere is missing the descriptive aspect, but, anyway... :-)


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

Personnally, I tend to not ask too much to the machine:-)
In fact, I think there is a misunderstanding here. MO is a RDF-schema,
not a full-fledged DL ontology. I agree that, when you design a DL
ontology, you define inverse properties (as well as many more things -
restrictions, defined classes...), because you intend some reasoning
to be done on it. That's what I did with the event/timeline stuff. In
MO, we wrote some RDFS "wrappers" around it, and therefore we
intentionally restricted their expressiveness (no multiple coordinate
systems, no complex timeline maps, no fancy defined class...).
I am not at all going against the open world assumption, and if
someone wants to put online a more expressive owl ontology based on
MO: no problem.

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.

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

I am not imposing anything! First: the inverse are here, using a bit
of OWL on top of the RDFS, but marked as unstable. Feel free to use
it, but be aware you make an assumption on the reasoning consumers of
your data can handle. Finally: anyone can add a more complete OWL
layer on top of it. But then he will surely get to the point where the
Music Production Ontology was. Really expressive, lots of DL stuff,
and no one uses it because it is too complex, and involves a too
demanding reasoning process for even a small amount of instance data.

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

Same: I don't see what "The knowledge of the world might not be
complete" is doing here. I agree with that, it is the open-world
assumption. 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.

I am not going to shout against it:-)

MO just provides a schema for a webby way of linking data. I agree
this is more "web" than "semantic", but it was a deliberate choice,
and I see nothing "closed world" to it.


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

I think it is a fair assumption - and I think it is a really important
thing to do if you are also talking about "web", not only about
"semantic". (Shameless plug: you should take a look at the Linking
Open Data project of SWEO [1]).

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

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


Yes - but you need reasoning, that's exactly what I said (quoting
myself: "all of that is true if we don't have reasoning").


In most large-scale available rdf repositories, there is no reasoning.
One solution is to do it on the "consumer" side - and that's great, I
have no problem with that. You can even  temporarely "close the world"
to compute n3 rules such as "a Quartet is a group which has 4 members"
(as cwm does). This is typically not feasable in an open world, as
there can perfectly be a fifth member in the world out there:-)

(Btw, what do you mean by "forward chaining at querying time"? query
expansion? or closed world / rules inside your "consumer" application?
or DL reasoning inside it?)

Quick summary:
 * MO is a RDF-schema, wrapping some DL ontologies (Event/Timeline)
and expressing simple RDFS statements about them in order, well, to
make it simple:-)
 * 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:-) )
 * It is not assuming anything "closed-world"
 * All resources in MO have URIs:-) Feel free to add statements which
can be interpreted as DL constructs.
 * RDF+HTTP provide a webby way to link data - and MO has that in
scope, to interlink large amounts of music-related information (see
[1]).


Best regards,
Yves

[1] http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData

Received on Wednesday, 28 March 2007 22:24:46 UTC