lightweight adoption of owlstar graph-level annotations
まだ誰も着手していません。
評価
調査の方向性
この issue ではファイル、テスト、エントリーポイントが示されていないため、まず既存の relation-graph と ubergraph のアノテーションおよびシリアライゼーションの動作を確認してください。これを準備完了とするには、グラフレベルのメタデータとクライアントクエリの適用可能性に関する、具体的な実装範囲とテストが必要です。
索引モデルが issue の本文から書いたものです。
説明
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?
- 主要言語
- Scala
- スター
- 24
- フォーク
- 4
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
INCATools/relation-graph のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
INCATools/relation-graph#270 ·
-
include RBoxオープン
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
INCATools/relation-graph#195 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
INCATools/relation-graph#155 · コメント 5 件 · リアクション 1 件 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
INCATools/relation-graph#152 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
INCATools/relation-graph#130 · コメント 4 件 ·
INCATools/relation-graph の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
bug 🐞 Untriaged user issue
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
valkey-io/valkey-glide#7443 ·
メンテナーはふだん 1 日以内に返信
-
OpenAPI: PowSolutions requires pk, w and d, but a V2 solution needs only n対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンA-api C-bug S-ready-for-human
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
ergoplatform/ergo#2851 ·
メンテナーはふだん 2 日以内に返信
-
? - Needs Triage audit_4.2.0 feature request test
難易度 2/5 1〜3時間 初心者へのやさしさ 87/100
NVIDIA/cudf-spark#16614 ·
メンテナーはふだん 1 日以内に返信
-
bug unit testing velox backend
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信