UJG / Editor's Draft /
W3C Community Group Draft Report

Profiles

incubating

Status of this Document

This report was published by the User Journal Graph Community Group . It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups .

Last Update
2026-06-09
Editors
  • Seva Dolgopolov
Group
User Journal Graph Community Group
Repository
View Source
License
W3C-Software-and-Document

Goal: define interoperability when not everyone implements every optional module, while keeping opaque Core extensions outside semantic profile claims.

The Optional Modules published in the Editor's Draft define the official optional capability family. Profiles are the future place to describe how implementations declare support for those modules, how modules are bundled into named capability sets, and how consumers degrade gracefully when optional capabilities are absent. Opaque Core extensions remain outside semantic profile claims except for pass-through behavior. This draft does not yet standardize the declaration format for those claims.

Archived extension specifications under specs/archive/extensions are historical material only. Profiles MUST NOT treat those archived packages as active Editor's Draft capabilities.

1. Normatives to evaluate

  • Profiles: named capability sets (e.g., graph-core, graph-composition, runtime-basic, runtime-mapped).

  • Profile declaration: how a producer/emitter/consumer declares supported profiles (document-level field vs out-of-band).

  • Optional module interoperability rules:

    • required publication artifacts (*.ttl, *.context.jsonld, *.shape.ttl),

    • collision handling for composed contexts and overlapping terms,

    • versioning expectations for module vocabularies,

    • graceful degradation when a module is unsupported.

  • Opaque extension safety rules:

    • what "namespaced" means for extensions keys,

    • collision handling,

    • preservation and pass-through requirements for stores/proxies.

  • Profile conformance rules:

    • what it means to "conform to profile X",

    • required keys/behaviors per profile,

    • how a consumer should degrade gracefully when profile data is missing.

2. Informatives to evaluate

  • Recommended starter profile set for TR v1.

  • Patterns for optional modules and vendor-private opaque payloads (e.g., UI presentation, experimentation, privacy).

  • Examples: same Journey expressed with/without optional profile features.

3. Decisions to make

  • Do profiles live inside the JSON payload (e.g., profiles: ["..."]) or outside (HTTP header, metadata)?

  • Do you want a formal prefix registry for compact namespaces, or just "SHOULD be URI-like"?

  • How should implementations declare support for the Optional Modules published in the Editor's Draft?

  • How should profiles bundle optional modules into named capability sets?

  • Should opaque extensions pass-through guarantees be declared as part of a profile or stay solely in Core?

4. Must-align with