[urn] Re: Request for Registration of CTS namespace
[email protected] Fri, 19 Jun 2026 07:44:29 +0000
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <trinity-4ada59b8-28f7-452b-8c67-f9113b20a608-1781855069197@trinity-msg-rest-gmx-gmx-live-5b7c84747d-9f5l5> |
--===============4384924575998166911==
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><body>There is a misunderstanding=2E I am not proposing a sub namespa=
ce or a change of the CTS sytax<br>Like urn:cts:saw:[datanamespace]<br><br>=
I am proposing that at SAW (or any other place) sits a contact person for C=
TS URN registration=2E This person then collects the neccessary information=
(say from the Telota group at bbaw) and sends the request or a batch of re=
quests for registration to you=2E<br><br>And I ask if that process would be=
fine with you before suggesting this for the proposal for funding=2E<br><b=
r>E=2Eg=2E The UB Heidelberg wants to register a namespace urn:cts:epigraph=
: =2E SAW collects the info=2E SAW sends request for urn:cts:epigraph: to I=
ANA in a standardised manner=2E IANA responds=2E SAW tells UB the result=2E=
urn:cts:epigraph: is registered=2E<br><br>The alternative would mean that =
all edition projects (which means basically every DH department) need to co=
ordinate with you individually for each edition project that is organized b=
y a different person=2E<br>This would be fine from our side, if you prefer =
that, but it may well develop into a situation where you get a lot of reque=
sts=2E Iff DH researchers even see the need for registering (which they see=
mingly did not in the past=2E)<br>Edition projects are a fastly growing gen=
re and DH departments are popping up everywhere=2E I am trying to find a so=
lution that scales with this fact bc the reviewers of the proposal will see=
that as a problem=2E<br><br><br><div class=3D"signature">--<br>Text Servic=
e Infrastructure<br><a href=3D"https://urncts=2Eeu">https://urncts=2Eeu</a>=
<br><br>DH-Digilab<br><a href=3D"https://dhdigilab=2Eeu">https://dhdigilab=
=2Eeu</a></div><div class=3D"mail_android_quote" style=3D"line-height: 1"><=
br><meta name=3D"viewport" content=3D"width=3Ddevice-width"><meta http-equi=
v=3D"Content-Type" content=3D"text/vnd=2Eui=2Einsecure+html;charset=3Dutf-8=
"><div class=3D"mail_android_quote" style=3D"line-height: 1"><br>Am 19=2E06=
=2E26, 03:53 schrieb "Dale R=2E Worley" <worley@<a href=3D"http://ariadn=
e=2Ecom">ariadne=2Ecom</a>>:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0=2E8ex 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;">
Responding to several messages:<br>
<br> tiepilab=3D<a href=3D"http://40gmx=2Ede">40gmx=2Ede</a>@<a href=3D"ht=
tp://dmarc=2Eietf=2Eorg">dmarc=2Eietf=2Eorg</a> writes:<br>
> Do you think IANA could provide a repo that maps data namespaces to<b=
r>
> server URLs?<br>
<br>
The "Uniform Resource Names (URN) Namespaces" registry at<br>
<a href=3D"https://www=2Eiana=2Eorg/assignments/urn-namespaces/urn-namespa=
ces=2Exhtml">https://www=2Eiana=2Eorg/assignments/urn-namespaces/urn-namesp=
aces=2Exhtml</a> is<br>
one of the more complex registries that IANA manages=2E I encourage you<b=
r>
look at it as an example of the services that IANA provides=2E My belief<=
br>
is that IANA has infrastructure that automatically maintains the "data<br>
tables" and displays the data this way=2E<br>
<br>
In particular, look at the top list "Available Formats" and the "XML"<br>
link just under it=2E That link is<br>
<a href=3D"https://www=2Eiana=2Eorg/assignments/urn-namespaces/urn-namespa=
ces=2Exml">https://www=2Eiana=2Eorg/assignments/urn-namespaces/urn-namespac=
es=2Exml</a> and<br>
it retrieves an XML document that seems to contain all of the<br>
information on the web page, including several data tables and the<br>
contact information for the individuals listed at the bottom of the<br>
page, who are the registrants or contact points for the registrations=2E<b=
r>
<br>
One possibility is to have IANA maintain a data table containing the<br>
columns:<br>
- CTS data namespace<br>
- server URL<br>
- registering institution<br>
- role contact address for the registering institution<br>
Then the XML download link would return a data structure that could be<br>
used to operate a server that maps data namespaces to their servers=2E<br>
<br> "Lars G=2E Svensson" <lars=2Esvensson=3D<a href=3D"http://40web=2E=
de">40web=2Ede</a>@<a href=3D"http://dmarc=2Eietf=2Eorg">dmarc=2Eietf=2Eorg=
</a>> writes:<br>
> If we make it a prerequisite for registration that registrants can on=
ly<br>
> be academic institutions or organisations working on their behalf, th=
at<br>
> danger could be circumvented=2E We would then, of course, need an exp=
ert<br>
> committee that reviews new applications, similar to the urn review<br=
>
> group!<br>
<br>
Instead of phrasing the requirement as "academic institutions or<br>
organisations working on their behalf", I would allow any organization<br>
to register but place requirements on their usage=2E For example,<br>
<br>
- Require that their usage be "for scholarly purposes"=2E That's rather<b=
r>
ill-defined, but in practice people can distinguish scholarly usage<br>
from most other human activities=2E (Fortunately, due to history, the<b=
r>
word "scholar" probably translates well between the European<br>
languages, and Google's answers suggest it translates well into<br>
Chinese and Japanese=2E)<br>
<br>
- Require that URNs and their meanings that the registrants mint be made<b=
r>
public information=2E<br>
<br>
- Require that a registered CTS data namespace be used in a way that<br>
supports/advances scholarship=2E (No squatting!)<br>
<br>
Violations may cause one's registration to be canceled=2E (And if servers=
<br>
use the IANA XML as their data source, we can enforce that!)<br>
<br>
It may be worth asking your academic users what requirements they think<br=
>
would be appropriate to ensure CTS is used for the benefit of research<br>
globally -- academic "source hoarding" is not that rare=2E<br>
<br> tiepilab=3D<a href=3D"http://40gmx=2Ede">40gmx=2Ede</a>@<a href=3D"ht=
tp://dmarc=2Eietf=2Eorg">dmarc=2Eietf=2Eorg</a> writes:<br>
> This would reduce<br>
> your workload as you would not have to explain the same things to<br>
> different institutions=2E <br>
<br>
I am not responding directly to your proposal here, but rather to the<br>
concept of "reducing workload" that you raise: I have been assuming<br>
that there will be a relatively small number of data namespaces, each of<b=
r>
which will be used to catalog a very large corpus of documents=2E But you=
<br>
suggest that in practice, there may be a large number of projects, each<br=
>
of them quite small (relative to the universe of scholarship), and it<br>
might be undesirable to have each one register its own data namespace=2E<b=
r>
<br>
Thus the concept you raise -- having an institution operate an<br>
"umbrella" data namespace, delegating "sub namespaces" to individual<br>
projects=2E For example, the Saxon Academy of Sciences could register<br>
<br>
urn:cts:SAW:=2E=2E=2E<br>
<br>
and then within that maintain a registry of sub-namespace names, within<br=
>
which the individual projects or institutions assign document<br>
identifiers:<br>
<br>
urn:cts=2ESAW:project1:=2E=2E=2E<br>
urn:cts=2ESAW:GI:=2E=2E=2E<br>
urn:cts:SAW:IDS:=2E=2E=2E<br>
urn:cts:SAW:MPI-WG:=2E=2E=2E<br>
<br>
And one could imagine a sub-registrant institute providing<br>
sub-registrations to many autonomous pojects within itself=2E<br>
<br>
I am not sure how much this duplicates your proposal, but I think it<br>
would be useful to consider these sub-registrations to be permanent, so<br=
>
the various sub-registrants don't, at some future point, have to reissue<b=
r>
new URNs under a different data namespace=2E<br>
<br>
This does require that the SAW provide a reliable, permanent<br>
infrastructure for the sub-registrations, and a server for translating<br>
all the URNs, or somehow forwarding resolution requests to to<br>
subordinate servers=2E Fortunately, the Academy has been in existence for=
<br>
180 years and is likely to be quite stable into the future=2E<br>
<br>
However, this idea would require additions to the syntax=2E Currently it<=
br>
is:<br>
<br>
urn:cts:CTSNAMESPACE:WORK:PASSAGE<br>
<br>
We would have to allow one or more SUBNAMESPACE components between<br>
CTSNAMESPACE and WORK=2E In the IETF's "ABNF" notation, that would be<br>
<br>
"urn:cts:" CTSNAMESPACE *(":" SUBNAMESPACE ) ":" WORK ":" PASSAGE<br>
<br>
where the "*(=2E=2E=2E)" means "zero or more repetitions of the grammar<br=
>
between the parentheses"=2E<br>
<br>
Looking at<br>
<a href=3D"https://github=2Ecom/cite-architecture/ctsurn_spec/blob/master/=
md/specification=2Emd">https://github=2Ecom/cite-architecture/ctsurn_spec/b=
lob/master/md/specification=2Emd</a>,<br>
I don't see a specification for CTSNAMESPACE, although I expect it is<br>
intended to be the common "letters, digits, hyphen" set, and for<br>
simplicity we would want SUBNAMESPACE to have the same specification=2E<br=
>
<br>
However, the grammar above has the problem that one can only reliably<br>
identify the WORK component if we know which NAMESPACE components will<br>
be followed by a further NAMESPACE component and which won't=2E A better<=
br>
grammar would signal that syntactically=2E So then let us separate the<br=
>
sub-namespaces not with ":" but "=2E" (making sure "=2E" is not allowed in=
<br>
NAMESPACE):<br>
<br>
"urn:cts:" CTSNAMESPACE *("=2E" SUBNAMESPACE ) ":" WORK ":" PASSAGE<br>
<br>
Then one can find the WORK part of each of these without knowing what<br>
registrations exist:<br>
<br>
urn:cts:SAW:work:passage<br>
urn:cts:SAW=2EGI:work:passage<br>
<br>
Dale<br>
</blockquote></div></div></body></html>
--===============4384924575998166911==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXJuIG1haWxp
bmcgbGlzdCAtLSB1cm5AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB1
cm4tbGVhdmVAaWV0Zi5vcmcK
--===============4384924575998166911==--