[urn] Re: Request for Registration of CTS namespace

[[e-mail]]

Dear all,

I try to sketch out something based on my understanding of everyone's interests. If you don't veto this sketch, I would describe it to the academy in the next round in the upcoming week and get their feedback.


IANA hosts the official registry that maps data namespaces to URLs and whatever info about the registrant and data provenence is useful in any format that fits.

Based on that everyone can build a technical mapping similiar to a DNS server, with minimal information, to be used by programming interfaces. (The goal here is to decentralise the server load so that not every program inside the infrastructure calls up the IANA server).
How this works and how often it updates is up to the host. Responsible hosts should use the official registry as the source, but it is also open to their discretion what they map (e.g. scholary contexts might want to have demo-namespaces without making them permanent). I would host one for my project (as I do now).

The academy opens a contact for "semi-registration" that is then responsible for an official registration at IANA for relevant data sets (the goal here is to be able to experiment with new - maybe temporary - data sets and also have a structured process so that not everyone requests IANA registration individually).
CTS URNs are then only official, if the IANA registration succeeds. This would reduce your workload as you would not have to explain the same things to different institutions. The Text+ / CLARIN context of the academy would be perfect to streamline that in the German research area and would be a very attractive new role for the academy. It would also sketch out, how the issue of unregistered CTS URNs is handled, that will prbly not go away (they exist, but are less reliable / trustworthy)


The goal of the work package would then be to have the process laid out in 2028 and - as proof - register each text corpus known in my project through that process. Then some kind of paper / publication and the registry process goes productive.


Could that be a structural solution that fits?


Best Regards
Jochen

--
Text Service Infrastructure
https://urncts.eu" rel="nofollow">https://urncts.eu

DH-Digilab
https://dhdigilab.eu" rel="nofollow">https://dhdigilab.eu

Am 18.06.26, 10:50 schrieb "Lars G. Svensson" <lars.svensson=http://40web.de" rel="nofollow">40web.de@http://dmarc.ietf.org" rel="nofollow">dmarc.ietf.org>:

Dear Jochen, all,

I, too, find Dale's idea having a registry hosted by IANA attractive.

> Do you think IANA could provide a repo that maps data namespaces to server URLs?

I think that's perfectly possible. We could use a format along the lines of (taking data from <https://urncts.eu/" rel="nofollow">https://urncts.eu/>):


<namespace> Registrant Registrant contact data Server URL
------------------------------------------------------------------------------------------------------------------------------------------
ancJewLit <Whoever...> ancjewlit@http://example.com" rel="nofollow">example.comhttps://example.com/ancJewLit" rel="nofollow">https://example.com/ancJewLit
dhd Verband Digital Humanities im dhd-urn-registry@http://example.org" rel="nofollow">example.orghttps://example.org/dhd" rel="nofollow">https://example.org/dhd
deutschsprachigen Raum e.V.
...

That registry would - of course - be only text or html, but if done in xhtml it should be easy to build an automated process that at intervals downloads the registry and builds an application that resolves namespaces to endpoint urls.

> I don't think there is anything we can do about people creating CTS URNs
> without proper registration, all we can do is create clear rules that
> allow us to say that they are nonconforming.

Yes, there are many cases of urn-squatting out there, urn:li comes to mind...

>> And finally I don't see, how a central registry could prevent
>> "namespace brokers" from registering and selling namespaces to
>> academic institutions. In a decentralised registry, this business
>> model cannot appear.

> I think the situation is similar to domain names, in that there are many
> alternative forms of the name of an institution or project, and it is
> unlikely that brokers will have speculatively registered all of them.

If we make it a prerequisite for registration that registrants can only be academic institutions or organisations working on their behalf, that danger could be circumvented. We would then, of course, need an expert committee that reviews new applications, similar to the urn review group!

Best,

Lars


-----Ursprüngliche Nachricht-----
Von: tiepilab=http://40gmx.de" rel="nofollow">40gmx.de@http://dmarc.ietf.org" rel="nofollow">dmarc.ietf.org [mailto:tiepilab=http://40gmx.de" rel="nofollow">40gmx.de@http://dmarc.ietf.org" rel="nofollow">dmarc.ietf.org]
Gesendet: Montag, 15. Juni 2026 08:16
An: Dale R. Worley <worley@http://ariadne.com" rel="nofollow">ariadne.com>
Cc: urn@http://ietf.org" rel="nofollow">ietf.org
Betreff: [urn] Re: Request for Registration of CTS namespace

That is heloful to know as it sets a clear goal.

Do you think IANA could provide a repo that maps data namespaces to server URLs?

I use such a (private) repo to direct the programming APIs to the servers. The idea was to host that repo at the academy instead.

If IANA registers data namespaces, it might be a good idea to have the core repo located at IANA(?) and allow users to clone that(?)

(Technically it is a trivial key-value mapping)



Am 13.06.26, 04:46 schrieb "Dale R. Worley" <worley@http://ariadne.com" rel="nofollow">ariadne.com <http://ariadne.com" rel="nofollow">http://ariadne.com> >:

tiepilab=http://40gmx.de" rel="nofollow">40gmx.de <http://40gmx.de" rel="nofollow">http://40gmx.de> @http://dmarc.ietf.org" rel="nofollow">dmarc.ietf.org <http://dmarc.ietf.org" rel="nofollow">http://dmarc.ietf.org> writes:
> I don't have a a full list. The namespaces that are connected to my
> project are listed at https://urncts.eu" rel="nofollow">https://urncts.eu.

That page lists 19 data namespaces, which shows that there is
significant user support for CTS.

> The registration process will be an interesting topic to discuss. I
> understand your comment in a way that leads to a central authority.
> My abstract idea is an open registration, hosted *somewhere* that
> works purely on FCFS without an authority that decides who may or may
> not register a new namespace as long as it does not collide. With the
> option to choose your registry similiar to how you can choose your DNS
> provider. Choosing your registry would also limit the harm that could
> arise from misuse.

We definitely need a registration system in order to ensure URN
uniqueness, which is a requirement of URN registration -- organizations
need to know what possible URNs they are allowed to create. If we get
an IANA registry established under "FCFS" policy, then there is no
restriction regarding who may register which new data namespace. Also,
registration with IANA would implicitly put each data namespace owner on
notice that they had to adhere to the registered CTS syntax.

And I do see it as a problem that we need to ensure the users of CTS
conform to the proper syntax.

It would be straightforward to establish an IANA registry. It would
take a great deal of work to establish a system with multiple
registrars. And it might not be possible to recruit multiple
registrars, whereas the IESG can direct IANA to operate a registry.

In regard to trusting IANA to carry out its duties correctly ... If IANA
doesn't function well, the Internet has many more problems than just
CTS.

Although if you see a way to do decentralized allocation of data
namespaces, I would like to see the details.

> Another issue with a central registry might come from the domain. It
> seems that the need to register namespaces is not very strong in the
> humanities :) . The problem with unregistered URNs would escalate
> further if new data sets appear without registration. A decentralised
> registry would eliminate this problem because then it is the users
> responsibility.

I don't think there is anything we can do about people creating CTS URNs
without proper registration, all we can do is create clear rules that
allow us to say that they are nonconforming.

> And finally I don't see, how a central registry could prevent
> "namespace brokers" from registering and selling namespaces to
> academic institutions. In a decentralised registry, this business
> model cannot appear.

I think the situation is similar to domain names, in that there are many
alternative forms of the name of an institution or project, and it is
unlikely that brokers will have speculatively registered all of them.

Dale