Specification for Management of URI identified resources

[TShapinsky]

Graph:

• Adopt the definition that a graph is a file with a single owl:ontology

Places where graphs are used:

• Models (Model graph and model shape collection)
• Libraries (Shape collection)
• Resolving Imports

Models:

• Models have two graphs, one representing the model and one representing the validation rules for said model.
• Model graphs contain an ontology that does not need to be unique.
• Models are unique from their name and primary key id

Libraries:

• Libraries contain a single graph as the shape collection.
• Libraries are unique by their URI
• Currently library names as the ontology name if loaded from ontology file or directory name if loaded from a directory.
  • perhaps libraries should adopt the name conventions laid out in the following section to allow for easy use of multiple versions

Import resolution:

• When a owl:imports statement is read a request is sent to an ontology caching back end
• The backend attempts to resolve the import locally first
• If the requested ontology does not exist locally an attempt is made to download the ontology at the URI in the import statement if the URI is a valid URL
• Locally cached ontologies are indexed by the URL which was used to import/download the ontology file, not URI of the ontology defined in the file.

[TShapinsky]

@gtfierro I think I got most of the things we talked about yesterday. If I missed anything feel free to edit the issue. I think you should have access to the comment.

[gtfierro]

Looks great! Two things:

When a owl:imports statement is read ...

We should be specific on when these owl:imports statements are read. I think they should be read:

• during inference (Model.compile)
• during validation (Model.validate)
• and that might be it?

Locally cached ontologies are indexed by the URL which was used to import/download the ontology file, not URI of the ontology defined in the file.

Technically these should be the same. A concrete example for people reading this later: the Brick ontology can be downloaded from https://brickschema.org/schema/1.4/Brick (once I fix the Brick website), and the graph you download contains this triple

<https://brickschema.org/schema/1.4/Brick> a owl:Ontology .

However the triples inside the file all exist in the Brick namespace:

<https://brickschema.org/schema/Brick#Temperature_Sensor> a sh:NodeShape .

[TShapinsky]

Interesting, I had it in my mind that the ontology would always be the prefix for most of the graph. But it seems like it pretty much just refers to the file.

There is one edge case that comes to mind, I can download the brick ontology from https://brickschema.org/schema/Brick but the version downloaded from that url defines the ontology https://brickschema.org/schema/1.3/Brick

[gtfierro]

There is one edge case that comes to mind, I can download the brick ontology from https://brickschema.org/schema/Brick but the version downloaded from that url defines the ontology https://brickschema.org/schema/1.3/Brick

Yes, this is a "bug" due to an error in the Google Domains -> Squarespace migration. It should be fixed soon, but generally, the URL of the ontology (the versionless "schema/Brick...") should point to the latest stable version