Summary
A Building Block that declares only isProfileOf (no dependsOn) renders with no visible
dependency graph in the viewer, even though it is related to another block. Blocks that are
pure profiles of a shared anchor - with no schema $ref to auto-detect, and no reason to
declare a literal dependsOn - currently have no way to show up in the graph without also
duplicating their isProfileOf target into dependsOn.
Root cause
In BuildingBlockRegister.__init__ (ogc/bblocks/models.py), the dependency graph and the
dependsOn metadata exposed in register.json are built only from:
- an explicit
dependsOn in bblock.json,
bblocks:// references auto-detected in the block's schema/OpenAPI document, and
extensionPoints.baseBuildingBlock / extensionPoints.extensions.
isProfileOf is never folded in. Since isProfileOf is documented as "profiling is akin to
inheritance", it seems reasonable that a profile should also count as depending on what it
profiles for graph-visibility purposes, the same way an extension point does.
Workaround used in the meantime
In our register, we added an explicit, redundant dependsOn (pointing at the same target as
isProfileOf) to every profile block, purely so the graph renders. This works, but requires
every register author to remember to duplicate the two fields in lockstep, and semantically
overloads dependsOn for something that isn't really a runtime dependency.
Suggested fix
When building the dependency graph / exported dependsOn metadata, also include each block's
isProfileOf target(s) - either by merging them into the same dependsOn list, or by exposing
them as their own edge set that consumers (like the viewer) can render alongside dependsOn.
This would let a profile block be graph-visible from isProfileOf alone, without authors having
to declare a duplicate dependsOn.
Reference: working example of the workaround in
ogcincubator/bblocks-prov-jsonld-alt#5, where five isProfileOf-only profile blocks needed a
duplicate dependsOn added purely to appear in the viewer's graph. A related viewer-side fix for
rendering these relationships as dependents is in ogcincubator/bblocks-viewer#14.
Summary
A Building Block that declares only
isProfileOf(nodependsOn) renders with no visibledependency graph in the viewer, even though it is related to another block. Blocks that are
pure profiles of a shared anchor - with no schema
$refto auto-detect, and no reason todeclare a literal
dependsOn- currently have no way to show up in the graph without alsoduplicating their
isProfileOftarget intodependsOn.Root cause
In
BuildingBlockRegister.__init__(ogc/bblocks/models.py), the dependency graph and thedependsOnmetadata exposed inregister.jsonare built only from:dependsOninbblock.json,bblocks://references auto-detected in the block's schema/OpenAPI document, andextensionPoints.baseBuildingBlock/extensionPoints.extensions.isProfileOfis never folded in. SinceisProfileOfis documented as "profiling is akin toinheritance", it seems reasonable that a profile should also count as depending on what it
profiles for graph-visibility purposes, the same way an extension point does.
Workaround used in the meantime
In our register, we added an explicit, redundant
dependsOn(pointing at the same target asisProfileOf) to every profile block, purely so the graph renders. This works, but requiresevery register author to remember to duplicate the two fields in lockstep, and semantically
overloads
dependsOnfor something that isn't really a runtime dependency.Suggested fix
When building the dependency graph / exported
dependsOnmetadata, also include each block'sisProfileOftarget(s) - either by merging them into the samedependsOnlist, or by exposingthem as their own edge set that consumers (like the viewer) can render alongside
dependsOn.This would let a profile block be graph-visible from
isProfileOfalone, without authors havingto declare a duplicate
dependsOn.Reference: working example of the workaround in
ogcincubator/bblocks-prov-jsonld-alt#5, where five
isProfileOf-only profile blocks needed aduplicate
dependsOnadded purely to appear in the viewer's graph. A related viewer-side fix forrendering these relationships as dependents is in ogcincubator/bblocks-viewer#14.