Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

lightweight adoption of owlstar graph-level annotations

Aperta
  • Qualcosa non va?
#114 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
scala
Ambito
data

Direzione di ricerca

La issue non indica file, test o punti di ingresso; inizia esaminando il comportamento esistente di annotazione e serializzazione di relation-graph e ubergraph. Prima che questo sia pronto, sarebbero necessari un ambito di implementazione concreto e test per i metadati a livello di grafo e l’applicabilità delle query del client.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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:SubClassBetweenNamedClasses

this 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?

Lingua principale
Scala
Stelle
24
Fork
4
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di INCATools/relation-graph

Tutte le issue di INCATools/relation-graph

Issue simili

Altre issue su Scala

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.