Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Should we allow the use of URI syntax in SSSOM tables? #51

Closed
matentzn opened this issue Feb 6, 2021 · 10 comments
Closed

Should we allow the use of URI syntax in SSSOM tables? #51

matentzn opened this issue Feb 6, 2021 · 10 comments

Comments

@matentzn
Copy link
Collaborator

matentzn commented Feb 6, 2021

To be self contained, the tsv format metadata should provide a curie map - we will make this mandatory.

@wdduncan
Copy link

wdduncan commented Mar 2, 2021

I am working with the Darwin Core group on the Darwin Core to MIxS mappings. See this repo:
https://github.com/tdwg/gbwg

In their SSSOM spreadsheet, they have been using full URIs. Why do we want prohibit this?

cc @cmungall @raissameyer @pbuttigieg

@balhoff
Copy link

balhoff commented Mar 2, 2021

Should full URIs be enclosed in angle brackets, to make CURIE vs. URI obvious?

@matentzn
Copy link
Collaborator Author

matentzn commented Mar 2, 2021

Hmmmm... I dont know. Can I ask why? In the original proposal the whole point was to zone in on a terse, curie based representation for the tables that can be handled by standard python libraries.. I am for now slightly against this, but I can be convinced otherwise.

@balhoff
Copy link

balhoff commented Mar 2, 2021

Personally I find CURIEs frequently an unnecessary complication, but I haven't been much involved here so take my opinion with a grain of salt. :-)

@matentzn
Copy link
Collaborator Author

matentzn commented Mar 2, 2021

I personally agree with that as well - the amount of times I wrote curie-iri converters is uncountable :D I just feel that this is too much of burden to standardisation.. SSSOM plus some standard curie maps to refer to would allow a very easy way to compare stuff, and not bring us back into the country of UMLS cui vs OBO purl vs SCTID etc.. Lets see what @cmungall says..

@wdduncan
Copy link

wdduncan commented Mar 2, 2021

We can (of course) add a section to the SSSOM document that is used to define the URI to CURIE mappings.

@matentzn matentzn changed the title For TSV SSSOM, a curie map must be provided Curie map, IRI and CURIE use May 20, 2021
@matentzn
Copy link
Collaborator Author

The main idea of restricting to CURIEs is, correct me if I am wrong @cmungall, that the whole design of SSSOM revolves around the idea that the files should be easy to use for regular bioinformaticians - and URIs are considered an ugly distraction. I am super torn about the overhead for the semweb/obo community to having to provide prefixes each time they emit an sssom file..

One compromise could be that we are more permissive in sssom parse, basically allowing TSV files to be passed in that have IRIs, but spit out the proper, clean prefixed SSSOM files using the linkml curie map. What do you think @cmungall ?

@wdduncan
Copy link

wdduncan commented Jul 6, 2021

FYI for the DWC-MIXS mapping we re removing quotes from the curies.

cf. DWC issue (68)[https://github.com/tdwg/gbwg/issues/68]

@matentzn
Copy link
Collaborator Author

matentzn commented Jul 6, 2021

as long as it is valid yaml its fine

@matentzn
Copy link
Collaborator Author

In the workshop, we need to decide whether we should officially permit the use of IRIs in SSSOM or not. My sense is that parse should allow inputs with IRIs, but the canonical form should be in CURIE form. But I am happy to be convinced otherwise.

@matentzn matentzn changed the title Curie map, IRI and CURIE use Should we allow the use of URI syntax in SSSOM tables? Jun 3, 2022
@mapping-commons mapping-commons locked and limited conversation to collaborators Jun 3, 2022
@matentzn matentzn converted this issue into discussion #188 Jun 3, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

3 participants