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

.entities() typedef update #690

Open
joeflack4 opened this issue Dec 19, 2023 · 2 comments
Open

.entities() typedef update #690

joeflack4 opened this issue Dec 19, 2023 · 2 comments

Comments

@joeflack4
Copy link
Contributor

joeflack4 commented Dec 19, 2023

Overview

Currently, the return type definitions for .entities() methods are inaccurate. it says Iterable[CURIE], but it is also possible for it to return "quoted URIs" (example: <http://identifiers.org/hgnc/10004>).

Possible solutions

a. Fix so that URIs, not quoted URIs are returned, and update type def Union[CURIE, URI]
b. Add new type for quoted URIs and update type def Union[CURIE, QUOTED_URI[
c. IDENTIFIER

  • rename CURIE to IDENTIFIER, such that this is used universally in signatures. This will be a large diff, but it will not affect runtime
  • Formally define this as IDENTIFIER = CURIE | QUOTED_URI. Again, this is typing information that does not affect runtime, but it helps make the intentions clear

Additional details

Context / discussion

Chris:

The intent is that CURIEs are input and output. Yes, I know that when using semsql URIs that have no prefixes get turned into quoted URIs (different from URIs), but this should be fixed elsewhere.

Joe:

I guess you're right, they are "quoted URIs". Here's an example of one I see:

'<http://identifiers.org/hgnc/10004>'

Why don't we add something like QUOTED_URI to oaklib.types?:

CURIE = str
QUOTED_URI = str
URI = str

When you say "should be fixed elsewhere", I assume you are referring to them being "quoted" URI strings rather than plain URI strings. I'm definitely down with that. If you mean that URIs should never be returned (you probably don't), I don't think that's possible 100% of the time.

Related

@joeflack4 joeflack4 linked a pull request Dec 19, 2023 that will close this issue
@joeflack4
Copy link
Contributor Author

I'm partial to doing (b) now via #688, and then doing (a) later, unless (a) can be done in the near term.

@joeflack4
Copy link
Contributor Author

I think we are favoring solution 'c'.

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 a pull request may close this issue.

1 participant