Rules for manifestation identifiers and URLs #23
Description
arxiv example provided https://github.com/skg-if/context/blob/b7b76907cea1c96b7b82b9114ff8fe9165097a0c/ver/1.0.1/samples/example-research-product.json in arxiv
opencitation example https://github.com/skg-if/examples/blob/main/OpenCitations/oc_1.jsonld on a journal
Question 1 :
I understand the main uses cases that are behind the manifestation are about deduplication (occuring in SKG systems aggregator, like OpenAire)
- on the arxiv example the root doi is the journal doi: is this a rule for aggregators to point to the official journal doi, which would be the resolvable one ?
- In Open citation example the aggregator the omid is repeated in the manifestation and at the root of the research product.
Is it the expected behaviour for all aggregators ?
Most systems in OSTrails are not deduplicating... they store single entities, single manifestation and venue.
- what if we implement SKG-IF on a catalog that is not deduplicating anything, for example a dataset catalog with datasets
- what if we implement SKG-IF on a catalog that is not deduplicating anything, for example a preprint server (that does not know where the last official version is )
Are there rules we would need to enforce ?
Question 2 :
when you /resolve a doi. (API)
- do you always "resolve" it at the root or at the manifestation level ?
- do you always return all manifestations or are you free to return what you want ?
Question 3 :
I understand there is a non written expectation, that each manifestation should have a single unique resolvable http URL (readable by humans). The manifestation is always a web page web can resolve on the web, on all examples provided.
Does it make sense to have a manifestation with an empty manifestation.identifiers ? (where we find these web URLs at the moment)
These questions are important because we are, in OSTrails, trying to link our http systems/catalogues as Manifestations for Datasets. If there are "obvious" rules related to URLs or identifiers, it would be good to have them.
- Some Dataset use cases are easy and match the "literature" pattern ( examples of Dataset Manifestation are analysed here for OSTrails : https://cloud.esrf.fr/s/PBkwFkgQJw9kxCS )
- some are more complex edge cases that may not fit the manifestation.
sorry a lot of questions today ;-)