-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add new slot "mapping_status" (mapping lifecycle) to SSSOM core model #347
Conversation
subject_id predicate_id object_id mapping_justification author_id mapping_date status comment | ||
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0009-0001-6090-9959 2023-12-01 draft | ||
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0000-0002-2934-5497 2024-01-03 reviewed Looks Ok but let's check with Piers | ||
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0000-0002-2568-59457 2024-01-10 approved Mapping has been approved by Pier and team. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get what's the difference between approved and published based on this example, also this doesn't match the enum values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is commonly a delay between approval and the actual release, which may be phased with other items or on pre-defined calendar dates.
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0009-0001-6090-9959 2023-12-01 draft | ||
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0000-0002-2934-5497 2024-01-03 reviewed Looks Ok but let's check with Piers | ||
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0000-0002-2568-59457 2024-01-10 approved Mapping has been approved by Pier and team. | ||
alum8:Marsh-or-wetlandsaline skos:exactMatch get:groups/MFT1.3 semapv:ManualMappingCuration orcid:0000-0002-2934-5497 2024-01-13 published |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the mapping is in a document, then it's published, so not really sure why this even exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That view may hold in amongst developers, but not in the statutory (government) sector or even amongst academics (who regularly withhold information 'until the journal article appears').
Overall I think this is a weak proposal. It increases complexity of the format while being sort of redundant of several things that already exist. Why not use some of the fields where you can put whatever arbitrary metadata you want to facilitate this for the minority of users who might want to use it? I think we will keep getting more and more requests to add arbitrary enums/metadata fields based on single use cases, and I want to oppose these |
My main problem with this is that it’s not merely just an addition of a field (that in itself wouldn’t be a big deal), it’s an addition that changes a rather important aspect of the format. Until now, any single mapping record (i.e. “row” in the TSV format) is “standalone” – the record contains all the metadata needed to evaluate it and decide what to do with it. No need to look anywhere else in the mapping set to make a decision. With that change, for every mapping I now need to check if there’s another record further down in the set for the same triple {subject, predicate, object} but with a different status (in particular, with a status of I am not fundamentally opposed to that, but I do feel this requires more consideration. In particular, if the idea is to “provide the metadata for the client to make the decision about "which records are valid"”, then the specification needs to be much more clear about how that decision of “which records are valid” should be made. Otherwise we run the risk of ending up with a format that is interoperable in name only, because each implementation will have its own logic to determine the validity of records. |
A bit unfortunate, but closing this PR here. Please move discussion back to #345 |
Resolves #345
docs/
have been added/updated if necessarymake test
has been run locallyIf you are proposing a change to the SSSOM metadata model, you must
examples/
see_also
field of the linkml modelsee_also
field of the linkml modelThis is a draft PR adding a
mapping_status
metadata field to the SSSOM core model to describe the life cycle phase a specific mapping is in. Please use the issue for general discussions, and the PR only about specific suggestions.