DOME 4.0 must have a scheme for defining persistent identifiers for identifiers, below we detail some of the possibilities to be investigated.
Seeking for improvements:
No info in the IRI. No taxonomies. Except for best practices.
No filenames in IRIs. (ironically, the opposite is a very common occurrence).
Let JSON-LD handle some things.
An improved possible permanent resource address scheme could be:
METADATA (dereferenceable IRIs)
Note: Metadata id(@id) refers to itself.
Dataset
<dome-domain>/dataset/<uuid> _for the dataset metadata_
Data files
<dome-domain>/distribution/<content-hash=id> _for that data file metadata_
DATA (in distribution)
<dome-domain>/data/<content-hash=id> _the actual data file (for an API)_
<dome-domain>/download/<content-hash=id> _the actual data file (for a Web client)_
The idea is that the scheme will hold as we will always have "datasets" and "datafiles".
Anything beyond the id can be added (centralised) via the JSON-LD semantic context. So we can improve it to be even more general:
(The RDF DB or a JSON-LD processor will complete the IRIs)
DOME 4.0 must have a scheme for defining persistent identifiers for identifiers, below we detail some of the possibilities to be investigated.
Seeking for improvements:
An improved possible permanent resource address scheme could be:
METADATA (dereferenceable IRIs) Note: Metadata id(@id) refers to itself.
DATA (in distribution)
The idea is that the scheme will hold as we will always have "datasets" and "datafiles".
We had:
Anything beyond the id can be added (centralised) via the JSON-LD semantic context. So we can improve it to be even more general: (The RDF DB or a JSON-LD processor will complete the IRIs)
It coud be like:
Some info/references:![identification of resources - by http-URIs](https://user-images.githubusercontent.com/90273055/165748453-ea738f4e-af3a-4fa4-9b07-ccfe497d3e90.png)
e.g. Study on persistent URIs (EU)