Add subclass hierarchy knowledge to case_sparql_* commands #25
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With UCO's OC-65/CP-13, a subclass hierarchy for
ObservableObject
was defined. The CASE Python utilities have not to date used those subclasses, because of needing to define a mechanism to provide the subclass knowledge.The resolution of CASE AC-210 involved adding a monolithic ontology as a pre-built resource accompanying the
case_utils
package installation. This patch series uses that pre-built resource to build another resource: a file containing only the subclass hierarchy statements. This hierarchy is loaded by thecase_sparql_*
commands to support queries that use subclassing, i.e. with?someNode a/rdfs:subClassOf* ?someClass .
.One immediately visible impact of this patch series is to let
case_file
output objects that are of typeuco-observable:File
instead ofuco-observable:ObservableObject
. However, the support to build up to this one-line change tocase_file
now enables more transparent CASE support in this repository's provided CASE SPARQL tools.