Hierarchies, Relations, and Collections

The Three Fundamental Semantic Relations

Knowledge organization relies on three basic types of semantic relations between concepts:

1. IS-A (taxonomic/subsumption): A subtype relationship

   • Example: “Width IS-A dimensional property”

2. PART-OF (mereological/composition): A component relationship

   • Example: “Optical window PART-OF reactor”

3. HAS-A (attribution/possession): A property relationship

   • Example: “Substrate HAS-A width”

Understanding these distinctions is essential for correctly structuring vocabularies and avoiding semantic confusion.

Core Principles

Using skos:narrower / skos:broader for IS-A Relations Exclusively

The SKOS standard does not constrain the type of hierarchy expressed with the relations skos:broader and skos:narrower. While SKOS focuses on “IS-A” relations (car is a vehicle), expressing part-whole relations (tire is part of car) would also be possible. However, Voc4Cat is designed as a taxonomy that organizes concepts by subject. Therefore, the type of relations between concepts to create hierarchies are strictly “IS-A” relationships, and skos:broader and skos:narrower are only used to express IS-A (but not for PART-OF or HAS-A relations).

Thus, Voc4Cat focuses on categorizing things by what they are. Such subject hierarchies with IS-A based hierarchies correspond well with ontological modeling and reasoning as well as semantic search.

Correct usage:

:Width skos:broader :DimensionalProperty .
# "Width IS-A Dimensional Property" (taxonomic)

Anti-patterns:

:SubstrateWidth skos:broader :Substrate .
# Wrong: Confuses HAS-A ("Substrate HAS-A width") with IS-A

:OpticalWindow skos:broader :Reactor .
# Wrong: Confuses PART-OF ("Window PART-OF reactor") with IS-A

Avoid Object-Specific Attribute Concepts

Each attribute concept should be placed at its most appropriate taxonomic level, based on IS-A relations, and should not be repeated for every object that it can describe.

Don’t create object-specific attribute concepts:

:Width a skos:Concept ;
    skos:broader :DimensionalProperty .

:SubstrateWidth a skos:Concept ;
    skos:broader :Width .
    
:FilmWidth a skos:Concept ;
    skos:broader :Width .

Problem: Unnecessary proliferation of concepts. While these technically follow IS-A logic, they create redundancy. The single concept Width can be applied to various objects (substrate, film, reactor) through data annotation metadata.

Create a generic attribute concept:

:Width a skos:Concept ;
    skos:broader :DimensionalProperty .
    # This single concept can be applied to substrates, films, reactors, etc.

Avoid Mixing Entity and Attribute Hierarchies

A more fundamental error is placing attribute concepts under entity concepts:

Never do this:

:Substrate a skos:Concept ;
    skos:broader :PhysicalEntity .
    
:SubstrateWidth a skos:Concept ;
    skos:broader :Substrate .
    # Wrong: "Width" is not a subtype of "Substrate"

Number of Parents

One parent is the norm. A concept may be given more than one parent (a polyhierarchy) when it belongs to two independent classifications at the same time. Polyhierarchies are permitted by ANSI/NISO Z39.19-2005 (R2010) and ISO 25964-1. In Voc4Cat they are the exception, and are used only where all three of the following conditions hold:

1. Each parent passes the IS-A test on its own. Every instance of the concept must be an instance of every parent, checked one parent at a time.

2. No parent is an ancestor of another parent. skos:broader itself is not transitive, but skos:broaderTransitive already yields the ancestor, so such an entry states a relation that holds anyway.

3. The parents come from different classifications. Parents that answer the same question about a concept do not separate anything.

Correct usage:

:DetectorDeadTime skos:broader :DeadTime .
# Classification by kind of quantity

:DetectorDeadTime skos:broader :DetectorPerformanceMeasure .
# Classification by what the quantity characterizes

Anti-patterns:

:DimensionalProperty skos:broader :Attribute .

:Width skos:broader :DimensionalProperty ;
    skos:broader :Attribute .
# Wrong: Attribute is already reached through DimensionalProperty (condition 2)

:Width skos:broader :SubstrateProperty ;
    skos:broader :FilmProperty .
# Wrong: both parents answer "which object does this describe?" (condition 3)

Practical check for condition 3: compare the members of the parent classes. If they always contain the same concepts, those classes are one class under several names. What then needs revision is the classification, not the number of parents on the concept.

Where a second parent would express a context of use rather than a kind, use a skos:Collection instead.

Using skos:Collection for HAS-A and Contextual Relations

For other use cases, grouping concepts by topic is valuable. For such groupings, skos:Collection should be used. In Voc4Cat, skos:Collection may be used to create topic-wise lists or even for representing list-of-lists. In this topic-wise form of organization, PART-OF relations, HAS-A relations, or even looser relations (e.g., skos:related) dominate.

Use collections to express HAS-A relationships and group attributes by context:

• Object context (e.g., substrate attributes, reactor parameters)

  • Expresses: “Substrate HAS-A {width, thickness, material}”

• Measurement technique (e.g., XRF-measurable attributes)

  • Expresses: “XRF HAS-A {set of measurable attributes}”

• Application domain (e.g., photocatalysis parameters)

An example for such a collection in Voc4Cat is voc4cat:0007130, which collects the attribute terms for Scanning Electron Microscopy (SEM) measurements.

Expressing PART-OF Relations

PART-OF relationships between physical entities should not be modeled in Voc4Cat.

Example of what NOT to do:

:OpticalWindowThickness skos:broader :ReactorDimensions .
# Mixes PART-OF (optical window PART-OF reactor) with attribute hierarchy

PART-OF relations should be modeled in a separate data model or ontology which may reference concepts from Voc4Cat. Voc4Cat focuses exclusively on providing well-defined concepts that can be used as building blocks in such data models, but does not itself express compositional relationships between physical entities.

Context from Metadata, Not Vocabulary Structure

HAS-A and PART-OF relationships are expressed in data annotation metadata, not in the vocabulary hierarchy.

In data annotation:

• Attribute concept: URI reference to voc4cat:Width

• Measured object (HAS-A): Specified in metadata field (e.g., “substrate HAS-A width”)

• Object composition (PART-OF): Specified in metadata (e.g., “substrate PART-OF thin film”)

• Measurement device: Specified in metadata field

Benefits for Data Annotation

1. Semantic clarity: Each relation type handled appropriately

2. Unambiguous concept URIs: One URI per semantic concept following IS-A logic

3. Simple queries: “Find all width measurements” queries a single concept

4. Maintainable: No proliferation of concepts mixing relation types

5. Flexible: Collections express HAS-A relations without hierarchy pollution

6. Extensible: New objects or measurement techniques don’t require new attribute concepts

Voc4Cat Top-Concepts

The concepts included in Voc4Cat are structured under the following Top-Concepts:

	Compact URI	Top-Concept	Definition	Examples
1	voc4cat:0000180	Physical entity	Entity with a concrete and physical nature.	electrode, photocatalyst
2	voc4cat:0000181	Non-temporal abstract entity	Any entity that cannot be located in space-time. E.g., mathematical entities, formal semantics elements, regions within dimensional spaces, ideas, models.	valence band, Fermi level
3	voc4cat:0000182	Temporal abstract entity	Anything that has a temporal dimension, whether it is an instantaneous point in time, a duration, or a sequence of events.
3.1	voc4cat:0000183	Events	An occurrence or happening, marked by a specific point in time. Events can be observed, recorded, and may have an impact on the state of the system or entities involved.	charge transport, oxidation
3.2	voc4cat:0000184	Actions	Temporal entities that have a duration and occur at specific points in time.	purging, calcination
3.3	voc4cat:0000185	Processes	A series of temporal entities, like actions, events, changes, or functions that are not isolated but rather a connected sequence of activities. Processes often involve the transformation of inputs into outputs and can be conceptualized as workflows.	hydrothermal synthesis, catalyst deactivation
4	voc4cat:0000186	Attributes	A property that an entity has rather than is: a quantity, whose value has a magnitude, or a nominal property, whose value is a name or a code.	reaction rate, sample mass, catalyst form, stirrer type

These top concepts are similar to those in top-level ontologies (BFO, SIO, DOLCE), to what is proposed in ANSI/NISO Z39.19-2005 (R2010), or what was proposed as minimal set of terms for a re-organization of AgroVoc.

Summary: Relation Types and Their Modeling

Relation Type	Modeling Approach	Example
IS-A	skos:broader/skos:narrower	Width IS-A dimensional property
HAS-A	skos:Collection membership	Substrate HAS-A {width, thickness}
PART-OF	External to attribute hierarchy	Window PART-OF reactor

Key principle: Keep the attribute vocabulary hierarchy pure by using skos:broader/skos:narrower exclusively for IS-A (taxonomic) relationships.