On 24/04/2013, at 00:47 , Hugh Cayless <[log in to unmask]> wrote:
> On Apr 22, 2013, at 7:54 , Neel Smith <[log in to unmask]> wrote:
>
>> Part of the appeal of URN notation is that they do not need to refer to digial resources: I can cite Sandys's reading specifically whether or not I know of an online version reachable via the CTS protocol. This is, IMHO, an important separation of concerns: the scholar correctly citing evidence with URNs does not have to address the question of how URNs are to be resolved, today or in the future. It is possible that in 2013, the way I resolve urn:cts:greekLit:tlg0086.tlg003.ap03:1 is to walk to my shelf, pull a volume off, and page through to chapter 1. (This is what I meant in an earlier post when I said that URNs pass the "paper napkin test".) If, in the future, a digital version of Sandys' edition is recognizable by a CTS resolver, then my digital references to that URN suddenly become even more valuable.
>>
> Well, HTTP URIs don't need to refer to digital resources either. They do implicitly offer a way to get information about resources whether they're digital or not (which URNs don't absent a resolver), but they might not point to anything. XML Namespaces are usually HTTP URIs and may not point to any resource. The URI RFC (http://tools.ietf.org/html/rfc3986#section-1.2.2) is quite clear on this point:
>
>> A common misunderstanding of URIs is that they are only used to refer
>> to accessible resources. The URI itself only provides
>> identification; access to the resource is neither guaranteed nor
>> implied by the presence of a URI. Instead, any operation associated
>> with a URI reference is defined by the protocol element, data format
>> attribute, or natural language text in which it appears.
Despite what that RFC says.
A http URL is and in itself an actual digital resource: hyper-text transfer protocol. If I saw your footnote annotated with a http URL and plugged it into my browser and got a 404, I would assume the data no longer exists. It is "not found". I certainly would not use google to find out more information. I'd tell you your text was faulty as the URL does not resolve. Alternatively, I would try to POST to it to create the resource.
I think despite whatever that IETF RFC says, a http URL implies there is a representation of some kind at the other end (a '404' is a representation - metadata - about the object which is well defined in the HTTP specification).
|