Overview of Semaphore SKOS-XL Constructs

Semaphore 5 models are SKOS and SKOS-XL based. To edit and manage existing RDF models in Semaphore, those models must have certain SKOS and SKOS-XL constructs incorporated into them. To use an RDF model in Semaphore there are some required SKOS constructs that must be incorporated into a model. Additionally, there are many optional constructs to be considered to optimize a model for use in Semaphore.

This section gives an overview of the constructs. Later, these will be discussed more fully.

Required Constructs

1. Concept Scheme(s)
2. Top Concept(s)
3. Concept(s) - Concepts are represented in RDF as instances of skos:Concept class, which is itself an instance of owl:Class.
4. Concept Relationships

Optional Constructs

1. Concept Sub-Classes
2. Concept Metadata
3. Concept Relationship Sub-types

Semaphore Required Constructs

This section describes the required RDF constructs necessary to view and edit models in Semaphore KMM.

A Note about Labels and Language

Semaphore supports modeling in multiple languages. All modelling elements that have a name, i.e. a label, can be given a language-specific label. All labels created in Semaphore KMM are either “language neutral” or associated with a specific language. Labels are constructed using SKOS-XL or RDFS depending on the type of object; for example, Concept Schemes use the rdfs:label tag, whereas Concepts use SKOS-XL constructs.

It is also important to note that for Concept Schemes and Concepts to have rulebases generated for automated classification, they must have a language identified in the Semaphore proscribed way. See the following sections for how labels are formed for each type of construct.

Details on how to manage labels within KMM are given here languages-everything-you-ever-wanted-to-know-about-using-multiple-languages-in-semaphore.

Note, that you can define any language in KMM using a BCP-47 (bcp47.txt) compliant code and any label. This mean that you can for example define labels in en-GB and en-US in the same model (note the format of the code). Within the BCP 47 code format, any number of languages and dialects can be present in KMM.

At publishing time you can choose to propagate these labels to SES as they are, or you can map them within the Publisher configuration file. SES carries out no validation itself about the values of the language codes.

For classification, however, the tokenization and lemmatization of the labels depends on their language. If you have language packs installed in the CLS server, then each label language must be mapped to one of those languages, so for the above case en-GB and en-US would both be mapped to en as the English language pack would be installed. (The difference between en-GB and en-US is spelling and some meanings, which side of the Atlantic you are on does not affect how words lemmatize.)

To select which languages from KMM are published, you add the language codes to the configuration set in the Publisher configuration file described here

To map languages from the KMM values to the values used to generate rulkes, you add the mappings to the rulebase output processor configuration, described here.

Concept Schemes

SKOS Concepts are grouped together in Concept Schemes. A Semaphore model can have one or more Concept Schemes, but it must have at least one. Concepts in a Concept Scheme usually share a common purpose, e.g. defining a particular knowledge domain, used for a particular purpose, e.g. a navigation scheme, or a classification strategy. Note that Concepts can belong to multiple Concept Schemes, serving multiple use cases.

When importing an existing RDF model into Semaphore, planning for the Concept Schemes must be done. The Concept Schemes may come from elements in the existing model, or may be created specifically for use in Semaphore.

Here are some things to keep in mind when determining or creating Concept Schemes:

• Concept Scheme labels can be used by Classification Server to tag documents.
• As noted above, the Concepts in a Concept Scheme usually share a commonality, such as a knowledge domain or a specific purpose.

If you are integrating multiple models into a single Semaphore model, a natural consideration (but certainly not required) is to have each model in a separate Concept Scheme.

Concept Schemes must have one or more defined Top Concepts; that is, the SKOS Concepts that form the top level of the vocabulary.

Concept Schemes created in KMM have their labels identified by language using RDFS.

Example:

<ConceptScheme URI>
  rdf:type skos:ConceptScheme ;
  rdfs:label "ConceptScheme1"@en ;
.

Top Concepts

The SKOS standard incorporates Top Concepts in Concept Schemes. Top Concepts themselves are Concepts like any other concept, the only thing that distinguishes them as Top Concepts is that the Concept Scheme specifies them with a skos:hasTopConcept tag. There must be at least one Top Concept, but there can be as many as needed for the model.

Since Top Concepts are Concepts, they can have Classification rules generated for them and be used as tags by Classification Server. Top Concepts created in KMM have their labels identified by language using SKOS-XL.

Example:

<ConceptScheme URI>
  rdf:type skos:ConceptScheme ;
  rdfs:label "ConceptScheme1"@en ;
  skos:hasTopConcept <Top Concept URI> ;
.
<Top Concept URI>
  rdf:type skos:Concept ;
  skosxl:prefLabel <Top Concept_en URI> ;
.
<Top Concept_en URI>
  rdf:type skosxl:Label ;
  skosxl:literalForm "TopConcept1"@en ;
.

Concepts

Concepts are the fundamental building blocks of enterprise terminologies. In a taxonomy or thesaurus they are often thought of as “preferred terms”. However, in SKOS, what a concept is called—or “labeled”—is in a separate Label property. According to the W3C SKOS Primer, concepts are “units of thought…ideas, meanings, or (categories of) objects and events—which underlie many knowledge organization systems”. Concepts are represented in RDF as instances of skos:Concept class, which is itself an instance of owl:Class.

Concepts are uniquely identified by a URI—not by their label, or in other words by what they are called. In modeling, it is assumed Concepts themselves rarely change—whereas labels of concepts do. Labels are therefore properties of Concepts. A Concept can have a single preferred label per language, but many alternate labels in the same and other languages.

Preferred Labels

Concepts created in Semaphore KMM use SKOS-XL to specify preferred labels by language. The concept has a skosxl:prefLabel triple with a “label URI” object that in turn has a set of triples, including a type and one that specifies the literal form of the label and its language (see example below).

If skos:preLabel triples are imported or inserted into a model, they will be displayed in the “Metadata” section of a concept’s details page with a warning icon. These triples should be used to form the SKOS-XL structure for KMM. The skos:preLabel triples can then be deleted if no longer needed, or left in the model as-is if needed for other applications.

Only 1 preferred label per language is allowed in KMM.

Example:

<Concept URI>
  rdf:type skos:Concept ;
  skos:broader <broader concept URI> ;
  skosxl:prefLabel <Concept_en URI>
.
<Concept_en URI>
  rdf:type skosxl:Label ;
  skosxl:literalForm "Concept1"@en ;
.

Alternate Labels

As with preferred labels, alternative labels use SKOS-XL to specify the labels by language (see example below).

There can be as many alternate labels in the same or multiple languages as the model requires.

Example:

<Concept URI>
  rdf:type skos:Concept ;
  skos:broader <broader concept URI> ;
  skosxl:prefLabel <Concept_en URI>
  skosxl:altLabel <Concept_AltLabel1_en URI> ;
.
<Concept_AltLabel1_en URI>
  rdf:type skosxl:Label ;
  skosxl:literalForm "Concept AltLabel1"@en ;
.

Concept Relationships

Concepts in a model are typically related to other Concepts, and for them to be visible and editable in KMM, Concepts must be related to one or more other Concepts.

In SKOS, the two most fundamental relationship types are broader/narrower (skos:broader/skos:narrower) and related (skos:related). To assert that one concept has a broader concept in meaning (i.e. that the domain concept has a broader concept, or a parent concept), then the domain concept will have the property skos:broader, with the range of that property set to the broader concept. When persisting its models, KMM will only use the skos:broaderrelationship - the skos:narrower one is not used, it is inferred by KMM to display the hierarchies properly. skos:broader and skos:narrower are inverse properties. skos:related is used to designate a relationship that is not hierarchical.

Semaphore Optional Constructs

In addition the to the required constructs described above, Semaphore supports additional constructs that can be very useful for downstream uses both within Semaphore (e.g. Classification Server and Semaphore connectors) and search and navigation applications.

Concept Classes

A Concept Class is a way to group Concepts together in order to:

1. Specify certain modeling constraints:
   a. Valid Concept-to-concept Relationships
   b. Valid Concept Metadata elements
   c. Valid Alternative Labels (i.e. Concept-to-label Relationships)
2. Specify common Classification Server rules and behaviors (although this can be accomplished in other ways also, such as by branch).

Every Concept is required to be a member of a least one Concept Class. By default, all Concepts are members of the base class, “Concept”, represented by the tag skos:Concept.

Additional sub-classes can be added to the model.

Example:

<Class1 URI>
  rdf:type owl:Class ;
  rdfs:label "Class1"@en ;
  rdfs:subClassOf skos:Concept ;
.

A Concept can then become a member of one or more Concept Classes by assigning it’s rdf:type as the appropriate sub-class. For example:

rdf:type <Class1 URI>

Concept Metadata

Metadata values can be added to Concepts. These include things like descriptions, notes, etc. Adding Metadata to a model is a two-step process: first, adding the Metadata “container”, or element, so that it is available to add values to; and secondly, adding the values once the elements are there. Out of the box, Semaphore makes some standard SKOS Metadata elements available in KMM:

skos:editorialNote
skos:historyNote
skos:note
skos:scopeNote

These elements are defined in an RDF ‘structure’ model that is incorporated into each KMM model. The ‘structure’ model is defined in the RDF file, semaphore-core.ttl, part of the Semaphore KMM install. Additional Metadata elements can be added to a model by language.

Example:

<Metadata1 URI>
  rdf:type owl:DatatypeProperty ;
  rdfs:domain skos:Concept ;
  rdfs:label "Metadata1"@en ;
  rdfs:range xsd:string ;
.

Values can be added to Concepts in specified Metadata elements:

<Concept URI>
  <Metadata Element URI> "Metadata1 value"@en ;
.

Concept Relationship Sub-types

In addition to the standard skos:broader/skos:narrower and skos:related relationship types, Semaphore supports the use of relationship sub-types, i.e. named relationship types. Each of these sub-types must be sub-types of either Hierarchical (skos:broader/skos:narrower) or Associative (skos:related) types.

Associative sub-types can either be symmetrical or ‘bidirectional’ – that is, having a forward label and an inverse label. Hierarchical sub-types are always ‘bidirectional’.

Hierarchical Sub-types

Example:

<Forward Label URI>
  rdf:type owl:ObjectProperty ;
  rdfs:domain skos:Concept ;
  rdfs:label "Has Hierarchical Sub-Type1 Relationship"@en ;
  rdfs:range skos:Concept ;
  rdfs:subPropertyOf skos:narrower ;
  owl:inverseOf <Inverse Label URI> ;
.
<Inverse Label URI>
  rdf:type owl:ObjectProperty ;
  rdfs:domain skos:Concept ;
  rdfs:label "Is Hierarchical Sub-Type1 Relationship"@en ;
  rdfs:range skos:Concept ;
  rdfs:subPropertyOf skos:broader ;
  owl:inverseOf <Forward Label URI> ;
.

Bidirectional Associative Sub-types

Bidirectional Associative sub-types are constructed the same way as Hierarchical sub-types except that the ‘rdfs:subPropertyOf’ is ‘skos:related’ for both the forward label and the inverse label.

Example:

<Forward Label URI>
  rdf:type owl:ObjectProperty ;
  rdfs:domain skos:Concept ;
  rdfs:label "Has Associate Sub-Type1 Relationship"@en ;
  rdfs:range skos:Concept ;
  rdfs:subPropertyOf skos:related ;
  owl:inverseOf <Inverse Label URI> ;
.
<Inverse Label URI>
  rdf:type owl:ObjectProperty ;
  rdfs:domain skos:Concept ;
  rdfs:label "Is Associate Sub-Type1 Relationship"@en ;
  rdfs:range skos:Concept ;
  rdfs:subPropertyOf skos:related ;
  owl:inverseOf <Forward Label URI> ;
.

Symmetrical Associative Sub-types

Symmetrical sub-types do not have an ‘inverse’ label. However, the rdf:type of owl:SymmetricProperty is used in the RDF model to denote symmetry.

Example:

<Symmetrical-Associate-Sub-Type1-Relationship URI>
  rdf:type owl:ObjectProperty ;
  rdf:type owl:SymmetricProperty ;
  rdfs:domain skos:Concept ;
  rdfs:label "Symmetrical Associate Sub-Type1 Relationship"@en ;
  rdfs:range skos:Concept ;
  rdfs:subPropertyOf skos:related ;
.