- From: Alistair Miles <a.j.miles@rl.ac.uk>
- Date: Mon, 03 Apr 2006 13:00:12 +0100
- To: PCavaleri@liuc.it
- CC: public-esw-thes@w3.org
Hi Piero, Thanks alot for this query and your related comment. I've added links to your emails to the 'coordination-8' item in the SKOS Proposals and Issues list: http://www.w3.org/2004/02/skos/core/proposals#coordination-8 You might also be interested in the discussion thread starting from this email: http://lists.w3.org/Archives/Public/public-esw-thes/2005Oct/0102.html ... as it contains some very useful comments on coordination from Leonard Will and Aida Slavic. I see this requirement for compound constructs to be firmly within scope for SKOS Core, and I think that this requirement should be represented in the use cases that will form the basis of SKOS Core recommendation track work, to be written later this year. My currently favoured solution to this problem is the addition of a skos:coordinationOf property, to be used as in: @prefix eg: <http://www.example.com/concepts/>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. eg:xxx a skos:Concept; skos:prefLabel "railways"@en. eg:yyy a skos:Concept; skos:prefLabel "safety"@en. <http://www.example.com/somedocument> skos:subject [ skos:coordinationOf ( eg:xxx eg:yyy ) ]; . If you need to represent the presence of the non-preferred term 'Rail Safety' in the thesaurus then I would do: [] a skos:Concept; skos:altLabel "rail safety"@en; skos:coordinationOf ( eg:xxx eg:yyy ). I deliberately omitted a skos:prefLabel property because there is in fact no such preferred term in the thesaurus being represented. A preferred label may of course be constructed by applications on the fly from the preferred labels of the coordinated concepts, if required. I also deliberately used a blank node for this compound concept, to reinforce the notion that the compound concept should not be referenced directly, but via the list of coordinated concepts. This solution is not fully worked out yet, and there are some logical and practical issues relating to establishing the identity of two coordinated concepts based on the value of the skos:coordinationOf property (this involves establishing the identity of two RDF lists). There are also unexplored issues to do with query expansion over coordinated indexes, i.e. should this graph: { <http://www.example.com/somedocument> skos:subject eg:xxx, eg:yyy. } ... be entailed by this graph: { <http://www.example.com/somedocument> skos:subject [ skos:coordinationOf ( eg:xxx eg:yyy ) ]; . } ... ? Cheers, Al. PCavaleri@liuc.it wrote: > I'm trying to convert our thesaurus in SKOS format, but I'm not able to > rappresent the splitting of compound not preferred terms. Sometimes it may > be usefull because users search using them. > Using an English example, I want to allow the user to find the compound > term rail safety, but redirecting them to use the two term railways and > safety. > > In a paper thesaurus I could write: > rail safety (not accepted) > use railways + safety > > In SKOS the non accepted terms haven't an autonomous entry, but I can't > indicate that rail safety is an <altlabel> for railways or for safety. > How do you resolve problems like this? > > Thank you in advance, > > Piero Cavaleri > Biblioteca Rostoni > Università Cattaneo > C.so Matteotti, 22 > 21053 Castellanza (VA) > Italy > > e-mail: pcavaleri@liuc.it > > > > -- Alistair Miles Research Associate CCLRC - Rutherford Appleton Laboratory Building R1 Room 1.60 Fermi Avenue Chilton Didcot Oxfordshire OX11 0QX United Kingdom Email: a.j.miles@rl.ac.uk Tel: +44 (0)1235 445440
Received on Monday, 3 April 2006 12:00:54 UTC