DESCRIPTION

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 http://www.w3.org/TR/skos-reference/, 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.

SYNOPSIS

  my $skos = SKOS::Simple->new( 
      base  => 'http://example.com/kos/',
      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;

SKOS CONFORMANCE

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].

Concepts

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

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.

ADDITIONAL CONSTRAINTS

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:

  • All concepts share a common URI base. By default this common prefix is also the URI of the concept scheme as whole.

  • All concepts must be identifyable by a unique string, that is refered to as the concept identifier. The URI of a concept is build of the common URI prefix and the concept's identifier. The identifier must either be the skos:notation (so every concept must have one), or the skos:prefLabel in one fixed language for all concepts. The only exception to this rule are filters, for instance to uri-encode the prefLabel/notation.

  • Empty strings as literal values are ignored. In most cases you can use undef and "" interchangeably.

  • All notations have the same Datatype URI (this may be changed).

  • The range of all documentation properties (skos:note, skos:example, skos:scopeNote etc.) is the plain literals instead of any resource.

  • ...sure there are some more limitations...

METHODS

new( [ %properties ] )

Creates a new concept scheme with the following properties:

base

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

scheme

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

title

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

namespaces

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

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

hierarchy

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

identity

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.

label

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).

notation

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

properties

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

description

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.

concepts

Returns a list of all concept's ids.

size

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 )

experimental.

SERIALIZATION METHODS

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.

turtleNamespaces

Returns Turtle syntax namespace declarations for this scheme.

turtleBase

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.

EXPORTABLE FUNCTIONS

skos

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.

SEE ALSO

The SKOS ontology and its semantics is defined in http://www.w3.org/TR/skos-primer and http://www.w3.org/TR/skos-reference. Turtle format is specified at http://www.w3.org/TeamSubmission/turtle/.

See also Biblio::Thesaurus for a similar module.