Re: FAQ:

Good sources of information for understanding SKOS.

I also found the paper by Miles et al titled "SKOS core: simple  
knowledge organisation for the web" very useful:
http://dcpapers.dublincore.org/ojs/pubs/article/download/798/794

On 21 May 2009, at 14:51, Kevin Doyle wrote:

> Thank you Dan and John for the information.
>
> I was also trying to suggest some content for this FAQ (currently  
> empty): http://www.w3.org/2004/02/skos/faq.  On that page, it lists public-esw-thes@w3.org 
>  as the email for suggestions.  One question might be, what  
> documents should I read to gain a basic understanding of SKOS?   
> Answer: SKOS primer, SKOS reference spec (with links).  The excerpt  
> from Dan below is also particularly helpful in filling in a basic  
> understanding.
>
> -Kevin
>
> On May 20, 2009, at 4:41 PM, Dan Brickley wrote:
>
>> On 20/5/09 21:57, Kevin Doyle wrote:
>>> Hi,
>>> I have a question I would like to put on the SKOS FAQ, because I  
>>> don't
>>> know the answer. Also, this is the first place that I looked for the
>>> answer. Why SKOS and not OWL? Or maybe to put the question another  
>>> way,
>>> what are the advantages of using SKOS over OWL?
>>
>> Hi Kevin,
>>
>> Did you see this section in the SKOS reference spec?
>>
>> http://www.w3.org/TR/2009/CR-skos-reference-20090317/#L1045
>>
>> Excerpted below. Does it help?
>>
>> cheers,
>>
>> Dan
>>
>> [[
>> 1.3. SKOS, RDF and OWL
>>
>> The "elements" of the SKOS data model are classes and properties,  
>> and the structure and integrity of the data model is defined by the  
>> logical characteristics of, and interdependencies between, those  
>> classes and properties. This is perhaps one of the most powerful  
>> and yet potentially confusing aspects of SKOS, because SKOS can, in  
>> more advanced applications, also be used side-by-side with OWL to  
>> express and exchange knowledge about a domain. However, SKOS is not  
>> a formal knowledge representation language.
>>
>> To understand this distinction, consider that the "knowledge" made  
>> explicit in a formal ontology is expressed as sets of axioms and  
>> facts. A thesaurus or classification scheme is of a completely  
>> different nature, and does not assert any axioms or facts. Rather,  
>> a thesaurus or classification scheme identifies and describes,  
>> through natural language and other informal means, a set of  
>> distinct "ideas" or "meanings", which are sometimes conveniently  
>> referred to as "concepts". These "concepts" may also be arranged  
>> and organized into various structures, most commonly hierarchies  
>> and association networks. These structures, however, do not have  
>> any formal semantics, and cannot be reliably interpreted as either  
>> formal axioms or facts about the world. Indeed they were never  
>> intended to be so, for they serve only to provide a convenient and  
>> intuitive "map" of some subject domain, which can then be used as  
>> an aid to organizing and finding objects, such as documents, which  
>> are relevant to that domain.
>>
>> To make the "knowledge" embedded in a thesaurus or classification  
>> scheme explicit in any formal sense requires that the thesaurus or  
>> classification scheme be re-engineered as a formal ontology. In  
>> other words, some person has to do the work of transforming the  
>> structure and intellectual content of a thesaurus or classification  
>> scheme into a set of formal axioms and facts. This work of  
>> transformation is both intellectually demanding and time consuming,  
>> and therefore costly. Much can be gained from using thesauri etc.  
>> "as-is", as informal, convenient structures for navigation within a  
>> subject domain. Using them "as-is" does not require any re- 
>> engineering, and is therefore much less costly. In addition, some  
>> KOS are, by design, not intended to represent a logical view of  
>> their domain. Converting such KOS to a formal logic-based  
>> representation may, in practice, involve changes which result in a  
>> representation that no longer meets the originally intended purpose.
>>
>> OWL does, however, provide a powerful data modeling language. We  
>> can, therefore, use OWL to construct a data model for representing  
>> thesauri or classification schemes "as-is". This is exactly what  
>> SKOS does. Taking this approach, the "concepts" of a thesaurus or  
>> classification scheme are modeled as individuals in the SKOS data  
>> model, and the informal descriptions about and links between those  
>> "concepts" as given by the thesaurus or classification scheme are  
>> modeled as facts about those individuals, never as class or  
>> property axioms. Note that these "facts" are facts about the  
>> thesaurus or classification scheme itself, such as "concept X has  
>> preferred label 'Y' and is part of thesaurus Z"; these are not  
>> facts about the way the world is arranged within a particular  
>> subject domain, as might be expressed in a formal ontology.
>>
>> SKOS data are then expressed as RDF triples. For example, the RDF  
>> graph below (in [TURTLE] as discussed in Section 1.7.3) expresses  
>> some facts about a thesaurus.
>>
>> <A> rdf:type skos:Concept ;
>> skos:prefLabel "love"@en ;
>> skos:altLabel "adoration"@en ;
>> skos:broader <B> ;
>> skos:inScheme <S> .
>>
>> <B> rdf:type skos:Concept ;
>> skos:prefLabel "emotion"@en ;
>> skos:altLabel "feeling"@en ;
>> skos:topConceptOf <S> .
>>
>> <S> rdf:type skos:ConceptScheme ;
>> dct:title "My First Thesaurus" ;
>> skos:hasTopConcept <B> .
>>
>> This point is vital to understanding the formal definition of the  
>> SKOS data model and how it may be implemented in software systems.  
>> This point is also vital to more advanced applications of SKOS,  
>> especially where SKOS and OWL are used in combination as part of a  
>> hybrid formal/semi-formal design.
>>
>> From a user's point of view, however, the distinction between a  
>> formal knowledge representation system and an informal or semi- 
>> formal knowledge organization system may naturally become blurred.  
>> In other words, it may not be relevant to a user that <A> and <B>  
>> in the graph below are individuals (instances of skos:Concept), and  
>> <C> and <D> are classes (instances of owl:Class) .
>>
>> <A> rdf:type skos:Concept ;
>> skos:prefLabel "love"@en ;
>> skos:broader <B> .
>>
>> <B> rdf:type skos:Concept ;
>> skos:prefLabel "emotion"@en .
>>
>> <C> rdf:type owl:Class ;
>> rdfs:label "mammals"@en ;
>> rdfs:subClassOf <D> .
>>
>> <D> rdf:type owl:Class ;
>> rdfs:label "animals"@en .
>>
>> An information system that has any awareness of the SKOS data model  
>> will, however, need to appreciate the distinction.
>>
>> RDF schemas for SKOS and the SKOS eXtension for Labels (XL) are  
>> described in Appendix C. SKOS Data Model as RDF Triples. Note that,  
>> as there are constraints that cannot be completely captured in the  
>> schema, the RDF/XML document provides a normative subset of this  
>> specification. ]]
>
>


Matthew Rowe, MEng
PhD Student
OAK Group
Department of Computer Science
University of Sheffield
m.rowe@dcs.shef.ac.uk

Received on Friday, 22 May 2009 12:26:51 UTC