Re: permanent URIs for media

Thanks for the details on XMP. xmp.iid would be covered by the bottom
row of my table
http://www.w3.org/2001/tag/2010/06/persistence-teaser.html where I
cryptically called it "cient-side mapping of urn:, ark:, etc.". The
technical solutions to the problem of chasing persistent references
automatically are not deep. The problem is what advice to give. The
TAG's advice so far has been that one should use http: URIs to name
things. I agree with you that this story isn't completely convincing.
Either the http: story needs to be fixed or something else needs to be
made to work.

My original motivation was to come up with advice to publishers
concerning RDF and OWL (e.g. as supplementary material or inline
RDFa), but any use of URIs, such as HTML, has the same problem. If we
put any weight behind one particular approach (such as UUIDs,
checksums, DOIs, permanent domains, I don't care) that won't
necessarily be decisive but it might help in improving the current
unsatisfying state of the art, in expanding the reach of web
standards, and in making the web more unified.

My question for you regarding UUIDs would be: what do you imagine the
procedure might be for, say, publishing an HTML document to the
archival record, assuming it links only to other documents that are
already in the archival record? Do you replace all http: URIs with
xmp.iid: URIs?  Or affix a "footnote" (maybe in RDFa?) mapping all the
http: URIs to xmp.iid URIs? Or add new attributes to anchor elements,
so that both the http: URI and the xmp.iid: URI are logically part of
the link? Or do you choose http: URIs such that the UUID is
recoverable from them? Any of these could be made to work... of course
when an http: link breaks you (or your children) will need to modify
all client software to be able to look up the UUIDs somewhere. And if
the http: link isn't there at the outset, you'll need the client
updates immediately (UUIDs and URNs are hyperlinks that are born
broken). I'm not ruling this out.

Jonathan

On Sun, Jun 6, 2010 at 6:28 PM, Larry Masinter <LMM@acm.org> wrote:
>  “permanence” is a desirable characteristic for many things: data, names,
> URIs, etc.
>
> However, it’s difficult to think how to “add” permanence.
>
>
>
> We are doing task A, and we have a pretty good way of doing it, but it needs
>
> characteristic X, how do we add X?
>
>
>
> I think “permanence” fits in with “security”, “reliability”, “performance”,
> “usable”:
>
> characteristics that are best approached from the negative: remove things
> that
>
> are “not X”.  To make something secure, you discover all of the
> vulnerabilities
>
> and mitigate them. To make something fast, you discover the bottlenecks and
>
> optimize them.  To make something “permanent”, you discover all of the ways
> in
>
> which might interrupt continuity and eliminate those.
>
>
>
> Permanent IDs in XMP (eXtensible Metadata Platform)
>
>
>
> http://www.adobe.com/devnet/xmp/ and in particular, page 19 of
>
> http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf
>
>
>
>
>
> XMP uses GUID-based URIs for referencing content. It is assumed that there
> is
>
> a system/index which can be used to discover content if all you have is the
>
> GUID.
>
>
>
> Each asset has at least two such identifiers:
>
> one which changes every time any edit is made by any tool (the "instance
> ID"),
>
>  and one of which does not change but refers to the entire version history
>
> (the “document ID”).  (There is a complex bit of infrastructure for
> asserting
>
> relationships between versions using History, Ingredients, and other bits
>
> of relationship metadata.)
>
>
>
> The URI scheme “xmp.iid:” is a bit reflexive.
>
>
>
>    xmp.iid:b9db20421f30bb3fe10e5f90
>
>
>
> is a URI which identifies the file that has the following attribute/value
>
> pair in its metadata:
>
>
>
>          xmpMM:InstanceId = “xmp.iid:b9db20421f30bb3fe10e5f90”
>
>
>
> (xmpMM is the XML namespace prefix used by the XMP media management schema
>
>  of metadata properties.)
>
>
>
>
>
> Similarly
>
>
>
>     xmp.did:b9db20421f30bb3fe10e5f90
>
>
>
> is a URI which identifies any/all/the most recent file that has the
> following
>
> attribute/value pair in its metadata:
>
>
>
>          xmpMM:DocumentId = “xmp.did:b9db20421f30bb3fe10e5f90”
>
>
>
> xmp.iid and xmp.did URIs are used only for files that have XMP actually
>
> stored in the file, not in sidecar files. Files that do not have embedded
>
> XMP still have InstanceID and DocumentID, but not in this form. Some
>
> documents that do have embedded XMP might still have a DocumentID
>
> that does not use xmp.did, because the document started out as a file
>
> without XMP but with some other kind of unique document identifier.
>
>
>
> These are URIs (that is, they uniformly identify resources), but they
>
> are only useful as URLs (Uniform Resource Locators) if there is an index
>
> of files with XMP indexed by the IDs found within them. In the case
>
> of xmp.did:, it might be necessary to examine modification dates
>
> and history to determine which is the latest of multiple instances
>
> with the same document ID.

Received on Sunday, 6 June 2010 22:11:08 UTC