Cater for ontology dependencies

[nicholascar]

• owl:imports
• prof:isProfileOf
  • if this property is found, we should infer owl:imports
• alignments to other ontologies
• normal sub-classing/sub-propertying
  • will infer owl:imports

[nicholascar]

@rob-metalinkage: can you assist?

[rob-metalinkage]

Ontologies may have several possible relationships that are important to understand the context.

owl:imports is an obvious one to handle by default - and an import diagram is useful to contextualize the ontology before description of the contents. (e.g. https://www.researchgate.net/publication/320064335_Reusing_Domain_Ontologies_in_Linked_Building_Data_The_Case_of_Building_Automation_and_Control)

The simplest pattern he is Ontology O imports P,Q,R (show only direct imports).

Often the transitive import chain is relevant - as per the example cited above. This should be a DAG (Directed acyclic graph) but its possible that imports may form a cycle -

c,f Jena docs "Imports are processed recursively, so if our base document imports ontology A, and A imports B, we will end up with the structure shown in Figure 4. Note that the imports have been flattened out. A cycle check is used to prevent the document handler getting stuck if, for example, A imports B which imports A!"

The third nuance is that a custom diagram may be supplied - for example SSN https://www.w3.org/TR/vocab-ssn/#Modularization

There may be more specific relationships not handled by owl:imports - such as versioning (adms:previous) - are these handled already? Some such properties may be declared as owl:subPropertyOf owl:imports - but its probably not worth looking at this is you have a generic mechanism to include specific relationships

The one of key interest is prof:isProfileOf - this implies an owl:import but has much more semantic information and should be diagrammed separately, before the owl:imports diagram. Alternatively profileOf should be shown as emphasised links in the import diagram.

relationships via PROV-O (wasDerivedFrom, etc) are also very important - ability to use an optional provenance graph or embedded prov:Activity objects would be useful.

Alignments to other ontologies are important - but if these are separately modelled as in SSN/SOSA they are inbound references, so pyLODE will need help discovering these.

What seems necessary is support for a generalised pattern of being able to configure property chains for relationships and to understand when these are specialisations to avoid duplicates.

These should be a chain of configurations - and generated diagrams presented in the order the configurations are chained.

To enable it is neccesary to invoke the tool with options to include an arbitrary number of additional graphs.

To recap - these are the key patterns

A owl:imports B A owl:imports B (owl:imports C etc) with cycle detection Alignement X (A,B) owl:imports A,B A prof:isProfileOf B (prof:isProfile of C) prov:Activity P ?p B ( where P prov:wasGeneratedBy A and B a owl:Ontology) - need to play with this - Nick?