$Id: appextensions.html,v 1.8 2005/10/26 10:36:36 ajm65 Exp $

This is a draft of a proposed appendix to the SKOS Core Guide to be updated. See http://isegserv.itd.rl.ac.uk/cvs-public/skos/drafts/appextensions.html for revisions of this document.

Extending SKOS Core

Abstract

This is a preliminary draft of an appendix to the SKOS Core Guide, describing how to declare extensions to the SKOS Core Vocabulary using RDF, RDFS and OWL.

Contents

Introduction

This document is a preliminary draft of an appendix to the SKOS Core Guide, describing how to declare extensions to the SKOS Core Vocabulary using RDF, RDFS and OWL.

This document makes extensive use of the Turtle syntax for RDF, a subset of Notation 3. If the basic practices described here are approved by the SKOS development community and the SWBPD-WG it is expected that the examples will be rewritten using images depiction RDF graphs and the RDF/XML syntax.

All snippets of Turtle used in this document assume the following prefixes have been declared:

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema-datatypes> .
@prefix eg: <http://www.example.com/eg#> .

Declaring RDF Properties and RDFS Classes

To extend SKOS Core you will need to know how to declare your own RDF Properties and RDFS Classes.

The procedure for declaring an RDF Property or an RDFS Class is exactly the same as the procedure for declaring a SKOS Concept:

  1. First you allocate a URI to the property/class you wish to declare. I.e. you identify the class/property.
  2. Second, you create some RDF statements that describe the property/class.
  3. Finally, publish the description on the web.

The SKOS Core Vocabulary itself consists of RDF properties and RDFS classes, declared in this way.

Declaring an RDFS Class

Let's take the skos:Concept class as an example.

Identify:The URI <http://www.w3.org/2004/02/skos/core#Concept> has been allocated by the W3C (as owners of the URI) as the identifier for this property.

(N.B. The notation skos:Concept is a shorthand for the full URI <http://www.w3.org/2004/02/skos/core#Concept>, where the prefix skos: stands for <http://www.w3.org/2004/02/skos/core#>.)

Describe: The skos:Concept class is described by the following statements, here represented using the Turtle RDF syntax:

skos:Concept a rdfs:Class;
  rdfs:label 'Concept'@en;
  skos:definition 'An abstract idea or notion; a unit of thought.'@en;
  skos:example <http://www.w3.org/2004/02/skos/core/examples/Concept.rdf.xml>;
  rdfs:isDefinedBy <http://www.w3.org/2004/02/skos/core>;
  vs:term_status 'testing';
  dcterms:issued '2004-03-26'^^xsd:date;
  dcterms:modified '2004-12-17'^^xsd:date;
.

Taking each of the above statements in turn:

skos:Concept a rdf:Property.
This statement should be made for any resource you wish to be treated as an RDFS class. (Note that this is a shorthand for the statement {skos:Concept rdf:type rdf:Property.}, allowed in both the Notation 3 and Turtle syntaxes.)
skos:Concept rdfs:label 'Concept'@en.
The rdfs:label property is used to give a human readable label. Notice the use of a language tag.
skos:Concept skos:definition '...'@en.
A class ought to have some human-readable description of what it means. You can use skos:definition for this.
skos:Concept skos:example <http://www.w3.org/2004/02/skos/core/examples/Concept.rdf.xml>.
An example is always useful, here given as a link to another resource.
skos:Concept vs:term_status 'testing'.
Indicates the stability of the class, i.e. the degree of confidence you may have in it remaining persistently in an unchanged form. The property vs:term_status is an experimental property, used by SKOS and FOAF vocabularies.
skos:Concept dcterms:issued '2004-03-26'^^xsd:date.
Housekeeping. Note the use of a datatype.
skos:Concept dcterms:modified '2004-12-17'^^xsd:date.
Housekeeping.

Publish: These statements are published at <http://www.w3.org/2004/02/skos/core>. This means that any agent dereferencing the URI <http://www.w3.org/2004/02/skos/core#Concept> will by default obtain a definitive RDF description of the resource identified by this URI.

Declaring an RDF Property

Let's take the property skos:semanticRelation as an example.

Identify:The URI <http://www.w3.org/2004/02/skos/core#semanticRelation> has been allocated by the W3C (as owners of the URI) as the identifier for this property.

Describe: The skos:prefLabel property is described by the following statements, here represented using the Turtle RDF syntax:

skos:semanticRelation a rdf:Property;
  rdfs:label 'semantic relation'@en;
  skos:definition 'A concept related by meaning.'@en;
  rdfs:comment 'This property should not be used directly, but as a super-property for all properties denoting a relationship of meaning between concepts.'@en;
  skos:example <http://www.w3.org/2004/02/skos/core/examples/semanticRelation.rdf.xml>;
  rdfs:range skos:Concept;
  rdfs:domain skos:Concept;
  rdfs:isDefinedBy <http://www.w3.org/2004/02/skos/core>;
  vs:term_status 'testing';
  dcterms:issued '2004-03-26'^^xsd:date;
  dcterms:modified '2004-10-20'^^xsd:date;
.

Taking each of the above statements in turn:

skos:semanticRelation rdf:type rdf:Property.
This statement should be made for any resource you wish to be treated as an RDF property.
skos:semanticRelation rdfs:label 'semantic relation'@en.
The rdfs:label property is used to give a human readable label. Notice the use of a language tag.
skos:semanticRelation skos:definition '...'@en.
A property ought to have some human-readable description of what it means. You can use skos:definition for this.
skos:semanticRelation rdfs:comment '...'@en.
Use rdfs:comment for any human-readable information about the property.
skos:semanticRelation skos:example <http://www.w3.org/2004/02/skos/core/examples/semanticRelation.rdf.xml>.
An example is always useful, here given as a link to another resource.
skos:semanticRelation rdfs:range skos:Concept.
The range of a property is the class of things you intend to use as objects of statements involving the property. I.e. it is the class of things to be used as values of this property. In this case, the range of skos:semanticRelation is the class skos:Concept because we want concepts to be used as values of this property.
skos:semanticRelation rdfs:domain skos:Concept.
The domain of a property is the class of things you intend to use as subjects of statements involving the property. I.e. it is the class of things you want to use the property to make statements about. In this case, the domain is the class skos:Concept because we want to use the property skos:semanticRelation to relate concepts to other concepts.
skos:semanticRelation rdfs:isDefinedBy <http://www.w3.org/2004/02/skos/core>.
http://www.w3.org/2004/02/skos/core is the URI of the resource where the definitive RDF description of skos:semanticRelation is published.
skos:semanticRelation vs:term_status 'testing'.
Indicates the stability of the property, i.e. the degree of confidence you may have in it remaining persistently in an unchanged form. The property vs:term_status is an experimental property, used by SKOS and FOAF vocabularies.
skos:semanticRelation dcterms:issued '2004-03-26'^^xsd:date.
Housekeeping. Note the use of a datatype.
skos:semanticRelation dcterms:modified '2004-10-20'^^xsd:date.
Housekeeping.

Publish: These statements are published at <http://www.w3.org/2004/02/skos/core>. This means that any agent dereferencing the URI <http://www.w3.org/2004/02/skos/core#semanticRelation> will by default obtain a definitive RDF description of the resource identified by this URI.

So, to recap: to declare an RDF property or an RDF class, first give it a URI, then describe it using RDF, and finally publish your description on the web. Now we're ready for the first type of extension scenario.

Extension By Refinement

In this scenario, you declare classes and properties that are specialisations (i.e. refinements) of existing classes and properties in the SKOS Core Vocabulary. This section gives some example scenarios using this technique.

Example: Specialised Labelling Properties

The SKOS Core Vocabulary has declared three properties for assigning lexical labels to concepts: skos:prefLabel, skos:altLabel and skos:hiddenLabel. These properties allow you to assign preferred, alternative, and hidden lexical labels to concepts. However, you may have more specialised requirements. You may need to have different preferred and alternative lexical labels for different users. For example, you may to want to supply different labels for scientists and non-scientists, or for doctors and patients, or for youths and adults.

To do this, you may extend SKOS Core by declaring refinements of the skos:prefLabel and skos:altLabel properties. E.g.:

eg:prefScientificLabel a rdf:Property;
  rdfs:label 'preferred scientific label';
  skos:definition 'The preferred lexical label for scientists.';
  rdfs:subPropertyOf skos:prefLabel;
.

eg:altScientificLabel a rdf:Property;
  rdfs:label 'alternative scientific label';
  skos:definition 'An alternative lexical label for scientists.';
  rdfs:subPropertyOf skos:altLabel;
.

eg:prefNonScientificLabel a rdf:Property;
  rdfs:label 'preferred non-scientific label';
  skos:definition 'The preferred lexical label for non-scientists.';
  rdfs:subPropertyOf skos:altLabel;
.  

eg:altNonScientificLabel a rdf:Property;
  rdfs:label 'alternative non-scientific label';
  skos:definition 'An alternative lexical label for non-scientists.';
  rdfs:subPropertyOf skos:altLabel;
.

The crucial bit of the above is the use of rdfs:subPropertyOf - each of the above properties has been declared as a sub-property of a SKOS Core property. This is the formal mechanism by which you declare a property refinement.

Now let's use these extensions:

eg:concept001 a skos:Concept;
  eg:prefScientificLabel 'Clamydera maculata';
  eg:prefNonScientificLabel 'Spotted bowerbird';
.

eg:concept002 a skos:Concept;
  eg:prefScientificLabel 'acetylsalicylic acid';
  eg:altScientificLabel '2-acetoxybenzoic acid';
  eg:prefNonScientificLabel 'aspirin';
.

The important feature of extension by refinement is that RDFS inference can be used to obtain a 'dumbed-down' SKOS Core description of the concepts you declare. The above example, by RDFS inference, implies the following:

eg:concept001 a skos:Concept;
  skos:prefLabel 'Clamydera maculata';
  skos:altLabel 'Spotted bowerbird';
.

eg:concept002 a skos:Concept;
  skos:prefLabel 'acetylsalicylic acid';
  skos:altLabel '2-acetoxybenzoic acid';
  skos:altLabel 'aspirin';
.

Note also that, in the above example, only the eg:prefScientificLabel property was made a sub-property of skos:prefLabel; the three others were declared as sub-properties of skos:altLabel. This is to avoid violating the constraint on skos:prefLabel after 'dumbing-down' via RDFS inference that a concept may only have one preferred lexical label per language. I.e. you should only refine skos:prefLabel once, although you may refine skos:altLabel any number of times. Which of your specialised labelling properties you choose to make a refinement of skos:prefLabel depends on how you want your scheme to appear by default, under a dumbed-down representation.

Example: Specialised Semantic Relation Properties

The SKOS Core Vocabulary has declared four properties for use in asserting relationships of meaning (paradigmatic relationships) between concepts: skos:semanticRelation, skos:broader, skos:narrower and skos:related. However, you may wish to use properties that are more specific than these. For example, many thesauri differentiate different types of broader/narrower relationships, using 'broader/narrower instantive', 'broader/narrower generic' and 'broader/narrower partitive'.

The properties skos:broader, skos:narrower and skos:related are in fact themselves sub-properties of the more generic skos:semanticRelation property. You may refine skos:broader, skos:narrower or skos:related, or if your specialised relationship does not fall naturally under these properties, you may refine skos:semanticRelation directly.

In this example, we shall refine skos:broader and skos:narrower to represent the specialised thesaurus relationships mentioned above:

eg:broaderInstantive a rdf:Property;
  rdfs:label 'broader (instantive)'@en;
  skos:definition 'A broader concept, according to the instantive ("instance of") relationship.'@en;
  rdfs:subPropertyOf skos:broader;
  owl:inverseOf eg:narrowerInstantive;
.

eg:narrowerInstantive a rdf:Property;
  rdfs:label 'narrower (instantive)'@en;
  skos:definition 'A narrower concept, according to the instantive ("instance of") relationship.'@en;
  rdfs:subPropertyOf skos:narrower;
  owl:inverseOf eg:broaderInstantive;
.

eg:broaderGeneric a rdf:Property;
  rdfs:label 'broader (generic)'@en;
  skos:definition 'A broader concept, according to the generic ("sub-type of") relationship.'@en;
  rdfs:subPropertyOf skos:broader;
  a owl:TransitiveProperty;
  owl:inverseOf eg:narrowerGeneric;
.

eg:narrowerGeneric a rdf:Property;
  rdfs:label 'narrower (generic)'@en;
  skos:definition 'A narrower concept, according to the generic ("sub-type of") relationship.'@en;
  rdfs:subPropertyOf skos:narrower;
  a owl:TransitiveProperty;
  owl:inverseOf eg:broaderGeneric;
.

eg:broaderPartitive a rdf:Property;
  rdfs:label 'broader (partitive)'@en;
  skos:definition 'A broader concept, according to the partitive ("part of") relationship.'@en;
  rdfs:subPropertyOf skos:broader;
  a owl:TransitiveProperty;
  owl:inverseOf eg:narrowerPartitive;
.

eg:narrowerPartitive a rdf:Property;
  rdfs:label 'narrower (partitive)'@en;
  skos:definition 'A narrower concept, according to the partitive ("part of") relationship.'@en;
  rdfs:subPropertyOf skos:narrower;
  a owl:TransitiveProperty;
  owl:inverseOf eg:broaderPartitive;
.

Note again the use of rdfs:subPropertyOf to declare these properties as refinements of semantic relation properties from the SKOS Core Vocabulary.

Note also the use of some OWL constructs. The owl:inverseOf property has been use to declare inverse relationships between e.g. eg:broaderInstantive and eg:narrowerInstantive. Also the owl:TransitiveProperty class has been used to declare the transitivity of appropriate relationships. See the OWL Guide for more information about these features.

Now let us use these new specialised properties, e.g.:

eg:concept010 a skos:Concept;
  skos:prefLabel 'Animals';
  eg:narrowerGeneric eg:concept011;
.

eg:concept011 a skos:Concept;
  skos:prefLabel 'Mammals';
  eg:broaderGeneric eg:concept010;
.

eg:concept020 a skos:Concept;
  skos:prefLabel 'Kings of England';
  eg:narrowerInstantive eg:concept021;
.

eg:concept021 a skos:Concept;
  skos:prefLabel 'Henry Tudor';
  eg:broaderInstantive eg:concept020;
.

eg:concept030 a skos:Concept;
  skos:prefLabel 'Europe';
  eg:narrowerPartitive eg:concept031;
.

eg:concept031 a skos:Concept;
  skos:prefLabel 'United Kingdom of Great Britain and Northern Ireland';
  eg:broaderPartitive eg:concept030;
.

This example, given the property declarations, by RDFS inference implies the following:

eg:concept010 skos:narrower eg:concept011.
eg:concept011 skos:broader eg:concept010.
eg:concept020 skos:narrower eg:concept021.
eg:concept021 skos:broader eg:concept020.
eg:concept030 skos:narrower eg:concept031.
eg:concept031 skos:broader eg:concept030.

Example: Specialised Documentation Properties

The SKOS Core Vocabulary includes several properties for linking concepts to documentation: skos:note, skos:definition, skos:example, skos:scopeNote, skos:historyNote, skos:editorialNote and skos:changeNote. However, many applications require a richer set of documentation properties. You may declare your own documentation properties, as refinements of SKOS Core documentation properties. For example:

eg:relocationNote a rdf:Property;
  rdfs:label 'relocation note';
  skos:definition 'A note describing the relocation of this concept within the hierarchy.';
  rdfs:subPropertyOf skos:historyNote;
.

This property could then be used as in e.g.:

eg:concept101 a skos:Concept;
  skos:prefLabel 'tomatoes';
  eg:relocationNote 'Moved from under "vegetables" to under "fruits".';
.

By RDFS inference the following is implied:

eg:concept101 skos:historyNote 'Moved from under "vegetables" to under "fruits".';

If it is not appropriate to refine skos:definition, skos:example, skos:scopeNote, skos:historyNote, skos:editorialNote or skos:changeNote then refine the generic skos:note property.

N.B. The SKOS Core describes the three ways in which it is allowed to use the SKOS Core documentation properties ('documentation as RDF literal', 'documentation as a related resource description' and 'documentation as a resource reference'). If your application requires that the usage of your specialised property be constrained to e.g. only documentation as an RDF literal, then you may declare this formally using rdfs:range, e.g.:

eg:relocationNote rdfs:range rdf:Literal.

Example: Specialised Classes of Concept

SKOS Core is oriented towards the identification and description of 'concepts', which are defined as individuals of the class skos:Concept. Each of these individuals is essentially an identified meaning, which can be referred to via its URI. It is possible to subdivide this class, by declaring sub-classes of the skos:Concept class, which can be useful in a number of situations. For example, you might wish to explicitly declare a class for the class of concepts that are in a specific concept scheme, e.g.:

eg:Concept a rdfs:Class;
  rdfs:label 'Example Concept';
  skos:definition 'The class of concepts from the Example Concept Scheme';
  rdfs:subClassOf skos:Concept;
.

This class could then be used as in:

eg:concept200 a eg:Concept;
  skos:prefLabel 'behavioural ecology';
.

From the above, the following is inferred by RDFS inference:

eg:concept200 a skos:Concept.

Note that, with some constructs from OWL, it is possible to declare the meaning of this particular class more formally, e.g.:

eg:Concept a owl:Class;
  rdfs:subClassOf [
    a owl:Restriction;
    owl:onProperty skos:inScheme;
    owl:hasValue eg:MyConceptScheme;
  ];
.

eg:MyConceptScheme a skos:ConceptScheme;
  dc:title 'The Example Concept Scheme';
  dc:creator 'Alistair Miles';
.

There may also be other reasons for declaring sub-classes of the skos:Concept class. One use case involves the declaration of 'fundamental facets', also known as 'faceted taxonomies', and is considered below.

Example: Fundamental Facets (Faceted Taxonomies)

Several thesauri are constructed such that the concepts are divided into a small number of mutually exclusive fundamental facets. This approach has also been encouraged in the development of enterprise taxonomies, where such a scheme is referred to as a faceted taxonomy. These structures may be formally described by declaring sub-classes of the skos:Concept class for each fundamental facet. For example, borrowing from the example of the Art and Architecture Thesaurus:

eg:AssociatedConcept a rdfs:Class;
  rdfs:label 'Associated Concept';
  skos:definition 'The class of associated concepts.';
  rdfs:subClassOf skos:Concept;
.

eg:PhysicalAttributesConcept a rdfs:Class;
  rdfs:label 'Physical Attributes Concept';
  skos:definition 'The class of concepts relating to physical attributes of objects.';
  rdfs:subClassOf skos:Concept;
.  

eg:StylesAndPeriodsconcept a rdfs:Class;
  rdfs:label 'Styles and Periods Concept';
  skos:definition 'The class of concepts relating to styles and periods.';
  rdfs:subClassOf skos:Concept;
.  

eg:AgentsConcept a rdfs:Class;
  rdfs:label 'Agents Concept';
  skos:definition 'The class of concepts relating to agents.';
  rdfs:subClassOf skos:Concept;
.  

eg:ActivitiesConcept a rdfs:Class;
  rdfs:label 'Activities Concept';
  skos:definition 'The class of concepts relating to activities.';
  rdfs:subClassOf skos:Concept;
.  

eg:MaterialsConcept a rdfs:Class;
  rdfs:label 'Materials Concept';
  skos:definition 'The class of concepts relating to physical materials.';
  rdfs:subClassOf skos:Concept;
.  

eg:ObjectsConcept a rdfs:Class;
  rdfs:label 'Objects Concept';
  skos:definition 'The class of concepts relating to physical objects.';
  rdfs:subClassOf skos:Concept;
.

Each of these new classes can be used to declare concepts, for example:

eg:concept301 a eg:StylesAndPeriodsConcept;
  skos:prefLabel 'Prehistoric';
  skos:scopeNote 'Refers to the period antecedent to the first contemporary written accounts of a people. The time span for this period varies according to specific local habitation patterns and in different scholarly disciplines.';
.

To support stronger validation of your faceted concept scheme, you could also use OWL to explicitly declare that a concept may not be a member of more than one fundamental facet, for example:

eg:StylesAndPeriodsConcept 
  owl:disjointWith eg:AssociatedConcept;
  owl:disjointWith eg:PhysicalAttributesConcept;
  owl:disjointWith eg:AgentsConcept;
  owl:disjointWith eg:ActivitiesConcept;
  owl:disjointWith eg:MaterialsConcept;
  owl:disjointWith eg:ObjectsConcept;
.

Obviously a similar declaration must be made for each class.

Example: Pre-Coordinate Indexing

N.B. There is a strong argument for making the extension vocabulary described in this example a part of the SKOS Core Vocabulary itself. However, until that proposal is made, the example is described here as an extension scenario.

Under 'pre-coordinate' indexing, concepts are meant to be combined by the indexer into more meaningful units, at the time the indexing is done. However, this requires that the formal representation captures the fact that a document is being indexed not just with two concepts, but with the coordination of two concepts. This could be captured by declaring refinements both of the skos:Concept class, and of the skos:broader property. For example, first the following is declared:

eg:CompoundConcept a rdfs:Class;
  rdfs:label 'Compound Concept';
  skos:definition 'A coordination of two or more concepts, where the resultant meaning is derived from the combination of the component concepts.';
  rdfs:subClassOf skos:Concept;
.

eg:component a rdf:Property;
  rdfs:label 'component';
  skos:definition 'A concept that is a component of a compound (coordinated) concept.';
  rdfs:domain eg:CompoundConcept;
  rdfs:range skos:Concept;
  rdfs:subPropertyOf skos:broader;
.

This allows declarations such as e.g.:

eg:concept501 a skos:Concept;
  skos:prefLabel 'cut flowers';
.

eg:concept502 a skos:Concept;
  skos:prefLabel 'crop production';
.

<http://www.somewhere.org/someDoc>
  skos:subject [
    a eg:CompoundConcept;
    eg:component eg:concept501;
    eg:component eg:concept502;
  ].

That the property eg:component was made a sub-property of skos:broader allows the following to be inferred via RDFS inference and the subject generality rule:

<http://www.somewhere.org/someDoc> 
  skos:subject eg:concept501; 
  skos:subject eg:concept502.

I.e. this extension, via RDFS inference, could fit seamlessly into an application doing simple query expansion using the subject generality rule.

N.B. this solution doesn't handle the situations where the order of coordination is significant.

Example: Weighted Semantic Relationships

This is an advanced example, that uses a refinement of the RDF reification vocabulary, which is itself non-normative, so you have been warned!

Some applications have a requirement to attach a numerical weight to semantic relations between concepts. A weighted relationship may be modelled in RDF as an n-ary relationship [ref N-ary Relations]. Furthermore, by refining some of the RDF reification vocabulary, we can get weighted semantic relationships that are fully backwards-compatible with normal binary unweighted semantic relationships, requiring only that the RDF toolkit in use supports RDF reification. So, for example, declare:

eg:WeightedSemanticRelation a owl:Class;
  rdfs:label 'Weighted Semantic Relation';
  skos:definition 'A resource representing a reified, weighted, semantic relationship between two concepts.';
  rdfs:subClassOf rdf:Statement;
  rdfs:subClassOf [
    a owl:Restriction;
    owl:onProperty rdf:subject;
    owl:allValuesFrom skos:Concept;
  ];
  rdfs:subClassOf [
    a owl:Restriction;
    owl:onProperty rdf:object;
    owl:allValuesFrom skos:Concept;
  ];
  rdfs:subClassOf [
    a owl:Restriction;
    owl:onProperty eg:weight;
    owl:cardinality '1'^^xsd:integer;
  ];
.

eg:weight a rdf:Property;
  rdfs:label 'weight';
  skos:definition 'The numerical weight assigned to a semantic relationship.';
  rdfs:domain eg:WeightedSemanticRelation;
  rdfs:range xsd:integer;
.

This may be used as in e.g.:

[] a WeightedSemanticRelation;
  rdf:subject eg:concept410;
  rdf:predicate skos:related;
  rdf:object eg:concept420;
  eg:weight '42'^^xsd:integer;
.

Note that, because we have refined the RDF reification vocabulary, the following statement will also be present in the RDF graph:

eg:concept410 skos:related eg:concept420.

Hybrid SKOS/OWL Ontologies

It is possible to use simple concept hierarchies, defined using SKOS Core, within an OWL ontology. The following example illustrates this idea, and is based on the ontologies used in the SWED portal [ref@@TODO].

This example is an ontology for describing environmental organisations. Classes of concepts are used as the ranges of some of the properties of an environmental organisation. The following gives the basis:

eg:EnvironmentalOrganisation a owl:Class;
  rdfs:label 'Environmental Organisation';
  rdfs:comment 'The class of organisations whose core business has something to do with the natural environment.';
.

eg:topicOfInterest a owl:ObjectProperty;
  rdfs:label 'topic of interest';
  rdfs:comment 'The main topic of interest of an organisation.';
  rdfs:domain eg:EnvironmentalOrganisation;
  rdfs:range eg:TopicOfInterestConcept;
.

eg:TopicOfInterestConcept a owl:Class;
  rdfs:label 'Topic of Interest Concept';
  rdfs:comment 'The class of concepts used to describe the topic of interest of an organisation.';
  rdfs:subClassOf skos:Concept;
.

eg:activity a owl:ObjectProperty;
  rdfs:label 'activity';
  rdfs:comment 'The primary activity of an organisation.';
  rdfs:domain eg:EnvironmentalOrganisation;
  rdfs:range eg:ActivityConcept;
.

eg:ActivityConcept a owl:Class;
  rdfs:label 'Activity Concept';
  rdfs:comment 'The class of concepts used to describe the activity of an organisation.';
  rdfs:subClassOf skos:Concept;
.

This then provides the basic framework for declaring some concepts, e.g.:

eg:topicConcept001 a eg:TopicOfInterestConcept;
  skos:prefLabel 'Sustainable development';
  skos:narrower eg:topicConcept010;
.

eg:topicConcept010 a eg:TopicOfInterestConcept;
  skos:prefLabel 'Ecotourism';
  skos:broader eg:topicConcept001;
.

eg:activityConcept002 a eg:ActivityConcept;
  skos:prefLabel 'Education and training';
  skos:narrower eg:activityConcept012;
.

eg:activityConcept012 a eg:ActivityConcept;
  skos:prefLabel 'Awareness raising';
  skos:broader eg:activityConcept002;
.

This in turn gives the basis for describing organisations, such as e.g.:

eg:org1 a eg:EnvironmentalOrganisation;
  rdfs:label 'Society for Environmental Exploration (SEE)';
  eg:topicOfInterest eg:topicConcept001;
  eg:activity eg:activityConcept012;
  foaf:homepage <http://www.frontier.ac.uk/>;
.

In the case of the SWED portal, modelling the topic of interest, activity, project type and organisation type using classes of concepts (i.e. simple concept hierarchies) is sufficient to provide a rich faceted browsing interface.

Mapping to SKOS Core with Rules

@@TODO something describing how to generate a SKOS Core representation from WordNet

$Id: appextensions.html,v 1.8 2005/10/26 10:36:36 ajm65 Exp $
			

$Log: appextensions.html,v $
Revision 1.8  2005/10/26 10:36:36  ajm65
fixed error re difference between post-coordinate and pre-coordinate indexing

Revision 1.7  2005/10/06 11:54:05  ajm65
minor

Revision 1.6  2005/10/06 11:07:20  ajm65
added note on refining skos:prefLabel

Revision 1.5  2005/10/05 19:21:01  ajm65
minor

Revision 1.4  2005/10/05 19:19:57  ajm65
Added hybrid example

Revision 1.3  2005/10/05 18:53:41  ajm65
minor

Revision 1.2  2005/10/05 18:52:33  ajm65
added weighted sem rels, and post-coord indexing

Revision 1.1  2005/10/05 18:19:09  ajm65
initial import, still TODO weighted, hybrid and mapping with rules