Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alter the notion of import and store local #29

Open
nicholascar opened this issue Mar 10, 2022 · 0 comments
Open

Alter the notion of import and store local #29

nicholascar opened this issue Mar 10, 2022 · 0 comments

Comments

@nicholascar
Copy link
Collaborator

nicholascar commented Mar 10, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant