Use Case Report for W3C Community Groups
CUE's lattice-based unification simultaneously performs SPARQL-class graph pattern matching and SHACL constraint validation at compile time. A single typed dependency graph produces 17 W3C specification outputs — including JSON-LD, SHACL, SKOS, OWL-Time, PROV-O, ODRL, and Verifiable Credentials — without runtime processors, triplestores, or pipelines. An 18th (Hydra) is implemented downstream.
This report documents the implementation, provides computed evidence from a live example graph, and identifies relevance to four W3C Community Groups.
All evidence below is computed, not hand-written. Each JSON block is
generated by cue export ./w3c/ -e evidence.<field>. Reproduce from source:
github.com/quicue/apercue.
The semantic web stack traditionally requires five or more runtime components: an RDF store, a SPARQL query engine, a SHACL processor, a serializer, and a query planner. Each introduces its own execution model, failure modes, and infrastructure requirements. Schema drift between layers is common.
For constrained domains — research data management, project plans, infrastructure topology, academic curricula — this operational complexity is disproportionate to the problem. These domains share a common structure: typed resources with directed acyclic dependency edges. They need standards-compliant output, not the full semantic web runtime.
apercue.ca implements a constraint-based
alternative using CUE, a configuration language with lattice-theoretic type
semantics. Resources declare two things: what they are (@type, a
struct-as-set) and what they need (depends_on, also a struct-as-set):
"analysis-code": {
name: "analysis-code"
"@type": {Process: true}
depends_on: {"sensor-dataset": true}
}
Everything else — topology, impact analysis, compliance, scheduling, and every
W3C output — is a projection of this single value.
cue export -e <expression> produces the target format.
The inline example graph defines a 5-node research publication pipeline:
ethics approval, sensor dataset, analysis code, draft paper, and peer review.
This domain was chosen because W3C specifications map to their intended
purposes: Dublin Core for publication metadata, PROV-O for dataset provenance,
ODRL for data embargo policies, and OWL-Time for submission deadlines. This is
the same #Graph pattern used in production deployments with 30+ nodes.
All evidence blocks share this @context, which maps resource fields to
standard W3C vocabularies:
{
"@context": {
"@base": "urn:resource:",
"dcterms": "http://purl.org/dc/terms/",
"prov": "http://www.w3.org/ns/prov#",
"dcat": "http://www.w3.org/ns/dcat#",
"sh": "http://www.w3.org/ns/shacl#",
"skos": "http://www.w3.org/2004/02/skos/core#",
"schema": "https://schema.org/",
"time": "http://www.w3.org/2006/time#",
"earl": "http://www.w3.org/ns/earl#",
"odrl": "http://www.w3.org/ns/odrl/2/",
"org": "http://www.w3.org/ns/org#",
"cred": "https://www.w3.org/2018/credentials#",
"as": "https://www.w3.org/ns/activitystreams#",
"void": "http://rdfs.org/ns/void#",
"dqv": "http://www.w3.org/ns/dqv#",
"oa": "http://www.w3.org/ns/oa#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"owl": "http://www.w3.org/2002/07/owl#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"apercue": "https://apercue.ca/vocab#",
"charter": "https://apercue.ca/charter#",
"name": "dcterms:title",
"description": "dcterms:description",
"depends_on": {
"@id": "dcterms:requires",
"@type": "@id"
},
"status": {
"@id": "schema:actionStatus",
"@type": "@id"
},
"tags": {
"@id": "dcterms:subject",
"@container": "@set"
}
}
}
This context is not a configuration file — it is a CUE value computed from the vocabulary registry. Every resource exported through this context produces valid JSON-LD 1.1.
A compliance rule requires that publications have upstream dependencies
(cannot exist without supporting data). The #ComplianceCheck pattern
produces a standard sh:ValidationReport:
{
"@type": "sh:ValidationReport",
"sh:conforms": true,
"sh:result": []
}
sh:conforms: true — all compliance rules pass. This is produced at CUE
evaluation time. No separate SHACL processor runs.
The #CriticalPath pattern computes forward/backward passes and identifies
the critical sequence:
[
{
"resource": "ethics-approval",
"start": 0,
"finish": 60,
"duration": 60
},
{
"resource": "sensor-dataset",
"start": 60,
"finish": 150,
"duration": 90
},
{
"resource": "analysis-code",
"start": 150,
"finish": 195,
"duration": 45
},
{
"resource": "draft-paper",
"start": 195,
"finish": 225,
"duration": 30
},
{
"resource": "peer-review",
"start": 225,
"finish": 285,
"duration": 60
}
]
5-node critical path, 285-day total
duration. The same data produces standard OWL-Time time:Interval entries:
{
"@type": "time:Interval",
"@id": "urn:resource:analysis-code",
"dcterms:title": "analysis-code",
"time:hasBeginning": {
"@type": "time:Instant",
"time:inXSDDecimal": 150
},
"time:hasEnd": {
"@type": "time:Instant",
"time:inXSDDecimal": 195
},
"time:hasDuration": {
"@type": "time:Duration",
"time:numericDuration": 45,
"time:unitType": {
"@id": "time:unitDay"
}
},
"apercue:slack": 0,
"apercue:isCritical": true
}
Each resource becomes a time:Interval with time:hasBeginning,
time:hasEnd, and time:hasDuration. Slack and criticality are extensions
in the apercue: namespace.
The #ODRLPolicy pattern projects dependency-graph resources into an ODRL
policy set:
{
"@type": "odrl:Set",
"odrl:uid": "apercue:graph-policy",
"odrl:permission": [
{
"odrl:action": {
"@id": "odrl:read"
}
},
{
"odrl:action": {
"@id": "odrl:execute"
},
"odrl:assignee": {
"@id": "apercue:operator"
}
}
],
"odrl:prohibition": []
}
Permissions and prohibitions are typed by the same @type set that drives
graph construction. Adding a policy is adding a CUE file, not configuring
middleware.
The #ProvenanceTrace pattern maps dependency edges to prov:wasDerivedFrom
relations:
{
"@type": "prov:Entity",
"@id": "urn:resource:analysis-code",
"dcterms:title": "analysis-code",
"prov:wasAttributedTo": {
"@id": "apercue:graph-engine"
},
"prov:wasDerivedFrom": [
{
"@id": "urn:resource:sensor-dataset"
}
],
"prov:wasGeneratedBy": {
"@id": "apercue:graph-construction"
}
}
Every resource becomes a prov:Entity. Dependency edges become derivation
links. The full provenance graph includes all 5 resources plus the
generating prov:Activity and prov:Agent.
The #VoIDDataset pattern produces a VoID dataset description — the graph's
machine-readable "about" page:
{
"@type": "void:Dataset",
"@id": "urn:apercue:w3c-evidence",
"dcterms:title": "W3C Evidence Dataset",
"void:entities": 5,
"void:triples": 24,
"void:classes": 5,
"void:classPartition": [
{
"@type": "void:Dataset",
"void:class": {
"@id": "apercue:Governance"
},
"void:entities": 1
},
{
"@type": "void:Dataset",
"void:class": {
"@id": "apercue:Dataset"
},
"void:entities": 1
},
{
"@type": "void:Dataset",
"void:class": {
"@id": "apercue:Process"
},
"void:entities": 1
},
{
"@type": "void:Dataset",
"void:class": {
"@id": "apercue:Publication"
},
"void:entities": 1
},
{
"@type": "void:Dataset",
"void:class": {
"@id": "apercue:Review"
},
"void:entities": 1
}
]
}
5 entities, 24 triples, 5 classes. Class partitions show
how many resources belong to each @type. This is standard VoID — any LOD
catalog or SPARQL endpoint description consumer can read it.
The #OWLOntology pattern extracts the implicit ontology from the graph's
type system. Each @type becomes an rdfs:Class; dependency edges become
an owl:ObjectProperty:
{
"@graph": [
{
"@type": "owl:Ontology",
"@id": "https://apercue.ca/ontology/w3c-evidence#",
"dcterms:description": "OWL vocabulary from research publication dependency graph",
"dcterms:title": "W3C Evidence Ontology"
},
{
"@type": [
"rdfs:Class",
"owl:Class"
],
"@id": "https://apercue.ca/ontology/w3c-evidence#Governance",
"rdfs:label": "Governance"
},
{
"@type": [
"rdfs:Class",
"owl:Class"
],
"@id": "https://apercue.ca/ontology/w3c-evidence#Dataset",
"rdfs:label": "Dataset"
},
{
"@type": [
"rdfs:Class",
"owl:Class"
],
"@id": "https://apercue.ca/ontology/w3c-evidence#Process",
"rdfs:label": "Process"
},
{
"@type": [
"rdfs:Class",
"owl:Class"
],
"@id": "https://apercue.ca/ontology/w3c-evidence#Publication",
"rdfs:label": "Publication"
},
{
"@type": [
"rdfs:Class",
"owl:Class"
],
"@id": "https://apercue.ca/ontology/w3c-evidence#Review",
"rdfs:label": "Review"
},
{
"@type": "owl:ObjectProperty",
"@id": "dcterms:requires",
"rdfs:label": "depends on",
"rdfs:comment": "A resource depends on another resource"
}
]
}
W3C Evidence Ontology — the graph's type vocabulary as a formal OWL ontology. Loadable in Protégé, validatable by OWL reasoners.
The #SKOSTaxonomy pattern projects graph types as a SKOS ConceptScheme
with broader/narrower hierarchy:
{
"@type": "skos:ConceptScheme",
"@id": "https://apercue.ca/vocab#TypeTaxonomy",
"skos:prefLabel": "Research Pipeline Type Taxonomy",
"apercue:concepts": [
{
"@type": "skos:Concept",
"@id": "https://apercue.ca/vocab#Governance",
"skos:broader": {
"@id": "https://apercue.ca/vocab#ResearchActivity"
},
"skos:prefLabel": "Governance",
"skos:inScheme": {
"@id": "https://apercue.ca/vocab#TypeTaxonomy"
},
"skos:scopeNote": "Governance — used by 1 resources"
},
{
"@type": "skos:Concept",
"@id": "https://apercue.ca/vocab#Dataset",
"skos:broader": {
"@id": "https://apercue.ca/vocab#ResearchOutput"
},
"skos:prefLabel": "Dataset",
"skos:inScheme": {
"@id": "https://apercue.ca/vocab#TypeTaxonomy"
},
"skos:scopeNote": "Dataset — used by 1 resources"
},
{
"@type": "skos:Concept",
"@id": "https://apercue.ca/vocab#Process",
"skos:broader": {
"@id": "https://apercue.ca/vocab#ResearchActivity"
},
"skos:prefLabel": "Process",
"skos:inScheme": {
"@id": "https://apercue.ca/vocab#TypeTaxonomy"
},
"skos:scopeNote": "Process — used by 1 resources"
}
]
}
Each @type becomes a skos:Concept with skos:broader linking to
parent categories. Types that co-occur on resources are linked via
skos:related. The scheme is navigable by any SKOS-aware vocabulary
browser.
The #ActivityStream pattern models graph construction as an Activity
Streams 2.0 OrderedCollection:
{
"type": "OrderedCollection",
"totalItems": 5,
"orderedItems": [
{
"type": "Create",
"actor": {
"type": "Application",
"name": "apercue"
},
"object": {
"summary": "Institutional review board approval (Protocol #2024-0142)",
"type": "Object",
"id": "urn:resource:ethics-approval",
"name": "ethics-approval",
"apercue:depth": 0,
"apercue:types": {
"Governance": true
}
}
},
{
"context": [
{
"type": "Link",
"href": "urn:resource:ethics-approval"
}
],
"type": "Create",
"actor": {
"type": "Application",
"name": "apercue"
},
"object": {
"summary": "Telemetry dataset (embargoed until publication)",
"type": "Object",
"id": "urn:resource:sensor-dataset",
"name": "sensor-dataset",
"apercue:depth": 1,
"apercue:types": {
"Dataset": true
}
}
}
]
}
Each resource creation is a Create activity ordered by topological
depth. Layer 0 resources (no dependencies) are created first. Dependency
edges appear as context links.
The #ValidationCredential pattern wraps the SHACL validation result
in a W3C Verifiable Credential:
{
"type": [
"VerifiableCredential",
"ValidationCredential"
],
"issuer": "apercue:graph-engine",
"validFrom": "2026-02-27T00:00:00Z",
"credentialSubject": {
"id": "urn:apercue:w3c-evidence",
"type": "sh:ValidationReport",
"sh:conforms": true,
"apercue:violationCount": 0,
"apercue:validationReport": {
"@type": "sh:ValidationReport",
"sh:conforms": true,
"@context": {
"@base": "urn:resource:",
"dcterms": "http://purl.org/dc/terms/",
"prov": "http://www.w3.org/ns/prov#",
"dcat": "http://www.w3.org/ns/dcat#",
"sh": "http://www.w3.org/ns/shacl#",
"skos": "http://www.w3.org/2004/02/skos/core#",
"schema": "https://schema.org/",
"time": "http://www.w3.org/2006/time#",
"earl": "http://www.w3.org/ns/earl#",
"odrl": "http://www.w3.org/ns/odrl/2/",
"org": "http://www.w3.org/ns/org#",
"cred": "https://www.w3.org/2018/credentials#",
"as": "https://www.w3.org/ns/activitystreams#",
"void": "http://rdfs.org/ns/void#",
"dqv": "http://www.w3.org/ns/dqv#",
"oa": "http://www.w3.org/ns/oa#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"owl": "http://www.w3.org/2002/07/owl#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"apercue": "https://apercue.ca/vocab#",
"charter": "https://apercue.ca/charter#",
"name": "dcterms:title",
"description": "dcterms:description",
"depends_on": {
"@id": "dcterms:requires",
"@type": "@id"
},
"status": {
"@id": "schema:actionStatus",
"@type": "@id"
},
"tags": {
"@id": "dcterms:subject",
"@container": "@set"
}
},
"sh:result": []
}
}
}
The credential attests that the graph passed compliance validation.
The credentialSubject embeds the full sh:ValidationReport. This
is the VC data model only — cryptographic proof requires an external
issuer.
The #DCATCatalog pattern projects the graph as a DCAT catalog with one
dcat:Dataset per resource:
{
"@type": "dcat:Catalog",
"dcterms:title": "Research Publication Pipeline",
"dcat:dataset": [
{
"@type": "dcat:Dataset",
"@id": "urn:resource:sensor-dataset",
"dcterms:description": "Telemetry dataset (embargoed until publication)",
"dcterms:requires": [
{
"@id": "urn:resource:ethics-approval"
}
],
"dcterms:title": "sensor-dataset",
"dcat:theme": [
{
"@type": "skos:Concept",
"skos:prefLabel": "Dataset"
}
]
}
]
}
Each resource becomes a dataset entry with Dublin Core metadata. The catalog is consumable by any DCAT-aware data portal (CKAN, data.gov, EU Open Data Portal).
The #SmokeTest pattern produces EARL assertions describing the test plan for
graph validation:
{
"@graph": [
{
"@type": "earl:Assertion",
"earl:subject": {
"@id": "urn:apercue:w3c-evidence"
},
"earl:test": {
"@type": "earl:TestCriterion",
"dcterms:title": "graph has 5 resources",
"apercue:command": "cue export ./w3c/ -e evidence.graph_summary.total_resources"
},
"earl:result": {
"@type": "earl:TestResult",
"earl:outcome": {
"@id": "earl:untested"
},
"earl:expected": "5"
}
},
{
"@type": "earl:Assertion",
"earl:subject": {
"@id": "urn:apercue:w3c-evidence"
},
"earl:test": {
"@type": "earl:TestCriterion",
"dcterms:title": "SHACL report conforms",
"apercue:command": "cue export ./w3c/ -e evidence.shacl[\"sh:conforms\"]"
},
"earl:result": {
"@type": "earl:TestResult",
"earl:outcome": {
"@id": "earl:untested"
},
"earl:expected": "true"
}
}
]
}
Each check becomes an earl:Assertion with an earl:TestCriterion and
earl:TestResult. Outcomes are earl:untested at compile time — the plan
is linked data; execution happens at runtime.
The #SchemaOrgAlignment pattern annotates resources with schema:additionalType
via a configurable type map:
{
"@graph": [
{
"@type": {
"Governance": true
},
"@id": "urn:resource:ethics-approval",
"dcterms:description": "Institutional review board approval (Protocol #2024-0142)",
"dcterms:title": "ethics-approval",
"schema:additionalType": [
"schema:Action"
]
},
{
"@type": {
"Dataset": true
},
"@id": "urn:resource:sensor-dataset",
"dcterms:description": "Telemetry dataset (embargoed until publication)",
"dcterms:title": "sensor-dataset",
"schema:additionalType": [
"schema:Dataset"
],
"schema:isPartOf": [
{
"@id": "urn:resource:ethics-approval"
}
]
}
]
}
Graph types (Process, Dataset, etc.) map to schema.org types
(schema:SoftwareApplication, schema:Dataset). This makes the graph
discoverable by Google Rich Results and other schema.org consumers.
The #OrgStructure pattern groups resources by @type into
org:OrganizationalUnit within an org:Organization:
{
"@type": "org:Organization",
"@id": "https://apercue.ca/org#org",
"skos:prefLabel": "Research Pipeline Organization",
"org:hasUnit": [
{
"@type": "org:OrganizationalUnit",
"@id": "https://apercue.ca/org#unit/Governance",
"skos:prefLabel": "Governance",
"org:hasMember": [
{
"@id": "urn:resource:ethics-approval",
"dcterms:title": "ethics-approval"
}
]
}
]
}
Types become departments; resources become members. The same typed graph that drives scheduling and compliance also projects as an organizational hierarchy.
The #AnnotationCollection pattern attaches structured notes to graph
resources using the W3C Web Annotation model:
{
"type": "AnnotationCollection",
"label": "Research Pipeline Review Annotations",
"total": 3,
"items": [
{
"type": "Annotation",
"motivation": "oa:assessing",
"body": {
"type": "TextualBody",
"value": "IRB protocol approved 2024-01-15",
"format": "text/plain"
},
"target": {
"type": "SpecificResource",
"source": "urn:resource:ethics-approval"
}
},
{
"type": "Annotation",
"motivation": "oa:commenting",
"body": {
"type": "TextualBody",
"value": "Data under embargo until publication",
"format": "text/plain"
},
"target": {
"type": "SpecificResource",
"source": "urn:resource:sensor-dataset"
}
}
]
}
Each annotation carries a motivation from the W3C vocabulary (assessing,
commenting, classifying). Targets are validated against the graph — an
annotation referencing a nonexistent resource fails at CUE evaluation time.
The #DataQualityReport pattern projects compliance and structural metrics
as DQV quality measurements:
{
"@graph": [
{
"@type": "dqv:Category",
"@id": "apercue:quality/Intrinsic",
"skos:prefLabel": "Intrinsic Data Quality"
},
{
"@type": "dqv:Dimension",
"@id": "apercue:quality/Consistency",
"skos:prefLabel": "Consistency",
"dqv:inCategory": {
"@id": "apercue:quality/Intrinsic"
}
},
{
"@type": "dqv:Metric",
"@id": "apercue:quality/CompliancePassRate",
"skos:prefLabel": "Compliance Pass Rate",
"skos:definition": "Percentage of compliance rules that pass",
"dqv:inDimension": {
"@id": "apercue:quality/Consistency"
}
}
]
}
Quality dimensions (Completeness, Consistency, Accessibility) organize
metrics computed from the graph. Each dqv:QualityMeasurement links to
its metric, dimension, and the dataset under evaluation.
17 specifications implemented, 1 downstream (in the infrastructure-specific extension). Adding a projection is adding a file, not modifying a framework.
Implemented (17):
| W3C Specification | CUE Produces |
|---|---|
| JSON-LD 1.1 | @context, @type, @id on all resources |
| SHACL | sh:ValidationReport from compliance/gap analysis + sh:NodeShape generation from graph types |
| SKOS | skos:ConceptScheme from type vocabularies, lifecycle phases, and hierarchical taxonomies with broader/narrower |
| EARL | earl:Assertion from smoke test plans |
| OWL-Time | time:Interval from critical path scheduling |
| Dublin Core | dcterms:title, dcterms:description, dcterms:requires on all resources |
| PROV-O | prov:Entity + prov:wasDerivedFrom from dependency edges; prov:Plan from charter gates with prov:Activity per gate |
| schema.org | schema:additionalType annotations via configurable type mapping |
| ODRL 2.2 | odrl:Set policies with permissions/prohibitions by resource type |
| Activity Streams 2.0 | as:OrderedCollection of Create activities from topology layers |
| Verifiable Credentials 2.0 | VerifiableCredential wrapping SHACL validation attestation |
| W3C Org | org:Organization with type-based OrganizationalUnits |
| VoID | void:Dataset with class/property partitions, linkset statistics, and vocabulary usage |
| Web Annotation | oa:Annotation with TextualBody, SpecificResource targets, and W3C motivations |
| RDFS | rdfs:Class and rdfs:subClassOf from graph type hierarchy with owl:ObjectProperty for dependencies |
| DQV | dqv:QualityMeasurement for completeness, consistency, and accessibility dimensions |
| DCAT 3 | dcat:Catalog with dcat:Dataset, dcat:Distribution, dcat:DataService, and dcat:theme from @type |
Downstream (1):
| W3C Specification | CUE Produces |
|---|---|
| Hydra Core | hydra:ApiDocumentation in quicue.ca operator dashboard |
_ancestors: {
[_]: true
if _hasDeps {
for d, _ in _deps {
(d): true
resources[d]._ancestors
}
}
}
Six lines. CUE resolves the fixpoint — the struct expands until merging produces no new keys, then stops. No explicit loop, no recursion depth tracking. This is the same mechanism as SPARQL property paths, but resolved statically.
for tname, _ in provider.types
if resource["@type"][tname] != _|_ {tname}
A resource with {Dataset: true, Governance: true} matches a data
repository (serves Dataset) AND an ethics board (serves Governance)
simultaneously. Set intersection, not registration. This is the CUE
equivalent of SPARQL ?resource a ?type pattern matching.
CUE constraints live in the same package as the computation:
sh:conforms: true // unification — false is ⊥
If a compliance check produces sh:conforms: false, unification with
true is bottom (_|_). cue vet fails. No assertion framework —
the language IS the constraint solver. SHACL validation becomes a type
error.
The same patterns have been validated across four independent domains:
| Domain | Resources | Patterns Used |
|---|---|---|
| Research data mgmt | 5 resources, 3 types | Provenance, embargo, scheduling |
| IT infrastructure | 30 nodes, 29 providers | Full stack (654 CLI commands) |
| University curricula | 12 CS courses | Critical path, compliance, charter |
| Construction PM | 18 work packages | 5 DAG gates, CMHC retrofit phases |
Same #Graph, same #CriticalPath, same #ComplianceCheck. The domain is
data; the patterns are generic.
@type as multi-context resource
identity — one resource participates in data governance, provenance,
scheduling, and semantic web contexts simultaneously via set
intersection..kb/ convention and ODRL/DCAT projections as
lightweight dataspace primitives with structural governance.
Each knowledge base entry validates against typed schemas at
evaluation time.