One element, one complete statement

An element bearing rdf-predicate is a statement element. A conforming statement element MUST determine exactly one subject, one predicate, one object, and at most one graph name.

An incomplete statement element is an authoring error. Processors MUST NOT retain it as pending state or complete it from a descendant, ancestor, sibling, or later element.

No inheritance

The following values are never inherited for RDF extraction:

• subject;
• predicate;
• graph name;
• blank-node identity;
• datatype;
• language;
• base direction.

HTML nesting has no RDF meaning by itself.

This decision rejects RDFa-style scoped evaluation context in favor of local decidability. Once the source document IRI and document base IRI are known, a processor can determine a statement by inspecting its element and, only for a triple-term object, its direct object template. It never needs to walk ancestors looking for a subject, graph, datatype, language, vocabulary, or partially constructed relationship.

The rationale is practical:

• Stable fragments: moving a statement element within the same document does not silently change the RDF it expresses. Moving it to another document naturally re-resolves document-relative IRIs.
• Mutation safety: adding, removing, or changing an HTML wrapper does not reinterpret every annotated descendant.
• Independent extraction: statement elements can be validated and extracted independently or in parallel after the source document IRI and document base are established.
• Direct debugging: the complete cause of an emitted triple is visible on one element rather than distributed through an ancestor chain.
• DOM-query fidelity: every active element returned by the statement selector represents a locally complete assertion.
• Reliable generation: templates, content-management systems, and server components can emit valid statements without coordinating hidden parser state with their eventual ancestors.

The cost is some repetition: a descendant that describes an identified ancestor refers to that ancestor explicitly, and graph names, datatypes, and literal metadata may appear on multiple elements. The Core model accepts that cost because explicit references are easier to inspect, move, sign, cache, and debug than inherited meaning. An element describing itself does not repeat its subject: its own HTML identity supplies the default.

HTML inheritance still controls presentation and accessibility as usual. For example, an ancestor’s lang continues to affect the rendered document, but it does not become part of an RDF literal unless lang is directly present on the statement element. This keeps the identity of the extracted RDF term stable when the element moves between HTML contexts.

No implicit chaining

The object of one statement does not become the subject of nested statements. A statement’s subject is constructed from that statement element itself or given by an explicit subject attribute; it never flows from another statement.

No external semantic state

The Core model has no context URL, default vocabulary, imported prefix map, or vocabulary lookup step. Ordinary IRI references are resolved against the RDF document base IRI. Element identities and fragment-only subject references use the source document IRI established from the retrieval IRI and any usable HTML canonical link, as defined in §5.2.

Processors MUST NOT dereference an IRI merely to extract the dataset.

Core 0.1 defines no compact IRI or prefix-expansion syntax. A value such as schema:name is processed as an ordinary RFC 3987 IRI reference and, because it has a scheme component, denotes the absolute IRI schema:name; it is never expanded through a prefix map. Authoring tools MAY accept compact notation in their own interfaces, but they MUST emit full IRI references when producing this binding.

Extraction is not execution

Extracting a SHACL rule, SPARQL query, function declaration, script IRI, or executable vocabulary term records RDF statements only. It does not authorize or cause execution.

Reading the attributes

The examples in this section assume the HTML document IRI is https://example.com/page and use the Turtle prefixes ex:, rdf:, schema:, and xsd: with their conventional meanings.

An element bearing rdf-predicate is a statement carrier. By default, it also represents the statement’s subject. Its attributes and native HTML identity answer four independent questions:

1. What RDF term is the statement about? This is the subject.
2. What relationship or property is being stated? This is the predicate.
3. What is the value or other RDF term at the end of that relationship? This is the object.
4. In which graph is the statement asserted? This is the optional graph name.

For example, this identified heading describes itself:

<h1
  id="alice"
  rdf-predicate="https://schema.org/name"
>Alice</h1>

<https://example.com/page#alice> schema:name "Alice" .

The h1 is both the statement carrier and the subject-bearing HTML element. Its id gives it the fragment IRI https://example.com/page#alice; rdf-predicate supplies schema:name; and its text supplies the literal object "Alice".

If a statement carrier has no explicit subject attribute and no non-empty id, it still describes itself, but its RDF subject is a fresh blank node associated with that element for this extraction:

<span rdf-predicate="https://schema.org/name">Alice</span>

_:generated schema:name "Alice" .

The Turtle label is illustrative and need not be stable between extractions.

Another element can describe the identified element by referring explicitly to its fragment IRI. The identified element need not carry a statement itself:

<article id="alice">
  <h1
    rdf-subject="#alice"
    rdf-predicate="https://schema.org/name"
  >Alice</h1>

  <a
    href="https://example.com/bob"
    rdf-subject="#alice"
    rdf-predicate="https://schema.org/knows"
  >Bob</a>
</article>

<https://example.com/page#alice> schema:name "Alice" ;
                                     schema:knows ex:bob .

The h1 and a do not inherit the article’s subject. Each contains the explicit IRI reference #alice, which happens to identify the parent element. Moving either statement elsewhere in the document does not change its subject. The article’s id makes it referable; it does not assert a triple because the article has no rdf-predicate.

The Turtle semicolon is only serialization shorthand. The RDF graph contains two complete triples, just as the HTML contains two complete statement elements.

HTML authors choose a carrier according to the page’s ordinary information architecture. RDF extraction does not prefer visibly semantic markup over an exact-value or metadata carrier. Given an event represented by <article id="launch">, each of the following alternatives expresses the same typed literal:

<!-- Visible, semantically appropriate HTML -->
<time
  datetime="2026-09-01"
  rdf-subject="#launch"
  rdf-predicate="https://schema.org/startDate"
  rdf-datatype="http://www.w3.org/2001/XMLSchema#date"
>September 1, 2026</time>

<!-- A visible label with a separately preserved machine value -->
<data
  value="2026-09-01"
  rdf-subject="#launch"
  rdf-predicate="https://schema.org/startDate"
  rdf-datatype="http://www.w3.org/2001/XMLSchema#date"
>Launch date</data>

<!-- Metadata-only carriage, for example in head -->
<meta
  name="date"
  content="2026-09-01"
  rdf-subject="#launch"
  rdf-predicate="https://schema.org/startDate"
  rdf-datatype="http://www.w3.org/2001/XMLSchema#date"
>

All three extract as:

<https://example.com/page#launch>
  schema:startDate "2026-09-01"^^xsd:date .

The first form contributes native time semantics and human-readable presentation. The second preserves a lexical value while allowing different visible text. The third carries information without visible presentation. This interchangeability is intentional: authors should use the HTML element that best fits the document while the RDF attributes preserve one extraction model.

The examples below explain each attribute individually. Their Turtle prefixes are:

PREFIX ex: <https://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX schema: <https://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

<html rdf-version="1.2">

VERSION "1.2"

<data
  value="Alice"
  rdf-subject="https://example.com/alice"
  rdf-predicate="https://schema.org/name"
></data>

ex:alice schema:name "Alice" .

<data
  value="IA² HTML/RDF"
  rdf-subject=""
  rdf-predicate="https://schema.org/name"
></data>

<https://example.com/page> schema:name "IA² HTML/RDF" .

<cite
  rdf-subject-key="work"
  rdf-predicate="https://schema.org/name"
>The Dispossessed</cite>

_:work schema:name "The Dispossessed" .

<a
  href="/license"
  rdf-subject=""
  rdf-predicate="http://purl.org/dc/terms/license"
>License</a>

<https://example.com/page>
  <http://purl.org/dc/terms/license>
  <https://example.com/license> .

<address
  rdf-object-key="address"
  rdf-subject="https://example.com/alice"
  rdf-predicate="https://schema.org/address"
>
  <span
    rdf-subject-key="address"
    rdf-predicate="https://schema.org/addressLocality"
  >Vancouver</span>
</address>

ex:alice schema:address _:address .
_:address schema:addressLocality "Vancouver" .

<time
  datetime="2026-09-01"
  rdf-subject="https://example.com/conference"
  rdf-predicate="https://schema.org/startDate"
  rdf-datatype="http://www.w3.org/2001/XMLSchema#date"
>September 1, 2026</time>

ex:conference schema:startDate "2026-09-01"^^xsd:date .

<a
  href="https://example.com/bob"
  rdf-subject="https://example.com/alice"
  rdf-predicate="https://schema.org/knows"
  rdf-graph="https://example.com/graphs/public"
>Bob</a>

<https://example.com/graphs/public> {
  ex:alice schema:knows ex:bob .
}

<img
  src="https://example.com/photos/alice.jpg"
  alt="Alice at the conference"
  rdf-subject="https://example.com/alice"
  rdf-predicate="https://schema.org/image"
  rdf-graph-key="observations"
>

_:observations {
  ex:alice schema:image <https://example.com/photos/alice.jpg> .
}

<aside
  rdf-subject-key="claim"
  rdf-predicate="http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies"
>
  <p>This claim is recorded for provenance review.</p>
  <template>
    <a
      href="https://example.com/bob"
      rdf-subject="https://example.com/alice"
      rdf-predicate="https://schema.org/knows"
    >Bob</a>
  </template>
</aside>

_:claim rdf:reifies <<( ex:alice schema:knows ex:bob )>> .

Discovering asserted statements

An extraction root is either an HTML Document or a DocumentFragment. A processor begins with statement elements in that root’s tree. For a document extraction, the candidate set is equivalent to:

document.querySelectorAll("[rdf-predicate]")

An ordinary query on a Document or DocumentFragment does not traverse the contents of a descendant HTML template. Therefore, statements inside template.content are not asserted merely because their markup contains rdf-predicate.

The content of any template MAY be supplied explicitly as a separate extraction root. Its statements then form a separate extraction result; they do not become assertions in the dataset extracted from the tree containing the template element. A fragment extraction uses the source document IRI and document base IRI supplied by the caller, normally those of the template’s owner document.

For example, this ordinary template contains two independently extractable statements but contributes neither to the containing document’s dataset:

<template id="candidate-profile">
  <span
    rdf-subject="/people/alice"
    rdf-predicate="https://schema.org/name"
  >Alice</span>

  <a
    href="/people/bob"
    rdf-subject="/people/alice"
    rdf-predicate="https://schema.org/knows"
  >Bob</a>
</template>

If candidate-profile.content is explicitly supplied as an extraction root, its result contains:

</people/alice> schema:name "Alice" ;
  schema:knows </people/bob> .

Subject

A statement’s subject is constructed locally from its statement element in this order:

1. If rdf-subject is present, its value is resolved to an IRI and used as the subject.
2. Otherwise, if rdf-subject-key is present, its value selects the blank-node subject by extraction-local key.
3. Otherwise, if the element has a non-empty HTML id, the source document IRI, with any existing fragment removed and the element’s encoded fragment identifier appended, gives the subject.
4. Otherwise, the subject is a fresh blank node uniquely associated with that element for the duration of the extraction.

rdf-subject and rdf-subject-key MUST NOT occur together. They override the element’s default self-subject; neither is required.

The empty string is a valid empty relative IRI reference. rdf-subject="" therefore resolves to the document base IRI using the IRI-reference-processing algorithm. It is an explicit base-resource subject, not missing or inherited semantic state. In the absence of an explicit HTML base, this is the canonical source document IRI when one was declared. Authors MAY use an explicit document IRI when they specifically mean the source document and an HTML base could differ from it.

For subject construction, a fragment-only rdf-subject value such as #alice is a local element reference and MUST resolve against the source document IRI, not against an IRI supplied by HTML base. An id-derived self-subject and an explicit reference to that encoded fragment therefore denote the same RDF term even when the document changes the base used by ordinary relative URLs. Other relative rdf-subject values use the document base IRI.

To construct an IRI fragment from id, remove any existing fragment from the source document IRI and append # followed by the encoded identifier. For each Unicode scalar value in the identifier, preserve it when RFC 3987 permits it directly in ifragment and it is not %; otherwise encode its UTF-8 bytes as uppercase percent-encoded octets. Encoding % unconditionally makes the mapping from arbitrary HTML identifiers injective. A value that is not a Unicode scalar-value string cannot supply an id-derived subject. Processors MUST compare the resulting RDF terms, not their source spellings.

An element with id but no rdf-predicate does not assert a statement. Its fragment IRI can nevertheless be named explicitly by statement elements, including descendants:

<article id="alice">
  <h1
    rdf-subject="#alice"
    rdf-predicate="https://schema.org/name"
  >Alice</h1>
</article>

This is an explicit IRI reference, not subject inheritance. Extraction of the h1 does not require inspecting its parent, and moving it elsewhere in the same document does not change its subject.

An automatically allocated blank-node self-subject has no author-controlled key and cannot be named by another statement. Authors needing several statements to share an anonymous subject MUST use the same extraction-local key with rdf-subject-key and, where that resource is an object, rdf-object-key.

Local keys are scoped to one extraction operation, including any term fragments parsed as part of it. The same key in rdf-subject-key, rdf-object-key, or rdf-graph-key selects the same blank node within the extracted dataset, including across RDF positions. Separately extracting a template’s content starts a separate key scope. Keys are authoring-time correlation handles: they are not RDF terms, are not persistent identifiers, and are not matched across extraction operations. A serializer chooses its own blank-node labels independently of the source keys.

A local key MUST be non-empty and MUST NOT contain ASCII whitespace. Keys are compared case-sensitively using their parsed DOM attribute values. They are not resolved as IRIs and processors MUST NOT dereference them.

RDF 1.2 triple terms cannot occupy the subject position, so this binding defines no triple-term subject form.

Predicate

The value of rdf-predicate MUST be a valid IRI reference. It is resolved against the document base IRI.

The Core model defines no special treatment for rdf:type or any other predicate.

Object

The statement’s object is determined from the statement element itself. Exactly one of the following object-carrier forms MUST apply.

<a
  href="/people/bob"
  rdf-subject="/people/alice"
  rdf-predicate="https://schema.org/knows"
>Bob</a>

<a
  hidden
  href="https://schema.org/Person"
  rdf-subject="/people/alice"
  rdf-predicate="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
></a>

<p
  rdf-subject="/people/alice"
  rdf-predicate="https://schema.org/description"
>
  Alice <em>builds</em>
  knowledge graphs.
</p>

<data
  value="01"
  rdf-subject="/inventory/widget"
  rdf-predicate="https://example.com/count"
  rdf-datatype="http://www.w3.org/2001/XMLSchema#integer"
>1 item</data>

Literal datatype, language, and direction

Literal metadata is determined by the following ordered algorithm:

1. If rdf-datatype is present:
   1. resolve its value to the datatype IRI;
   2. the datatype IRI MUST NOT be http://www.w3.org/1999/02/22-rdf-syntax-ns#langString or http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString;
   3. a non-empty directly present lang or a directly present dir whose value matches ltr or rtl ASCII case-insensitively MUST NOT also be present; and
   4. construct a typed literal with no language tag and no base direction.
2. Otherwise, inspect only lang and dir directly present on the statement element:
   1. an absent or empty lang supplies no language tag;
   2. a non-empty lang MUST be a well-formed BCP 47 language tag;
   3. dir values are matched ASCII case-insensitively: ltr and rtl supply the corresponding lowercase RDF base direction, while an absent dir or dir="auto" supplies no RDF base direction;
   4. any other directly present dir value makes the statement invalid;
   5. a base direction without a non-empty language tag makes the statement invalid;
   6. a language tag plus a base direction constructs an RDF 1.2 directional language-tagged string with datatype http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString;
   7. a language tag without a base direction constructs a language-tagged string with datatype http://www.w3.org/1999/02/22-rdf-syntax-ns#langString; and
   8. if neither is present, construct a literal with datatype http://www.w3.org/2001/XMLSchema#string.

Language tags are compared ASCII case-insensitively as required by RDF 1.2. An extractor MAY preserve their source case or normalize them according to BCP 47; either representation denotes the same RDF 1.2 term.

HTML language or direction inherited from ancestors affects presentation but not RDF extraction. dir="auto" remains available for HTML presentation but has no RDF base-direction equivalent.

rdf-datatype on an IRI, blank-node, or triple-term object is an authoring error.

<cite
  lang="ar"
  dir="rtl"
  rdf-subject="/books/1"
  rdf-predicate="https://schema.org/name"
>تصميم مواقع الويب</cite>

</books/1> schema:name "تصميم مواقع الويب"@ar--rtl .

The cite element communicates that the visible phrase is a work title; direct lang and dir simultaneously determine the RDF 1.2 directional language-tagged literal.

Graph names and declarations

If neither graph attribute is present, the triple belongs to the default graph.

Otherwise, a statement element MUST have exactly one of:

• rdf-graph, naming an IRI graph; or
• rdf-graph-key, selecting a blank-node graph by extraction-local key.

Graph membership is stated on every statement. It is never inherited from a container.

<a
  href="/people/bob"
  rdf-subject="/people/alice"
  rdf-predicate="https://schema.org/knows"
  rdf-graph="/graphs/public-profile"
>Bob</a>

An element without rdf-predicate that carries exactly one of rdf-graph or rdf-graph-key, and is not an object-position template, is a graph declaration element. It adds the named graph to the extracted dataset without adding a triple. This represents empty named graphs and may also redundantly declare a graph populated by statements elsewhere in the extraction root.

<template rdf-graph="/graphs/reserved"></template>
<template rdf-graph-key="private-observations"></template>

The result contains an empty IRI-named graph and an empty blank-node-named graph. The choice of template has no RDF significance; any non-statement HTML element may serve as the carrier. A declaration does not scope its descendants, and statements placed inside a declared template remain outside the containing extraction unless its content is separately supplied as an extraction root.

The corresponding TriG dataset structure is:

<https://example.com/graphs/reserved> {}
_:private-observations {}

A graph declaration element MUST NOT carry both graph attributes or any other Core-defined rdf-* attribute. Unknown attributes remain subject to the general unknown-attribute rule. Repeated declarations of the same graph are idempotent. A graph declaration with an invalid graph IRI reference or local key is invalid and does not add a named graph.

Inert term fragments

A direct child template selected as a statement’s object carrier is a term fragment. Its content MUST contain exactly one element child, that element MUST be a statement element, and it MUST contain no other non-whitespace text nodes. Comments are ignored. A query equivalent to template.content.querySelectorAll("[rdf-predicate]") MUST return exactly that one statement element. Additional statement descendants are therefore forbidden except inside nested template contents, which occupy separate document fragments. A term fragment MUST NOT contain a graph declaration element.

That statement is parsed by the same subject, predicate, and object rules as an asserted statement, with these differences:

1. It constructs an RDF triple term.
2. It does not add that triple to any graph.
3. It MUST NOT have a graph attribute.

The triple term may itself contain an object-position template as a nested term fragment. This permits the recursive triple terms defined by RDF 1.2.

Term fragments are inline. Core 0.1 defines no ID reference or reusable term registry. Repetition is the canonical serialization because references would require DOM lookup, cycle detection, blank-node scope rules, and a distinction between active asserted targets and inert targets. Processors MUST NOT interpret an id, fragment reference, or other HTML relationship as a reusable triple-term reference. Authoring tools MAY deduplicate terms internally but MUST serialize each triple-term occurrence inline.

An ordinary template that is not in object-carrier position is not a term fragment. Its content may contain zero or more statement elements and MAY be supplied explicitly as a separate extraction root. This is ordinary fragment extraction, not an RDF graph term, quotation mechanism, or assertion in the containing dataset.

Reification without accidental assertion

<div
  rdf-subject-key="claim-1"
  rdf-predicate="http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies"
>
  <template>
    <a
      href="/people/bob"
      rdf-subject="/people/alice"
      rdf-predicate="https://schema.org/knows"
    >Bob</a>
  </template>
</div>

<a
  href="/sources/interview-7"
  rdf-subject-key="claim-1"
  rdf-predicate="http://www.w3.org/ns/prov#wasDerivedFrom"
>Interview 7</a>

The extracted default graph contains two asserted triples:

_:claim-1 rdf:reifies <<( </people/alice> schema:knows </people/bob> )>> .
_:claim-1 prov:wasDerivedFrom </sources/interview-7> .

It does not contain:

</people/alice> schema:knows </people/bob> .

The proposition becomes asserted only if an equivalent statement element also exists in the extraction root’s tree.

DOM separation

The asserted and non-asserted layers remain mechanically distinct:

// Asserted statements in the document dataset
const asserted = document.querySelectorAll("[rdf-predicate]");

// Direct object templates of asserted statements
const terms = [...asserted]
  .map(statement => statement.querySelector(":scope > template"))
  .filter(Boolean);

// A term's internal statement is queried explicitly
const inner = terms[0].content.querySelector("[rdf-predicate]");

A document-wide selector does not accidentally return inner.

Shapes are RDF

SHACL data graphs and shapes graphs use the same statement syntax. The extractor does not interpret sh:NodeShape, sh:path, sh:rule, or any other vocabulary term specially.

A consumer chooses which extracted graph is the data graph and which is the shapes graph. Authors SHOULD place shapes in an explicitly named graph when an HTML document carries both.

Core 0.1 defines no non-RDF graph-role attribute. A consumer may select a graph by its name through application configuration, or the graph-name resource may be described with ordinary RDF statements. For example, an application vocabulary can classify the shapes graph in the default graph:

<a
  hidden
  href="https://example.com/vocab/ShapesGraph"
  rdf-subject="/graphs/shapes"
  rdf-predicate="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
></a>

The extractor remains vocabulary-neutral: it emits the classification triple but does not assign operational meaning to ex:ShapesGraph.

Example shape graph

The following hidden HTML asserts a minimal SHACL shape into /graphs/shapes:

<section hidden>
  <a
    href="http://www.w3.org/ns/shacl#NodeShape"
    rdf-subject="#PersonShape"
    rdf-predicate="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
    rdf-graph="/graphs/shapes"
  ></a>

  <a
    href="https://schema.org/Person"
    rdf-subject="#PersonShape"
    rdf-predicate="http://www.w3.org/ns/shacl#targetClass"
    rdf-graph="/graphs/shapes"
  ></a>

  <span
    rdf-object-key="name-property"
    rdf-subject="#PersonShape"
    rdf-predicate="http://www.w3.org/ns/shacl#property"
    rdf-graph="/graphs/shapes"
  ></span>

  <a
    href="https://schema.org/name"
    rdf-subject-key="name-property"
    rdf-predicate="http://www.w3.org/ns/shacl#path"
    rdf-graph="/graphs/shapes"
  ></a>

  <data
    value="1"
    rdf-subject-key="name-property"
    rdf-predicate="http://www.w3.org/ns/shacl#minCount"
    rdf-datatype="http://www.w3.org/2001/XMLSchema#integer"
    rdf-graph="/graphs/shapes"
  ></data>
</section>

The use of hidden affects HTML presentation only. These are active document elements, so their triples are asserted and discoverable by the ordinary asserted-statement query.

Advanced Features and Rules

SHACL Advanced Features—including custom targets, annotation properties, functions, node expressions, and rules—are RDF graph structures and can be represented without extending the Core model or its HTML binding.

RDF lists used by function calls and node expressions are expressed as explicit rdf:first and rdf:rest statements. SPARQL bodies are literal objects. SHACL 1.2 Rules are likewise ordinary RDF statements.

Extraction MUST NOT execute any of them.

A separate SHACL processor MAY consume the extracted shapes graph. Such a processor MUST apply its own trust, capability, resource, and execution policy. The presence of a rule or function declaration in HTML is never consent to run it.

Invalid statements and recovery

An invalid statement emits no triple. A processor MUST report a diagnostic and MUST continue with other independent statement elements.

If a term fragment is invalid, construction of that triple term fails and the immediately containing statement is invalid. This rule applies recursively to nested term fragments. No triple represented by an invalid term fragment is asserted merely as a recovery action.

Competing object carriers, an invalid or unresolved IRI reference, invalid literal metadata, a forbidden graph attribute on a term-fragment statement, or failure to construct any required RDF term makes the affected statement invalid. Processors MUST NOT select one competing carrier by precedence, repair a malformed value, or infer replacement state from surrounding markup.

Statements are independent for recovery unless one contains the other through an object-position term fragment. An invalid ordinary statement does not invalidate another statement merely because they use the same IRI or local key.

An invalid graph declaration adds no named graph and does not invalidate statements that independently use the same graph name.

Semantic and source signatures

Core extraction defines the semantic input to a signing layer but does not define canonicalization, hashing, key discovery, or a signature envelope. A semantic-signature profile performs these operations in order:

1. extract the Core dataset;
2. reject unsupported constructs or transform them by a profile-defined, information-preserving procedure;
3. canonicalize the resulting dataset with an explicitly identified algorithm;
4. sign the canonical bytes; and
5. bind the signature to the extraction version and every transformation and canonicalization identifier used.

Presentation-only HTML edits preserve a semantic signature when and only when they leave that profile’s canonical semantic input unchanged. A signature over the HTML representation itself is a separate source signature and MUST cover explicitly defined source bytes or a separately defined HTML canonical form.

RDFC-1.0 is based on an RDF 1.1-style set-of-quads model. It cannot by itself represent every Core 0.1 dataset, including datasets with RDF 1.2 triple terms or significant empty named graphs. A profile using RDFC-1.0 MUST therefore restrict such inputs or define and identify a compatible information-preserving transformation before canonicalization. Core extractors MUST NOT silently apply one.

RDFa

RDFa integrates RDF with HTML but includes inherited evaluation context, incomplete triples, and chaining behavior. This Core model intentionally trades compactness for statement locality and mechanical extraction.

JSON-LD

JSON-LD represents RDF in a separate serialization, commonly inside a script element. This Core model keeps semantic statements correlated with DOM elements and does not require JSON parsing, context processing, or script-element discovery.

Microdata and microformats

Microdata and microformats provide useful HTML-integrated patterns but do not aim to expose the full RDF 1.2 data model, arbitrary named graphs, or triple terms.

MCP, A2A, and WebMCP

Those efforts address agent/service communication, agent interoperability, or callable webpage tools. This model addresses a lower layer: deterministic, non-executing extraction of document meaning. A tool protocol may consume this dataset, but is not required to extract it.