PR #84 adds a hasFormat relation (dct:hasFormat/isFormatOf) to link Building Blocks that are alternate-format siblings of the same content — e.g. a JSON and an XML serialization of the same model. It's a good, minimal addition following the existing dependsOn/isProfileOf pattern, but it surfaces a broader modeling question worth discussing before this pattern proliferates further.
Right now a "family" of related bblocks is expressed as a graph of pairwise, symmetric, manually-declared relations: dependsOn, isProfileOf, and now hasFormat/seeAlso. Each one is a bolt-on with the same boilerplate (bblocks:// URI normalization, schema property, JSON-LD context mapping), and nothing enforces the symmetry that hasFormat requires — it's declared as a convention ("list it on every sibling"), not checked. Two siblings can drift out of sync with no validation error.
hasFormat in particular feels like it may be compensating for a missing primitive rather than the right shape for "same content, different format". OGC API practice already has a name for this: an abstract resource model with multiple per-encoding requirement classes within a single specification — which is close to what bblocks' own requirementClasses field already does at the single-bblock level. So the open question is:
- Should "alternate format" be a relation between separate bblocks at all, or
- should a bblock be able to declare itself as one encoding/perspective of a shared abstract model — with JSON, XML, etc. as views that share identity (same semantics, ideally the same test cases) rather than siblings linked after the fact?
The second framing would make correctness checkable (e.g. uplift both formats and assert equivalent RDF) instead of resting purely on author convention, and would avoid an ever-growing set of pairwise relation types as new kinds of "family" membership come up.
Opening this to discuss before hasFormat sees wider adoption across registers — not blocking #84, which is a reasonable step either way.
cc @fmigneault @rob-metalinkage
PR #84 adds a
hasFormatrelation (dct:hasFormat/isFormatOf) to link Building Blocks that are alternate-format siblings of the same content — e.g. a JSON and an XML serialization of the same model. It's a good, minimal addition following the existingdependsOn/isProfileOfpattern, but it surfaces a broader modeling question worth discussing before this pattern proliferates further.Right now a "family" of related bblocks is expressed as a graph of pairwise, symmetric, manually-declared relations:
dependsOn,isProfileOf, and nowhasFormat/seeAlso. Each one is a bolt-on with the same boilerplate (bblocks:// URI normalization, schema property, JSON-LD context mapping), and nothing enforces the symmetry thathasFormatrequires — it's declared as a convention ("list it on every sibling"), not checked. Two siblings can drift out of sync with no validation error.hasFormatin particular feels like it may be compensating for a missing primitive rather than the right shape for "same content, different format". OGC API practice already has a name for this: an abstract resource model with multiple per-encoding requirement classes within a single specification — which is close to what bblocks' ownrequirementClassesfield already does at the single-bblock level. So the open question is:The second framing would make correctness checkable (e.g. uplift both formats and assert equivalent RDF) instead of resting purely on author convention, and would avoid an ever-growing set of pairwise relation types as new kinds of "family" membership come up.
Opening this to discuss before
hasFormatsees wider adoption across registers — not blocking #84, which is a reasonable step either way.cc @fmigneault @rob-metalinkage