- From: Hausenblas, Michael <michael.hausenblas@joanneum.at>
- Date: Thu, 29 Mar 2007 11:55:25 +0200
- To: Raphaël Troncy <Raphael.Troncy@cwi.nl>, "Yves Raimond" <yves.raimond@elec.qmul.ac.uk>
- Cc: "Oscar Celma" <ocelma@iua.upf.edu>, "Michiel Hildebrand" <Michiel.Hildebrand@cwi.nl>, <public-xg-mmsem@w3.org>
Gentlemen, I found your discussion so far very interesting, may I chime in here? Raphael mentioned a SWBPD-WG note where the 'inverse' issue might have been mentioned. I myself am just aware of [1] that discusses this issue w.r.t. n-ary relations, and a suggested note [2] from 2005, which tackles the problem in the context of transitive props. Another source that might be of interest is the RDF/OWL Representation of WordNet [1]. IMHO they have quite comparable objectives there, so looking at section "4. Advanced options", tells us: " ... the WordNet data does not explicitly contain the inverse of e.g. hyponymOf. The inverse statement is only implied with the OWL statement hyponymOf owl:inverseOf hypernymOf. In other words, querying the hypernymOf relation will return no results when using software that is not OWL-aware. Therefore, RDFS users should not use the inverse properties because they do not yield query results. Because querying for X hypernymOf Y is just a syntactic variant of querying for Y hyponymOf X RDFS users do not have less information than OWL users." Does this help? Cheers, Michael [1] http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 [2] http://www.w3.org/2001/sw/BestPractices/OEP/#suggest [3] http://www.w3.org/TR/wordnet-rdf/ ---------------------------------------------------------- Michael Hausenblas, MSc. Institute of Information Systems & Information Management JOANNEUM RESEARCH Forschungsgesellschaft mbH http://www.joanneum.at/iis/ ---------------------------------------------------------- >-----Original Message----- >From: public-xg-mmsem-request@w3.org >[mailto:public-xg-mmsem-request@w3.org] On Behalf Of Raphaël Troncy >Sent: Thursday, March 29, 2007 11:10 AM >To: Yves Raimond >Cc: Oscar Celma; Michiel Hildebrand; public-xg-mmsem@w3.org >Subject: 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:52:05 UTC