Rethink how we model "family of formats" bblocks (re: hasFormat, PR #84)

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

Start by reviewing PR #84 and the existing dependsOn, isProfileOf, seeAlso, and hasFormat relation patterns. Compare those with the requirementClasses field and consider how alternate encodings, shared identity, symmetry, and equivalent RDF validation would be represented. Done means reaching and documenting a project decision before wider adoption.