Subject: [urn] CTS and CITE2 URNs

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 4 Mar 2019 18:51:33 -0700

A few months ago while doing research for a side project, I came across
two URN namespaces (used in humanistic scholarship) that had not yet
been registered: CTS and CITE2. Since then I've worked with the scholars
who designed these URN namespaces regarding the registration process. As
a result, they have prepared the following two registrations:

http://cite-architecture.org/ctsurn/rfc.txt

http://cite-architecture.org/cite2urn/rfc.txt

Review by the other members of the expert review team would be appreciated.

Thanks!

Peter

---

From: "Hakala, Juha E" <[email-masked]>
Date: Tue, 5 Mar 2019 06:58:44 +0000

Hello, 

from my point of view these namespace registrations are interesting, not least because I am currently involved revision of ISO 690, the ISO standard for bibliographic referencing. URNs for citing resources is something that needs to be considered in the revision process. 

I am in favour of registering these namespaces. The only reservation I have is the usage of "@" to separate subreferences. Would it be possible to use hash character for this purpose? 

At https://cite-architecture.github.io/ohco2/quick/ 

the researchers themselves give the following example: 

urn:cts:greekLit:tlg5026.msA.hmt:1.2.lemma#μῆνις

which would be better aligned with RFCs 3986 and 8141. According to the request, there are no plans to make these URNs actionable, so in the short term it does not really matter which character is used, but if in the long term actionability becomes an issue, it is better not to divert from RFC 3986 unless there is a good reason to do so.    

The project refers to RFC 2141 at http://cite-architecture.org/ctsurn/ and elsewhere; they should use RFC 8141 instead. 

In theory, the project should use ISTC (International Standard Text Code) to identify textual works, but since ISTC has kicked the bucket, I would not insist on using it. 

Best, 

Juha

-----Original Message-----
From: urn <[email-masked]> On Behalf Of Peter Saint-Andre
Sent: tiistai 5. maaliskuuta 2019 3.52
To: [email-masked]
Subject: [urn] CTS and CITE2 URNs

A few months ago while doing research for a side project, I came across two URN namespaces (used in humanistic scholarship) that had not yet been registered: CTS and CITE2. Since then I've worked with the scholars who designed these URN namespaces regarding the registration process. As a result, they have prepared the following two registrations:

Thanks!

Peter

_______________________________________________
urn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/urn

---

From: "Smith, Neel" <[email-masked]>
Date: Tue, 5 Mar 2019 14:40:21 +0100

I believe the original rationale was that in the literary texts the Cts URN
was primarily imagined for, "#" might appear far more frequently "@", and
thus would more frequently require either escaping or eye-straining runs of
"##" (the first syntactic, the second interpreted as content).

Thanks for pointing out the outdated RFC reference!

Neel

On Tue, Mar 5, 2019 at 7:59 AM Hakala, Juha E <[email-masked]>
wrote:

> Hello,
>
> from my point of view these namespace registrations are interesting, not
> least because I am currently involved revision of ISO 690, the ISO standard
> for bibliographic referencing. URNs for citing resources is something that
> needs to be considered in the revision process.
>
> I am in favour of registering these namespaces. The only reservation I
> have is the usage of "@" to separate subreferences. Would it be possible to
> use hash character for this purpose?
>
> which would be better aligned with RFCs 3986 and 8141. According to the
> request, there are no plans to make these URNs actionable, so in the short
> term it does not really matter which character is used, but if in the long
> term actionability becomes an issue, it is better not to divert from RFC
> 3986 unless there is a good reason to do so.
>
> The project refers to RFC 2141 at http://cite-architecture.org/ctsurn/
> and elsewhere; they should use RFC 8141 instead.
>
> In theory, the project should use ISTC (International Standard Text Code)
> to identify textual works, but since ISTC has kicked the bucket, I would
> not insist on using it.
>
> Best,
>
> Juha
>
>
> two URN namespaces (used in humanistic scholarship) that had not yet been
> registered: CTS and CITE2. Since then I've worked with the scholars who
> designed these URN namespaces regarding the registration process. As a
> result, they have prepared the following two registrations:
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Mar 2019 15:30:10 +0100

On 05.03.2019 07:58, Hakala, Juha E wrote:
> ...

How is using "#" (the fragment identifier) better aligned with RFC 3986???

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Mar 2019 19:31:17 -0700

On 3/5/19 7:30 AM, Julian Reschke wrote:
>> from my point of view these namespace registrations are interesting,
>> not least because I am currently involved revision of ISO 690, the ISO
>> standard for bibliographic referencing. URNs for citing resources is
>> something that needs to be considered in the revision process.
>>
>> have is the usage of "@" to separate subreferences. Would it be
>> possible to use hash character for this purpose?
>>
>> which would be better aligned with RFCs 3986 and 8141. According to
>> the request, there are no plans to make these URNs actionable, so in
>> the short term it does not really matter which character is used, but
>> if in the long term actionability becomes an issue, it is better not
>> to divert from RFC 3986 unless there is a good reason to do so.
>> ...
> 

Correct. '@' is in the pchar rule from RFC 3986, and RFC 8141 defines
the NSS rule as one or more code points conforming to the pchar rule.
Thus '@' is fine here, as far as I can see.

Peter

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Mar 2019 22:55:31 -0500

Comments on these registrations:

As Julian points out, using '#' as part of the URN assigned-name is
not allowed.

CTS URN registration

   CTS URNs provide permanent, canonical, scholarly references to
   texts or passages of text associated with the unique cultural
   phenomena that humanists study.

s/unique cultural phenomena/cultural phenomena/ -- I can't see any
manner in which the enormous number of humanistic phenomena are each
"unique".

   Syntax:

   The general structure of a CTS URN is as follows:

   urn:cts:SUBNAMESPACE:WORK:PASSAGE@SUBREFERENCE

   ...

   A detailed definition of CTS syntax can be found at:

   http://cite-architecture.org/ctsurn/

Unfortunately, neither this registration nor the pointed-to syntax
definition gives an exact description of the syntax.  E.g., at every
location where I noticed a part of the syntax described as "optional",
there was no exact statement regarding what adjacent separating
characters could or could not be omitted.  BNF is necessary.

   o An optional passage reference refers either to an individual
     passage or to a range of passages within a work. [...]

   o An optional subreference identifies a span within a single
     citation unit using indexed substrings. [...]

No assignment process is specified for either of these components.

CITE2 URN registration

All of the above comments for CTS URN apply to CITE2 as well.

   Documentation:

   More detailed information about CTS URNs and the CTS architecture
   can be found at:

Was "CITE2" intended here rather than "CTS"?

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Mar 2019 21:02:13 -0700

> urn:cts:greekLit:tlg5026.msA.hmt:1.2.lemma#μῆνις
Parsing according to urn:cts:SUBNAMESPACE:WORK:PASSAGE@SUBREFERENCE as
defined in the registration request, we get:

SUBNAMESPACE = `greekLit`
WORK = `tlg5026.msA.hmt`
PASSAGE = `1.2.lemma#μῆνις`
SUBREFERENCE (none)

Is that correct?

A follow-on observation. As the genesis of the CTS and CITE2 namespaces
within the Homer Multitext project indicates, it might be desirable for
literal strings in the NSS to include characters outside the ASCII range
(e.g., `μῆνις`). I suspect that such strings would be limited to the
PASSAGE and SUBREFERENCE constructs, but perhaps the registrants could
clarify that for us. In any case, here it seems that "the nature of the
particular URN namespace makes such characters necessary" (RFC 8141, §2.2).

However, the same section of RFC 8141 also clearly states:

   In particular, with regard to characters outside the ASCII range,
   URNs that appear in protocols or that are passed between systems MUST
   use only Unicode characters encoded in UTF-8 and further encoded as
   required by RFC 3986.

As far as I can see, this implies that the foregoing PASSAGE value needs
to be encoded as follows:

`1.2.lemma#%CE%BC%E1%BF%86%CE%BD%CE%B9%CF%82`

Unfortunately, that's not as user-friendly for people who know the
language of the source text from which the literal string is taken.

(Yes, the URNBIS Working Group had lengthy discussions about whether to
allow non-percent-encoded Unicode characters outside the ASCII range in
the URN syntax, and ultimately decided against it.)

Peter

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 7 Mar 2019 07:10:12 +0000

Hello, 

detailed CTS URN syntax specification and examples at 

http://cite-architecture.github.io/ctsurn_spec/

are helpful, at least for a librarian, although URN like 

urn:cts:greekLit:tlg0012.tlg001.hmt01:[email-masked]@trembling

does make even me tremble a bit ;-).  

The specification is based on RFC 2141 (it is dated February 2014). It might be a good idea to check if this version (2.0.rc.1) could benefit in one way or another from being made RFC 8141 -compliant. These URNs will not be actionable so it does not really matter if subreferences are treated as URN F-components (as I suggested) or not, but if the specification can easily be made more compliant with the current URN syntax, it would make no harm. 

Non-ascii characters in subreferences would be an issue if urn:cts and urn:cite2 provided resolution services. But that is not an intention, and since these URNs are intended mainly for humans, I would rather leave non-ascii chars un-encoded although that is against RFC 8141 (but not RFC 2141, if I remember correctly).     

Best, 

Juha

-----Original Message-----
From: urn <[email-masked]> On Behalf Of Dale R. Worley
Sent: torstai 7. maaliskuuta 2019 5.56
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] CTS and CITE2 URNs

As Julian points out, using '#' as part of the URN assigned-name is not allowed.

CTS URN registration

s/unique cultural phenomena/cultural phenomena/ -- I can't see any manner in which the enormous number of humanistic phenomena are each "unique".

   Syntax:

   ...

Unfortunately, neither this registration nor the pointed-to syntax definition gives an exact description of the syntax.  E.g., at every location where I noticed a part of the syntax described as "optional", there was no exact statement regarding what adjacent separating characters could or could not be omitted.  BNF is necessary.

CITE2 URN registration

   Documentation:

Dale

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 22 Mar 2019 05:38:21 +0000

Hello Peter, others,

Sorry to reply to an older email.

> the URN syntax, and ultimately decided against it.)

Well, all URNs are URIs (RFC 3986), and for URIs, there's IRIs (RFC 
3987), so urn:cts:greekLit:tlg5026.msA.hmt:1.2.lemma#μῆνις would work in 
any protocol slot that accepted IRIs, and would automatically be 
converted to the ugly 
urn:cts:greekLit:tlg5026.msA.hmt:1.2.lemma#%CE%BC%E1%BF%86%CE%BD%CE%B9%CF%82 
whenever necessary.

Regards,   Martin.

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 24 Mar 2019 18:16:58 -0400

The situation we are in as one of conflicing requirements:  (1) the need
for URNs to absolutely follow the standard (RFC 8141), and (2) the need
for them to be human-convenient.

One way to square this circle would be to define two forms which are in
one-to-one correspondence:  If it starts with "urn:", it is in URN
format, and if it starts with "cts:" or "cite2:", it is in
human-friendly format.  For example, we could define these two strings
to be equivalent:

    cts:greekLit:tlg5026.msA.hmt:1.2.lemma#μῆνις

    urn:cts:greekLit:tlg5026.msA.hmt:1.2.lemma@%CE%BC%E1%BF%86%CE%BD%CE%B9%CF%82 

As long as this correspondence is algorithmicly defined, it shouldn't be
difficult to implement.

The latter proper URN can probably be translated into an IRI that would
show the final characers in the native Greek alphabet, but I don't know
enough about IRIs to know how that would work.

Dale

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 24 Mar 2019 23:03:14 +0000

Hello Dale, others,

> enough about IRIs to know how that would work.

Well, it would work very easily. It would give

It's just the reversal of the encoding with UTF-8 and %-encoding that 
the URN RFC specifies.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 Mar 2019 07:21:35 +0100

>      cts:greekLit:tlg5026.msA.hmt:1.2.lemma#μῆνις

Even if it doesn't claim to be a RFC8141-URN, it would still need to be
a RFC3986-URI (right?); and the same restrictions would apply.

If you need non-URI-characters, just leverage RFC 3987.

Best regards, Julian

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Mar 2019 20:57:45 -0400

> a RFC3986-URI (right?); and the same restrictions would apply.

My conceptualization is that the above string *isn't* intended to be a
URI of any sort; it's a different type of citation entirely.  That gives
the scholars leeway to make it convenient for themselves.

Dale

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Mar 2019 07:23:03 +0100

> the scholars leeway to make it convenient for themselves.

It sure looks like something that would be used in place of a URI or IRI...

Best regards, Julian