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

Content identifiers: what we call them, what formats we support #8

Closed
cboettig opened this issue Feb 17, 2020 · 5 comments
Closed

Content identifiers: what we call them, what formats we support #8

cboettig opened this issue Feb 17, 2020 · 5 comments

Comments

@cboettig
Copy link
Owner

@jhpoelen I've noticed that hash-archive.org appears to support the kitchen sink of content identifiers:

It seems to support the 5 different hash types in #1 for all of these, though it looks like some are hex, some are base64, and (multi-hashes is weirdly base58 encoded). Some of these seem to be 'just' standards posted on a GitHub repo, others maybe have more recognition (e.g. the W3C scheme), though all meet the core desiderata of Trask's Hash URI proposal (unsalted hashes which also specify the algorithm needed in the name).

I'm partial to the Hash URI format still, though I feel I could maybe be convinced that following something like Subresource integrity would be the best way not to reinvent the wheel? I don't really have a principled argument for preferring one or the other.

@jhpoelen
Copy link
Collaborator

I think using base64 is problematic because of the casing: transcription, indexing, file systems are all possible issues when using case sensitive identifiers. DOIs are explicitly case insensitive (see https://www.doi.org/doi_handbook/2_Numbering.html#2.4 ) .

Also, the Ben Trask "hash uri" fits nicely into "url" fields (like Zenodo's related references) and are likely familiar to anyone that knows about urls.

In addition, we already have a giant corpus of biodiversity datasets described in many provenance logs using hash://sha256/xxx format . This corpus can be used to bootstrap development of registries and stores that can scale to reasonable levels.

This is why I'd like to stick with the hash://sha256/xxxx format.

@cboettig
Copy link
Owner Author

💯 👍

@cboettig
Copy link
Owner Author

Related to this, do we also stick with calling these things "hash URIs" (as you noted in #3, W3C has given that term a different meaning)? Other options:

  • content URIs
  • content hash URIs
  • content based identifiers

I suppose content URI is best, it matches the name of the package and preserves the notion that the format we are using is the URI format and not one of the others given above. However, in the documentation, I'm leaning towards calling these 'content-based identifiers' as something a bit more tangible to readers unfamiliar with "URI" as the term of art?

@jhpoelen
Copy link
Collaborator

I much like your idea to use "content-based identifiers" in the documentation. With that, a hash://sha256/... is an example of a content-based identifier. As far as giving this content hash uri (or URI, content URI, or hash uri) a name, . . . time will tell . I ok with using content uri for now and am trying to keep an open mind.

@cboettig cboettig changed the title Content idenfiers: what we call them, what formats we support Content identifiers: what we call them, what formats we support Feb 20, 2020
@cboettig
Copy link
Owner Author

Sounds like we have consensus so closing this out!

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

No branches or pull requests

2 participants