Essential Information Elements

The Minimum Required Components

Every ontology, regardless of domain or complexity, requires certain foundational elements. Understanding these components and their interdependencies ensures systematic development and prevents costly rework.

Class Definitions with Annotations

Classes form your ontology's conceptual backbone. In the ontologies, classes like 'Social_Process', 'Social_Group', or 'BaselinePlan' and 'ProjectBrief' represent fundamental domain-relevant concepts. Each class requires more than merely a label—comprehensive annotations transform bare concepts into meaningful, reusable knowledge.

Essential annotations include:

Definitions (rdfs:comment or skos:definition): Precise, unambiguous explanations of what the class represents. "A Social_Movement is a collective action by a group of people sharing common objectives, typically seeking social or political change through coordinated activity." Such definitions resolve ambiguity and guide consistent usage. If we want to see the ontology among the OBO Foundry ontologies, then of course we need to use OBO Foundry-conform annotation assertions, such as:

             

Labels (rdfs:label): Human-readable names in one or more languages. Multilingual labels enhance accessibility and international collaboration. The PRINCE2 ontology (it's a project management methodology) could benefit from English, Dutch and German labels alongside English ones, facilitating use by English, Dutch or German managers:

             

Editorial notes (skos:editorialNote): Documentation of design decisions, scope boundaries, or known limitations. "This class excludes purely online movements without physical manifestation; those belong under Digital_Social_Phenomena." Future maintainers thank you for such clarifications.

Provenance metadata: Citations to authoritative sources—textbooks, standards documents, domain experts consulted. This grounds your ontology in established knowledge and facilitates verification.

Object Properties: Annotations and Characteristics

Object properties define relationships between instances. In PRINCE2 ontology, properties like 'isMemberOfActor', 'isStakeholderOf', and 'stageFulfillmentBy' structure the management knowledge graph.

Critical specifications:

Domain and range: Which classes can serve as subjects and objects? The property 'supervises' might have domain 'Manager' and range 'Employee', constraining usage and enabling reasoner validation.

Property characteristics matter profoundly:

• Functional: Each subject relates to at most one object ('hasBirthDate')
• Inverse functional: Each object relates to at most one subject ('isIdentifiedBy' for unique identifiers)
• Transitive: If A relates to B and B relates to C, then A relates to C ('isPartOf', 'hasAncestor')
• Symmetric: If A relates to B, then B relates to A ('isMarriedTo', 'isColleagueOf')
• Asymmetric: If A relates to B, then B cannot relate to A ('isParentOf', 'supervises')
• Reflexive/Irreflexive: Whether entities can relate to themselves

The PRINCE2 ontology meticulously specifies these characteristics for its 34 object properties, enabling sophisticated automated reasoning. For instance, marking 'isPartOf' as transitive allows reasoners to infer that if a Department is part of a Faculty, and the Faculty is part of a University, then the Department is transitively part of the University—without explicit assertion.

Inverse properties: Defining inverse pairs ('creates' / 'createdBy', 'supervises' / 'supervisedBy') enables bidirectional navigation and query flexibility. Both the OCS and the PRINCE2 ontologies define inverses for each object property, ensuring comprehensive relationship coverage.

Data Properties: Types and Constraints

Data properties link instances to literal values—numbers, strings, dates, booleans. Where object properties connect entities within your ontology, data properties ground those entities in measurable or descriptive data.

Essential specifications:

Data types (xsd:integer, xsd:string, xsd:dateTime, xsd:decimal): Explicit typing enables validation and appropriate handling. A property 'hasAge' typed as xsd:integer prevents nonsensical values like "twenty-three" or "blue".

Domain constraints: Which classes can bear this property? 'hasEmployeeCount' makes sense for 'Organisation' but not for 'Person'.

Cardinality restrictions:Must every instance have this property? Can it have multiple values? "Every Person has exactly one birthDate" versus "A Person may have zero or more emailAddresses."

Functional characteristics: If 'hasSerialNumber' is functional, each instance has at most one serial number—reasoners flag violations.

The reference ontology's 78 data properties include annotations explaining measurement units, valid ranges, and data collection methodologies—crucial for reproducibility and correct interpretation.

Relationship Definitions: Beyond Simple Triples

Simple subject-predicate-object triples suffice for many relationships, but complex domains often require richer patterns. N-ary relations handle multi-factor causation: Rather than stating "A causes B" (binary), sociological phenomena often involve "factors X, Y, and Z collectively produce outcomes A and B." The reference ontology's reification pattern creates explicit 'Collective_Causal_Event' individuals connecting multiple causes to multiple effects whilst maintaining logical coherence and query tractability.

Each relationship requires:

Relation name and identifier: Systematic naming ('causal_Event_ID000139') enables reference and tracking.

Annotations explaining: Theoretical basis, empirical support, scope limitations, and sociological significance. These transform formal structures into interpretable scholarly knowledge.

Type specification: Is this causal, temporal, spatial, compositional, or functional? Explicit typing guides appropriate reasoning and query formulation.

Subject(s) and object(s): In n-ary patterns, multiple entities participate. The reference ontology's pattern explicitly links contributory factors via 'contributesToCausalEvent' and consequent effects via 'causalEventProduces', whilst also generating Cartesian product assertions for direct query access.

Representation Formats for Information Elements

How you capture these elements depends on workflow preferences. We can employ structured text files—space-delimited for class hierarchies, formatted specifications for properties and relationships. This approach balanced human readability, version controllability, and automated processing.

Alternative approaches include spreadsheets (accessible to non-technical domain experts but limited expressiveness), direct Protégé editing (immediate validation but requiring tool familiarity), or programmatic generation from databases (powerful but requiring robust scripting infrastructure).

The critical requirement: whatever format you choose, ensure completeness. Every class needs definitions and annotations. Every property requires domain/range specifications and characteristic declarations. Every relationship demands clear documentation. Incomplete specifications create ambiguity, undermining the ontology's value proposition.