Alter the notion of import and store local

[nicholascar]

From the GSO v1.0 Introduction:

Although intended for general geoscience usage, a driving use-case for GSO is knowledge management for 3D geological modelling, specifically for the LOOP initiative (https://loop3d.org). This requires GSO to be easily deployable in internet-free environments, such as remote mining and field camps, and to be readily coupled with 3D modelling software. Compactness and efficiency are thus priorities, as is logical consistency to promote effective reasoning. For these reasons, GSO is a stand-alone product that does not import other ontologies. However, many modules consist of contents adapted from existing ontologies and exchange formats, with links to original sources added as annotations, e.g. some GeoSciML vocabularies are converted from SKOS to GSO and OWL. This adapt, versus import, approach not only avoids unnecessary bloat, but also addresses difficult challenges of conceptual misalignment between imports. Another factor is the strong research emphasis, which is facilitated by this compact approach: in addition to its goal of being an operational and useful knowledge structure, GSO is also a vehicle for developing and testing new ontological ideas with application to geology.

Sorry but I don't buy the logic of either or both "easily deployable in internet-free environments" and "Compactness and efficiency are thus priorities" necessitating "GSO is a stand-alone product that does not import other ontologies".

Firstly, almost nothing is, in fact, "internet free" these days. Even if it were, it is essentially no extra effort to include other ontologies dependencies as test files.

Secondly, GSO is clearly dependent on and import at least some elements from many ontologies - OWL, RDFS, scheme.org, Dublin Core. How could you perform reasoning without importing some/all of those, unless you just deferred your dependency to other sources of those ontologies' content like rulesets?

I suggest GSO declare its dependencies in a more obvious manner (not forcing me to read prefix statements) and then provide local copies of those dependencies if you really want to be offline.

---

The approach I've taken elsewhere, e.g. ICS, is to declare a whole Knowledge Graph that is the primary ontology and all supporting assets. See https://github.com/i-c-stratigraphy/geologic-timescale-kg.

Imports & dependencies are declared in a manifest (https://github.com/i-c-stratigraphy/geologic-timescale-kg/blob/master/rdf/manifest.ttl) so that the worst that can occur is offline operation with potentially out-of-date dependencies. Most dependencies like standard ontologies hardly ever change, so this is unlikely.

Following this approach, you can store version-locked forms of QUDT, the ICS chart etc. and use them with confidence.