Re-visit Identifiers.org registration #6
Comments
|
@mbjones pointed out that our ROR ID is https://ror.org/00hr5y405 so we should probably use that in our Identifiers.org registration |
|
Here's what I propose we should register as a new resource:
|
|
IIRC this registration was created very early in the life of identifiers.org
and never utilized beyond a few test cases.
Considering identifiers.org is really a registration of identifier types,
I'm not sure it's a good fit for DataONE since we don't have an identifier
scheme, but rather run a resolution service.
Do we really want to promote a "d1id" identifier type?
Otherwise, this change makes sense if the overall goal is to eventually
deprecate the existing service interfaces.
- Dave
…On Wed, Feb 17, 2021 at 8:47 PM Bryce Mecum ***@***.***> wrote:
@mbjones <https://github.com/mbjones> and I were looking at our
Identifiers.org <https://registry.identifiers.org/> registration for the
d1id prefix <https://registry.identifiers.org/registry/d1id>. This is a
great thing to have. A couple of questions came up:
- Could the prefix be dataone instead or is there a good reason to use
d1ids?
- The URL Pattern set for the namespace is
https://cn.dataone.org/cn/v2/resolve/{{$id}}. Considering the PIRI
Service
<https://dataoneorg.github.io/api-documentation/services/piri_service.html>,
would changing this to https://dataone.org/datasets/{{$id}} make any
sense? The /resolve/ API endpoint has specific and narrow HTTP request
semantics and we could probably better serve identifier resolution
semantics within the PIRI service.
Thoughts or other ideas? ping @datadavev <https://github.com/datadavev>
@mbjones <https://github.com/mbjones>, all dev team folks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAETZYPYLFLUCKRBMN6IVSTS7RWTFANCNFSM4XZNJBTQ>
.
|
|
Hrm, not sure I totally follow you, @datadavev.
We established an identifier scheme under https://dataone.org/datasets/ last year. Do we still like that direction? One of the big limitations of how we do identifiers in DataONE is that our bare identifiers are not HTTP-resolveable. The PIRI space fixes that but does mean we have two identifiers for every object.
I see our identifier scheme as being a mostly separate thing from the service endpoints and I'm not sure how that relates to deprecating existing endpoints. Could you elaborate? |
|
Is DataONE generating the identifier value or using an identifier provided
by the content creator?
My impression of the PIRI service was as an alternative endpoint to the
resolve endpoint.
…On Wed, Feb 17, 2021 at 9:18 PM Bryce Mecum ***@***.***> wrote:
Hrm, not sure I totally follow you, @datadavev
<https://github.com/datadavev>.
since we don't have an identifier scheme, but rather run a resolution
service
We established an identifier scheme under https://dataone.org/datasets/
last year. Do we still like that direction? One of the big limitations of
how we do identifiers in DataONE is that our bare identifiers are not
HTTP-resolveable. The PIRI space fixes that but does mean we have two
identifiers for every object.
this change makes sense if the overall goal is to eventually deprecate the
existing service interfaces.
I see our identifier scheme as being a mostly separate thing from the
service endpoints and I'm not sure how that relates to deprecating existing
endpoints. Could you elaborate?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAETZYMJFVBUII6P3Q5BLATS7R2GTANCNFSM4XZNJBTQ>
.
|
|
The reason I am pursuing this is that I think we need a location-independent resolution scheme for DataONE identifiers that don't have another resolution scheme. If I think the This would also make resolution independent of the partocular service API version that is installed, which would improve resolution stability. |
|
I agree that d1id was a poor choice for an identifier scheme label, at the
time there was encouragement for brevity.
In anycase, I don't doubt the benefit of a DataONE specific scheme. It is
necessary for practical recognition of the many identifiers that can't be
resolved except through the DataONE service. Just not sure how it's going
to work, particularly with existing identifiers in DataONE. Will they all
be prefixed with "dataone:"? Perhaps only some? What about a DataONE PID
that looks like a DOI but doesn't resolve using the DOI infrastructure? Do
we check to see if an identifier resolves according to its apparent scheme
and apply a dataone: prefix if not? Perhaps the PIRI service should
delegate to known resolvers, or at least advertise their availability for
known identifier schemes (the http link headers are good for this)?
…On Wed, Feb 17, 2021 at 9:39 PM Matt Jones ***@***.***> wrote:
The reason I am pursuing this is that I think we need a
location-independent resolution scheme for DataONE identifiers that don't
have another resolution scheme. If dataone:{pid} were to resolve to
https://dataone.org/datasets/{pid}, it would provide a nice, compact way
for citing non-DOI identifiers that has a stable resolution URL. So I view
this as a way to formalize our resolver and tie it into the
well-established identifiers.org system of resolvers.
I think the d1id was a strategically poor choice -- its difficult to
remember or identify. So I thought that adding another 'Resource' at the
dataone prefix was a chance to update our resolution URL as well. But I
also think we should update the d1id endpoint URL in the off chance that
people have used it somewhere in a publication.
This would also make resolution independent of the partocular service API
version that is installed, which would improve resolution stability.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAETZYM632CESI4WNC7YYWLS7R4WDANCNFSM4XZNJBTQ>
.
|
|
For DOI PIDs, we currently link the citation to the DOI resolver, but for everything else we link to the |
|
Oh, and as a side comment: we could switch to linking to the identifiers.org resolver for all PIDs, including DOIs and ARKs, because identifiers.org does know how to resolve those identifier types as well. So our citations might link out to:
|
@mbjones and I were looking at our Identifiers.org registration for the
d1idprefix. This is a great thing to have. A couple of questions came up:dataoneinstead or is there a good reason to used1ids?https://cn.dataone.org/cn/v2/resolve/{{$id}}. Considering the PIRI Service, would changing this tohttps://dataone.org/datasets/{{$id}}make any sense? The /resolve/ API endpoint has specific and narrow HTTP request semantics and we could probably better serve identifier resolution semantics within the PIRI service.Thoughts or other ideas? ping @datadavev @mbjones, all dev team folks
The text was updated successfully, but these errors were encountered: