- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Thu, 27 Nov 2003 21:21:57 +0000
- To: "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk>
- Cc: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Hi Alistair, > Does this change your opinion? Yes. Sorry, I hadn't read your example properly. > So I'm saying the best way to interpret equivalence expressions is > as being set-like. They do imply something about sets, but the > concepts themselves are not the sets, the sets are the sets of > resources that are about the concepts. OK. As it happens, in RDF a class is not itself a set instances either, it is something which has an extension which is in turn a set of instances. It's this level of indirection which allows you to have things which are both classes and instances without stepping outside the bounds of normal set theory. This is quite close to what you are trying to capture here. > Now if I say something like ... > > <soks:Concept rdf:about="#A"> > <owl:equivalentClass rdf:parseType="resource"> > <owl:intersectionOf rdf:parseType="collection"> > <soks:Concept rdf:about="#B"/> > <soks:Concept rdf:about="#C"/> > </owl:intersectionOf> > </owl:equivalentClass> > </soks:Concept> > > ... I am in fact saying something about the things that are true > instances of the concepts. That is, things with the property > <rdf:type> pointing to the concepts. There are certainly KOS applications in which this is a perfectly valid modelling approach - where the concepts can be reasonably treated as classes, where the resources being organized are instances of the concept and in those cases this is a good way of expressing the mapping which does allow you to transform queries. However, I do agree with you that thesauri don't typically work that way and using rdf:type to represent the relationship between the concept and the resources associated with that concept is not always going to be appropriate. So I do agree with your approach. It is a shame to end up with something which is so decoupled from RDFS/OWL though. There do seem to be applications where people start out with an informal thesaurus like model of the world and then over time move to a more ontology-like model (the GeneOntology is, perhaps, an example of this). It would be appealing to have a KOS representation that facilitated that by exploiting the quite forgiving nature of the RDFS semantics but I guess there is too much of a disconnect with thesauri to make that work. [And I still recommend changing rdf:li but that's a minor point.] Cheers, Dave Miles, AJ (Alistair) wrote: > Hi Dave, > > Thanks for the heads up on the <rdf:li> property, that does need changing I > think. > > To explain why I did what I did ... > > Let's say I have concept A from thesaurus T1, and concepts B and C from > thesaurus T2. I also have a document collection D which has been indexed > against concepts from T2. > > Somebody tells me that 'concept A is exactly equivalent to concepts B and > C.' > > If I interpret this to mean that 'the set of resources that are about > concept A is identical to the intersection of the set of resources that are > about concept B and the set of resources that are about concept C' I have > some useful information about how to transform queries. Now if somebody > asks for documents from D that are about concept A, I can transform this > into a query in terms of B and C and guarantee accurate results. > > So I'm saying the best way to interpret equivalence expressions is as being > set-like. They do imply something about sets, but the concepts themselves > are not the sets, the sets are the sets of resources that are about the > concepts. > > This is the interpretation taken by Doerr > <http://jodi.ecs.soton.ac.uk/Articles/v01/i08/Doerr/>. > > Now if I say something like ... > > <soks:Concept rdf:about="#A"> > <owl:equivalentClass rdf:parseType="resource"> > <owl:intersectionOf rdf:parseType="collection"> > <soks:Concept rdf:about="#B"/> > <soks:Concept rdf:about="#C"/> > </owl:intersectionOf> > </owl:equivalentClass> > </soks:Concept> > > ... I am in fact saying something about the things that are true instances > of the concepts. That is, things with the property <rdf:type> pointing to > the concepts. > > There are two problems with this: > > 1. I don't have the information I need in order to be able to guarantee > recall of documents after query transformation. > > 2. Many concepts should not be modelled as <owl:Class>es. The concept > 'Running' is not a class. The concept 'Java programming language version > 1.4.2' is not a class. The concept 'fish and chips' is not a class. Yet > all these may be concepts in a thesaurus. If a concept is not a class, we > can't use it as the subject or object of OWL set based expressions. > > However, you can use OWL to make statements about the sets of things that > are 'about' some concept. Hence the restrictions over things with property > <dc:subject>. What I'm trying to say is, this is what equivalence > expressions are best taken to mean. Then we avoid hazy philosophical > questions and just end up with useful information about how to transform > queries. > > Does this change your opinion? > > Al. > > > -----Original Message----- > >>From: Dave Reynolds [mailto:der@hplb.hpl.hp.com] >>Sent: 27 November 2003 14:41 >>To: Miles, AJ (Alistair) >>Cc: 'public-esw-thes@w3.org' >>Subject: Re: FW: SKOS-Mapping and OWL - set based constructs >> >> >> >>Hi Alistair, >> >> > What do you think of this? >> >>This does not sound like a good idea. >> >>[Apologies - I haven't had time to look at the mapping >>proposal yet so >>these comments are based purely on the quoted message and I >>might have got >>hold of the wrong end of the stick ...] >> >>First, I'd expect you to translate the soks AND into an OWL >>intersectionOf >>over the concepts not over restrictions on dc:subject. >> >>Second, I don't see the argument that these constructs are >>more "intuitive" >> than the OWL equivalents. If they are truly equivalent and >>all you've >>done is change the name then that doesn't seem helpful. >> >>Third, it's not a good idea to use rdf:li here. The OWL >>constructs use >>parseType collection for very good reasons (to express a >>closed collection >>which can't be messed up semantically by later assertions). >> >>Dave >> >>Miles, AJ (Alistair) wrote: >> >> >>>The idea is that the skos-mapping constructs are a more >> >>convenient and >> >>>intuitive shorthand for more formal set based constructs >> >>that could be >> >>>expressed in OWL. >>> >>>So for example, you may consider that statements such as ... >>> >>><soks:Concept rdf:about="#A"> >>> <soks-map:broaderMatch> >>> <soks-map:AND> >>> <rdf:li rdf:resource="#B"/> >>> <rdf:li rdf:resource="#C"/> >>> </soks-map:AND> >>> </soks-map:broaderMatch> >>></soks:Concept> >>> >>>... are in fact a convenient shorthand for the statements ... >>> >>><owl:Restriction> >>> <owl:onProperty rdf:resource="&dc;subject"/> >>> <owl:hasValue rdf:resource="#A"/> >>> <rdfs:subClassOf rdf:parseType="resource"> >>> <owl:intersectionOf rdf:parseType="collection"> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="&dc;subject"/> >>> <owl:hasValue rdf:resource="#B"/> >>> </owl:Restriction> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="&dc;subject"/> >>> <owl:hasValue rdf:resource="#C"/> >>> </owl:Restriction> >>> </owl:intersectionOf> >>> </rdfs:subClassOf> >>></owl:Restriction> >>> >>>For further discussion of this problem, see the extended >> >>writeup of open >> >>>design issues on the SWAD RDF Thesaurus wiki (Issue 9 - >> >>Inter-thesaurus >> >>>mapping) <http://esw.w3.org/topic/RdfThesaurus>. >>> >>>What do you think of this? >>> >>>Yours, >>> >>>Alistair. >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: ewallace@cme.nist.gov [mailto:ewallace@cme.nist.gov] >>>>Sent: 26 November 2003 18:59 >>>>To: A.J.Miles@rl.ac.uk >>>>Subject: Re: SKOS-Mapping comments and labels added >>>> >>>> >>>> >>>>You wrote: >>>> >>>> >>>> >>>>>Comments and labels have been added to the SKOS-Mapping vocabulary. >>>>> >>>>><http://www.w3c.rl.ac.uk/2003/11/21-skos-mapping> >>>> >>>>This file contains AND, OR, and NOT properties which mimic OWL >>>>vocabulary elements: owl:intersectionOf, owl:unionOf, and >>>>owl:complementOf respectively. Why invent new terms? >>>> >>>>-Evan >>>> >>>>Evan K. Wallace >>>>Manufacturing Systems Integration Division >>>>NIST >>>> >>>> >>> >>> >
Received on Thursday, 27 November 2003 16:26:50 UTC