View on
Jakob Voß > SKOS-Simple-0.09_01 > SKOS::Simple



Annotate this POD


View/Report Bugs
Module Version: 0.09_01   Source  


This module provides a simple class to create and handle classifications, thesauri and similar systems in Simple Knowledge Organization System (SKOS) data model. Most features of SKOS, as specified at, are supported. In addition there are some useful constraints, which mostly derive from best-practice.

In contrast to other RDF-related modules, SKOS::Simple does not depend on any non-core Perl modules, so you can install it by just copying one file. The module implements basic entailment rules of the SKOS standard without the burden of a full RDF reasoning engine. Actually, you can use this module without having to deal with any details of RDF.

The current version of this class is optimized form creating and serializing valid SKOS schemes, but not for reading and modifying them. A common use case of SKOS::Simple is to transform a given terminology from some custom format to SKOS, which is then serialized in Terse RDF Triple language (Turtle). You can then publish the Turtle data and/or process them with general RDF and SKOS tools.


  my $skos = SKOS::Simple->new( 
      base  => '',
      title => 'My little Knowledge Organization System',
      hierarchy => 'tree' # check classification constraints

  $skos->addConcept( pref => { en => 'foo', ru => 'baz' } );
  $skos->addConcept( notation => '42.X-23' );

  print $skos->turtle;


The following classes and properties from the SKOS vocabulary are supported. The numbers in brackets ([Sxx]) refer to integrity conditions from the SKOS specification. Additional constraints are marked by numbers like [Cxx].


Instances of skos:Concept [S1] are not represented as objects but as parts of a SKOS::Simple object, so every Concepts must belong to a Concept Scheme [C1]. You can attach Concepts to a scheme with "addConcept".

Concept Schemes

Instances of skos:ConceptScheme are implemented as objects of type SKOS::Simple [S2]. Concepts added to a scheme are automatically connected to the scheme via skos:inScheme [S3-S4] (only serialized if requested). Concepts can be selected as top concepts (skos:hasTopConcept / skos:topConceptOf [S5-S8]). In contrast to the SKOS specification, (see 4.6.3) the top concepts of a scheme cannot have broader concepts in the same scheme [C2].

Concepts and concept schemes must be disjoint [S9]. This is ensured only if you do not use a scheme but a base parameter.

Lexical Labels

The label types skos:prefLabel, skos:altLabel, and skos:hiddenLabel are supported. In addition this module supports the label properties dc:title and dc:identifier, which are not explicitly included in the SKOS reference.

rdfs:label as super-property of skos:prefLabel, skos:altLabel, and skos:hiddenLabel will be supported in a later version.


Notations (skos:notation) must be unique per concept and scheme [C3].

Semantic Relations

So called "semantic" relations (skos:semanticRelation) include skos:broader, skos:narrower, and skos:related.

The skos:broaderTransitive and skos:narrowerTransitive are currently not supported.

With this module you can only model semantic relations between concepts in the same scheme.

Documentation properties

skos:note, skos:changeNote, skos:definition, skos:editorialNote, skos:example, skos:historyNote and skos:scopeNote can be used to document concepts. In contrast to the SKOS specification their range is limited to literal values [C4].

Concept Collections (skos:Collection, skos:OrderedCollection, skos:member, skos:memberList) and SKOS extension for labels (skosxl:Label etc.) are not supported. Mapping Properties (skos:mappingRelation, skos:closeMatch, skos:exactMatch, skos:broadMatch, skos:narrowMatch, skos:relatedMatch) will probably be implemented in another module.


The current version of this module aims at classifications. Support for thesauri will be implemented later.

An instance of SKOS::Simple holds exactely one skos:ConceptScheme with the following properties:


new( [ %properties ] )

Creates a new concept scheme with the following properties:


The URI prefix that is used for all concepts (not required but recommended).


The URI of the whole concept scheme (skos:conceptScheme). By default the base property is used as concept scheme URI.


Title(s) of the concept scheme. Must be either a string or a hash that maps language tags to strings.


An optional hash with additional namespaces. You can also override standard namespaces (e.g. skos). All namespaces explicitly specified by this parameter are always included as @prefix in the Turtle output.


Language tag of the default language. By default set to en.


Either tree or thesaurus or the empty string for no hierarchy check (default). At the moment only tree is supported.


Specifies which property is used as concept identifier. Possible values are label (skos:prefLabel), notation (skos:notation, and identifier (dc:identifier). If no value is given, you must either specify label or notation as unique.


Specifies how to encode concept labels. Possible values are pref (skos:prefLabel), which is the default value and implied if identify => 'label', alt (skos:altLabel, hidden (skos:hiddenLabel) and title (dc:title).


Specifies whether to check notations to be unique (unique) and/or mandatory (mandatory) per concept. identity => 'notation' implies notation => 'unique'.


Additional properties as structured Turtle. Triples with predicates a, dc:title, and skos:... are not allowed but removed.


not supported yet.

addConcept ( %properties )

Adds a concept with given properties. Only the identifying property to be used as concept id (notation, label, identifier, or id ) is mandatory. If there already is a concept with the same id, both are merged!

Returns the id of the added or modfied concept.

topConcepts ( [ @ids ] )

Marks one or more concepts as top concepts. The given concepts must already exist and must not have any broader concepts. Without parameters, this methods returns a list of all top concept identifiers. Unless you explicitly specify top concepts, a list of all concepts without broader concepts is returned. As soon as you explicitly set some top concepts, they will be the only top concepts. You can reset the top concepts to all concepts without broader concepts, provide undef as only argument.

concept ( %properties )

Returns the identifier of a concept with given notation and/or label. It is not checked whether the given concept exists in this scheme. Returns either a string or an empty string if no identifier is given.

hasConcept ( $id | %properties )

Returns whether there is a concept of a given id. Instead of providing a specific concept id you can also use unique properties (notation, label, identifier) depending on the scheme's settings.


Returns a list of all concept's ids.


Returns the total number of concepts.

conceptentification ( %properties )

Checks and possibly expands some given concept properties to ensure that there is a valid concept id. Returns a hashref that contains the concept id (field id) or croaks. Depending on the identification settings of this scheme you must pass at least one of notation, label, identifier, id.

addHashref ( $hashref )



The following methods serialize the concept scheme or parts of it in Terse RDF Triple language (RDF/Turtle). A valid serialization must start with some namespace declarations, and a base declaration. Both are only included by the turtle method, but they can also be requested independently. All return values end with a newline unless it is the empty string.

A later version may also support 'hashref' format for serializing.

turtle ( [ %options ] )

Returns a full Turtle serialization of this concept scheme. The return value is equivalent to calling turtleNamespaces, turtleBase, turtleScheme, and turtleConcepts.

The parameter lean => 1 enables a lean serialization, which does not include infereable RDF statements. Other parameters are passed to turtleScheme and turtleConcepts as well.


Returns Turtle syntax namespace declarations for this scheme.


Returns a Turtle URI base declaration for this scheme. An empty string is returned if no URI base is set.

turtleScheme ( [ top => 0 ] )

Returns RDF statements about the concept scheme in Turtle syntax. Details about concepts or namespace/base declarations are not included. The option top => 0 (enabled by default) can be used to supress serializing the skos:hasTopConcept property.

turtleConcept ( $id [, %options ] )

Returns a concept in Turtle syntax. With option top => 0 you can disable serializing the skos:topConceptOf property. By default, each concept is connected to its concept scheme with either skos:topConceptOf, or with skos:inScheme. With option scheme => 0 you can disable serializing the latter property. With scheme => 2 the property skos:inScheme is also included in the serialization if skos:topConceptOf is given, although the former can be derived as super-property of the latter.

turtleConcepts ( [ %options ] )

Returns all concepts in Turtle syntax.



This is just a shortcut for SKOS::Simple->new.

is_uri ( $uri )

Copied from Data::Validate::URI, originally by Richard Sonnen.

uri_or_empty ( $uri )

Checks whether the passed parameter is either an URI or undefined.


The SKOS ontology and its semantics is defined in and Turtle format is specified at

See also Biblio::Thesaurus for a similar module.

syntax highlighting: