W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2009

Re: FAQ:

From: Kevin Doyle <kdoyle@teranode.com>
Date: Thu, 21 May 2009 09:51:40 -0400
Cc: public-esw-thes@w3.org
Message-Id: <397CC169-1213-45DE-B987-7E8C7D305FF5@teranode.com>
To: Dan Brickley <danbri@danbri.org>, "John F. Madden" <john.madden@me.com>
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. ]]
Received on Thursday, 21 May 2009 13:52:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:39:03 GMT