-
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 issue tracker item to SSSOM datamodel #259
Conversation
@matentzn - do you define the type "uri" in your schema outside of linkml_types? I don't think we have plain "uri" as a type. You can define it more rigorously as just a "uri" in your model (with all the regex you want to restrict that). |
Is the intent that this would be a new field in the file where you could attach an issue URL to an individual mapping (e.g. a single row in the tsv file) or is this intended to be a new item in the header to point to the location of an issue tracker for the mapping project? I could see where either would be useful but it wasn't clear to me from the description. I would also hope that if the field is for each mapping that this field is optional since we don't usually have issues for each mapping. |
@sierra-moxon thank you for your feedback, very much appreciated - what is the correct linkml type for URLs (rather than resources)? @sbello thank you very much for your feedback. No SSSOM field aside subject, predicate, object and justification will ever be required. This is totally optional! |
What do you think about the name of the element, see first comment above? |
Despite a desire to have a short label, I think 'issue' is too ambiguous. Possibly 'tracker_item', a bit shorter and I think still reasonably clear. |
Some other options:
And, in a pinch, |
found the schema doc for LinkML types: https://linkml.io/linkml-model/linkml_model/model/schema/types.yaml -- it looks like we've got the types you're looking for! |
Thank you @sierra-moxon, @sbello and @gaurav I think we should opt for the more verbose "issue_tracker_item", just because the issue tracker URLs are anyways super long, so a long element name wont really make much difference, and I kind of like the fact that it's not too ambiguous. If you think I am wrong, let me know! @sierra-moxon thanks for sharing the type spec. Do I see this correctly then that |
This separetes the use of issue trackers as a whole and specific issue tracker items.
I will leave this open until Monday night (31st July), then I will merge so I can add this to the OAEI report. Thanks @gouttegd for your suggestions and review! |
Fixes #78
docs/
have been added/updated if necessarymake test
has been run locally