Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

lightweight adoption of owlstar graph-level annotations

Đang mở
  • Có gì không ổn?
#114 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
scala
Lĩnh vực
data

Hướng nghiên cứu

Issue không nêu tên tệp, test hoặc entry point nào; hãy bắt đầu bằng việc xem xét hành vi chú thích và tuần tự hóa hiện có của relation-graph và ubergraph. Cần có phạm vi triển khai cụ thể và các test cho siêu dữ liệu cấp đồ thị cũng như khả năng áp dụng của truy vấn client trước khi việc này sẵn sàng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?

Ngôn ngữ chính
Scala
Star
24
Fork
4
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của INCATools/relation-graph

Tất cả issue của INCATools/relation-graph

Issue tương tự

Thêm issue về Scala

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.