You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor: expand a library's imports into manifest membership
Imports are followed when a library is added rather than resolved again on
every validation, so a manifest is an explicit and complete list: what
library_names shows is exactly what the model is compiled and validated
against, with no resolution step in between that could add or drop a
graph.
model.manifest.add(shapes_lib) # owl:imports Brick
model.manifest.library_names
# ['https://brickschema.org/schema/1.4/Brick', 'urn:my/shapes']
add() takes import_depth with OntoEnv's own meaning -- -1 (default) for
the full closure, 0 for the named library alone, 1 for it and its direct
imports. For a library OntoEnv knows the names come from list_closure, a
name lookup rather than a graph build; for one it does not know (a
directory-loaded library, named after its directory) the same walk runs
over that library's own shape collection, which is where its owl:imports
live. Removal does not cascade: dropping the shapes library leaves Brick
a member, because the manifest is a flat set that reads as what it is.
This replaces the manifest-rooted closure from the previous commit.
Manifest.register() and imports_closure() are gone, and with them the
write-on-a-read-path -- validating no longer registers the manifest graph
with OntoEnv. Manifest.shapes_graph() is now the union of the members'
shape collections, so validation sees each library's *own* stored graph,
including whatever SHACL inference added when it was loaded, rather than
OntoEnv's separately stored copy of the same ontology. That divergence
measured zero triples on every library at hand, but it is now structurally
impossible rather than merely unobserved.
shapes_graph() still asks OntoEnv the one question resolve_imports always
asked -- is anything imported here unaccounted for? -- once over the union
instead of once per collection. Expansion normally makes the answer no; it
catches a library reloaded with new imports since, or one added with
import_depth=0. It raises OntologyImportsNotFound unless
error_on_missing_imports=False.
Consequence worth knowing: compile() now infers against everything the
members import, because those are members. The previous commit deliberately
kept them out of the inference input; complete membership makes that
distinction unavailable, which is the point of the design.
Full unit suite: 572 passed, 1 skipped.
0 commit comments