[urn] Re: Request for Registration of CTS namespace
Jochen Tiepmar <[email protected]> Fri, 22 May 2026 15:32:11 +0000
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <trinity-81e93fee-6e1e-4c7e-9fc7-9b55de5d695b-1779463931193@trinity-msg-rest-gmx-gmx-live-67f45748b-vx4bx> |
--===============2749553453221855150==
Content-Type: text/html; charset=UTF-8
<html><body>With regard to the brackets [ and ].<br><br>Would it be possible to exclude that from the registration with the argument that the specs must be adapted?<br><br>If Neel Smith is not working on that I think it would be my right to change the syntax rules if neccessary.<br><br><div class="signature">--<br>Gesendet mit der GMX Mail App</div><div class="mail_android_quote" style="line-height: 1"><br><meta name="viewport" content="width=device-width"><meta http-equiv="Content-Type" content="text/vnd.ui.insecure+html;charset=utf-8"><div class="mail_android_quote" style="line-height: 1"><br>Am 22.05.26, 17:17 schrieb "Dale R. Worley" <worley@<a href="http://ariadne.com">ariadne.com</a>>:<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; border-left: 1px solid rgb
(204, 204, 204); padding-left: 1ex;">
This is not a complete review of the proposal, but it can start<br>
discussion.<br>
<br>
Reading the proposal, it sounded familiar. Fortunately, others remember<br>
the history.<br>
<br>
The template links to<br>
<a href="https://github.com/cite-architecture/ctsurn_spec/blob/master/md/specification.md">https://github.com/cite-architecture/ctsurn_spec/blob/master/md/specification.md</a><br>
as the specification of the URN syntax. That specification would gain<br>
greatly by being fleshed out as ABNF, as there is no ambiguity in ABNF.<br>
Some rather long text passages translated directly into short, clear<br>
specifications. E.g.<br>
<br>
WORK = TEXTGROUP [ "." WORK [ "." VERSION [ "." EXEMPLAR ] ] ]<br>
<br>
But the lowest-level parts discussed in speification.md don't have any<br>
specification for what characters they can be composed of. In a number<br>
of cases, there are certain characters that a component must not contain<br>
to prevent the syntax from being ambiguous. E.g. VERSION may not conain<br>
either "." or ":".<br>
<br>
There's a serious problem regarding the use of "[" ad "]"; they aren't<br>
allowed in URNs, and the template can't define a URN namespace that<br>
allows them. (It may be possible to substitute "(" and ")" in the<br>
definition, assuming that causes no confusion, that is, nobody is<br>
allowed to use those in PASSAGE for any other meaning.)<br>
<br>
I would change the phrasing of<br>
<br>
Assignment: The definition of data namespaces is completely<br>
open. Data namespaces can be registered for the namespace resolver<br>
based on FCFS principle.<br>
<br>
"can be" carries the implication of optionality and the meaning you want<br>
is mandatory. So I would say "Data namespaces must be registered for<br>
the namespace resolver based on FCFS principle."<br>
<br>
And you should start to think of this work as an institution. Give it a<br>
name like "Canonical Text Services". Then say "Data namespaces must be<br>
registered with Canonical Text Services based on the FCFS principle."<br>
(Or is it "Text Services Infrastructure"? In any case, the project<br>
needs a name and attention must be paid to its human interfaces with the<br>
rest of society, not just its technonogical interfaces.)<br>
<br>
Resolution: <br>
<br>
The text data is served via a decentralised software<br>
infrastructure. The server addresses are mapped to the namespace<br>
inside CTS [data_namespace], similiar to a DNS server. The<br>
[data_namespace] is open source, with one instance being hosted at<br> https:<a href="http://urncts.eu/namespaceresolver.">urncts.eu/namespaceresolver.</a><br>
<br>
As part of the infrastructure project, a growing set of interfaces<br>
and tools is developed. At the moment CTS URNs can be resolved in<br>
Python, Javascript or via HTTP(S)-GET.<br>
<br>
Fetching that URL gives<br>
<br>
ancJewLit<br>
demo<br>
dhd<br>
dsb<br>
dta<br>
edh<br>
folgershakespeare<br>
gps4<br>
gwtc<br>
humboldtdigital<br>
jeanpaulbriefe<br>
kant<br>
lebenswelten<br>
offlinectstest<br>
openarabicpe<br>
pbc<br>
pcp<br>
textgrid<br>
tgap<br>
voth<br>
<br>
Which appears to be a list of CTSNAMESPACEs but doesn't provide any<br>
information about the resolution process. Presumably this is the list<br>
of currently registered CTSNAMESPACEs, but the documentation doesn't<br>
seem to state that. And that is how someone who wants to register a new<br>
CTSNAMESPACE knows that the name is not already in use.<br>
<br>
The template does not seem to point to any specification of how to<br>
access the resolver.<br>
<br>
Registrant: Dr. Jochen Tiepmar. Chief Implementor and Admin of<br>
the Text Service Infrastructure project.<br> Email: tiepilab@<a href="http://gmx.de">gmx.de</a><br> At registration date the project is hosted privately at https:<a href="http://urncts.eu">urncts.eu</a>.<br>
<br>
As always, it is best if the contact e-mail address is a "role address"<br>
which forwards messages to whatever person(s) hold the role at that<br>
time. That way the namespace as an institution is not permanently<br>
attached to a specific individual. In this case, it would be ideal to<br> obtain an e-mail address "...@<a href="http://urncts.eu">urncts.eu</a>" that is the contact address for<br>
this institution and its namespace.<br>
<br>
Dale<br>
</blockquote></div></div></body></html>
--===============2749553453221855150==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXJuIG1haWxp
bmcgbGlzdCAtLSB1cm5AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB1
cm4tbGVhdmVAaWV0Zi5vcmcK
--===============2749553453221855150==--