-
Notifications
You must be signed in to change notification settings - Fork 5
Description
While RG is awesome, some things I worry about:
- it requires a fair bit of tacit knowledge to understand both the operations and the relevance of the target output (materialized existential relations)
- there is no metadata in the derived graph that tells machines how to interpret the triples
I think the use of a README works fine in a local context but things can potentially get confusing when RG triples are remixed back into triples following the standard OWL-RDF serialization. This also has implications for ubergraph - the knowledge that certain queries are transferrable from ubergraph to other triplestores is currently also tacit, rather than having queryable metadata in the triplestore.
I think this could be mitigated by the adoption of some kind of standard. As far as I know the closest we have is https://github.com/cmungall/owlstar
The main anticipated use of owlstar is to annotate individual triples with OWL interpretations, as an alternative to the standard OWL-RDF mapping. Now obviously this would result in massive inflation in size of already massive turtle files (somewhat less if turtlestar is used, but still).
However, there are other ways to achieve the same thing, for example, annotating the graph the triples are contained in; e.g.
<g> os:hasTriplePattern os:SubClassOfSomeValuesFrom , os:TypeSomeValuesFrom, os:SubClassBetweenNamedClassesthis graph-level mechanism would also be a good way of communicating other tacit knowledge about the graph - e.g. that it must include reflexive entailed axioms, that materialization was performed for a certain subset of triples (this bleeds into OMO work, cc @matentzn).
The metadata can be probed by clients to determine if certain kinds of queries are applicable. It can also serve as a mechanism for humans to go and lookup in a standard place what we mean by a triple UBERON:1 BFO:2 UBERON:3
We may still want to switch off graph-annotations by default (it is handy in local contexts to assume that all triples represent edges)
There would still be work to do - e.g algebra of compositions for merging different RGs. But this can come later.
There may be other ways to do this - e.g SHACL shapes?