https://top.scientix.ai/v1#
TOP Core is the universal layer of The Ontology Project. It holds the first-class concepts that operators across every domain and every industry recognize: clinical research, care delivery, manufacturing, supply chain, energy, defense, anywhere. The layer is small on purpose. Workflow extensions for specific domains compose on top of the Core layer, never inside them, so the universal layer stays free of domain-specific concerns and reusable across every industry.
8
Category-Level Objects
28
Universal leaves
23
PROV-O alignments
3
SHACL invariants underneath
Architecture
L1 — Operator vocabulary, categories
Eight Category-Level Objects
Agent, Location, Resource, Scope, Temporal, Evidence, Outcome, Constraint. Each category groups the leaves that share a structural role across every operation.
L2 — Operator vocabulary, leaves
Twenty-eight universal entities
The concrete first-class concepts operators reach for: Person, Organization, Schedule, Document, Observation, Safety Guardrail, and so on. Each leaf belongs to exactly one category. Workflow extensions specialize a leaf rather than introducing a new universal one.
Infrastructure floor — Provenance contract (SHACL, not SKOS)
Three properties enforced underneath every entity
Beneath the operator vocabulary, three SHACL invariants apply to every entity in any TOP graph: identifier (what is this thing), observedAt (when it was captured or recorded), status (whether it is current). Together they are the provenance contract that lets a graph be traceable and version-able. The operator never names this layer, which is why it lives in core/v1/shapes.ttl as SHACL rather than as a concept in the taxonomy.
Artifacts
Source of truth
taxonomy.ttl · SKOS canonical taxonomy in Turtle (398 triples, 38 concepts, Termboard-clean)
core/v1/shapes.ttl · OWL classes + SHACL Universal DNA contract
core/v1/walkthroughs/person.ttl · Concrete instance demonstrating L0 → L1 → L2 end-to-end
Companion (queued)
core/v1/context.jsonld — JSON-LD context for NGSI-LD wire format, queued
core/v1/vocabulary/<category>/<leaf>.yaml — CV back-fill per ADR-0018, queued
core/v1/crosswalks/<category>/<leaf>.sssom.tsv — peer-ontology crosswalks (FHIR, USDM, SDTM, MedDRA, NCIt, LOINC, SNOMED, …), queued
PROV-O and NGSI-LD adherence · three layers
Provenance is the mission, so the Core layer binds to the W3C PROV-O standard explicitly rather than running parallel to it. The binding is layered so each layer earns its keep:
Layer 1 — SKOS signaling (this taxonomy, shipped)
23 PROV-O alignments via skos:exactMatch and skos:closeMatch
Every Core concept that has an honest PROV-O peer carries a mapping. top:Person skos:exactMatch prov:Person. top:Activity skos:exactMatch prov:Activity. Every Evidence and Outcome leaf skos:closeMatch prov:Entity. Every Scope leaf skos:closeMatch prov:Plan. Every Location leaf skos:closeMatch prov:Location. Constraint leaves have no PROV-O peer; they align to ODRL/SHACL conceptually, which is a separate alignment pass. The mappings make the alignment visible in any SKOS browse tool without requiring OWL inference.
Layer 2 — SHACL enforcement (core/v1/shapes.ttl, shipped)
Universal DNA contract enforced on every entity
The SHACL foundation carries the strict adherence. Every top:CommonEntity instance is required to carry the three Universal DNA properties (top:identifier, top:observedAt, top:status). Because every L1 category and every L2 leaf inherits from top:CommonEntity, the contract applies through the entire subClassOf chain — no per-leaf re-declaration, no risk of a workflow extension forgetting to enforce it.
Layer 3 — NGSI-LD wire format (core/v1/context.jsonld, queued)
JSON-LD context with the NGSI-LD profile
The JSON-LD context maps each Core concept to its NGSI-LD type and declares the foundation properties (identifier, observedAt, status) as standard NGSI-LD attributes. Anything emitting NGSI-LD JSON-LD against this context is automatically wire-compatible with FIWARE, Orion, Stellio, and any other NGSI-LD broker. The context.jsonld lands alongside the shapes.ttl rebuild.
Provenance contract · enforced underneath, not modeled as vocabulary
Three properties every entity must carry
The operator never sees a concept called "Provenance Contract" because there isn't one in the taxonomy. What the operator sees is a Phlebotomist with cert# 2024-088, a Centrifuge with calibration current through 2026-09-15, an eConsent v3.2 signed at Day -7 · 14:22 CET. The metadata that makes those references trustworthy and version-able is the contract underneath: every entity carries an identifier, an observedAt, and a status. Enforced as SHACL in core/v1/shapes.ttl, applied to every leaf in every workflow extension, asked of every entity by every query. This is the floor that makes the rest of TOP a provenance-grade ontology rather than a vocabulary list.
identifier · what is this thing, uniquely addressable
observedAt · when it was captured or recorded, temporally anchored
status · whether it is current, supersedes-aware
The eight categories and their leaves
1 / Agent top:Agent
top:Agent
Agent ¶
The Core category for entities that act on their own behalf or on behalf of others, hold decision rights over operations, and bear accountability for outcomes. Such entities are the performers of any operation: they initiate Activities, sign Documents, hold Credentials, and stand responsible for what gets done. Distinct from Resource: Resources are used; performers in this category use them.
top:Person
Person ¶
An Agent representing an individual human in any operational context: staff, members, contractors, regulators, recipients, observers, decision-makers. The same human may play multiple roles across different contexts; identity resolution is a federation concern.
Alt: Individual, Human
top:Organization
Organization ¶
An Agent representing a legal or business entity recognized as a distinct actor: corporations, hospitals, government agencies, vendors, academic bodies, regulatory authorities, NGOs, trade associations. Carries legal identifiers and operational addresses.
Alt: Legal Entity, Corporate Entity, Institution
top:Group
Group ¶
An Agent representing a collective body acting together toward a shared purpose, without the formal legal incorporation that defines an Organization: working bodies, committees, ad-hoc teams, panels of reviewers, oversight bodies, review boards.
Alt: Collective, Team
top:AutonomousAgent
Autonomous Agent ¶
An Agent that takes action, makes decisions, or executes operations without direct human control on each step: AI models that produce outputs, software services that act on schedules or events, robotic systems. Responsible party is recorded separately so accountability is preserved.
Alt: AI Agent, Software Agent, Bot
2 / Location top:Location
top:Location
Location ¶
The Core category for places where work happens, where Agents act, or where Resources and outputs are held. Such places span the physical real world, virtual digital systems, and storage containers. Every Activity occurs at some place in this category, every Resource resides somewhere within it, and every Agent has a current locale here.
top:Physical
Physical ¶
A Location subtype for real-world places that occupy space and can be reached by bodily presence: buildings, campuses, clinical sites, manufacturing plants, warehouses, distribution centers, field sites, vehicles in transit, outdoor environments under monitoring.
Alt: Physical Location, Site, Facility
top:Virtual
Virtual ¶
A Location subtype for non-physical places that exist within a network or digital system: service endpoints, web portals, online meeting rooms, cloud storage buckets, VPN tunnels, message queues, addressable services in distributed systems.
Alt: Virtual Location, Digital Address
top:Storage
Storage ¶
A Location subtype for spaces designated specifically for holding things, whether physical or digital: freezer slots, refrigerator shelves, secure vaults, supply bins, archive boxes, database partitions, archive buckets, document repositories, object stores.
Alt: Storage Location, Container
3 / Resource top:Resource
top:Resource
Resource ¶
The Core category for operational assets that Activities consume, use, or operate. As the means of production, members of this category are what Agents reach for to get work done: software systems process information, physical equipment performs tasks, material stocks flow through operations. Distinct from Agent: Agents act; members of this category are used.
top:System
System ¶
A Resource that performs operational work or holds operational data through software: applications, platforms, databases, control software that orchestrates physical equipment, integration buses, analytics engines.
Alt: Software System, Application
top:Equipment
Equipment ¶
A Resource leaf for physical devices and instruments used in operational work: sensors, machines, vehicles, measurement instruments, manufacturing tools, medical devices, lab analyzers, field instrumentation. Carries serial number, calibration date, maintenance interval.
Alt: Device, Instrument
top:Material
Material ¶
A Resource leaf for physical substances, batches, and stocks that flow through operations: raw feedstocks, intermediate products, finished goods, reagents, samples, parts, supplies, fuels, consumables. Carries batch numbers, chain-of-custody, expiration dates.
Alt: Substance, Stock, Consumable
4 / Scope top:Scope
top:Scope
Scope ¶
The Core category for bounded efforts with stated purpose, governance, and a defined boundary. Members of this category are how organizations frame what they are doing and why. They scale from strategic Portfolios at the top, through Programs that group related work under a single mandate, down to specific Projects with start and end dates.
top:Portfolio
Portfolio ¶
A Scope at the largest unit of bounded effort that an organization manages as a single concern. Aggregates Programs aligned to a strategic objective, governed at executive or board level. Carries strategic narrative and financial frame.
Alt: Strategic Portfolio
top:Program
Program ¶
A Scope that contains several related Projects sharing a common mandate, sponsor, or theme. Run by a designated lead. Sits between the strategic frame of a Portfolio and the deliverable focus of an individual Project.
Alt: Programme
top:Project
Project ¶
A Scope at a specific bounded effort with a defined phase, a start date, and an end date, organized to produce a stated deliverable. Where work meets the calendar. Workflow-specific scopes (a clinical Study, a manufacturing Campaign) specialize this leaf.
Alt: Initiative, Engagement
5 / Temporal top:Temporal
top:Temporal
Temporal ¶
The Core category for anything that exists in time, whether as a recurring pattern, a bounded interval, a performed event, or a marker on a timeline. Concepts in this category answer the question of when something happens, must happen, or has happened-and-mattered. Complements Location: when complements where.
top:Schedule
Schedule ¶
A Temporal pattern for repeating times that determine when Activities occur. Encodes the rhythm of work as a recurrence rule (often iCalendar RRULE or cron-style), scoped to a timezone for daylight-saving and cross-region correctness.
Alt: Recurrence, Cadence
top:Window
Window ¶
A Temporal interval within which an Activity must occur to be considered valid. Defined by an earliest acceptable start, a latest acceptable end, and an optional grace period.
Alt: Time Window, Validity Window
top:Activity
Activity ¶
A Temporal performance leaf, a unit of operational work actually performed at a definite time. The act of doing, distinct from the Schedule that may have triggered it and from the Window in which it must occur. Workflow-specific performances (a clinical Visit, a manufacturing Run) specialize this leaf.
Alt: Procedure, Work Unit
top:Milestone
Milestone ¶
A Temporal marker for a significant time-bound point in a Scope's progression: phase gates, release points, regulatory deadlines, contractual payment points. Carries significance level and dependency links.
Alt: Significant Marker
6 / Evidence top:Evidence
top:Evidence
Evidence ¶
The Core category for verifiable artifacts that prove a fact, a claim, or a state of affairs. Concepts here answer the question of how do we know what we know. They carry integrity through cryptographic hashes, signatures, version control, and audit trails. Distinct from Outcome: Outcomes are produced by work; Evidence proves work happened.
top:Document
Document ¶
An Evidence leaf for formal files and records produced and maintained for operational, regulatory, or evidentiary purposes: policies, procedures, reports, contracts, specifications, manuals, plans, certificates, regulatory submissions, protocols. Authored deliberately, distinct from generated outputs (Artifacts).
Alt: Record, File
top:Log
Log ¶
An Evidence leaf for temporal trails of entries that record what happened, in order, as it happened: audit trails, communication trails, monitoring trails, change trails, event trails. Append-only by design.
Alt: Trail, Audit Log
top:Attestation
Attestation ¶
An Evidence leaf for signed statements verifying a specific fact, claim, or condition. Carries a signature value (cryptographic, biometric, or witnessed) and a verification method. Digital signatures, notarized declarations, regulatory sign-offs, peer reviews, oversight-body decisions.
Alt: Signed Statement, Declaration
top:Credential
Credential ¶
An Evidence leaf for qualifications, licenses, and certifications held by an Agent that prove the right or competence to act in a particular role: professional licenses, training certifications, institutional accreditations, security clearances. Carries expiration and revocation states.
Alt: Qualification, Certification, License
7 / Outcome top:Outcome
top:Outcome
Outcome ¶
The Core category for observable, recordable products of work. Concepts here answer the question of what happened or what came of it. Workflow-specific outcomes (a clinical Adverse Event, a manufacturing Out-of-Specification result) specialize the appropriate leaf rather than introducing new universal result shapes.
top:Observation
Observation ¶
An Outcome leaf for data points captured by an Activity, recorded with the raw signal and a confidence assessment: a measurement read off an instrument, a sensor reading, a survey response, a manually recorded note, a calculated value derived from inputs.
Alt: Measurement, Reading, Data Point
top:StatusChange
Status Change ¶
An Outcome leaf for recorded transitions from a previous status to a new one, with the trigger that caused the transition: a Project advancing from planning to execution, a Document moving from draft to approved, an Equipment going from operational to maintenance.
Alt: State Transition, Lifecycle Event
top:Artifact
Artifact ¶
An Outcome leaf for produced files and records that are the output of an Activity, distinct from a Document in that an Artifact is generated rather than authored: generated datasets, rendered reports, build outputs, compiled binaries, exported records, processed images, model files.
Alt: Output File, Produced Asset
top:Conclusion
Conclusion ¶
An Outcome leaf for reasoned decisions and determinations supported by stated evidence and explainable logic. Records decision logic and supporting evidence: findings from investigations, recommendations from reviews, regulatory determinations, AI-generated determinations that require traceable provenance.
Alt: Decision, Determination
8 / Constraint top:Constraint
top:Constraint
Constraint ¶
The Core category for rules, limits, and bounds that govern what counts as valid operation. Concepts here are the rails along which work runs, the boundary conditions that separate compliant from non-compliant. A member of this category is enforced by some Agent and applies to one or more entities in this taxonomy.
top:PhysicalLimit
Physical Limit ¶
A Constraint leaf for numerical thresholds and tolerance ranges that define what counts as physically acceptable operation: temperature ranges for storage, pressure ceilings for vessels, stress tolerances for materials, capacity bounds, concentration ranges, dose ceilings, bandwidth thresholds.
Alt: Threshold, Operational Range
top:RegulatoryLaw
Regulatory Law ¶
A Constraint leaf for formal laws and rules that govern operations under the authority of a jurisdiction: national statutes, agency regulations, supranational directives, binding industry standards adopted by reference, treaty obligations enforced through domestic law.
Alt: Regulation, Statute
top:SafetyGuardrail
Safety Guardrail ¶
A Constraint leaf for safety rules that prevent harm to people, equipment, or operations, classified by severity and paired with a defined remediation path: operational rails, hazard controls, emergency procedure triggers, sterility constraints, lockout-tagout rules, dose-limiting rules, exposure ceilings.
Alt: Safety Rule, Operational Guardrail
Composition rule · domain KGs extend Core, inherit everything
Workflow extensions for specific domains (clinical research at topcr:, future CMC at topcmc:, future energy at topenergy:) compose on top of the Core layer by specializing a Core concept. A clinical Visit specializes top:Activity. A clinical Study specializes top:Project. A clinical IRB specializes top:Group. A manufacturing Run specializes top:Activity. A supply-chain Shipment specializes top:Activity. The universal layer stays small and reusable; the domain-specific concerns live in the domain's own namespace.
By specializing a Core concept, a domain class inherits the full alignment stack at no additional cost. A clinical Visit, declared as topcr:Visit rdfs:subClassOf top:Activity, automatically gets:
Inherited · The provenance contract
identifier, observedAt, status enforced on every instance
The SHACL invariants on top:Activity apply to every topcr:Visit automatically. No per-domain declaration of the contract; no risk of a domain forgetting to enforce it.
Inherited · PROV-O peer mapping
Every clinical Visit is automatically a prov:Activity
Because top:Activity skos:exactMatch prov:Activity, any PROV-aware reasoner treats a topcr:Visit as a prov:Activity without further declaration. Same for clinical Documents (prov:Entity), clinical IRBs (prov:Agent), clinical Investigators (prov:Person).
Inherited · NGSI-LD wire compatibility
FIWARE / Orion / Stellio interop without per-domain mapping
When core/v1/context.jsonld lands, every domain class extending a Core concept maps to the right NGSI-LD type and emits the standard observedAt / identifier / status attributes automatically. A clinical KG that extends Core is wire-compatible with any NGSI-LD broker on day one.
Inherited · SHACL property requirements
PROV-O property shapes apply down the inheritance chain
Every Activity subtype inherits the requirement to carry prov:used and prov:wasAssociatedWith. Every Evidence subtype inherits prov:wasGeneratedBy and prov:wasAttributedTo. Every Artifact subtype inherits prov:wasGeneratedBy. Domain-specific properties extend the shape rather than redefining the floor.
This is the architectural payoff. A working group convening for cell therapy, for rare disease, for energy and process industries does not have to reinvent provenance, redeclare the Core layer, or rewrite NGSI-LD compatibility. They specialize the Core concepts that fit, declare the domain-specific properties they need, and inherit the constitutional commitments at zero cost.
The membership test that decides what lives at the universal layer stays sharp: do operators across multiple domains and industries (clinical research, care delivery, manufacturing, supply chain, energy, defense, anywhere) recognize this concept as a first-class thing? If yes, it lives here. If it is specific to one domain, it lives in that domain's workflow extension and inherits from the right Core concept.
Worked examples · what extension looks like in practice
Two angles on the inheritance pattern: one universal Core concept specialized many ways across industries, and one industry specializing many Core concepts at once. Both are class-declaration sketches in Turtle; the actual workflow extensions will live in their own files (e.g., clinical-research/v1/shapes.ttl, forming now) and add domain-specific properties beyond what is shown here.
Angle 1 / One Core concept, every industry that needs it
Take top:Activity, the universal performance leaf for any unit of operational work performed at a definite time. Every industry that has things-that-happen-at-a-time specializes it:
# Clinical research topcr:Visit rdfs:subClassOf top:Activity . # Manufacturing topmfg:BatchRun rdfs:subClassOf top:Activity . # Care delivery topcd:Encounter rdfs:subClassOf top:Activity . # Energy and process industries topenergy:Inspection rdfs:subClassOf top:Activity . # Cell and gene therapy topct:HarvestRun rdfs:subClassOf top:Activity .
Five domain classes, one parent. None of those five domains had to declare identifier / observedAt / status. None had to declare PROV-O alignment. None will have to declare NGSI-LD compatibility when context.jsonld lands. None will have to redeclare the prov:used / prov:wasAssociatedWith requirements. All five inherit them through the SubClassOf chain.
Angle 2 / One industry, many Core concepts at once
The clinical research workflow extension declares roughly fifteen domain classes, each anchored to the Core concept that fits. The full clinical research vocabulary then composes by adding domain-specific properties to each subclass (an InvestigatorCredential carries IRB-approval-date and country scope; a Visit carries protocol-section and visit-window; an AdverseEvent carries CTCAE-grade and causality), but the constitutional commitments come down through the inheritance chain at zero cost.
# Agents — who acts in a clinical trial topcr:Sponsor rdfs:subClassOf top:Organization . topcr:CRO rdfs:subClassOf top:Organization . topcr:Investigator rdfs:subClassOf top:Person . topcr:IRB rdfs:subClassOf top:Group . # Scope — the bounded effort itself topcr:Study rdfs:subClassOf top:Project . # Locations and resources used by the trial topcr:Site rdfs:subClassOf top:Physical . topcr:EDCSystem rdfs:subClassOf top:System . topcr:InvestigationalProduct rdfs:subClassOf top:Material . # Time-bound things topcr:Visit rdfs:subClassOf top:Activity . topcr:VisitWindow rdfs:subClassOf top:Window . # Evidence — the trustworthy artifacts topcr:Protocol rdfs:subClassOf top:Document . topcr:eConsent rdfs:subClassOf top:Attestation . topcr:InvestigatorCredential rdfs:subClassOf top:Credential . # Outcomes — what the work produces topcr:AdverseEvent rdfs:subClassOf top:Observation . topcr:EnrollmentStatusChange rdfs:subClassOf top:StatusChange . topcr:CSR rdfs:subClassOf top:Artifact . topcr:RegulatoryDecision rdfs:subClassOf top:Conclusion .
Sixteen domain classes anchored to thirteen distinct Core concepts across six categories. Every one becomes a prov:Agent, prov:Activity, prov:Entity, or prov:Plan automatically. Every one carries identifier / observedAt / status. Every one is NGSI-LD wire-compatible. The clinical research extension is then this skeleton plus the domain-specific properties each subclass adds, not a re-declaration of the floor.
Status
This namespace is at v1.0.0-strawman as of May 2026. The SKOS taxonomy is locked and Termboard-clean (zero circular-definition flags, zero anti-pattern words, zero standalone-acronym flags, every L2 leaf names its L1 parent). The OWL/SHACL companion (core/v1/shapes.ttl) ships with the Universal DNA SHACL contract; the JSON-LD context, the per-leaf CV YAMLs, and the SSSOM crosswalks (per ADR-0018) are queued.