- From: Quentin Reul <qreul@csd.abdn.ac.uk>
- Date: Wed, 03 Oct 2007 15:44:43 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>
- CC: SWD WG <public-swd-wg@w3.org>
Hi Antoine, Obviously, it's most of the time possible to separate the different concepts in different ConceptScheme but this is not always possible if you want to create a domain independent organisation system. Although skos:Concept are not just words their interpretation by human will be based on the terms defined as both prefLabel and altLabel. My view of SKOS is to share dictionaries (or thesauri) across the web using one formalism and also to create methodologies independent of the thesauri. If SKOS dictionaries are to successfully shared, there is to have a proper semantic for how to create them in order to reduce some linguistic problems such as ambiguities. Regards, Quentin Antoine Isaac wrote: > Hi Quentin, > > Well if you are within a single ConceptScheme the elementary good > practice is to create 3 concepts with prefLabel that are unique! No > mystery: if you've put crap data in it, you'll get crap data out of it... > Notice then that nothing pevents you (until now) to put a shared > altLabel, hence having some way to retrieve this "ambiguity". > > Notice that this is coherent with SKOS approach of concept modelling: > skos:Concept are, well, concepts (unit of thoughts, senses, whatever) > and not bare words. > > Cheer, > > Antoine >> Hi Antoine, >> >> By ambiguity I mean terms that have multiple sense. For example, the >> term group either means: >> 1. any number of entities (members) considered as a unit. >> 2. (chemistry) two or more atoms bound together as a single unit and >> forming part of a molecule. >> 3. a set that is closed, associative, has an identity element and >> every element has an inverse. >> >> Obviously, a skos concept can be created for each one with and ID >> associated. However, querying the thesaurus might pose problems as the >> user could have 3 concepts when querying for prefLabel or altLabel. >> >> Regards, >> >> Quentin >> >> Antoine Isaac wrote: >>> Hi Quentin, >>> >>> I won't answer on transitivity, I think I agree with Sean. >>> For the second point your feedback is much appreciated! Thanks for >>> the reading and reacting effort. >>> And for the last point, if by "ambiguity" you mean "mapping", then >>> yes, we will work on that. >>> >>> Cheers, >>> >>> Antoine >>> >>>> Hi Antoine, >>>> >>>> The goal of SKOS is to share knowledge organisation, such as >>>> thesauri over the web. Imagine that a user defines a thesaurus >>>> containing only skos:broader relations between skos:Concept. If >>>> skos:broader and skos:narrower are not transitive, a user x who >>>> wants to use this thesaurus to find all narrower concepts of a >>>> concept will have to add the relation to every concept in the >>>> thesaurus. Hence, transitivity between these relations enable a >>>> better sharing among user. >>>> >>>> Looking at [1], I realised that my question is already covered. I >>>> have reviewed the different solutions proposed. I believe that >>>> solution 4 (mixing 1 and 2), despite is cons, would be most >>>> appropriate. SKOS relations such as skos:definition and >>>> skos:altLabel offer more information about the concept described >>>> whereas skos:broader and skos:narrower describes relations between >>>> terms (in my view anyway). Furthermore, FOAF and Dublin Core are >>>> sometimes used in OWL ontologies to add information about concept or >>>> the ontology itself. >>>> >>>> Lastly, I was wondering if the group was planning on addressing the >>>> question of ambiguity between terms. >>>> >>>> Cheers, >>>> >>>> Quentin >>>> >>>> [1] http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSemantics >>>> >>>> Antoine Isaac wrote: >>>>> Hi Quentin, >>>>>> >>>>>> I understood that skos:narrower and skos:broader are inverses. And >>>>>> I guess my question is actually going to be covered as part of the >>>>>> f2f in Amsterdam [1] in a few weeks time. My personal opinion is >>>>>> that these should be transitive in a similar manner to >>>>>> rdfs:subClass in OWL especially if users want to be able to get >>>>>> information through inference. >>>>> >>>>> Do you have a specific application which requires this? For the >>>>> moment my personal opinion is rather not enthousiastic about >>>>> transitivity, and it's grounded in some practical concerns. I guess >>>>> other workgroup member will come with strong arguments for >>>>> transitivity, but the more practical cases we can discuss, the >>>>> better... >>>>> >>>>>> >>>>>> Another question that comes to mind is whether SKOS is intended to >>>>>> be used as stand-alone or within an ontology. As part of the >>>>>> project I work on, we have used SKOS properties such as >>>>>> skos:definition to define concept label in OWL ontologies. But I >>>>>> also can see some applications where SKOS can be used to represent >>>>>> thesaurus on its own. >>>>> >>>>> Your sentence is unclear: do my scribblings in [1] cover this >>>>> problem? >>>>> >>>>> Cheers, >>>>> >>>>> Antoine >>>>> >>>>> [1] http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSemantics >>>>>> >>>>>> >>>>>> Sean Bechhofer wrote: >>>>>>> >>>>>>> On 24 Sep 2007, at 11:41, Quentin Reul wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have looked at different aspects of SKOS and I have got a few >>>>>>>> questions as a result: >>>>>>>> >>>>>>>> First of all, I was wondering if there was any reasoner >>>>>>>> available to create a thesaurus tree and find out all the >>>>>>>> different terms that are "broader/narrower" for a given term. >>>>>>>> >>>>>>>> My understanding is that the "broader/narrower" relationship is >>>>>>>> transitive, i.e. if the user adds a term has being broader, this >>>>>>>> term would have the previous term as narrower without having to >>>>>>>> add the statement to the second term. >>>>>>> >>>>>>> Broader/narrower are intended to be *inverses*, which I think is >>>>>>> what you mean here. >>>>>>> >>>>>>> The transitivity of broader/narrower is one of the topics that's >>>>>>> up for discussion at the F2F. See "Semantic Relation Properties" >>>>>>> in [1]. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Sean >>>>>>> >>>>>>> [1] http://www.w3.org/2006/07/SWD/wiki/AmsterdamAgenda >>>>>>> >>>>>>> -- >>>>>>> Sean Bechhofer >>>>>>> School of Computer Science >>>>>>> University of Manchester >>>>>>> sean.bechhofer@manchester.ac.uk >>>>>>> http://www.cs.manchester.ac.uk/people/bechhofer >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> Quentin H. Reul >>>>>> Computing Science >>>>>> University of Aberdeen >>>>>> >>>>>> +44 (0)1224 27 *4485* >>>>>> qreul@csd.abdn.ac.uk >>>>>> http://www.csd.abdn.ac.uk/~qreul >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > > -- ****************************************** * Quentin H. Reul * * PhD Research Student * * Department of Computing Science * * University of Aberdeen, King's College * * Room 238 in the Meston Building * * ABERDEEN AB24 3UE * * Phone: +44 (0)1224 27 4485 * * http://www.csd.abdn.ac.uk/~qreul * ******************************************
Received on Wednesday, 3 October 2007 14:45:12 UTC