I have a couple of questions:
First, I totally see the value of the URN syntax as a globally unique name for entities in the citation hierarchy. That's useful because it's a hook I can use to join up different collections. From a Linked Data perspective, I'd like, as I said earlier, to have a standard way of munging that URN into a URL for a number of reasons. But if I really want to do Linked Data, the very first thing I need to know is what we're talking about.
So, in RDF terms, what is urn:cts:greekLit:tlg0012.tlg001.msA? What is urn:cts:greekLit:tlg0012.tlg001? That is to say, what properties and types would you assign to them? Is urn:cts:greekLit:tlg0012.tlg001.msA Venetus A itself? A TEI (or other) transcription of Venetus A? Or is it just an identifier for Venetus A (or for a particular transcription of Venetus A)? I'm really hoping the latter, for what it's worth.
Second, do you have any plans or interest in a registry for CTS top-level identifiers? Understandably, using the TLG and PHI identifiers has gotten you out of the need for this for a long time, but more questions: How do I know not to use msA as an identifier for something other than Venetus A? If I have to invent a new set of author/work ids because they aren't in PHI, how do I ensure their uniqueness? I've already got the latter problem with the text of Servius vs. Servius Auctus—PHI is the Thilo and Hagen edition, which merges them. So I can't use the PHI identifier if I want to treat them as distinct. This actually strikes me as more of a CTS-killer than anything else. If I can't depend on the global uniqueness of a CTS URN, then I'm better off just using an HTTP URI from a domain I own—because I can control how it resolves.
I have vague memories of us talking about this kind of thing years and years ago, but don't know if it went anywhere.
All the best,
Hugh
On Apr 15, 2013, at 7:36 , Neel Smith <[log in to unmask]> wrote:
> I won't be able to monitor this list closely for the next couple of days, but wanted to chime in briefly.
>
> If we want to use CTS URNs to retrieve contents, the CTS protocol provides methods for doing that. (But, as I claimed in another post, this is not the only use we might make of URNs: we might want to make statements about and reason about URNs rather than retrieving contents.) We can think of retrieving contents identifeid by a CTS URN in two parts, a little like DNS and TCP/IP.
>
> part 1: we need to determine where a URN is available (a little like dns). I think this is exactly the kind of problem linked data approaches were intended to handle. Easy enough for a CTS implementation to advertise that "ServiceURL provides VersionLevelURN".
>
> part 2: using that information, some services need to redirect URNs to an appropriate URL. There are a number of possible strategies for implementing this functionality, but the CTS protocol offers a black box for implementations. Any kind of indexing, caching, store and forward system or other design could back a CTS GetPassagePlus request. And as has already been pointed out in this thread, that might actually reside behind a url formatted like http://CTSSERVICE/ctsurn
>
> Hope to be back on the list more attentively later this week...
>
> Neel
|