Competency questions are frequently written as anonymous strings even though ontology scope, requirements, formalization, evidence, and review evolve independently. This specification defines a first-class RDF contract that preserves those distinctions and supports traceability, machine-extractable natural-language templates, executable SPARQL evaluation, lifecycle governance, and recursive testing of the ontology's own competency questions.

This is an unofficial 0.1 Editor's Draft maintained by Inferal. Feedback should be sent to contact@inferal.com.

Conformance

The key words MUST, MUST NOT, SHOULD, and MAY are to be interpreted as described in BCP 14 when they appear in all capitals.

A publisher emits RDF using the vocabulary. A data graph conforms when its targeted resources pass the declared SHACL validation regime with the base ontology and its imported MOD and PROV semantics available. A query processor executes a formal query under its declared language and graph assumptions. A validator applies SHACL; it does not execute query source merely because that source is present in RDF.

Vocabulary meaning is open-world RDFS/OWL meaning. Cardinality, required links, cross-resource consistency, and malformed graph rejection are closed-world SHACL concerns. Query results and execution statuses are operational evidence. No inverse triples or inferred types need to be materialized by publishers, but validators MUST make the imported type hierarchy available when applying class constraints.

Introduction and audience

Treating a competency question as a string on an ontology loses its identity when the wording is translated, revised, assigned to a stakeholder, formalized more than once, or evaluated against a new version. Treating the SPARQL text as the question loses the human requirement and incorrectly makes one implementation definitive. Treating a passing SHACL report as the answer confuses graph well-formedness with domain truth.

Ontology authors use this model to state requirements and scope. Reviewers use it to inspect rationale, lifecycle, and coverage. Test runners use it to locate query artifacts, fixtures, and expected results. Catalog and governance tools use stable question IRIs rather than attempting to reconcile changing text.

Scope and non-goals

The ontology owns the identity and traceability contract around competency questions. It models natural-language formulations, requirements, use cases, stakeholders, semantic-artifact targets and versions, expectations, query artifacts, fixtures, executions, machine-observed results, qualified expectation assessments, lifecycle and review states, ordered template elements, and qualified coverage.

It does not provide a general project-management or requirements-management ontology. It does not translate natural language into SPARQL, define a universal scoring metric, or infer that unrecorded coverage is false. It does not claim that a passed query proves the target ontology complete, nor that self-application proves the initial requirements correct or independent.

Competency questions

The ontology's own acceptance corpus asks:

1. Which first-class questions define this ontology, and what formulations express them?
2. Which requirement, use case, and stakeholder motivate each question?
3. Which module and version does each question target?
4. Which expected answer or answer constraint belongs to each question?
5. Which formal query, fixture, execution, result, and status provide evidence?
6. What lifecycle and review states apply?
7. Which CQ kinds classify the questions, and which natural-language templates are available for qualified realization?
8. Which ordered fixed-text and slot occurrences constitute each template?
9. Which declared public terms lack qualified coverage, and which seeded mutations escape detection?
10. Which resources constitute the seed that exists before self-description?
11. Which machine-checkable expectations are satisfied by observed results, and is empty distinct from unknown?
12. Which passing executions used a target version other than the question's current target?
13. Do multiple formal queries for one question agree over the shared semantic fixture?

Identity, traceability, governance, template structure, and the bootstrap boundary are visibly answered by the self-application graph. Coverage, ordered element extraction, satisfaction, evidence currency, and co-formalization are also acceptance criteria for executable queries, SHACL constraints, and mutation tests.

Namespace and dependencies

MOD's mod:competencyQuestion is a datatype property whose value is a string. It MAY provide a lossy catalog summary, but cqo:hasCompetencyQuestion is intentionally not its subproperty or equivalent because it relates a resource.

Landscape, reuse, and non-reuse

C-ODO established that a competency question can be a use-case pattern and a motivating query usable as a unit test. Its legacy upper-ontology commitments and dependency closure are much stronger than this module's portable contract, so it is cited but not imported or aligned. [[CODO]]

CORAL makes an ontological requirement a resource, while its CQ and answer remain literals and every requirement is committed to a lexico-syntactic pattern. This module preserves the useful distinctions but rejects import and subclass alignment because not every valid CQ has that mandatory pattern commitment. [[CORAL]]

The QuO model used by ROCQS defines five CQ kinds by their function and distinguishing constituents. This module preserves those definitions as locally governed values with source provenance, not as imported classes, because ROCQS is a CC0 research corpus rather than a stable RDF vocabulary. QuO explicitly leaves room for further kinds, so the local range remains extensible. [[ROCQS]]

CLaRO motivates separate question, formulation, and template resources. Its XML serialization distinguishes ordered text, entity, and predicate chunks rather than leaving a template only as presentation text. This module adopts that occurrence-and-order insight while using locally governed RDF terms; it does not import or equate the XML element names, which have no stable RDF vocabulary IRIs. [[CLARO]] [[CLARO-REPOSITORY]] A template still does not entail one query. The CQ/SPARQL-OWL dataset demonstrates many-to-many and missing mappings between linguistic patterns and formal query signatures. These sources therefore support an explicit, non-functional CQ-to-query relation. [[CQSPARQLOWL]]

Version 0.1.0 makes no external OWL equivalence or subclass alignment. Similar labels across these sources do not establish identical identity, lifecycle, or entailments.

Conceptual model

The model follows a question from authoring intent to operational evidence without collapsing the resources that change at different times. A question can retain its identity while its wording is translated, its target advances to a new version, a second query is added, or a new execution supersedes earlier evidence. The following table is a boundary guide; the normative patterns are explained in the sections that follow.

flowchart LR
    R["Ontology
requirement"] -->|"addressed by"| CQ["Competency
question"]
    U["Use case"] -->|"supported by"| CQ
    S["Stakeholder"] -->|"has interest in"| CQ
    CQ -->|"has formulation"| F["Question
formulation"]
    CQ -->|"has instantiation"| I["Template
instantiation"]
    I -->|"uses"| T["Question
template"]
    I -->|"realizes"| F
    T -->|"has ordered element"| E["Text segment
or slot"]
    CQ -->|"has expectation"| A["Expected answer
or constraint"]
    CQ -->|"has formal query"| Q["Executable
formal query"]
    Q -->|"uses fixture"| X["Test fixture"]
    Q -->|"run by"| RUN["Query execution"]
    RUN -->|"generates"| RESULT["Execution result"]
    RESULT -->|"compared with expectation"| ASSESS["Expectation
assessment"]

flowchart LR
    T["QuestionTemplate"] -->|"has element"| E0["0 · Text segment"]
    T -->|"has element"| E1["1 · Slot occurrence"]
    T -->|"has parameter"| P["TemplateParameter"]
    E1 -->|"uses parameter"| P
    I["TemplateInstantiation"] -->|"uses template"| T
    I -->|"has binding"| B["TemplateBinding"]
    B -->|"binds parameter"| P
    B -->|"binding text"| V["Rendered phrase"]
    I -->|"realizes"| F["QuestionFormulation"]
    I -.->|"does not bind"| Q["FormalQuery"]

Self-application and recursive acceptance

This ontology's fourteen competency questions are instances of cqo:CompetencyQuestion. They target this ontology and its 0.1.0 version, link to requirements, use cases, stakeholders, formulations, answers, kinds, purposes, and, where an exact realization is claimed, qualified template instantiations. Two boundary-setting questions are Scoping CQs; the twelve answerable checks on module content are Validation CQs. None is mislabeled Foundational merely because it concerns bootstrapping, or Relationship merely because it retrieves RDF links. One question specifically asks for the ordered elements of the ontology's own templates and is answered by an independent extraction query. A second asks whether qualified parameter bindings reconstruct linked formulations and is answered by an ordered-fragment realization query. The primary row-producing query evaluates the recursive contract; the co-formalization question also has a boolean query over the same semantic fixture.

The reference query returns a row for any missing recursive link, inconsistent target version, incomplete query artifact, stale passed evidence, missing machine observation or expectation assessment, malformed template structure, non-regression corpus member, incorrect self-corpus kind assignment, or public class or property without a covered assertion. A passing result is zero rows. Its qualified assessment compares that observed cardinality with the declared zero-row constraint. Implementations claiming this recursive capability MUST execute the query; copying a hand-authored passing result is insufficient.

The alternate boolean formalization returns true for the complete graph. Removing a public-term coverage assertion makes the row-producing query return a diagnostic and the boolean query return false. Agreement is therefore demonstrated by execution on both the valid graph and a checked mutation, rather than inferred merely because both artifacts are linked to one question.

Bootstrap boundary

Self-description begins from a seed: RDF/Turtle syntax, stable vocabulary IRIs, initial class and property declarations, question instances, and executable query text must exist before those resources can be described with this vocabulary. Once asserted, the ontology can describe the seed and the query can evaluate the combined graph.

This is not a logical proof of the vocabulary by the vocabulary. The questions do not entail their own class declarations, and the passing query does not prove that the initial requirements are exhaustive. It proves only that the declared recursive contract is internally present and operationally exercised.

Examples

Validation and entailment

The complete-question shape targets explicit cqo:CompetencyQuestion instances. It requires contextual traceability, controlled states, and answer expectations. The target version consistency constraint checks dcterms:isVersionOf. Query and execution shapes require artifact identity, query language, fixtures, completion time, a used semantic-artifact version, result generation, and agreement between an execution's query and each evaluated question. Completed-result constraints require a machine observation; not-run and error states prohibit one. Expectation assessments bind one result to one expectation and check the local result-cardinality convention when selected.

Template validation requires one rendering and at least one element, exactly one owning template and index per element, exactly one element kind, unique contiguous indices, and parameters owned and used by the same template. Parameter names are unique within a template. Instantiation validation requires one owning question, one template, one formulation belonging to that question, and exactly one binding for every declared parameter. Binding validation distinguishes a resource value from a literal value and requires one language-tagged surface phrase. These checks validate supplied structure; SHACL does not parse cqo:templateText, concatenate fragments, or generate elements, bindings, or formulations.

SHACL conformance establishes structural consistency under the declared data and ontology graphs. It cannot establish that a natural-language answer is correct, that a stakeholder truly approved a question, or that the question set is exhaustive. [[SHACL]]

RDFS domains and ranges infer types; they are not validation filters. The OWL addendum types classes, object properties, datatype properties, and controlled individuals. It deliberately adds no functional properties, equivalences, keys, disjointness, or cardinality axioms.

Operational behavior

A processor evaluates a question only when it can load the query text under the declared query language and the named fixtures or target graph. It MUST report an error rather than fabricate a passed result when the query cannot be prepared, required input is unavailable, or graph assumptions are contradictory.

The recursive reference behavior uses SPARQL 1.1 [[SPARQL11]] and returns diagnostic rows. Missing evidence fails closed by producing a row; a processor never infers a pass from the absence of an execution record. A completed tabular execution records its observed row count; a boolean execution records its observed boolean. A processor evaluating a result-cardinality constraint compares the integer expression with the observed count and emits a qualified assessment.

The template-element reference query returns one row for each ordered occurrence, including its owning template, element IRI, index, element class, fixed text or parameter identity, name, and optional role. It orders rows by template and index and never inspects cqo:templateText. Returning those rows is data extraction, not SHACL validation or ontology entailment.

The template-realization reference query returns one ordered fragment per element of each qualified instantiation. For a text segment the fragment is cqo:segmentText; for a slot it is the cqo:bindingText attached to that slot's parameter. A processor concatenates the fragments in numeric index order and MUST compare the result with the linked formulation text when claiming exact realization. This is an explicit natural-language transformation, not an OWL entailment, SHACL rule, or formal-query variable binding.

The reference corpus supplies row-producing and boolean co-formalizations. Both are executed over the same semantic graph and MUST agree on the declared pass and on the seeded coverage failure. Repeated evaluation over an unchanged RDF dataset is deterministic because neither query generates identifiers nor depends on solution ordering.

Security and privacy

Questions, fixtures, expected answers, stakeholder links, and query results can reveal product strategy, unpublished ontology scope, personal identities, sensitive test data, or attack-oriented queries. Publishers SHOULD apply access controls appropriate to each resource and MUST NOT infer that a public ontology requires every connected fixture or stakeholder record to be public.

Processors MUST treat query text and fixture locations as untrusted input. This vocabulary does not authorize network access, mutation, entailment regimes, or processor extensions.

Evolution and governance

Public term IRIs are stable. Meanings that must change incompatibly will be represented with new terms and migration guidance rather than silent redefinition. Question IRIs SHOULD remain stable across wording changes; replaced questions SHOULD be deprecated while their prior formulations, executions, and coverage evidence remain traceable.

Design, evaluation, and regression purposes are independent. A question reused from construction during regression proves adherence to an accepted requirement, not held-out generalization. Claims of domain coverage SHOULD use independently elicited evaluation questions and disclose their provenance.

Term reference