On CITE/CTS URNs in cRef or source

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

On CITE/CTS URNs in cRef or source

Paolo Monella
Dear all,

I'm following up on a previous discussion on the use of @cRef on this
list, originated from this message:

https://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1606&L=tei-l&P=R2608&1=tei-l&9=A&I=-3&J=on&d=No+Match%3BMatch%3BMatches&z=4

When I replied to that thread, I used some CITE/CTS URNs to point to. I
was encoding medieval Latin passages pointing to their classical/late
Empire sources. My question was whether to use

(A) <ref cRef="urn:cts:latinLit:stoa0234a.stoa001:2.53.8-2.53.12"
type="source">

or

(B) <seg source="urn:cts:latinLit:stoa0234a.stoa001:2.53.8-2.53.12">

Lou Burnard wrote:

> At the risk of staying the obvious, the @source and ,@target attributes both take Uri values. So you could use them directly to supply your CTS values. No need for cref.

But some of my CTS URNs don't resolve to an actual retrievable URI
(http://...), and Martin Holmes wrote:

> The result of dereferencing a private URI scheme through the mechanism
> documented in a <prefixDef> should be a pointer: [...]
> If a CTS identifier is not intended to be processed into something from
> which a resource can be retrieved, then I don't think there's much
> benefit in using this mechanism; @cRef seems more appropriate.

So I decided to stick with @cRef for my CTS URNs. Now I have the same
issue with another project.

So I'm asking a more specific question this time: can @source take a CTS
URN as a value in the form "urn:cts:..." like in code (B) above?

That is: can this URN be considered a valid URI for inclusion in @source
regardless of whether it resolves to an http URI or not?

If not, is code (A) above a valid solution?

Thank you,
Paolo