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

`dependsOn`-derived dependency graph doesn't include `isProfileOf` targets

Đang mở
  • Có gì không ổn?
#83 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ó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
75/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
tooling

Hướng nghiên cứu

Bắt đầu trong ogc/bblocks/models.py tại BuildingBlockRegister.init và theo dõi cách đồ thị dependency cùng siêu dữ liệu dependsOn của register.json được tạo từ bblock.json, các tham chiếu schema/OpenAPI và extensionPoints. Kiểm tra với một profile isProfileOf-only rằng đồ thị hướng tới viewer và siêu dữ liệu được xuất có bao gồm target của nó mà không cần một dependsOn trùng lặp.

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

Mô tả

Summary

A Building Block that declares only isProfileOf (no dependsOn) renders with no visible
dependency graph in the viewer, even though it is related to another block. Blocks that are
pure profiles of a shared anchor - with no schema $ref to auto-detect, and no reason to
declare a literal dependsOn - currently have no way to show up in the graph without also
duplicating their isProfileOf target into dependsOn.

Root cause

In BuildingBlockRegister.__init__ (ogc/bblocks/models.py), the dependency graph and the
dependsOn metadata exposed in register.json are built only from:

  1. an explicit dependsOn in bblock.json,
  2. bblocks:// references auto-detected in the block's schema/OpenAPI document, and
  3. extensionPoints.baseBuildingBlock / extensionPoints.extensions.

isProfileOf is never folded in. Since isProfileOf is documented as "profiling is akin to
inheritance", it seems reasonable that a profile should also count as depending on what it
profiles for graph-visibility purposes, the same way an extension point does.

Workaround used in the meantime

In our register, we added an explicit, redundant dependsOn (pointing at the same target as
isProfileOf) to every profile block, purely so the graph renders. This works, but requires
every register author to remember to duplicate the two fields in lockstep, and semantically
overloads dependsOn for something that isn't really a runtime dependency.

Suggested fix

When building the dependency graph / exported dependsOn metadata, also include each block's
isProfileOf target(s) - either by merging them into the same dependsOn list, or by exposing
them as their own edge set that consumers (like the viewer) can render alongside dependsOn.
This would let a profile block be graph-visible from isProfileOf alone, without authors having
to declare a duplicate dependsOn.

Reference: working example of the workaround in
ogcincubator/bblocks-prov-jsonld-alt#5, where five isProfileOf-only profile blocks needed a
duplicate dependsOn added purely to appear in the viewer's graph. A related viewer-side fix for
rendering these relationships as dependents is in ogcincubator/bblocks-viewer#14.

Ngôn ngữ chính
Python
Star
1
Fork
6
Merge trung bình
23 giờ 43 phút
Pull request đã merge (30 ngày)
7

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

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

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 opengeospatial/bblocks-postprocess

Tất cả issue của opengeospatial/bblocks-postprocess

Issue tương tự

Thêm issue về Python

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.