- From: Doug Tudhope <dstudhope@glam.ac.uk>
- Date: Tue, 24 Aug 2004 14:41:21 +0100
- To: "Miles, AJ \(Alistair\) " <A.J.Miles@rl.ac.uk>, "Danny Ayers" <danny.ayers@gmail.com>, "Stella Dextre Clarke" <sdclarke@lukehouse.demon.co.uk>
- Cc: <public-esw-thes@w3.org>
> The problem is: how to extract and explicitly state the semantics that are > implicit within a thesaurus. Martin Doerr made a study of the AAT which argued that a large proportion of its characteristics by division belonged to a fairly small set of base semantic types - form, function, etc. Making more use of arrays of concepts semantics automatically is an areas where I see definite possibilities. They could have potential for personalised or adaptive views of a KOS. At the moment, they can only be used for displaying hierarchies (unless you have special purpose software for a particular thesaurus). It's difficult to make use of them automatically in retrieval while you are dealing with literals. However, I'm also not sure about the cost/benefits (and range of application) without experimenting - Stella's point about not over-complicating things so people are deterred from building or using thesauri is crucial. Doug ----- Original Message ----- From: "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk> To: "Danny Ayers" <danny.ayers@gmail.com>; "Stella Dextre Clarke" <sdclarke@lukehouse.demon.co.uk> Cc: <public-esw-thes@w3.org> Sent: Tuesday, August 24, 2004 1:48 PM Subject: RE: [Proposal][SKOS-Core] New vocab for arrays of concepts > > Hi all, > > There are some very cool ideas floating around about this. I thought I'd > try and partition the problem space a bit ... > > 1. The immediate requirement for SKOS Core is to be able to support all the > features of a thesaurus that can be extracted from a direct, automated > transformation from its current form. So when generating a SKOS description > of e.g. the AAT or EH Thesaurus of Historic Aircraft, we can write an > algorithm that detects that a particular term is intended as a 'guide term' > or 'node label', but we cannot write an algorithm that extracts more > information about the characteristic of division (if indeed there is one - > see Stella's comments). > > What I'm saying is, to generate something like what Danny suggested below > requires human intervention (i.e. manual labour). Which is not to say that > we shouldn't be thinking about it, because that leads onto another topic ... > > > > > > What I had in mind was something like the following (where A1, A2 etc > > are the aircraft concepts in Alistair's example): > > > > <skos:Concept rdf:about="Fn"> > > <skos:prefLabel>Function</skos:prefLabel> > > </skos:Concept> > > > > <skos:Collection rdf:about="COL1"> > > <rdfs:label>Aircraft by function</rdfs:label> > > <skos:divisionCharacteristic rdf:resource="Fn" /> > > <skos:members rdf:parseType="Collection"> > > <skos:Concept rdf:about="A1"/> > > <skos:Concept rdf:about="A2"/> > > <skos:Concept rdf:about="A3"/> > > </skos:members> > > <skos:length>3</skos:length> > > <skos:viewUnder rdf:resource="A"/> > > <skos:ordered>false</skos:ordered> > > </skos:Collection> > > > > ... and the topic is this: thesaurus -> ontology migration (!!) > > The problem is: how to extract and explicitly state the semantics that are > implicit within a thesaurus. > > Because this is a manual task, guidelines, frameworks and tool support that > make it easier are requisite. > > Anyway, this one I'd like to save for later, because it doesn't bear > directly on the immediate goal to develop and publish SKOS Core. However, > it is an important topic, and some clear guidelines about how to perform > such a migration would get a few people quite excited I suspect. And it is > a very interesting problem - I'm having to restrain myself :) > > Al. > > > > > > > > Where the node label was naming the facet, then I suppose another > > property, something like skos:usesFacet might be used in place of > > divisionCharacteristic (or another level of term indirection added). > > > > Cheers, > > Danny. > > >
Received on Tuesday, 24 August 2004 13:41:26 UTC