Succession plan for Names 2 Things

[Mark Jordan]

Hi everyone,

As my institution moves closer to implementing ARKs as its general purpose PID framework, I would like to ask whether there has been any discussion of a succession plan for the Names 2 Things resolution service. In particular, what happens when CIDL chooses not to, or can no longer, support global-to-local resolution at https://n2t.net? Is there a formal succession plan in place like there would be for a TDR? If not, should there be?

I am asking this question from the perspective of an implementor who sees value in exposing https://n2t.net ARKs as persistent URLs to users to mitigate the risk of my local resolver needing to change its hostname (citing ARKs' resilience to organizational fragility, etc.). I don't foresee that either our local resolver or https://n2t.net going away any time soon, but I do foresee the need to make a decision about whether we expose global or local ARKs to users and having to justify that choice.

Mark

[chod...@gmail.com]

I believe that the unique value of the ARK community is rooted in the decentralized nature of our approach. So, from my perspective, all ARK implementations should be able to handle resolution themselves. However, I agree with you that we should have clarity on when/if formal plans are developed to support centralized options for our ARK implementations…and we should ensure that we have options. 

Regarding whether other options to N2T exist… I know that there are other organizations that can offer the kind of guarantees that you are looking for (eg identifiers.org). But I agree this shouldn’t be assumed just as you suggested that the availability of N2T shouldn’t be assumed. So this all needs to be discussed by the community. I happen to be on the ARK Alliance Advisory Board, a group focused on facilitating ARK community discussions and designs, and I will bring this to their attention. Feel free to also reach to other members of that committee, as well. That’s what it is here for! 

[Greg Janée]

An ARK resolver can be run locally for local purposes, and I suppose there have always been users doing that, but ARKs have also always been advertised as being universally resolvable à la Handles and DOIs and such. So, I would say that while ARKs have an existence that is somewhat independent of N2T (e.g., the ARK spec almost doesn't mention N2T at all), much of the value of ARKs relies on N2T existing.

Creating a viable, distributed, co-equal community supporting N2T is a tall order. But I think three things could lower the barriers to institutions joining the N2T co-op:

1. A clear statement of mission, purpose, and scope: to entice institutions to join, to make clear the obligations and resources required, and to ensure to potential institutions that the resource ask is limited.

2. Turnkey distributed technical infrastructure. CNRI's Handle System is the model to emulate here. They provide the software, and all you have to do is run it; you don't have to have any Java developers on your staff. It's not necessary for N2T to be distributed (either hierarchically like the Handle System or peer-distributed). There can continue to be one N2T resolver which multiple institutions agree to keep running, with some kind of succession plan as was asked about earlier in this thread. But there would be considerable advantages to having a distributed infrastructure, for then each resolver host would be equally engaged and committed to running the resolver system, and a failure or dropout of one institution/host would not trigger any existential emergency like we witnessed with the PURL system. For the technical WG I recently outlined an approach in which N2T, with minor changes, could be changed from a single global resolver, to a collection of distributed global resolvers that mirror each other via harvesting with no central coordination other than a GitHub page listing the resolvers. A little DNS wizardry could make this system look like a single resolver with redundancy/failover. So I think this part is doable. But the key is that it has to be turnkey.

3. An open source community supporting said turnkey software: to keep the software alive, but also to give potential institutions assurance that they're not going to be left unsupported.

CDL has somehow found the goodwill to host N2T for many years now; surely there are other institutions with similar convictions. But to get them engaged and committed, supporting N2T can't be a large or costly investment; it has to be relatively easy. I would imagine that once a couple other institutions join, the co-op might start looking attractive to a broader range of institutions, and would start to gain a kind of community essentialness that it doesn't quite have right now. And that in turn could attract developers to help out with an important open source project.

That's where I'd like to see N2T headed anyway.

-Greg

> --
> You received this message because you are subscribed to the Google Groups ARKs group. To post to this group, send email to arks-...@googlegroups.com. To unsubscribe from this group, send email to arks-forum+...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/arks-forum?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "ARKs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to arks-forum+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/56425edb-7dd0-4eb6-9e66-810f4a07742fn%40googlegroups.com.

[Donny Winston]

This has been actively discussed via https://wiki.lyrasis.org/display/ARKs/Advisory+Group :

The Advisory Group (AG) will provide a means for transitioning the ARK infrastructure (specification, NAAN registry) from the California Digital Library (CDL) to a community supported and managed activity. Planning is underway for an initial meeting of the group to review the goals, proposed timetable and roles drafted so far, as well as to launch working groups dedicated to pursuing objectives related to outreach, technical best practices, and sustainability. 

I don't know the current status / next steps. Any Advisory Group members want to hop in this thread?

--

You received this message because you are subscribed to the Google Groups ARKs group. To post to this group, send email to arks-...@googlegroups.com. To unsubscribe from this group, send email to arks-forum+...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/arks-forum?hl=en

---

You received this message because you are subscribed to the Google Groups "ARKs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to arks-forum+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/dbacd913-0aeb-4e5b-938d-6709fc1dc9b2n%40googlegroups.com.

--

Donny Winston, PhD (he/him/his)

Polyneme LLC

New York, NY

https://polyneme.xyz

[Dave Vieglais]

Hi Mark,
great question! There are currently three well known URLs for global ARK resolution:

• https://identifiers.org/
• https://arks.org/
• https://n2t.net/

Note however, that currently both identifiers.org and arks.org redirect to n2t.net for ARK resolution. As a consequence, N2T is a currently a single point of failure for global ARK identifier resolution. This is a problem, though one for which the technical aspects are being actively addressed through a progression of updates to the underlying infrastructure.

First, the ARK identifier resolution functionality of the N2T service is undergoing transition to a simpler, more sustainable implementation suitable for deployment at multiple locations. As a consequence, it is anticipated that multiple global ARK resolvers shall be available, potentially hosted by multiple institutions. With appropriate coordination and agreement, these services may operate under a single DNS name such as "n2t.net" or under multiple names including arks.org and potentially identifiers.org as well.

In addition, efforts are underway to simplify the ability of any local ARK resolver to support global resolution of ARK identifiers (regardless of NAAN) to the corresponding local resolver service. The eventual outcome being that ARK identifier resolution may be reliably available from any endpoint recorded in the NAAN registry with resources to offer such capability.

The combination of these adjustments in ARK resolver infrastructure will reduce the dependence on the need to express an ARK identifier as a URL tied to a specific service domain name such as "n2t.net".

There is of course still considerable benefit in presenting a consistent pattern for expressing any identifier as a URL to be a resolvable target. There are several options here, but it seems an appropriate practice is to use a service that is well known, reliable, performant, and has a good sustainability plan with consideration of handoff should there be a change in administration.

The specific recommendation for expression of ARK identifier resolution in a URL is one that should emerge from the ARK community, though with the upcoming updates to the ARK infrastructure it is anticipated that any of the aforementioned services may be able to offer equivalent capability for global ARK identifier resolution.

regards,
Dave Vieglais

[Greg Janée]

This all sounds great, Dave. Is there any web presence for this work? A page giving goals, architecture, milestones, status, future community roles, etc., or failing that, a GitHub repo? -Greg

> To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/7A762B50-2844-4711-B73A-B5EF6236A2F2%40vieglais.com.

[Mark Jordan]

Thanks everyone, this discussion is encouraging. Dave summarized the kernel of my query well with 'these services may operate under a single DNS name such as "n2t.net"'. What I would hope to see is a plan to sustain a resolver using that hostname well past any individual organization's capacity to host and manage the infrastructure listening there.

Mark

---

From: arks-...@googlegroups.com <arks-...@googlegroups.com> on behalf of Greg Janée <gja...@ucsb.edu>
Sent: Friday, April 7, 2023 5:44 PM
To: arks-...@googlegroups.com
Subject: Re: [arks] Succession plan for Names 2 Things

 

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/35268143-CE14-4783-94F3-6D5025F85123%40ucsb.edu.

[Dave Vieglais]

Hi Thanasis,

Coincidentally, ARKs were recently registered under:

https://github.com/perma-id/w3id.org/tree/master/arkid

We used arkid instead of ark to avoid confusion with the existing ARK entry.

So ARK identifiers may also be expressed as a URL using a pattern like:

https://w3id.org/arkid/ark:/NAAN/suffix
or
https://w3id.org/arkid/NAAN/suffix

For example: https://w3id.org/arkid/ark:12148/bpt6k10733944

Right now the service simply redirects through N2T which is a single point of failure concern, though that is also being addressed.

regards,
Dave V.

On 18 Apr 2023, at 14:04, Athanasios Velios wrote:

Members of the list may find the w3id.org community relevant to this discussion - perhaps there is more overlap on membership than I realise - but I have used the w3id.org github repository for a few projects and it is a convenient model (with its issues of course).

https://github.com/perma-id/w3id.org

All the best,

Thanasis

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/e0caefb7-a505-4e20-9ecf-6ef39045cd48n%40googlegroups.com.