This is an exploratory supplemental profile. It complements the HTML/RDF Core Model, but its RDF relationships and consumer guidance can also be used by other RDF-bearing formats. It defines no new HTML attributes. This version also publishes a compact RDF vocabulary for discovery records, retrieved contributions, enrichment views, processing activities, relationship roles, and lifecycle states.

The document is itself an HTML/RDF document. The optional RDF Navigator exposes the dataset extracted from its current DOM.

Abstract

RDF makes it easy to state that another resource is related. It does not, by itself, tell an application whether that resource should be offered to a person, retrieved as additional information, or kept separate as evidence, provenance, validation material, an alternative, or a definition.

This profile defines a conservative discovery model for those cases. Publishers use established RDF relationships, beginning with rdfs:seeAlso, and may qualify a relationship with the DCAT relationship and role pattern. Consumers turn recognized relationships into explicit enrichment candidates. Discovery never implies retrieval; retrieval never implies assertion, merging, trust, validation, or execution.

It also defines a standard vocabulary whose namespace is https://ia2.dev/spec/discovery-enrichment#. The vocabulary makes consumer-side discovery state and enrichment provenance portable without turning a descriptive relationship into an instruction.

Introduction

A useful knowledge surface rarely contains everything worth knowing. A report may have supporting evidence, a claim may have provenance, a dataset may have a validation shape, and a concept may be defined by an ontology maintained elsewhere. RDF can identify all of those relationships. The remaining architectural question is how a consumer should turn them into understandable, controllable opportunities to obtain more knowledge.

This specification calls that process discovery and enrichment. Discovery is the recognition that a source dataset relates a context resource to a potentially useful target. Enrichment is the optional, policy-governed act of retrieving and presenting a target's contribution while preserving where it came from. Neither process changes what the source asserted.

Competency questions

The following questions define the practical capability expected of this profile. They are also useful as review criteria for publishers, consumers, and future revisions.

Scope

This profile addresses:

• advertising one or more resources that may add useful knowledge;
• describing the role of an additional resource when a direct RDF predicate is not precise enough;
• serializing portable consumer records for candidates, contributions, views, activities, roles, and lifecycle states;
• presenting enrichment choices to people and applications;
• retrieving RDF-bearing representations under an explicit consumer policy;
• preserving source and graph boundaries after retrieval; and
• re-evaluating discovery when a live source changes.

This profile does not define:

• a crawler, search engine, or universal link registry;
• an automatic graph-union or conflict-resolution algorithm;
• a trust, authorization, signature, or credential model;
• execution semantics for linked resources; or
• a general qualification mechanism for every possible RDF subject.

Terminology

source dataset

The RDF dataset in which a discovery relationship was observed.

context resource

The subject of a direct discovery relationship, or the resource carrying a qualified DCAT relationship.

target resource

The resource identified as potentially providing additional information.

enrichment candidate

A consumer-side record containing a context resource, target resource, relationship, optional roles, source identity, and presentation metadata.

retrieved contribution

An RDF graph or dataset obtained by following an enrichment candidate.

enrichment view

A presentation that lets a user inspect a source dataset together with one or more retrieved contributions while preserving their boundaries.

Core boundary An enrichment candidate is an application affordance derived from RDF. It is not an instruction embedded in the graph.

Design principles

1. Use precise relationships first. A known predicate is preferable to a generic relation plus an explanatory label.
2. Keep links descriptive. A relationship does not grant authority to fetch, disclose credentials, combine claims, or execute content.
3. Preserve provenance. Retrieved information remains attributable to the source from which it was obtained.
4. Keep choice visible. A person or policy can decide which candidates to follow and which contributions to display.
5. Remain vocabulary-neutral. Domain vocabularies may define useful discovery relationships without changes to this profile.

Discovery and Enrichment vocabulary

The vocabulary namespace is https://ia2.dev/spec/discovery-enrichment#, abbreviated de: in this specification. Its terms describe records maintained by a consumer. They do not alter the source dataset and do not grant permission to retrieve, merge, trust, validate, or execute a target.

This section is both the human-readable vocabulary reference and its RDF publication. Every class, property, hierarchy edge, domain, range, role, and status below is asserted by the HTML/RDF attributes on the corresponding definition.

Direct discovery relationships

<#claim-42>
    rdfs:seeAlso <https://example.com/claims/42/evidence> .

Qualified purpose with DCAT

For a document, dataset, cataloged artifact, or other legitimate dcat:Resource, a publisher MAY use dcat:qualifiedRelation, dcat:Relationship, dcterms:relation, and dcat:hadRole to answer the question “what is this target for?”

<https://example.com/report>
    a dcat:Resource ;
    rdfs:seeAlso <https://example.com/report/evidence> ;
    dcat:qualifiedRelation [
        a dcat:Relationship ;
        dcterms:relation <https://example.com/report/evidence> ;
        dcat:hadRole <http://www.iana.org/assignments/relation/describedby>
    ] .

A role MUST be identified by an IRI. Publishers SHOULD reuse a suitable role from an established controlled vocabulary, including the standard Discovery and Enrichment roles and the IANA Link Relations registry. A domain-specific role MAY be defined as a dcat:Role and skos:Concept when no existing role is accurate.

<https://example.com/report>
    dcat:qualifiedRelation [
        a dcat:Relationship ;
        dcterms:relation <https://example.com/report/evidence> ;
        dcat:hadRole de:SupportingEvidence
    ] .

A direct discovery triple and its qualified relationship MAY coexist. The direct triple supports simple consumers; the relationship node adds role and other metadata for qualified consumers. They do not cause two retrievals of the same target.

HTML/RDF authoring

HTML/RDF requires no supplemental syntax for discovery. A visible anchor can carry a complete relationship while retaining its ordinary browser behavior.

<article id="claim-42">
  <p>The release meets the accessibility contract.</p>
  <a
    href="/claims/42/evidence"
    rdf-subject="#claim-42"
    rdf-predicate="http://www.w3.org/2000/01/rdf-schema#seeAlso"
  >Inspect supporting evidence</a>
</article>

The DCAT relationship node can be expressed with extraction-local keys. The keys join the statements; DOM nesting does not establish RDF scope.

<a
  href="/report/evidence"
  rdf-subject="#report"
  rdf-predicate="http://www.w3.org/2000/01/rdf-schema#seeAlso"
>Evidence and provenance</a>

<meta
  rdf-subject="#report"
  rdf-predicate="http://www.w3.org/ns/dcat#qualifiedRelation"
  rdf-object-key="report-evidence-relation"
>
<link
  href="http://www.w3.org/ns/dcat#Relationship"
  rdf-subject-key="report-evidence-relation"
  rdf-predicate="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
>
<link
  href="/report/evidence"
  rdf-subject-key="report-evidence-relation"
  rdf-predicate="http://purl.org/dc/terms/relation"
>
<link
  href="https://ia2.dev/spec/discovery-enrichment#SupportingEvidence"
  rdf-subject-key="report-evidence-relation"
  rdf-predicate="http://www.w3.org/ns/dcat#hadRole"
>

Metadata-only carriers MAY be hidden. The primary discovery link SHOULD remain visible when it is also useful to a person.

Enrichment candidate model

A consumer creates one candidate record for each recognized context-target relationship. The record SHOULD retain:

• the context resource in de:contextResource;
• the target in de:targetResource;
• the direct de:discoveryPredicate or de:qualifiedRelationship that exposed it;
• zero or more de:enrichmentRole IRIs;
• the source document or RDF source identity in de:discoveredIn;
• the de:sourceGraph, when the relationship occurs in a named graph;
• a human-readable label or description when available; and
• the de:carrier when extraction from a live host document provides an addressable carrier.

Candidate records are consumer state. Creating one MUST NOT add an RDF assertion to the source dataset.

@prefix de: <https://ia2.dev/spec/discovery-enrichment#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

_:candidate
    a de:EnrichmentCandidate ;
    de:contextResource <https://example.com/report#claim-42> ;
    de:targetResource <https://example.com/report/evidence> ;
    de:discoveryPredicate rdfs:seeAlso ;
    de:enrichmentRole de:SupportingEvidence ;
    de:discoveredIn <https://example.com/report> ;
    de:enrichmentStatus de:Available .

The candidate above is an assertion made by the consumer about its own observation. It does not assert that the report retrieved, accepted, or endorsed the evidence target.

Consumer processing

A conforming consumer processes discovery in distinct phases:

1. Extract. Obtain the source RDF dataset according to its host format. HTML/RDF extraction remains local and non-executing.
2. Discover. Find recognized direct and qualified relationships and create enrichment candidates.
3. Present or select. Expose candidates to a user or apply an explicit application policy.
4. Retrieve. Dereference only selected targets, under ordinary network, credential, privacy, and content-negotiation rules.
5. Interpret. Parse a supported RDF representation or extract RDF from a supported host representation.
6. Retain boundaries. Store the retrieved contribution with its retrieval identity, source identity, and graph boundaries intact.
7. Display. Offer an enrichment view without silently rewriting the original dataset.

@prefix de: <https://ia2.dev/spec/discovery-enrichment#> .
@prefix prov: <http://www.w3.org/ns/prov#> .

_:discovery
    a de:DiscoveryActivity ;
    prov:used <https://example.com/report> ;
    prov:generated _:candidate .

_:selection
    a de:SelectionActivity ;
    prov:used _:candidate .

_:retrieval
    a de:RetrievalActivity ;
    prov:used _:candidate ;
    prov:generated _:representation .

_:interpretation
    a de:InterpretationActivity ;
    prov:used _:representation ;
    prov:generated _:contribution .

_:contribution
    a de:RetrievedContribution ;
    de:retrievedFrom <https://example.com/report/evidence> ;
    de:interpretedFrom _:representation ;
    de:enrichmentStatus de:Retrieved .

_:view
    a de:EnrichmentView ;
    de:presentsCandidate _:candidate ;
    de:includesContribution _:contribution .

Source, graph, and trust boundaries

A retrieved contribution MUST remain distinguishable from the source dataset. A consumer MAY maintain separate datasets, a provenance-aware store, or another representation that preserves the same distinction.

A consumer MUST NOT, solely because a target was followed:

• treat its triples as assertions made by the source document;
• place its default graph into the source default graph;
• discard or rename its named graphs without recording the transformation;
• treat its claims as trusted, validated, current, or mutually consistent;
• execute scripts, rules, queries, functions, actions, or instructions it describes; or
• send ambient credentials to another origin without an applicable authorization policy.

An enrichment view MAY display a union or comparison, but it MUST make the contributing sources available for inspection. Visual combination is not semantic assertion.

Presentation guidance

A user interface SHOULD explain both the target and why it was offered. It SHOULD prefer, in order:

1. a title or label explicitly attached to the qualified relationship;
2. a human-readable label for its role;
3. the visible HTML link text associated with the relationship;
4. metadata already known about the target; and
5. the target IRI as a final fallback.

A consumer SHOULD distinguish “available,” “loading,” “loaded,” “unsupported,” “failed,” and “blocked by policy” states without relying on color alone. It SHOULD let users remove a retrieved contribution without modifying the source RDF.

Live sources

When an application changes a semantic DOM, a consumer MAY repeat local extraction and update its candidate set. Candidates no longer present in the latest snapshot SHOULD be marked unavailable or removed according to the interface policy.

A previously retrieved contribution does not become part of the new source snapshot merely because it remains visible in an enrichment view. Runtime observation, retrieval history, and source assertions remain distinct.

When an enrichment view is persisted as provenance-bearing RDF, a materially changed view SHOULD be represented as a new de:EnrichmentView or as a revision related with PROV. A runtime interface may reuse the same DOM or application object while maintaining that distinction in its persisted record.

Security and privacy

Discovery targets are untrusted network input. They can reveal user interest, trigger cross-origin requests, redirect to unexpected hosts, return very large representations, or attempt to exploit parsers and renderers.

A consumer SHOULD:

• apply URL, origin, content-size, timeout, and redirect limits;
• avoid speculative retrieval of sensitive targets;
• isolate parsing and rendering of untrusted representations;
• avoid sending cookies, authorization headers, or client certificates across origins by default;
• make automatic retrieval policies visible and reversible; and
• retain enough provenance to explain where displayed statements came from.

Conformance classes