$Revision: 1.7 $ on $Date: 2006/07/31 12:50:49 $ by Alistair Miles.
All parts and revisions of this document can be obtained from http://isegserv.itd.rl.ac.uk/cvs-public/skos/press/dc2006/.
Please note that this document has been superseded, and is maintained for historical purposes only. The final (current) version of this paper is available from http://isegserv.itd.rl.ac.uk/public/skos/press/dc2006/camera-ready-paper.pdf (to be presented at the 2006 International Conference on Dublin Core and Metadata Applications).
This appendix describes a possible RDF representation for the semantic coordination of conceptual units, to support more precise indexing and searching.
By "semantic coordination" is meant the meaningful combination of more than one conceptual unit of a controlled structured vocabulary, in order to create a new meaning.
The representation proposed here requires a single additional property to
be declared in the SKOS Core namespace: skos:coordinationOf. The
domain of this property would be the class skos:Concept, and the
range would be the class rdf:List.
So, for example, given the following controlled structured vocabulary ...
@prefix x: <http://www.example.com/vocab-x#>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. x:A rdf:type skos:Concept; skos:prefLabel "roads"@en. x:B rdf:type skos:Concept; skos:prefLabel "safety"@en. x:C rdf:type skos:Concept; skos:prefLabel "coal"@en. x:D rdf:type skos:Concept; skos:prefLabel "mining"@en.
... an indexing application might then allow an indexer to construct coordinated indexing assertions which would be represented in RDF as ...
@prefix x: <http://www.example.com/vocab-x#>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. <http://www.example.com/docs/roadsafety.html> skos:subject [ skos:coordinationOf (x:A x:B) ]. <http://www.example.com/docs/coalmining.html> skos:subject [ skos:coordinationOf (x:C x:D) ].
A search application might then allow users to coordinate conceptual units in queries in a similar way, which could then be evaluated as SPARQL queries, e.g.:
PREFIX x: <http://www.example.com/vocab-x#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?doc
WHERE {
?doc skos:subject [ skos:coordinationOf (x:A x:B) ].
}
The design proposed here makes the assumption that the order in which conceptual units are coordinated is always significant. The example of "roads" and "safety" illustrates a case where this is likely to be true (i.e. "roads safety" and "safety roads" would probably be interpreted as having very different meanings), and the example of "coal" and "mining" illustrates the case where this is probably false (i.e. "coal mining" and "mining coal" would probably be interpreted as having a very similar meaning).
There is no way of telling a priori whether or not the meaning of a semantic coordination of two or more conceptual units will depend on the order of coordination. Assuming that the order is significant in the representation framework is the safest strategy, because retrieval systems then have the choice as to whether they decide to ignore ordering or not.
An open question remains with respect to what inferences can be made from an assertion such as e.g.:
@prefix x: <http://www.example.com/vocab-x#>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. <http://www.example.com/docs/roadsafety.html> skos:subject [ skos:coordinationOf (x:A x:B) ].
For example, is it reasonable to infer from the above the following:
@prefix x: <http://www.example.com/vocab-x#>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. <http://www.example.com/docs/roadsafety.html> skos:subject x:A, x:B.
I.e. if a document is about road safety, is it necessarily also about roads and about safety?
The proposed representation could also provide a means of capturing the "USE x + y" and "UF+" conventions found in some thesauri. For example, the following may be found in a thesaurus:
road safety USE roads + safety roads UF+ road safety safety UF+ road safety
As SKOS Core stands currently, the above would be represented in RDF as:
@prefix x: <http://www.example.com/vocab-x#>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. x:A rdf:type skos:Concept; skos:prefLabel "roads"@en; skos:altLabel "road safety"@en. x:B rdf:type skos:Concept; skos:prefLabel "safety"@en; skos:altLabel "road safety"@en.
... however, the fact that the same alternative label is used at two conceptual units does not allow the reverse construction of the original thesaurus representation as shown above (see also Appendix J. Thesaurus Representation Issues).
However, if the following were added to the RDF representation of the thesaurus:
[] skos:coordinationOf (x:A x:B); skos:altLabel "road safety"@en.
... then it would become possible to reconstruct the original representation. I have used a blank node in the above because (a) the coordinated meaning may always be referenced via a contruction of the atomic components, and therefore it is not necessary to allocate a URI, and (b) to emphasise that the meaning of the coordination is derived entirely from the combination of the coordinated components.
The discussion above implies that, in the representation proposed, two nodes are the same if they are the same coordination. I.e. the following graph:
_:xxx skos:coordinationOf (x:A x:B). _:yyy skos:coordinationOf (x:A x:B).
... entails ...
_:xxx owl:sameAs _:yyy.
It is probably not necessary to ever make this inference, because a query can always leave the coordinated node as blank or as a variable, and match on the values of the coordination (e.g. as shown in the SPARQL query above). However, this entailment is consistent with the usage I have described, and is not trivial to implement given that it requires establishing identity based on the identity of two RDF lists.
--- Change Log --- $Log: coordination.html,v $ Revision 1.7 2006/07/31 12:50:49 ajm65 Minor spelling. Revision 1.6 2006/07/31 12:41:19 ajm65 Added deprecation note. Revision 1.5 2006/05/03 12:47:14 ajm65 Unknown change. Revision 1.4 2006/05/02 11:10:31 ajm65 Style changes. Revision 1.2 2006/05/01 15:33:02 ajm65 First draft, almost completed. Revision 1.1 2006/04/29 14:25:10 ajm65 Initial. ---