Enable TROV extensibility via embedded term declarations

[tmcphillips]

Adopters building a TRS may need transparency capabilities, performance attributes, or signing mechanisms that TROV doesn't define yet. Waiting for a TROV vocabulary update should not be on the critical path for launching a TRS. Adopters should be able to embed the minimal declarations needed for their custom terms directly in TRO declarations, making them self-contained for validation.

Approach

Ideally, TRS implementers would be able to employ custom terms extending TROV concepts with minimal overhead while retaining the self-contained nature of TRO declarations. This goal can be achieved as follows:

1. Support for defining custom types in TRO declarations

Add a trov:customTerm property on the TRS node. System implementers list their custom types with rdfs:subClassOf declarations connecting each to the TROV class it extends. These declarations make the TRO declaration self-contained for validation. SHACL shapes and SPARQL queries can recognize custom types as legitimate TROV types without fetching an external vocabulary.

{
    "@id": "trs",
    "@type": "trov:TrustedResearchSystem",
    "trov:customTerm": [
        {
            "@id": "mytrs:CanProvideAuditLogging",
            "rdfs:subClassOf": { "@id": "trov:TRSCapabilityType" }
        },
        {
            "@id": "mytrs:BlockchainNotarization",
            "rdfs:subClassOf": { "@id": "trov:SigningMechanism" }
        }
    ],
    "trov:hasCapability": [ ... ],
}

One entry per custom type. Data properties that do not extend TROV concepts (like sivacor:architecture) don't need declarations — only types that participate in the TROV type hierarchy.

2. JSON Schema support for custom terms

The JSON Schema needs to accept trov:customTerm as a property on the TRS node. Properties that take typed values (trov:hasCapability, trov:signingMechanism, etc.) must allow namespaced values beyond the TROV-defined types so that custom types are not rejected by schema validation. This is consistent with the existing extension pattern where the schema validates standard TROV terms and lets namespaced extensions through.

3. SHACL shapes that recognize custom types

SHACL shapes for TROV validation need to accept custom types that declare themselves as subclasses of TROV classes. For example, a shape constraining trov:hasCapability values to be instances of trov:TRSCapabilityType might accept mytrs:CanProvideAuditLogging when the subclass triple is present in the graph. This requires RDFS inference or equivalent entailment in the SHACL validation pipeline.

4. SPARQL patterns that work across standard and custom terms

Competency queries and verification queries should use patterns that find both standard TROV terms and custom terms declared as subclasses. For example, querying for all capability types used by a TRS should return both trov:CanProvideInternetIsolation and mytrs:CanProvideAuditLogging.

Tasks

• Update TROV Extension Guide to document trov:customTerm, clarify which terms need declarations
• Update TROV Vocabulary Reference to include trov:customTerm property
• Update TRO Declaration Format to document trov:customTerm in the TRS section
• Update SHACL shapes in trov/ repo to accept custom subclass types
• Ensure JSON Schema accepts trov:customTerm on TRS node, allows namespaced type values
• Ensure SPARQL competency queries (SPARQL competency queries for TROV vocabulary verification #23) use subclass-aware patterns