W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

Re: Draft minutes from TAG telcon of 2008-07-24, plain text

From: Ray Denenberg, Library of Congress <rden@loc.gov>
Date: Fri, 25 Jul 2008 17:30:54 -0400
Message-ID: <1b6c01c8ee9d$db8fa700$2caf938c@lib.loc.gov>
To: <www-tag@w3.org>

>  it's not fine for any client to interpret the presence
> of ark: to mean "this URI is an ARK"

I think the ARK spec addresses this problem, at least theoretically (if not
practically).

Suppose the library of congress, who does not participate in ARK at present,
has a URI of the form:

http://www.loc.gov/ark:/12025/654xz321

where 12025/654xz321  is a document within our Architecture and Recursive
Knowledge database. The problem is that some client will see that URI and
assume that it will resolve to an instance of the resource identified by the
ARK  ark:/12025/654xz321

The answer to the problem (in theory) is that the client should first know
whether www.loc.gov services ARKs. More generally, there is (should be) a
"Name Mapping Authority" discovery mechanism. (e.g. if www.loc.gov services
ARKs then it is referred to as an "Name Mapping Authority").  The ARK spec
discusses this discovery mechanism (if only theoretically). Section 4,
http://tools.ietf.org/html/draft-kunze-ark-15.

The second part of the problem, what if loc subsequently decides that it
wants to join the ARK party, though it already has unrelated URIs like
http://www.loc.gov/ark:/12025/654xz321  .

That's an easy problem (as Eric Hetzer pointed out) it can use ark.loc.gov
to service ARK requests, and as long as www.loc.gov isn't listed in the ARK
name mapping authority database, there's no conflict.

--Ray
Received on Friday, 25 July 2008 21:32:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC