Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update for latest changes of the SSSOM schema #552

Merged
merged 2 commits into from
Aug 9, 2024

Conversation

gouttegd
Copy link
Contributor

@gouttegd gouttegd commented Aug 7, 2024

This PR updates SSSOM-Py to prepare it for changes that either have already occurred or that will occur in the SSSOM schema:

  • the semantic_similarity_{score|measure} slots have been renamed to similarity_{score|measure};
  • the subject_id and object_id slots will no longer be unconditionally required, but instead will be required or not depending on the value of subject_type and object_type (something the generated Python class is unfortunately unable to enforce on its own, despite the proper rules expressed in the schema).

The `semantic_similarity_score` slot (and the accompanying
`semantic_similarity_measure` slot) has recently been renamed to
`similarity_score` in the tip of the master branch in the sssom-schema
repository.

That renaming causes the `TestUtils::test_get_dict_from_mapping` test to
fail, because that test expects that a mapping constructed from a
dictionary will contain `semantic_similarity_*` slots, which will not be
the case with newer version of the schema.

We update that test to automatically detect whether the SSSOM schema
defines a `semantic_similarity_score` slot (by looking at the
auto-generated `slots` class) and change its expectations consequently.

That way the test will work as expected regardless of the version of the
SSSOM schema we are testing against.
The SSSOM schema will soon no longer define the `subject_id` slot as
being inconditionally required. Instead, it will only be required iff
`subject_type` is not set to `rdfs literal`; if `subject_type` is set to
`rdfs literal`, it is `subject_label` that will be required instead.

Unfortunately, even though this variable constraint is formally
expressed in the SSSOM schema, the generated Python constructor does not
enforce it, and simply treat `subject_id` as a non-required slot.

This means that we can no longer rely on the Mapping constructor to
correctly flag mappings with a missing `subject_id`. Instead, we need to
perform a post-constructor validation by manually looking at
`subject_id` and `subject_type`. This is what we do here.

(All the above also applies, mutatis mutandis, to `object_id`.)
Copy link
Collaborator

@matentzn matentzn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, I didnt believe you would even touch sssom-py!! Much much much appreciated!!

@gouttegd
Copy link
Contributor Author

gouttegd commented Aug 8, 2024

I didnt believe you would even touch sssom-py

Not that I like that (you know my opinion on Python… right? :p ), but I am the one who pushed for this method of representing literal mappings, so the least I can do is help sorting the resulting issues.

@matentzn matentzn merged commit e89256f into mapping-commons:master Aug 9, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants