RE: [MMSEM] Music Use Case & FOAF

Hi all,

It is a very interesting discussion indeed. I would like to add to what
Raphael said that the semantic web is mainly based in RDF and OWL, which
have open world semantics. This means that the knowledge is not complete
(may exist somewhere in the world) and therefore you cannot have
negation-as-failure like normal databases have. However, there is a long
discussion whether is better to use open or closed world semantics (or
something in between, scoped negation-as-failure) in the semantic web. There
are applications that require closed world semantics and
negation-as-failure. I strongly believe that the Music use case must be
based on the open world assumption.

Vassilis


> -----Original Message-----
> From: public-xg-mmsem-request@w3.org [mailto:public-xg-mmsem-
> request@w3.org] On Behalf Of Raphael Troncy
> Sent: Wednesday, March 28, 2007 11:31 PM
> To: Yves Raimond
> Cc: Oscar Celma; Michiel Hildebrand; public-xg-mmsem@w3.org
> Subject: 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 21:26:55 UTC