skos:broader

Broader relationships

skos:broader, skos:narrower and skos:related reflect what, in ISO 2788/5964, was BT, NT and RT at the concept level.

However, since SKOS has a broader scope in terms of KOS types, it does not make any recommendation as precise as in ISO 2788 on what is a valid hierarchy. It is primarily up to KOS editors to ensure that the links in their schemas do not conflict with what is observed in general KOS practice, of which thesauri are only one part. Instead, SKOS focuses on separating explicitly asserted “parent-child” links (skos:broader) from the more general “ancestor-descendant” links that can be automatically inferred from them (skos:broaderTransitive).

SKOS also allows to specialize semantic relations (see below). However, it does not propose a standard set of such specializations. Rather, these are expected to come from other standards and guidelines, such as ISO 2788 itself.

Broader/specific relationships

.
To assert that one concept has a broader (i.e., more general) meaning than another, the skos:broader property is used. The skos:narrower property is used to assert the opposite, i.e., when one concept has a narrower (i.e., more specific) meaning than another. For example:

ex:animals rdf:type skos:Concept;
skos:prefLabel “animals”@en;
skos:narrower ex:mammals.
ex:mammals rdf:type skos:Concept;
skos:prefLabel “mammals”@en;
skos:broader ex:animals.

As is often the case in KOS, a SKOS concept can be attached to several broader concepts at the same time. For example, a concept ex:dog could have both ex:mammals and ex:pets as broader concepts.

Note on the direction of skos:broader: for historical reasons, the name of the skos:broader property (the word “broader”) does not provide an explicit indication of its direction. The word “broader” should be read here as “has a broader concept”; the subject of a skos:broader assertion is the more specific concept implied by the assertion and its object is the more generic one.

Note on implicit skos:broader/skos:narrower assertions: the skos:broader and skos:narrower properties are inverse. When a concept X is broader than another concept Y, then Y is a narrower concept of X according to the SKOS data model. This can be useful for making SKOS representations more efficient by limiting the information they contain. In the above example, for example, the ex:mammals skos:broader ex:animals statement can be omitted if, before using the conceptual schema data, an OWL reasoner is used to infer it from the ex:animals skos:narrower ex:mammals statement.

In many cases, hierarchical relationships in a conceptual schema can be considered transitive [OWL]. If ex:animals is broader than ex:mammals, which in turn is broader than ex:cats, it makes sense to state that ex:animals is broader than ex:cats. However, there are “dirtier” hierarchies, especially in KOSs other than well-designed standard thesauri, where such a feature would not be considered appropriate. Consider, for example, a case where ex2:vehicles is said to be broader than ex2:cars, which in turn is claimed to be broader than ex2:wheels. It can be problematic if one automatically infers that “wheels” is a narrower concept with respect to “vehicles”. SKOS anticipates these problems by not defining skos:broader and skos:narrower as generally transitive properties. The reader interested in representing “transitive hierarchies” is encouraged to examine some way of doing so while maintaining compatibility with the skos:broader semantics defined in this section.

Note on non-transitive vs. intransitive: the SKOS model does not state that skos:broader and skos:narrower are transitive. However, this does not imply that these properties are intransitive. Consider a concept cats that is narrower than the concept mammals, which in turn is narrower than animals: cats can be said to be narrower than animals as well, while still being compatible with the SKOS model. Not specifying skos:broader as transitive implies that no new skos:broader claim between cats and animals can be inferred by applying the SKOS axioms. This does not preclude editors of a SKOS concept scheme from asserting hierarchical statements that reflect locally transitive behavior.

Similarly, SKOS does not assume that hierarchical relationships are by default unreflective. In many thesaurus guidelines, it is forbidden for a concept to be broader than itself. However, in specific cases beyond classical thesauri, some reflexive skos:broader statements may occur. Consider the conversion of an existing RDFS/OWL ontology into a SKOS concept schema. In such a case, it is legitimate for each rdfs:subClassOf statement to be reinterpreted as a skos:broader statement. However, rdfs:subClassOf is a reflexive property, which means that for each class C, the C declaration rdfs:subClassOf C is true [OWL]. In this case, each concept would have itself among its broader concepts.

Mixing hierarchy with association

The transitive closure of skos:broader is disjoint from skos:related. If resources A and B are related through skos:related, there should not be a chain of skos:broader relationships from A to B. The same is true for skos:narrower.

SKOS collections, semantic relationships and systematic visualizations

.
Note that, according to the SKOS data model, collections are disjoint from concepts. Therefore, it is impossible to use SKOS semantic relationships to make a collection fit directly into a SKOS semantic network. In other words, grouping concepts into collections does not replace statements about the place of concepts in a conceptual scheme. For example, in the above example of “milk”, all source-defined milks must be explicitly attached to a more generic ex:milk using the skos:broader property:

ex:cowMilk skos:broader ex:milk.
ex:goatMilk skos:broader ex:milk.
ex:buffaloMilk skos:broader ex:milk.

A systematic (hierarchical) visualization can then be generated that includes the concept grouping “milk by animal of origin”, as presented in the example that introduces this subsection. The skos:broader hierarchy and collection membership information can be used for this, but the process still requires a dedicated algorithm, the implementation of which is left to specific applications.

One may wonder whether the use of collections is desirable, as they add complexity to the representations that applications have to manipulate. Indeed, for some cases, for example when KOSs are intended primarily as navigational hierarchies, it seems more intuitive to represent “node labels” or “guiding terms” as instances of skos:Concept, and to use the normal semantic relationships to link them to other concepts. Let’s take the following variant of the “milk” example:

ex3:milkForSourceAnimal rdf:type skos:Concept;
skos:prefLabel “milkBySourceAnimal”@en;
skos:broader ex3:milk;
skos:narrower ex3:cow’s milk;
skos:narrower ex3:goat’s milk;
skos:narrower ex3:buffaloMilk.

The choice between the two representation options is left open, depending on the application in question. However, readers should be aware that not using collections, although more intuitive, may result in a detrimental loss of semantic precision. For many description applications, for example, “node labels” are entities of a truly specific nature, and should not be used as object indexes alongside “normal” concepts. Representing them as mere concepts is therefore not best practice.

Transitive hierarchies

The properties used to represent KOS hierarchies, skos:broader and skos:narrower, are not defined as transitive.

For applications that require such semantics-for example, to perform query expansion-SKOS presents two specific properties, skos:broaderTransitive and skos:narrowerTransitive. They are defined as transitive superproperties of skos:broader and skos:narrower. This pattern allows, using a Semantic Web inference tool, to access the “transitive closure” of a hierarchy expressed with skos:broader and skos:narrower.

Consider the example:

ex:animals skos:prefLabel “animals”@en.
ex:mammals skos:prefLabel “mammals”@en;
skos:broader ex:animals.
ex:cats skos:prefLabel “cats”@en;
skos:broader ex:mammals.

Reading the above triples, a reasoner can use the definition of skos:broaderTransitive as a superproperty of skos:broader to infer the following statements:

ex:cats skos:broaderTransitive ex:mammals.
ex:mammals skos:broaderTransitive ex:animals.

The transitivity of skos:broaderTransitive then causes the desired assertion to be inferred:

ex:cats skos:broaderTransitive ex:animals.

The use of the skos:broaderTransitive superproperty allows communities of practice to exploit transitive interpretations of hierarchical networks as they see fit, without interfering with the semantics of skos:broader, which cannot impose such transitivity. Intuitively, one can interpret skos:broader statements as explicitly asserted direct parental links, whereas skos:broaderTransitive is used to reflect more general (and possibly indirect) ancestry relationships.

Note on the supposed “transitive inheritance”: the superproperty link between skos:broader and skos:broaderTransitive may seem counterintuitive at first glance. In this case, a non-transitive property is defined as a child of a transitive one, but does not inherit its transitivity.

About the specialization of the SKOS model

SKOS is intended to serve as a common denominator between different modeling approaches. As such, the current specification of the vocabulary will allow many existing KOSs to move to the semantic web. However, the wide variety of KOS models makes it impossible to capture all the details of these models without losing the first “S” (“simple”) of “SKOS”.

Applications that require finer granularity will benefit greatly from SKOS being a semantic web vocabulary. In fact, SKOS can be seamlessly extended to suit the specific needs of a particular KOS community, while maintaining compatibility with applications that rely on SKOS core features.

This can be done mainly by specializing existing SKOS constructs into more specific ones. Users can create their own properties and classes and attach them to the standard SKOS vocabulary elements using the rdfs:subPropertyOf and rdfs:subClassOf properties of the RDF Schema vocabulary.

The example illustrates how skosxl:labelRelation can be specialized into a semantically richer property dedicated to the representation of acronym links. Other uses are possible, such as creating different “flavors” of skos:broader and skos:narrower properties. Thesaurus standards in fact identify a small number of hierarchical relation types, such as generic, part-whole or instance-class [ISO 2788]. The SKOS approach allows an application designer to create new properties to capture this distinction, and declare them as subproperties of skos:broader:

ex:broaderGeneric rdfs:subPropertyOf skos:broader.
ex:broaderPartitive rdfs:subPropertyOf skos:broader.
ex:broaderInstantive rdfs:subPropertyOf skos:broader.

Each ex:broaderPartitive statement between two concepts, for example, can be formally interpreted by a suitable Semantic Web reasoning engine. This interpretation will produce the inference of a skos:broader statement between these concepts, information that can be exploited by the basic SKOS tools.

Fact checker: Conrad

The visualization and hierarchical structure

These options should be considered:

• The hierarchical visualization. This is the visualization of the structure of a thesaurus based on the relationships between broader and narrower concepts. In this type of visualization, narrower terms are usually indented under the broader term that is their parent. Each hierarchy, starting with a “parent term,” contains terms from a single facet or sub-facet, so node labels containing facet names do not appear within hierarchies, although they may appear at the top of each hierarchy. A hierarchical display may contain node labels that specify division characteristics.
• The mono-hierarchical structure. This is the hierarchical arrangement of concepts, in a thesaurus or classification scheme, in which each concept can have only one broader concept. Compare with the polyhierarchical structure. In a monohierarchical structure, each concept can only appear in one place in the hierarchy, and other broader term relationships have to be shown as related term relationships.
• The polyhedral structure. This is the hierarchical arrangement of concepts, in a thesaurus or classification scheme, in which each concept may have more than one broader concept. Compare with the monohierarchical structure. In a polyhierarchical structure, the same concept may appear in more than one place in the hierarchy. Its attributes and relationships, and specifically its scope note and its narrower, related terms, are the same wherever it appears.
• The search thesaurus. This is the vocabulary intended to facilitate searching even if it has not been used to index the documents searched. Search thesauri are designed to facilitate the choice of terms and/or the expansion of search expressions to include terms for broader, narrower, or related concepts, as well as synonyms. Optionally, a regular thesaurus can be used as a search thesaurus.