Allow inline_records to inline optional properties? #5

Closed
opened 2026-02-04 10:58:16 +00:00 by msz · 2 comments
Member

Currently, inline_records -p prop::pid_prop takes a record, takes its prop (if it can be found, lines 20-23) and does dictionary lookup for its pid_prop (line 28). This produces an error when pid_prop is not available.

datalink/query-rse-group@04cfed5fc7/query_rse_group/inline_records.py (L20-L28)

Consider a class such as Delegation for which both object and roles are optional, but both are good candidates for inlining. These would be two example objects:

{"schema_type": "dlthings:Delegation", "object": "ror:024z2rq82", "roles": ["http://purl.obolibrary.org/obo/OMRSE_00000087"]}
{"schema_type": "dlthings:Delegation", "object": "ror:02nv7yv05"}

Because of the above, inline_records -p delegation::object -p delegation::roles would produce error for the second record.

I would propose that the inlining should not produce an error if pid_prop is not found, similar to how it does not produce error if the entire prop is not found. In other words, it should do prop.get("pid_prop") and check whether the result is (not) None.

I would also propose to either make this the only behavior, or make it optional by introducing -p prop::?pid_prop notation (the ? meaning that missing pid_prop should be ignored). The latter is a little bit more complex to implement, but doable.

If the behavior change is desired, I would be happy to submit a PR for a preferred version.

Currently, `inline_records -p prop::pid_prop` takes a record, takes its `prop` (if it can be found, lines 20-23) and does dictionary lookup for its `pid_prop` (line 28). This produces an error when `pid_prop` is not available. https://hub.psychoinformatics.de/datalink/query-rse-group/src/commit/04cfed5fc75af89e89947e4e766f006da83c1267/query_rse_group/inline_records.py#L20-L28 Consider a class such as [Delegation](https://concepts.trr379.de/s/research-information/unreleased/Delegation/) for which both `object` and `roles` are optional, but both are good candidates for inlining. These would be two example objects: ``` {"schema_type": "dlthings:Delegation", "object": "ror:024z2rq82", "roles": ["http://purl.obolibrary.org/obo/OMRSE_00000087"]} {"schema_type": "dlthings:Delegation", "object": "ror:02nv7yv05"} ``` Because of the above, `inline_records -p delegation::object -p delegation::roles` would produce error for the second record. I would propose that the inlining should not produce an error if `pid_prop` is not found, similar to how it does not produce error if the entire `prop` is not found. In other words, it should do `prop.get("pid_prop")` and check whether the result is (not) None. I would also propose to either make this the only behavior, or make it optional by introducing `-p prop::?pid_prop` notation (the `?` meaning that missing `pid_prop` should be ignored). The latter is a little bit more complex to implement, but doable. If the behavior change is desired, I would be happy to submit a PR for a preferred version.
Owner

Makes sense!

Makes sense!
Author
Member

Which of the two options - do that always, or with prop::?pid_prop notation?

Which of the two options - do that always, or with `prop::?pid_prop` notation?
mih closed this issue 2026-02-23 10:41:21 +00:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
orinoco/query-things#5
No description provided.