SkosDev/NiceIdeas

From W3C Wiki

Just a place to write down nice ideas for things you can do with SKOS.

Prefixes for what's below: 


@prefix ex: <http://www.example.com/ns#>.
@@TODO


'Favourites'

Concept schemes can get big. Where a user regularly uses a scheme, they probably won't use the whole thing, they'll have areas they visit most often, i.e. 'favourites' or 'bookmarks'.

A concept scheme browser based on SKOS Core and RDF could make use of the transitivity of skos:broader and skos:narrower to automatically generate a favourites hierarchical display. I.e. a user adds concepts to their set of favourites, and a hierarchical display is obtained by querying the transitive closure of skos:broader/skos:narrower computed on the scheme as a whole.

I.e. if the following concepts are presented, assuming hierarchy has been generated from skos:broader statements ... 


Food
  Vegetarian Food
    Fruit
    Vegetables


... and the user adds 'Food' and 'Vegetables' to their favourites, then the browser can generate ... 


Food
  Vegetables


... by querying the transitive closure of skos:broader.

Making statements about relative generality of two documents

Using SKOS Core to say that 'one document is broader in scope than another' ... 


:A a foaf:Document.
:B a foaf:Document.

[] skos:isPrimarySubjectOf :A;
  skos:broader [
    skos:isPrimarySubjectOf :B;
  ];
.

# ... or saying exactly the same thing in a slightly different way ...

:A 
  skos:primarySubject [
    skos:broader [
      skos:isPrimarySubjectOf :B;
    ];
  ];
.


... i.e. 'The (bnode) primary subject of document B is broader than the (bnode) primary subject of document A.'

A 'Weighted' Semantic Relation

Asserting a 'weighted' semantic relationship between concepts ... 


# Set up the bits needed ...

ex:WeightedRelationship a rdfs:Class;
  rdfs:subClassOf rdf:Statement;
.

ex:weight a rdf:Property;
  rdfs:domain ex:WeightedRelationship;
  rdfs:range xsd:float;
.

# ... now use them ...

ex:A a skos:Concept.
ex:B a skos:Concept.

[] a ex:WeightedRelationship;
  rdf:subject ex:A;
  rdf:predicate skos:related;
  rdf:object ex:B;
  ex:weight '0.7'^^xsd:float;
.


This solution allows assertion of semantic 'weights' without giving away the simple pattern of binary relations between concepts.

Fundamental Facets

Representing fundamental facets using SKOS Core and OWL ... 


# First declare each fundamental facet as a class of concepts ...

ex:AgentsConcept a owl:Class;
  rdfs:subClassOf skos:Concept;
.

ex:MaterialsConcept a owl:Class;
  rdfs:subClassOf skos:Concept;
.

ex:ObjectsConcept a owl:Class;
  rdfs:subClassOf skos:Concept;
.

# Now declare that the classes are disjoint ...

ex:AgentsConcept owl:disjointWith ex:MaterialsConcept;
  owl:disjointWith ex:ObjectsConcept;
.

ex:MaterialsConcept owl:disjointWith ex:ObjectsConcept.

# So now the following instance data would raise a validation error ...

ex:A skos:prefLabel 'wood';
  a ex:ObjectsConcept;
  a ex:MaterialsConcept;
.


... i.e. fundamental facets are disjoint classes of concepts.

Concept Schemes and Classes of Concept

Declaring a class of concepts, and relating that to a concept scheme ... 


ex:theExampleScheme a skos:ConceptScheme;
  dc:title 'The example.com concept scheme';
.

ex:Concept a owl:Class;
  rdfs:subClassOf skos:Concept;
  skos:definition 'The class of concepts that participate in the example.com concept scheme.';
  owl:equivalentClass [
    a owl:Restriction;
    owl:onProperty skos:inScheme;
    owl:hasValue ex:theExampleScheme;
  ];
.


... i.e. 'the class ex:Concept is equivalent to the class of concepts that are in the example.com concept scheme.'

Using a class of concepts as the range for an RDF property

Here is an example of using a class of SKOS concepts as part of an RDFS/OWL ontology ... 


ex:Organisation a rdfs:Class.

ex:topicOfInterest a rdf:Property;
  rdfs:domain ex:Organisation;
  rdfs:range ex:TopicOfInterest;
.


... now if it is appropriate, you can model the range of values for a property as a class of SKOS concepts, which allows you to describe a broader/narrower generality hierarchy within the values for that property ... 


# Declare a class of concepts ...

ex:TopicOfInterest a rdfs:Class;
  rdfs:subClassOf skos:Concept;
.

# Now for some instance data ...

ex:orgA rdfs:label 'International Institute For Energy Conservation - Europe';
  a ex:Organisation;
  ex:topicOfInterest ex:B;
.

ex:A skos:prefLabel 'Environmental Issues'; 
  a ex:TopicOfInterest;
  skos:narrower ex:B;
.

ex:B skos:prefLabel 'Climate Change';
  a ex:TopicOfInterest;
  skos:broader ex:A;
.


A simple rule is now required to support the type of query expansion needed for filtering at progressively narrower levels (which is what SWED allows you to do) ... 


(?org ex:topicOfInterest ?x)
(?x skos:broader ?y)
->
(?org ex:topicOfInterest ?y)


This type of thing is very useful for building faceted browsing interfaces. Lots of websites use a faceted browser type interface now, for example see SWED. The SWED browser has a number of 'facets' by which environmental organisations can be filtered, e.g. 'Topic of interest' and 'Operational area'. If the set of possible values for 'Topic of interest' were presented as a list, this would be quite unusable as the list would be very long. In fact the topics of interest have been arranged in a broader/narrower hierarchy, which makes selecting the right value easier. The SWED implementation follows the pattern above, where each 'facet' is modelled as the range of an rdf:Property.

Mapping

Added by aliman 2005-05-05:

Looking at the requirements for mapping between concept schemes again, I think there are two distinct types of mapping. The first type ('semantic mapping') involves a person asserting something about the relative meaning between two concepts from different schemes. The second type ('lexical mapping') involves an automated process asserting a relationship between two concepts from different schemes based on some sort of analysis of the labels, documentation etc. associated with the concepts. E.g. if two concepts have exactly the same string of characters as the value of the skos:prefLabel property then a lexical mapping can be asserted. The key point is that semantic mappings cannot be inferred from lexical mappings. However, lexical mappings could be used as a basis for presenting suggestions for semantic mappings to a person.

Some more thoughts about designing RDF vocab to support expression of these types of mapping:

  • A 'mapping assertion' always involves a 'source' and a 'target'.
  • A lexical mapping always involves a single source concept and a single target concept (?)
  • The source for a semantic mapping is always a single concept.
  • The target for a semantic mapping may be a single concept, or it may be some meaningful combination of concepts.

A semantic mapping always involves some sort of assertion about the relative meaning of a source concept and a mapping target. But assessing and describing the relative meaning of two concepts from different schemes can be notoriously hard and subjective - how do we make that as easy and reliable as possible?

One suggestion for making semantic mappings is the following: when considering a mapping, consider the relationship between a hypothetical set of documents that is 'about' the source concept and a hypothetical set of documents that is 'about' the target concept.

If you imagine that every document that is 'about' the source concept would also be 'about' the target concept, and vice versa, then you have an 'exact' semantic mapping.

For example, if I have ... 


:A skos:prefLabel 'Chocolate'@en.
:B skos:prefLabel 'Chocolat'@fr.


... then it's pretty reasonable to imagine that ... 


[] a owl:Restriction;
  owl:onProperty dc:subject;
  owl:hasValue :A;
  owl:equivalentClass [
    a owl:Restriction;
    owl:onProperty dc:subject;
    owl:hasValue :B;
  ];
.


... which is just a formal way of saying that every document that is about :A is also about :B and vice versa ... and which should be the formal implication of an exact semantic mapping assertion between :A and :B.

If you imagine that some documents that are 'about' the source concept would also be 'about' the target concept, and vice versa, then you have an 'inexact' mapping.

For example, if I might have ... 


@@TODO


The degree of overlap you imagine between the hypothetical set of all documents that are about the source and the hypothetical set of documents that are about the target is also a quantitative (albeit highly subjective) estimate of the probability that a document will be be about both the source and the target.

If you imagine that every document that is about the source concept is also about the target, but only some of the documents that are about the target are about the source, then you have a 'broader' mapping.

For example, if I have ... 


@@TODO


...@@TODO unfinished ...

There are other types of mappings that can be obtained via automated process, for example a subject index where documents have been indexed against two schemes concurrently could be analysed as a basis for probable mappings.

Retrieved from "https://www.w3.org/wiki/index.php?title=SkosDev/NiceIdeas&oldid=11925"