The Inferal Evidence Ontology provides a small, domain-neutral model for recording how claims are supported and challenged. It treats evidence, premise, conclusion, and warrant as roles within an explicit argument; distinguishes rebuttal, undercutting, and undermining; and reuses PROV-O for generation, use, attribution, and agent responsibility. The model is suitable for human and software-agent findings without asserting that an argument proves its conclusion or defining a second confidence vocabulary.

This is an unofficial 0.1 Editor's Draft maintained in the Inferal ontology repository.

Feedback should be sent to contact@inferal.com.

This specification defines three conformance classes: evidence data graph, evidence publisher, and evidence processor.

An evidence data graph is an RDF graph that uses the public terms consistently with their definitions. A graph claiming structural conformance MUST satisfy the Evidence Ontology SHACL shapes with RDFS inference over this ontology and PROV-O enabled.

A validator evaluates the submitted data graph together with the Evidence Ontology, PROV-O, and the Evidence Ontology SHACL shapes. A publisher does not need to materialize every type entailed by an RDFS domain, range, or subclass axiom before submission, provided the validation regime computes the corresponding RDFS closure. Loading the optional OWL addendum does not add further data constraints.

An evidence publisher is a person or system that emits evidence data. It MUST preserve distinct identities for a claim, an argument, an evidentiary artifact, and the activity that generated them whenever more than one of those things is represented.

An evidence processor consumes or traverses evidence data. It MUST NOT infer truth, acceptance, evidential sufficiency, validity, or confidence solely from a claim's participation in an argument. A processor MAY expose support traces, challenge targets, and missing local coverage. Any operation that weighs evidence, resolves defeat, or computes acceptance requires a separately identified policy or argumentation calculus.

Introduction

Systems increasingly publish findings that need an inspectable answer to a simple question: “why should this claim be considered?” A language model inspecting an external API, for example, may assert that a route exists and that its response has a particular schema. The assertion, the documentation fragment, the HTTP trace, the reasoning that connects them, and the software activity that produced the result are different resources. Collapsing them into one annotation makes the result hard to audit and impossible to challenge precisely.

This ontology supplies the missing justificatory layer. PROV-O explains where information came from and who or what produced it [[PROV-O]]. The Evidence Ontology explains which entities a publisher offers as evidence for which conclusion, through which stated premises and reasoning basis. Confidence and exact RDF-statement targeting compose at the edges rather than being redefined here.

Three common shortcuts lose information. A direct source supports claim edge cannot state the premise or warrant and gives the support relation no identity of its own. Treating every prov:used input as evidence confuses operational dependency with justification. Typing an artifact as Evidence makes a contextual role appear universally true. The core avoids all three by making the argument an addressable resource and assigning roles from that argument.

Audience

The specification is intended for ontology authors, knowledge-graph publishers, extraction-system designers, audit-tool implementers, and reviewers of human or machine-generated findings.

Design goals

Scope and non-goals

The ontology owns the evidentiary structure connecting arguments, conclusions, premises, evidentiary artifacts, reasoning bases, and explicit challenge targets. It is domain-neutral and does not privilege publications, experiments, biomedical evidence, or any particular reasoning formalism.

Its unit of description is an offered argument: a provenance-bearing information entity that records a conclusion and the inputs presented for it. The core does not attempt to describe every property of the source artifact, every sentence in a claim, or the runtime process that evaluates the argument. Domain vocabularies remain responsible for those details.

The ontology deliberately does not:

Competency questions

  1. Which support arguments conclude a given claim?
  2. Which premises, evidentiary artifacts, and reasoning bases does each argument use?
  3. Which activity generated an argument or claim, and which agent was responsible?
  4. Which arguments challenge a claim, another argument, or an evidentiary input?
  5. Is a challenge a direct rebuttal, an undercutter, or an underminer?
  6. Which supported claims are reused as premises in later arguments?
  7. Which claims lack an asserted support argument in the available graph?
  8. How can confidence or an exact RDF-statement target be attached without extending the evidence core?

The examples and query recipes answer these questions using asserted facts. Queries about missing support are dataset-coverage checks, not closed-world conclusions about what arguments exist elsewhere.

Namespaces and dependencies

PrefixIRIRole
ev https://ontology.inferal.com/modules/evidence/ Claims, arguments, contextual roles, and challenge relations.
prov http://www.w3.org/ns/prov# Entity, activity, agent, use, generation, derivation, attribution, and association.
conf https://ontology.inferal.com/modules/confidence/ Optional independent confidence assessments.
ss https://ontology.inferal.com/modules/scoped-statements/ Optional exact RDF quad targets and applicability scope.

The ontology imports PROV-O because claims, arguments, reasoning bases, and evidentiary artifacts are provenance-bearing entities. Confidence and Scoped Statements are optional compositions and are therefore not imported by the core.

Conceptual model

An ev:Argument is an information entity that assigns contextual roles. Its inputs are ev:Claim resources used as premises and PROV entities offered as evidence. An optional ev:ReasoningBasis serves as the warrant connecting those inputs to exactly one conclusion under the SHACL conformance regime. The model distinguishes a support argument, which offers that structure for its conclusion, from a defeating argument, which presents its own conclusion and identifies what it challenges. Neither kind implies that the argument succeeds.

The model separates three layers that are often collapsed in evidence systems:

Layer Question answered Representative terms Does not establish
Claim content What proposition is being considered? ev:Claim, optionally composed with a domain or statement-target vocabulary Truth, acceptance, or support
Justificatory structure What is offered for or against the proposition, and through what reasoning? ev:Argument and its role and challenge properties Soundness, relevance, sufficiency, or defeat resolution
Production provenance Who or what created the resources, when, and from which operational inputs? prov:Entity, prov:Activity, prov:Agent, use and generation That a used input was offered as evidence 
flowchart LR
    subgraph Inputs["Inputs to an argument"]
      E["Evidence artifact
prov:Entity"]
      P["Premise
ev:Claim"]
      W["Reasoning basis
ev:ReasoningBasis"]
    end
    A["Support argument
ev:SupportArgument"]
    C["Conclusion
ev:Claim"]
    D["Defeating argument
ev:DefeatingArgument"]

    A -->|"hasEvidence"| E
    A -->|"hasPremise"| P
    A -->|"hasWarrant"| W
    A -->|"hasConclusion"| C

    D -.->|"rebuts"| C
    D -.->|"undercuts"| A
    D -.->|"undermines"| E

    classDef support fill:#e8f4ff,stroke:#3977a8,color:#16344d;
    classDef challenge fill:#fff0ed,stroke:#b6533c,color:#51251c;
    classDef role fill:#f7f5ef,stroke:#706a5d,color:#302d28;
    class A support;
    class D challenge;
    class E,P,W,C role;
The core evidentiary structure. Solid arrows assign roles in a support argument; dashed arrows show three distinct attack targets. Every arrow follows the RDF subject-to-object direction of the property.

Role and identity

Evidence, premise, conclusion, and warrant are contextual roles, not universal classifications. The same claim can be the conclusion of one argument and a premise of another. The same document can be offered as evidence in one argument and merely used by a generation activity in another. The ontology therefore defines ev:hasEvidence, ev:hasPremise, ev:hasConclusion, and ev:hasWarrant rather than intrinsic Evidence, Premise, Conclusion, or Warrant classes.

ResourceIntrinsic typeContextual role
Documentation fragment or traceprov:EntityEvidence when linked by ev:hasEvidence.
Propositionev:ClaimPremise or conclusion according to the linking property.
Rule, method, or principleev:ReasoningBasisWarrant when linked by ev:hasWarrant.
Argument traceev:ArgumentSupported or attacked according to its class and incoming challenge.

Role assignment is local to one argument. Reusing the same artifact in two arguments does not make the arguments identical and does not require the artifact to play the same role in both. Likewise, two claims with the same label are not thereby the same proposition. Publishers SHOULD use stable IRIs for claims, arguments, reasoning bases, and evidence artifacts that need to be cited, revised, or challenged across graphs.

A materially different proposition SHOULD receive a distinct claim identity. A materially different combination of conclusion, inputs, or reasoning basis SHOULD receive a distinct argument identity. Revision and derivation relationships between such resources belong in PROV-O. Blank nodes remain structurally legal, but make cross-publication reference and later challenge difficult.

Toulmin correspondence

Toulmin's layout distinguishes a claim, data or grounds, a warrant licensing the step, backing for the warrant, a qualifier, and possible rebuttal conditions [[TOULMIN]]. The Evidence Ontology preserves the useful separation without treating each role as an intrinsic class.

Toulmin element Evidence Ontology pattern Modeling note
Claim ev:hasConclusion → ev:Claim The conclusion role belongs to the relation; the claim may be a premise elsewhere.
Data or grounds ev:hasPremise and/or ev:hasEvidence Propositional grounds remain distinct from documents, traces, observations, and other artifacts.
Warrant ev:hasWarrant → ev:ReasoningBasis The reusable basis may be a rule, method, principle, inference scheme, or assumption.
Backing A separate support argument concluding the warrant when that reasoning basis is also modeled as a claim Recursive support avoids a second, fixed backing relation.
Qualifier An independent confidence assessment, applicability scope, or domain-specific qualification No generic numeric or modal force is built into the evidence core.
Rebuttal ev:DefeatingArgument with an explicit challenge target Direct rebuttal, undercutting, and undermining are distinguished rather than merged.

This is a design correspondence, not an OWL equivalence to a complete Toulmin formalization. In particular, the core does not compute whether a qualifier applies or whether a rebuttal defeats the original argument.

Argument structure

A structurally conforming argument MUST have exactly one ev:hasConclusion value and MUST have at least one ev:hasPremise or ev:hasEvidence value. It MAY have multiple premises, evidentiary artifacts, and reasoning bases. These are SHACL requirements on a submitted graph, not OWL assertions that missing information cannot exist.

A warrant is optional because publishers may record incomplete or deliberately implicit reasoning. Applications that require explicit inference rules SHOULD add a stricter profile. A reasoning basis may also be an ev:Claim; another support argument can then conclude it. This recursive pattern supplies Toulmin-style backing without a separate backing primitive.

ev:hasEvidence is intentionally not a subproperty of prov:wasDerivedFrom. Offering an entity as evidence is not the same relation as constructing one entity from another. Publishers SHOULD assert PROV derivation separately when it is also true.

Evidence artifacts and premises

An evidentiary artifact is something a reviewer can identify as an input to the argument: for example, a document fragment, response trace, image, dataset, signed assertion, or observation record. The artifact's domain type and content remain defined by its native vocabulary. Linking it with ev:hasEvidence says only that this argument offers that entity in an evidentiary role.

A premise is itself a proposition. Publishers SHOULD use ev:hasPremise when the argument depends on a stated proposition and ev:hasEvidence when it depends on an inspectable artifact. An argument may use both: the premise records the interpretation extracted from a source, while the evidence edge preserves the source that a reviewer can inspect.

The core deliberately does not say that every evidence artifact supports every premise, nor does it qualify individual input edges with page ranges, extraction spans, or custody metadata. Publishers can represent such details with source-native selectors, Web Annotation, PROV qualified relations, or a future profile without changing the meaning of the core argument.

Worked example: support chains and backing in system discovery

This subsection applies the general support-chain pattern to one illustrative LLM-assisted API-discovery workflow. The ontology does not restrict support chains, backing, or defeating arguments to system discovery or to LLM-generated findings.

The motivating pattern is a staged investigation of how an external system works. A human analyst, an LLM-assisted extractor, or a mixed workflow rarely reaches a useful system model in one step. It may first identify an endpoint, then interpret its response schema, then infer resource relationships or operational constraints. Each later finding can depend on an earlier finding as well as on new source material.

Support chains are formed by reusing a claim as the conclusion of one argument and a premise of another. No special transitive support edge is entailed. A processor tracing the later conclusion MUST retain both argument resources because each step may have different evidence, warrants, provenance, confidence assessments, and challenges.

For an LLM-assisted process, the published chain is an inspectable justification record, not a transcript of private model chain-of-thought. A publisher SHOULD expose the claims, source artifacts, stated premises, and concise reasoning bases needed for review. PROV-O may separately identify the model or software agent, discovery activity, prompt or configuration inputs, and generated resources. A prompt or configuration is not evidence merely because the activity used it.

Example discovery stages in the LLM-assisted API case
Discovery step Conclusion New evidence Premise or warrant What remains uncertain
Discover the callable surface The service exposes GET /v1/customers/{id}. API reference fragment and an authenticated successful probe The reference names the route; agreement between documentation and observation warrants a provisional availability claim. Availability in other versions, tenants, credentials, or runtime states
Interpret the response structure A successful response represents one Customer resource. OpenAPI response schema The route-existence claim becomes a premise; object shape and identifier semantics provide the warrant. Whether production payloads always conform and whether the representation is complete
Review the scope of the finding The availability claim may not generalize across tenants. An authenticated 404 trace from a second tenant The second-tenant failure is a premise in a defeating argument that undercuts the earlier inference. Whether the difference is caused by tenancy, authorization, deployment version, or transient failure 
flowchart LR
    RUN["LLM-assisted system discovery
prov:Activity"]
    E1["Route documentation and probe"]
    A1["Route argument"]
    C1["Route exists
claim"]
    E2["OpenAPI schema"]
    A2["Schema argument"]
    C2["Response represents one Customer
claim"]
    D1["Scope challenge"]

    RUN -->|"generated"| A1
    RUN -->|"generated"| A2
    A1 -->|"hasEvidence"| E1
    A1 -->|"hasConclusion"| C1
    A2 -->|"hasPremise"| C1
    A2 -->|"hasEvidence"| E2
    A2 -->|"hasConclusion"| C2
    D1 -.->|"undercuts"| A1

    classDef argument fill:#e8f4ff,stroke:#3977a8,color:#16344d;
    classDef claim fill:#f7f5ef,stroke:#706a5d,color:#302d28;
    classDef challenge fill:#fff0ed,stroke:#b6533c,color:#51251c;
    classDef prov fill:#eef1f5,stroke:#5d6a79,color:#28313a;
    class A1,A2 argument;
    class C1,C2 claim;
    class D1 challenge;
    class RUN prov;
Example figure — LLM-assisted system discovery. One discovery activity may generate several independently inspectable argument steps. The first conclusion becomes a premise in the second step. A challenge to the first argument remains explicit and does not automatically become a challenge to the later conclusion.

Backing becomes useful when a discovery step relies on a contestable interpretation rule. For example, “an object schema with a stable identifier represents one resource” may be treated as both an ev:ReasoningBasis and an ev:Claim. A separate support argument can conclude that rule using an API standard, service convention, or evaluated extraction method as evidence. The schema argument then selects the same resource with ev:hasWarrant.

This recursive backing is optional. A publisher can record the reasoning basis without claiming to have established it. When backing is present, it remains a separate argument so reviewers can challenge the interpretation rule without conflating that challenge with the endpoint observation or schema artifact. Multi-typing one resource as a reasoning basis and claim is intentional; it does not make every reasoning basis a claim.

Challenges and defeat

A structurally conforming ev:DefeatingArgument MUST identify at least one challenged entity. The generic ev:challenges property is available when the attack kind is unknown or outside this core. More precise publishers SHOULD use:

Question raised by the challenge Target Property API-discovery example
Is the conclusion itself wrong or unacceptable? Claim ev:rebuts A counterclaim states that the route does not exist.
Even if the inputs are accepted, does this reasoning license that conclusion? Argument ev:undercuts A tenant-specific observation shows the warrant cannot justify a service-wide conclusion.
Is one premise or artifact credible, authentic, relevant, or applicable? Premise or evidence entity ev:undermines The probe trace is shown to come from a mock rather than the external service.
Is there an attack whose kind is not known or not represented by this core? Any provenance-bearing entity ev:challenges A reviewer records an objection for later classification.

A defeating argument MUST NOT challenge itself under the SHACL conformance regime. Challenge properties are neither transitive nor symmetric. A processor MUST NOT propagate defeat through a support graph unless an external, explicitly declared argumentation calculus authorizes that operation.

ev:SupportArgument and ev:DefeatingArgument are not disjoint. One argument may support its own conclusion while using that conclusion to attack a different claim or argument. Publishers SHOULD use both types only when both roles are intentional and explicit.

Challenge types may coexist. A counterargument can undercut an argument and undermine one of its inputs when both statements are warranted. The subproperty hierarchy also entails a generic ev:challenges relation for each precise challenge. That entailment aids broad discovery; it does not erase the asserted attack kind or compute an outcome.

Provenance and composition

PROV-O and this ontology answer different questions. A generation activity MAY use documentation, traces, prompts, or configurations with prov:used, generate claims and arguments with prov:generated or prov:wasGeneratedBy, and be associated with a software or human agent. Those facts explain production lineage. They do not make every used input evidence and do not establish the conclusion.

Statement Meaning Not interchangeable with
activity prov:used artifact The artifact participated as an input to an activity. argument ev:hasEvidence artifact
argument prov:wasGeneratedBy activity The activity produced the argument record. argument ev:hasConclusion claim
argument prov:wasAttributedTo agent Responsibility or attribution for the argument is assigned to an agent. Acceptance of the argument by that agent
argument ev:hasEvidence artifact The artifact is offered in this argument's justificatory structure. Derivation, custody, authenticity, or sufficient support 
flowchart TB
    subgraph Production["PROV production trace"]
      AG["LLM or reviewer
prov:Agent"]
      ACT["Discovery or review run
prov:Activity"]
      ART["Documents and traces
prov:Entity"]
      ACT -->|"wasAssociatedWith"| AG
      ACT -->|"used"| ART
    end

    subgraph Evidence["Evidence structure"]
      ARG["Argument
ev:Argument"]
      CL["Claim
ev:Claim"]
      ARG -->|"hasConclusion"| CL
      ARG -->|"hasEvidence"| ART
    end

    ACT -->|"generated"| ARG
    ACT -->|"generated"| CL

    subgraph Optional["Optional edge modules"]
      CA["Confidence assessment
conf:ConfidenceAssessment"]
      ST["Exact scoped statement
ss:ScopedClaim"]
    end

    CA -->|"assessmentTarget"| ARG
    CL -.->|"may also be typed as"| ST

    classDef prov fill:#eef1f5,stroke:#5d6a79,color:#28313a;
    classDef ev fill:#e8f4ff,stroke:#3977a8,color:#16344d;
    classDef optional fill:#f3edff,stroke:#7056a3,color:#302046;
    class AG,ACT,ART prov;
    class ARG,CL ev;
    class CA,ST optional;
Composition boundary for a machine-generated finding. PROV describes production, ev: describes justification, conf: assesses a resource, and ss: can give a claim exact RDF content and scope. No module is duplicated.

A machine-generated finding will commonly have at least four independently addressable resources: the extraction activity, the software agent, the claim, and the argument. Keeping them distinct lets a reviewer challenge the inference without denying that the activity occurred, or replace an argument without changing the identity of the proposition under review.

Reuse decisions

AMO is the closest conceptual predecessor because it implements Toulmin's claim, evidence, warrant, backing, qualifier, and rebuttal layout [[AMO]]. It is referenced rather than imported. AMO models these roles as classes tied to an argument by OWL equivalences and cardinalities, defines a strong proves relation, imports CiTO, and represents qualifiers inside the argument ontology. This module instead keeps roles contextual, places cardinality in SHACL, omits proof entailment, and delegates confidence. It also omits a generic qualifier primitive: probabilistic or ordinal force belongs in Confidence, applicability scope can use Scoped Statements, and exceptions can be represented by explicit defeating arguments.

Concern AMO-oriented approach Evidence Ontology decision
Argument components Claim, evidence, warrant, backing, qualifier, and rebuttal are modeled within a Toulmin-oriented argument layout. Only stable resource kinds become classes; premise, conclusion, evidence, and warrant remain contextual relations.
Logical strength OWL equivalences and cardinality restrictions participate in the model. RDFS states reusable meaning; closed-world cardinality belongs to SHACL.
Support force A strong proves-style relation is available. Support is an offered argument and never entails proof, truth, or acceptance.
Evidence identity Evidence is represented as an argument component class. Any prov:Entity may play the evidence role in a particular argument.
Counterargument Rebuttal follows the Toulmin component structure. A defeating argument has its own support and explicitly rebuts, undercuts, or undermines a target.
Confidence and qualification Qualifier is part of the argument model. Confidence and applicability scope remain independently assessable resources.

EVI is referenced rather than imported because it is explicitly designed to describe correctness evidence for findings in biomedical publications and includes deeper evidence-graph and challenge propagation commitments [[EVI]]. The generic core here can be used beneath a future EVI alignment without adopting those scientific and operational assumptions.

AIF is not imported because its purpose is an interlingua for computational argumentation languages and tools, including inference schemes, conflict, preferences, and dialogue-oriented structures [[AIF]]. Those capabilities are useful above this module but exceed the evidence-support boundary.

No OWL equivalence to AMO, EVI, or AIF is asserted. Any future mapping requires a term-by-term review of direction, role identity, challenge semantics, and truth commitments.

Extension and interoperability patterns

Extensions SHOULD preserve the core distinction between resource type and argument role. A scientific profile may classify an evidence artifact as an experiment report, a legal profile as testimony, and an API profile as a response trace; each remains linked to the argument with ev:hasEvidence. Profiles SHOULD NOT make those domain classes subclasses of a universal evidence class.

Claim-content vocabularies may multi-type an ev:Claim or link it to a statement, text span, proposition, or domain assertion. The representation SHOULD preserve a stable claim identity so that arguments, confidence assessments, and challenges can refer to the same proposition. The Evidence Ontology does not infer that the represented statement is asserted in the containing RDF graph.

Argumentation systems may add schemes, preferences, dialogue moves, burden-of-proof policies, or defeat calculi above this core. Such an extension MUST identify its evaluation regime and MUST NOT present a computed acceptance status as an entailment of the Evidence Ontology. Alignments to AMO, EVI, or AIF SHOULD use the weakest relation justified by a term-by-term semantic comparison.

Term reference

All public classes are subclasses of prov:Entity, directly or through ev:Argument. All public properties are object properties in the optional OWL addendum. The domains and ranges below are entailment rules: using a property can infer types for its subject and object. They are not merely form-field hints.

Classes

TermSuperclassNormative definition
ev:Claim prov:Entity A proposition presented for consideration or acceptance; its type does not assert truth, acceptance, or support.
ev:Argument prov:Entity An information entity presenting one conclusion together with premises, evidentiary artifacts, and optional reasoning bases.
ev:SupportArgument ev:Argument An argument offered in support of its conclusion without entailing that the support succeeds.
ev:DefeatingArgument ev:Argument An argument offered against an explicitly identified claim, argument, or evidentiary input.
ev:ReasoningBasis prov:Entity A reusable rule, method, principle, inference scheme, or assumption that may serve as a warrant.

Properties

TermDomain → rangeNormative role
ev:hasEvidence Argument → prov:Entity An entity offered as evidence in the argument, without a truth, relevance, sufficiency, or derivation entailment.
ev:hasPremise Argument → Claim A claim used as a premise without asserting its truth or independent support.
ev:hasConclusion Argument → Claim The claim concluded by the argument without entailment.
ev:hasWarrant Argument → ReasoningBasis The reasoning basis serving as warrant from inputs to conclusion.
ev:challenges DefeatingArgument → prov:Entity A generic challenge whose more precise attack kind is not stated.
ev:rebuts DefeatingArgument → Claim Direct opposition to the content or acceptability of a claim.
ev:undercuts DefeatingArgument → Argument A challenge to another argument's inferential connection or warrant applicability.
ev:undermines DefeatingArgument → prov:Entity A challenge to a premise or evidentiary artifact's credibility, authenticity, relevance, interpretation, or applicability.

Validation and entailment

The portable ontology uses RDFS subclass, domain, range, and subproperty semantics. The optional OWL addendum types the public terms as OWL classes and object properties. It defines no equivalence classes, disjoint classes, functional or transitive properties, property chains, cardinalities, or truth-producing axioms.

Semantic surface Responsibility Representative effect
Portable RDFS vocabulary Shared meaning and safe type/subproperty entailments Using ev:hasPremise entails an argument subject and claim object.
Optional OWL addendum Explicit OWL class and object-property typing Supports OWL-aware tooling without adding cardinality or truth conditions.
SHACL conformance regime Closed-world structural checks on a submitted graph Rejects an argument with zero or multiple conclusions.
Queries or application policy Traversal, coverage review, weighing, and evaluation Can list untraced claims but cannot turn local absence into universal negation.

SHACL defines the structural publication contract: one conclusion per argument, at least one premise or evidence entity, correct role-target types, at least one target per defeating argument, and no self-attack. Conformance establishes graph structure only. It does not establish that a premise is true, evidence is authentic, a warrant is applicable, a challenge succeeds, or a conclusion is justified.

Focus nodes Structural requirement Reason
Claims and reasoning bases Must be IRIs or blank nodes. They require identity as RDF resources and cannot be literal role targets.
All arguments Exactly one claim conclusion; at least one premise or evidence entity; typed resource-valued role targets. Provides a minimally inspectable support step without requiring a warrant.
Defeating arguments At least one challenge target; typed precise targets; no self-challenge. Makes the object of disagreement explicit and blocks a structurally degenerate attack.

RDF and OWL retain open-world semantics. A query that finds no support in one graph reports missing asserted coverage in that graph. It MUST NOT be interpreted as a universal claim that no support exists.

Under RDFS entailment, each precise challenge property is also an ev:challenges relation, and domains and ranges can supply missing class types. The ontology does not entail the inverse of any property, does not propagate support or challenge, does not infer that two resources with similar content are identical, and does not select a winning argument. These non-entailments follow the open-world RDF model [[RDF11-MT]]; SHACL validation [[SHACL]] does not change them.

Examples

Read the graph from the argument outward. The route argument concludes the route claim, uses a proposition extracted from the documentation as a premise, offers both the documentation and probe as inspectable evidence, and states the bridge from those inputs to its conclusion. Reading the PROV edges instead answers a different question: the run used two artifacts, was associated with the software agent, and generated the claim and argument records. Neither view replaces the other.

The chain does not collapse into a direct support edge from the first argument's evidence to ex:customerSchemaClaim. A consumer traverses the two argument steps and can encounter a different warrant, confidence assessment, or challenge at each step.

This graph records two explicit objections without retracting any earlier triple. The undercutting edge questions whether the original inputs license its conclusion; the undermining edge questions the probe as an input. Whether either objection changes an application's accepted view is deliberately left to an external evaluation policy.

Query recipes

These informative SPARQL recipes operate on asserted facts. They do not validate the graph, infer argument success, rank competing arguments, propagate challenges, or turn missing triples into negation.

Recipe Competency questions Result interpretation
Support trace 1–2 One row per matching combination of asserted argument roles and optional provenance values.
Finding provenance 3 Claim and argument generation, activity association, and direct attribution without conflating those relations.
Challenge trace 4–5 One row per explicit challenge property and target; precise kinds are not merged.
Support chain 6 Pairs of distinct support arguments joined by a claim that is an upstream conclusion and downstream premise.
Coverage review 7 Claims lacking an asserted support conclusion in the queried dataset.
Composition examples 8 Independent confidence and statement-target resources linked to core resources.

Trace support and provenance

This recipe starts from each support argument and returns its conclusion, inputs, warrant, generating activity, and the agent associated with that activity where asserted. Multiple premises, evidence artifacts, warrants, activities, or agents can multiply rows; consumers that need one record per argument SHOULD aggregate explicitly rather than assuming functional properties that the vocabulary does not define.

Trace claim and argument provenance

This recipe starts from claims and arguments participating in stated support and reports generation activity, the agent associated with that activity, and direct resource attribution. It accepts either orientation of the PROV generation relation. Activity association and direct attribution remain separate because they need not identify the same agent.

Find supported claims reused as premises

This recipe identifies an asserted two-step support chain. The intermediate claim must be the conclusion of one support argument and a premise of a distinct downstream support argument. A premise with no asserted upstream support is not returned, and the query does not infer transitive support for the downstream conclusion.

Trace challenge kinds and targets

This recipe reports each explicitly selected challenge property. It does not derive one challenge kind from another or propagate an attack to downstream conclusions. A defeating argument with two attack properties intentionally appears in two rows.

Find claims without asserted support

This recipe finds claims for which the queried graph contains no support argument conclusion. It is a review-queue query, not proof that the claim is unsupported in every graph. Entailed subclasses and types are visible only if the query dataset or processor supplies the corresponding inference regime.

Security and privacy considerations

Evidence traces can expose confidential source material, prompts, credentials, request and response bodies, personal data, internal reasoning, vulnerabilities, reviewer identities, and disputed allegations. Publishers SHOULD minimize sensitive content, use access-controlled evidence artifacts when necessary, and retain stable metadata stubs so redacted derivation or evidence targets remain inspectable as resources.

Evidence supplied by an untrusted publisher may be forged, malicious, selectively quoted, or designed to manipulate a reviewer or software agent. Processors MUST treat RDF labels, descriptions, documents, and retrieved evidence as data, not executable instructions. Validation of graph structure is not verification of authenticity or safety.

Dereferencing an evidence IRI can cross trust boundaries. Processors SHOULD apply ordinary network isolation, content-size limits, media type checks, authentication policy, and sandboxing before retrieval or rendering. A publisher SHOULD distinguish a stable metadata record from a protected or mutable payload so that access control does not require erasing the support trace.

Challenge graphs can also amplify sensitive allegations. The existence of an ev:rebuts, ev:undercuts, or ev:undermines edge records that an argument was offered; it is not an endorsement by the graph host. Applications presenting such data SHOULD expose attribution and provenance alongside the challenge.

Evolution and governance

Public IRIs in the Evidence Ontology are stable. Future releases will deprecate and map adopted terms rather than silently move or redefine them. Scientific evidence types, argument calculi, confidence semantics, exact statement syntax, AMO/EVI/AIF alignments, and stricter completeness profiles remain separate extension or mapping concerns and require their own semantic review.

New domain evidence categories SHOULD normally be introduced in profiles or domain modules. A new core term requires a competency question that cannot be answered by composing an existing entity type, argument role, PROV relation, or independent assessment vocabulary. New challenge properties require a stable distinction in attack target or meaning and a documented relationship to ev:challenges.

Changes that strengthen domains, ranges, subclass relations, or OWL characteristics can create new entailments for existing data and therefore require compatibility review. Changes to SHACL cardinalities can invalidate previously conforming graphs and require an explicit profile or version transition. Deprecated terms will remain identifiable and receive migration guidance rather than being silently repurposed.