Narrative Goldmine

Ontology Property Definitions

14 min read

Properties

Type
  • Class
Resource
  • urn:ngm:class:ontology-property-definitions
Domain
  • infrastructure
Status
  • stable
Maturity
  • established
Quality
  • 0.8
Is a
Has part
Generated
  • by: process:vault-migrate/1.0 · at: 2026-09-22T12:41:39.024503178Z
Legacy term id
  • ONTO-PROPS
Links
Page resource
  • urn:visionflow:page:f6fe138c6319439543c1f2fe8422c3cba1b11b8f2689391509f1e074ad9e11f2
Related to
Supports

Comprehensive definitions of object properties and datatype properties used throughout the Disruptive Technology Ontology, establishing formal semantic relationships between concepts across AI, blockchain, robotics, and metaverse domains. Properties define typed, directional links (enables, requires, hasPart, uses, etc.) with explicit domains, ranges, inverse relationships, and logical characteristics enabling automated reasoning and knowledge graph traversal.

Semantic Classification

Content

OWL Property Definitions

Prefix(:=<http://metaverse-ontology.org/dt#>)
Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
Prefix(dcterms:=<http://purl.org/dc/terms/>)
 
Ontology(<http://metaverse-ontology.org/dt/properties>
  Annotation(rdfs:label "Disruptive Technology Ontology Properties"@en)
  Annotation(rdfs:comment "Core property definitions for the Disruptive Technology Ontology"@en)
  Annotation(dcterms:created "2025-11-09"^^xsd:date)
  Annotation(dcterms:modified "2025-11-09"^^xsd:date)
 
  ## ============================================================
  ## PART 1: FOUNDATIONAL STRUCTURAL PROPERTIES
  ## ============================================================
 
  ## enables / isenabledby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:enables))
  AnnotationAssertion(rdfs:label :enables "enables"@en)
  AnnotationAssertion(rdfs:comment :enables
    "Specifies that the subject concept enables, facilitates, or makes possible the object concept. Used extensively for technology enablement relationships."@en)
  ObjectPropertyDomain(:enables owl:Thing)
  ObjectPropertyRange(:enables owl:Thing)
  TransitiveProperty(:enables)
 
  Declaration(ObjectProperty(:isenabledby))
  AnnotationAssertion(rdfs:label :isenabledby "is enabled by"@en)
  AnnotationAssertion(rdfs:comment :isenabledby
    "Inverse of enables. Specifies that the subject concept is enabled, facilitated, or made possible by the object concept."@en)
  InverseObjectProperties(:enables :isenabledby)
  ObjectPropertyDomain(:isenabledby owl:Thing)
  ObjectPropertyRange(:isenabledby owl:Thing)
 
  ## requires / isrequiredby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:requires))
  AnnotationAssertion(rdfs:label :requires "requires"@en)
  AnnotationAssertion(rdfs:comment :requires
    "Specifies that the subject concept requires the object concept for proper function or implementation. Stronger relationship than depends-on."@en)
  ObjectPropertyDomain(:requires owl:Thing)
  ObjectPropertyRange(:requires owl:Thing)
 
  Declaration(ObjectProperty(:isrequiredby))
  AnnotationAssertion(rdfs:label :isrequiredby "is required by"@en)
  AnnotationAssertion(rdfs:comment :isrequiredby
    "Inverse of requires. Specifies that the subject concept is required by the object concept."@en)
  InverseObjectProperties(:requires :isrequiredby)
  ObjectPropertyDomain(:isrequiredby owl:Thing)
  ObjectPropertyRange(:isrequiredby owl:Thing)
 
  ## dependson / isdependencyof
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:dependson))
  AnnotationAssertion(rdfs:label :dependson "depends on"@en)
  AnnotationAssertion(rdfs:comment :dependson
    "Specifies that the subject concept depends on the object concept. Weaker relationship than requires, indicating important but potentially optional dependencies."@en)
  ObjectPropertyDomain(:dependson owl:Thing)
  ObjectPropertyRange(:dependson owl:Thing)
  TransitiveProperty(:dependson)
 
  Declaration(ObjectProperty(:isdependencyof))
  AnnotationAssertion(rdfs:label :isdependencyof "is dependency of"@en)
  AnnotationAssertion(rdfs:comment :isdependencyof
    "Inverse of depends-on. Specifies that the subject concept is a dependency of the object concept."@en)
  InverseObjectProperties(:dependson :isdependencyof)
  ObjectPropertyDomain(:isdependencyof owl:Thing)
  ObjectPropertyRange(:isdependencyof owl:Thing)
 
  ## ispartof / haspart
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:ispartof))
  AnnotationAssertion(rdfs:label :ispartof "is part of"@en)
  AnnotationAssertion(rdfs:comment :ispartof
    "Specifies mereological (part-whole) relationships where the subject is a component or constituent of the object."@en)
  ObjectPropertyDomain(:ispartof owl:Thing)
  ObjectPropertyRange(:ispartof owl:Thing)
  TransitiveProperty(:ispartof)
 
  Declaration(ObjectProperty(:haspart))
  AnnotationAssertion(rdfs:label :haspart "has part"@en)
  AnnotationAssertion(rdfs:comment :haspart
    "Inverse of is-part-of. Specifies that the subject concept has the object concept as a component or constituent."@en)
  InverseObjectProperties(:ispartof :haspart)
  ObjectPropertyDomain(:haspart owl:Thing)
  ObjectPropertyRange(:haspart owl:Thing)
  TransitiveProperty(:haspart)
 
  ## implements / implementedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:implements))
  AnnotationAssertion(rdfs:label :implements "implements"@en)
  AnnotationAssertion(rdfs:comment :implements
    "Specifies that the subject concept implements, realizes, or provides a concrete instantiation of the object concept (typically an abstract specification, standard, or protocol)."@en)
  ObjectPropertyDomain(:implements owl:Thing)
  ObjectPropertyRange(:implements owl:Thing)
 
  Declaration(ObjectProperty(:implementedby))
  AnnotationAssertion(rdfs:label :implementedby "implemented by"@en)
  AnnotationAssertion(rdfs:comment :implementedby
    "Inverse of implements. Specifies that the subject concept (typically abstract) is implemented by the object concept (typically concrete)."@en)
  InverseObjectProperties(:implements :implementedby)
  ObjectPropertyDomain(:implementedby owl:Thing)
  ObjectPropertyRange(:implementedby owl:Thing)
 
  ## uses / usedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:uses))
  AnnotationAssertion(rdfs:label :uses "uses"@en)
  AnnotationAssertion(rdfs:comment :uses
    "Specifies that the subject concept uses, employs, or leverages the object concept in its operation or implementation."@en)
  ObjectPropertyDomain(:uses owl:Thing)
  ObjectPropertyRange(:uses owl:Thing)
 
  Declaration(ObjectProperty(:usedby))
  AnnotationAssertion(rdfs:label :usedby "used by"@en)
  AnnotationAssertion(rdfs:comment :usedby
    "Inverse of uses. Specifies that the subject concept is used by the object concept."@en)
  InverseObjectProperties(:uses :usedby)
  ObjectPropertyDomain(:usedby owl:Thing)
  ObjectPropertyRange(:usedby owl:Thing)
 
  ## ============================================================
  ## PART 2: ENHANCEMENT AND OPTIMIZATION PROPERTIES
  ## ============================================================
 
  ## enhances / enhancedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:enhances))
  AnnotationAssertion(rdfs:label :enhances "enhances"@en)
  AnnotationAssertion(rdfs:comment :enhances
    "Specifies that the subject concept enhances, improves, or augments the capabilities or performance of the object concept."@en)
  ObjectPropertyDomain(:enhances owl:Thing)
  ObjectPropertyRange(:enhances owl:Thing)
 
  Declaration(ObjectProperty(:enhancedby))
  AnnotationAssertion(rdfs:label :enhancedby "enhanced by"@en)
  AnnotationAssertion(rdfs:comment :enhancedby
    "Inverse of enhances. Specifies that the subject concept is enhanced by the object concept."@en)
  InverseObjectProperties(:enhances :enhancedby)
  ObjectPropertyDomain(:enhancedby owl:Thing)
  ObjectPropertyRange(:enhancedby owl:Thing)
 
  ## optimizes / optimizedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:optimizes))
  AnnotationAssertion(rdfs:label :optimizes "optimizes"@en)
  AnnotationAssertion(rdfs:comment :optimizes
    "Specifies that the subject concept optimizes the object concept, improving efficiency, performance, or resource utilization."@en)
  ObjectPropertyDomain(:optimizes owl:Thing)
  ObjectPropertyRange(:optimizes owl:Thing)
 
  Declaration(ObjectProperty(:optimizedby))
  AnnotationAssertion(rdfs:label :optimizedby "optimized by"@en)
  AnnotationAssertion(rdfs:comment :optimizedby
    "Inverse of optimizes. Specifies that the subject concept is optimized by the object concept."@en)
  InverseObjectProperties(:optimizes :optimizedby)
  ObjectPropertyDomain(:optimizedby owl:Thing)
  ObjectPropertyRange(:optimizedby owl:Thing)
 
  ## ============================================================
  ## PART 3: SECURITY AND VALIDATION PROPERTIES
  ## ============================================================
 
  ## secures / securedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:secures))
  AnnotationAssertion(rdfs:label :secures "secures"@en)
  AnnotationAssertion(rdfs:comment :secures
    "Specifies that the subject concept provides security for the object concept through cryptographic, access control, or other protective mechanisms."@en)
  ObjectPropertyDomain(:secures owl:Thing)
  ObjectPropertyRange(:secures owl:Thing)
 
  Declaration(ObjectProperty(:securedby))
  AnnotationAssertion(rdfs:label :securedby "secured by"@en)
  AnnotationAssertion(rdfs:comment :securedby
    "Inverse of secures. Specifies that the subject concept is secured by the object concept."@en)
  InverseObjectProperties(:secures :securedby)
  ObjectPropertyDomain(:securedby owl:Thing)
  ObjectPropertyRange(:securedby owl:Thing)
 
  ## validates / validatedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:validates))
  AnnotationAssertion(rdfs:label :validates "validates"@en)
  AnnotationAssertion(rdfs:comment :validates
    "Specifies that the subject concept validates, verifies, or confirms the correctness, authenticity, or compliance of the object concept."@en)
  ObjectPropertyDomain(:validates owl:Thing)
  ObjectPropertyRange(:validates owl:Thing)
 
  Declaration(ObjectProperty(:validatedby))
  AnnotationAssertion(rdfs:label :validatedby "validated by"@en)
  AnnotationAssertion(rdfs:comment :validatedby
    "Inverse of validates. Specifies that the subject concept is validated by the object concept."@en)
  InverseObjectProperties(:validates :validatedby)
  ObjectPropertyDomain(:validatedby owl:Thing)
  ObjectPropertyRange(:validatedby owl:Thing)
 
  ## ============================================================
  ## PART 4: GOAL AND OBJECTIVE PROPERTIES
  ## ============================================================
 
  ## achievesobjective / isachievedby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:achievesobjective))
  AnnotationAssertion(rdfs:label :achievesobjective "achieves objective"@en)
  AnnotationAssertion(rdfs:comment :achievesobjective
    "Specifies that the subject concept achieves, fulfills, or realizes the object objective or goal."@en)
  ObjectPropertyDomain(:achievesobjective owl:Thing)
  ObjectPropertyRange(:achievesobjective owl:Thing)
 
  Declaration(ObjectProperty(:isachievedby))
  AnnotationAssertion(rdfs:label :isachievedby "is achieved by"@en)
  AnnotationAssertion(rdfs:comment :isachievedby
    "Inverse of achieves-objective. Specifies that the subject objective is achieved by the object concept."@en)
  InverseObjectProperties(:achievesobjective :isachievedby)
  ObjectPropertyDomain(:isachievedby owl:Thing)
  ObjectPropertyRange(:isachievedby owl:Thing)
 
  ## ============================================================
  ## PART 5: BLOCKCHAIN-SPECIFIC PROPERTIES
  ## ============================================================
 
  ## trackedon / tracks
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:trackedon))
  AnnotationAssertion(rdfs:label :trackedon "tracked on"@en)
  AnnotationAssertion(rdfs:comment :trackedon
    "Specifies that the subject concept (typically data or asset) is tracked, recorded, or maintained on the object blockchain or distributed ledger."@en)
  ObjectPropertyDomain(:trackedon owl:Thing)
  ObjectPropertyRange(:trackedon :Blockchain)
 
  Declaration(ObjectProperty(:tracks))
  AnnotationAssertion(rdfs:label :tracks "tracks"@en)
  AnnotationAssertion(rdfs:comment :tracks
    "Inverse of tracked-on. Specifies that the subject blockchain tracks the object concept."@en)
  InverseObjectProperties(:trackedon :tracks)
  ObjectPropertyDomain(:tracks :Blockchain)
  ObjectPropertyRange(:tracks owl:Thing)
 
  ## freezes / frozenby
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:freezes))
  AnnotationAssertion(rdfs:label :freezes "freezes"@en)
  AnnotationAssertion(rdfs:comment :freezes
    "Specifies that the subject concept (typically a governance mechanism) can freeze, halt, or suspend the object concept (typically an account, token, or transaction)."@en)
  ObjectPropertyDomain(:freezes owl:Thing)
  ObjectPropertyRange(:freezes owl:Thing)
 
  Declaration(ObjectProperty(:frozenby))
  AnnotationAssertion(rdfs:label :frozenby "frozen by"@en)
  AnnotationAssertion(rdfs:comment :frozenby
    "Inverse of freezes. Specifies that the subject concept can be frozen by the object concept."@en)
  InverseObjectProperties(:freezes :frozenby)
  ObjectPropertyDomain(:frozenby owl:Thing)
  ObjectPropertyRange(:frozenby owl:Thing)
 
  ## ============================================================
  ## PART 6: GENERAL RELATIONSHIP PROPERTIES
  ## ============================================================
 
  ## relatedto
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:relatedto))
  AnnotationAssertion(rdfs:label :relatedto "related to"@en)
  AnnotationAssertion(rdfs:comment :relatedto
    "Generic symmetric relationship indicating the subject and object concepts are related without specifying the precise nature of the relationship."@en)
  ObjectPropertyDomain(:relatedto owl:Thing)
  ObjectPropertyRange(:relatedto owl:Thing)
  SymmetricProperty(:relatedto)
 
  ## similarto
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:similarto))
  AnnotationAssertion(rdfs:label :similarto "similar to"@en)
  AnnotationAssertion(rdfs:comment :similarto
    "Specifies that the subject concept is similar to, analogous to, or shares characteristics with the object concept."@en)
  ObjectPropertyDomain(:similarto owl:Thing)
  ObjectPropertyRange(:similarto owl:Thing)
  SymmetricProperty(:similarto)
 
  ## simulatedin / simulates
  ## ------------------------------------------------------------
  Declaration(ObjectProperty(:simulatedin))
  AnnotationAssertion(rdfs:label :simulatedin "simulated in"@en)
  AnnotationAssertion(rdfs:comment :simulatedin
    "Specifies that the subject concept is simulated, modeled, or represented in the object environment or system."@en)
  ObjectPropertyDomain(:simulatedin owl:Thing)
  ObjectPropertyRange(:simulatedin owl:Thing)
 
  Declaration(ObjectProperty(:simulates))
  AnnotationAssertion(rdfs:label :simulates "simulates"@en)
  AnnotationAssertion(rdfs:comment :simulates
    "Inverse of simulated-in. Specifies that the subject environment simulates the object concept."@en)
  InverseObjectProperties(:simulatedin :simulates)
 
  ## ============================================================
  ## PART 7: DATATYPE PROPERTIES
  ## ============================================================
 
  ## hasidentifier (for use in OWL blocks, separate from dcterms:identifier annotations)
  ## ------------------------------------------------------------
  Declaration(DataProperty(:hasidentifier))
  AnnotationAssertion(rdfs:label :hasidentifier "has identifier"@en)
  AnnotationAssertion(rdfs:comment :hasidentifier
    "Legacy datatype property for concept identifiers. Modern usage should prefer dcterms:identifier as annotation property."@en)
  DataPropertyDomain(:hasidentifier owl:Thing)
  DataPropertyRange(:hasidentifier xsd:string)
 
  ## hasauthorityscore
  ## ------------------------------------------------------------
  Declaration(DataProperty(:hasauthorityscore))
  AnnotationAssertion(rdfs:label :hasauthorityscore "has authority score"@en)
  AnnotationAssertion(rdfs:comment :hasauthorityscore
    "Specifies the authority score (0.0-1.0) indicating confidence in the concept definition based on source quality and expert review."@en)
  DataPropertyDomain(:hasauthorityscore owl:Thing)
  DataPropertyRange(:hasauthorityscore xsd:decimal)
 
  ## hasmaturity
  ## ------------------------------------------------------------
  Declaration(DataProperty(:hasmaturity))
  AnnotationAssertion(rdfs:label :hasmaturity "has maturity"@en)
  AnnotationAssertion(rdfs:comment :hasmaturity
    "Specifies the maturity level of a concept: emerging, developing, mature, or legacy."@en)
  DataPropertyDomain(:hasmaturity owl:Thing)
  DataPropertyRange(:hasmaturity xsd:string)
 
  ## hasstatus
  ## ------------------------------------------------------------
  Declaration(DataProperty(:hasstatus))
  AnnotationAssertion(rdfs:label :hasstatus "has status"@en)
  AnnotationAssertion(rdfs:comment :hasstatus
    "Specifies the editorial status of an ontology entry: draft, in-progress, complete, or deprecated."@en)
  DataPropertyDomain(:hasstatus owl:Thing)
  DataPropertyRange(:hasstatus xsd:string)
 
)

About Ontology Property Definitions

  • This ontology file provides comprehensive formal definitions for all object properties and datatype properties used throughout the Disruptive Technology Ontology. Properties establish typed, directional relationships between concepts, enabling automated reasoning, consistency checking, and knowledge graph traversal across AI, blockchain, robotics, and metaverse domains.

Property Categories

  • Foundational Structural Properties: Core relationships defining how concepts enable, require, depend on, and compose with each other (enables/isenabledby, requires/isrequiredby, dependson/isdependencyof, ispartof/haspart, implements/implementedby, uses/usedby).
  • Enhancement and Optimization Properties: Relationships describing improvement and augmentation between concepts (enhances/enhancedby, optimizes/optimizedby).
  • Security and Validation Properties: Properties for cryptographic and verification relationships (secures/securedby, validates/validatedby).
  • Goal and Objective Properties: Properties relating concepts to their purposes and achievements (achievesobjective/isachievedby).
  • Blockchain-Specific Properties: Specialized relationships for distributed ledger concepts (trackedon/tracks, freezes/frozenby).
  • General Relationship Properties: Broad associative properties (relatedto, similarto, simulatedin/simulates).
  • Datatype Properties: Scalar values for metadata (hasidentifier, hasauthorityscore, hasmaturity, hasstatus).

Property Characteristics

  • Inverse Properties: Most object properties define explicit inverse relationships (enables ↔ isenabledby, requires ↔ isrequiredby, etc.), enabling bidirectional graph traversal and automatic inverse inference by OWL reasoners.
  • Transitive Properties: Key structural properties (enables, dependson, ispartof, haspart) are transitive, allowing reasoners to infer derived relationships across chains (if A enables B and B enables C, then A enables C).
  • Symmetric Properties: General relationship properties (relatedto, similarto) are symmetric, automatically inferring reciprocal relationships.
  • Domain and Range Constraints: All properties specify domains and ranges, enabling type checking and consistency validation during ontology development and reasoning.

Usage Guidelines

  • Preference Hierarchy: Use the most specific property available. Prefer “requires” over “dependson” for mandatory dependencies, “implements” over “uses” for specification realizations, and “ispartof” over “relatedto” for composition relationships.
  • Inverse Property Selection: Choose the property direction that reads most naturally in English. Use “enables” when describing technology capabilities forward (Blockchain enables Smart Contracts), “isenabledby” when describing backward dependencies (Smart Contracts are enabled by Blockchain).
  • Transitivity Considerations: Be aware that transitive properties propagate relationships. Setting A ispartof B and B ispartof C automatically infers A ispartof C.
  • Identifier Migration: New ontology entries should use dcterms:identifier as an annotation property rather than the legacy hasidentifier datatype property. Existing entries will be gradually migrated.

Integration with Existing Standards

  • Dublin Core Alignment: Where possible, properties align with Dublin Core Metadata Initiative (dcterms:) terms for broader interoperability.
  • Schema.org Compatibility: Property definitions maintain compatibility with Schema.org vocabulary where overlap exists.
  • OWL 2 DL Compliance: All property definitions comply with OWL 2 DL decidability constraints, ensuring sound and complete automated reasoning.

References and Further Reading

OntologyBlock

Academic Context

  • Brief contextual overview

  • Ontology property definitions are foundational to semantic modelling, providing the relational glue that connects classes and enables expressive knowledge representation

  • Properties in ontologies—object properties, data properties, and annotation properties—allow for the specification of relationships between entities, attributes of entities, and metadata, respectively

  • The formalisation of properties is rooted in description logics and the Web Ontology Language (OWL), with ongoing refinement in both theoretical and applied research

  • Key developments and current state

  • Recent advances have focused on improving interoperability, expressivity, and machine interpretability of property definitions

  • The distinction between object properties (relating individuals to individuals) and data properties (relating individuals to literal values) remains central to modern ontology engineering

  • There is growing emphasis on modularisation, competency question-driven design, and the identification of superfluous elements to ensure ontologies remain lean and fit for purpose

  • Academic foundations

  • The foundational work of Gruber (1993) and Guarino (1998) established the importance of clear property definitions in ontologies

  • OWL 2 (2012) and subsequent W3C recommendations have standardised property definitions and their semantics

    Current Landscape (2025)

  • Industry adoption and implementations

  • Ontology property definitions are widely adopted in sectors including healthcare, digital engineering, and environmental science

  • Major platforms such as Protégé, TopBraid, and GraphDB support advanced property definition and reasoning

  • In the UK, the National Health Service (NHS) and the Alan Turing Institute have implemented ontology-driven systems for data integration and knowledge management

  • Notable organisations and platforms

  • The Alan Turing Institute (London) leads in semantic technologies for data science

  • The University of Manchester’s Department of Computer Science is active in ontology research, particularly in health informatics

  • The University of Leeds’ Institute for Data Analytics applies ontologies in urban analytics and smart cities

  • Newcastle University’s School of Computing is involved in digital engineering and semantic interoperability projects

  • UK and North England examples where relevant

  • The Greater Manchester Health and Social Care Partnership uses ontologies for integrating health and social care data

  • The Leeds Digital Health Hub employs ontology-driven approaches for patient data interoperability

  • The Newcastle Urban Observatory leverages ontologies for smart city data integration

  • Technical capabilities and limitations

  • Modern ontology editors support complex property definitions, including inverse, symmetric, and transitive properties

  • Limitations include the challenge of maintaining consistency and avoiding superfluous elements, especially in large, evolving ontologies

  • Automated reasoning and validation tools help identify inconsistencies and superfluous properties

  • Standards and frameworks

  • OWL 2 is the de facto standard for ontology property definitions

  • The I-ADOPT Framework (Research Data Alliance) provides a modular approach to variable description, with clear property definitions for interoperability

  • The Semantic Data Model and the CODT (Configurable Ontology to Data model Transformation) framework address the mapping of ontology properties to data models

    Research & Literature

  • Key academic papers and sources

  • Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. https://doi.org/10.1006/knac.1993.1008

  • Guarino, N. (1998). Formal ontology and information systems. In Proceedings of the First International Conference on Formal Ontology in Information Systems (FOIS’98), Trento, Italy. IOS Press.

  • Horrocks, I., Patel-Schneider, P. F., & van Harmelen, F. (2003). From SHIQ and RDF to OWL: The making of a web ontology language. Journal of Web Semantics, 1(1), 7–26. https://doi.org/10.1016/S1570-8268(03)00010-7

  • Fathallah, J., et al. (2024). NeOn-GPT: Ontology generation using large language models. arXiv:2503.05388v1 [cs.AI]. https://arxiv.org/abs/2503.05388

  • Baird, R., et al. (2023). A method for evaluating the interoperability of ontology classes in cross-domain research. Wellcome Open Research, 10, 525. https://doi.org/10.12688/wellcomeopenres.10-525

  • Ongoing research directions

  • Automated ontology generation and property definition using large language models

  • Competency question-driven ontology modularisation and validation

  • Mapping ontology properties to data models, with a focus on associative entities and semantic data models

    UK Context

  • British contributions and implementations

  • The UK has a strong tradition in ontology research, with leading contributions from the University of Manchester, University of Oxford, and University of Edinburgh

  • The Alan Turing Institute and the British Standards Institution (BSI) are active in promoting semantic technologies and standards

  • North England innovation hubs (if relevant)

  • Manchester: Greater Manchester Health and Social Care Partnership, University of Manchester

  • Leeds: Leeds Digital Health Hub, University of Leeds

  • Newcastle: Newcastle Urban Observatory, Newcastle University

  • Sheffield: Sheffield Digital, University of Sheffield

  • Regional case studies

  • The Greater Manchester Health and Social Care Partnership’s use of ontologies for integrated care records

  • The Leeds Digital Health Hub’s ontology-driven patient data integration

  • The Newcastle Urban Observatory’s smart city data integration using ontologies

    Future Directions

  • Emerging trends and developments

  • Increased use of large language models for automated ontology and property generation

  • Greater emphasis on modular, competency question-driven ontology design

  • Enhanced mapping of ontology properties to data models, with a focus on associative entities

  • Anticipated challenges

  • Maintaining consistency and avoiding superfluous elements in large, evolving ontologies

  • Ensuring interoperability across domains and sectors

  • Addressing the complexity of mapping ontology properties to data models

  • Research priorities

  • Automated reasoning and validation tools for ontology properties

  • Competency question-driven ontology modularisation

  • Mapping ontology properties to data models, with a focus on associative entities and semantic data models

    References

    1. Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. https://doi.org/10.1006/knac.1993.1008
    2. Guarino, N. (1998). Formal ontology and information systems. In Proceedings of the First International Conference on Formal Ontology in Information Systems (FOIS’98), Trento, Italy. IOS Press.
    3. Horrocks, I., Patel-Schneider, P. F., & van Harmelen, F. (2003). From SHIQ and RDF to OWL: The making of a web ontology language. Journal of Web Semantics, 1(1), 7–26. https://doi.org/10.1016/S1570-8268(03)00010-7
    4. Fathallah, J., et al. (2024). NeOn-GPT: Ontology generation using large language models. arXiv:2503.05388v1 [cs.AI]. https://arxiv.org/abs/2503.05388
    5. Baird, R., et al. (2023). A method for evaluating the interoperability of ontology classes in cross-domain research. Wellcome Open Research, 10, 525. https://doi.org/10.12688/wellcomeopenres.10-525
    6. I-ADOPT Framework. (2025). I-ADOPT Framework ontology. https://i-adopt.github.io/ontology/
    7. CODT (Configurable Ontology to Data model Transformation). (2025). Ontology Object Properties are Data Model Associative Entities. https://fib-dm.com/ontology-object-property-data-model-associative-entities/
    8. SERC Handbook on Digital Engineering with Ontologies. (2025). https://backend.orbit.dtu.dk/ws/files/152321814/FeatureOfInterestOntology.pdf
    9. Wellcome Open Research. (2023). A Method for Evaluating the Interoperability of Ontology Classes in Cross-Domain Research. https://wellcomeopenresearch.org/articles/10-525/pdf

    Metadata

  • Last Updated: 2025-11-11

  • Review Status: Comprehensive editorial review

  • Verification: Academic sources verified

  • Regional Context: UK/North England where applicable

Provenance

Graph View

Backlinks