[gcs-pcs-list] on using URIs

[Robert Sanderson]

On Tue, 28 Feb 2006, Daniel Chudnov wrote:
>The case for URIs includes:

> - they refer to the same thing across applications

Which is great, but not interesting for unapi surely where the use case
is 'I want this that I see now' not 'I want the thing identified by X'

> - they imply some measure of identifier persistence

Which is a disadvantage because it means that dynamic content which is
not persistent is less appropriate for unapi.  If the use case is 'I
want what I see now' (copy), not 'I want to refer back to this in the
future' (citation), then this means that we're adding hindrances.

> - where objects might be copied around using unAPI there is probably
>   already some sort of implication of object+id persistence

Why?

>Fwiw, we're getting to the point where we should be weighing decisions
>more and more w/r/to implemented code.  So, from the point of view of
>the projects for which I'm using unAPI...

Well, my code says that it's more complicated to put record identifier
into a fake URI, and I think that Mike's code says the same thing.


> - it is easy to map specific identifier patterns to specific webapps
> - without the standard URI prefix patterns, it might be impossible
>   to efficiently assign a handler to a particular arbitrary identifier

Isn't that a resolver, rather than a copy/paste format?

> - having full URI patterns makes it easy to use a library like OPA
>   to resolve ids
Which is acting as a resolver, effectively.

> - using full URIs makes it more likely that different pasted-in
>   stuff can refer to the same thing consistently, e.g. if user1 writes
>   about a book in a blog, user2 saves an amazon book link, and user3
>   saves an OPAC record for the book, unalog can collate all three around
>   the URI (as opposed to randomly differing variants on ISBNs)

In the 'I want this thing I see' mode, this isn't important.  As soon as
you get past that, then you're reinventing openURL.

> - unalog itself referring to an object by its URI allows potentially
>   better precision in service/content resolution, e.g. queries for
>   object "12345" might return wildly different things with (unlike
>   w/tagging) zero potential value to be derived from overlaps across
>   disparate objects

You even use the word resolution here.  I won't restate the obvious :)

>Another good reason to require URIs is that bridging other protocols
>(APP, OpenURL, OpenSearch/SRU) might be easier if implementers already
>have fully-specified URIs.

Ditto.

>As for the Evergreen blog post:  Mike, I'd suggest that what you want
>there isn't some tag or other made-up URI for your internal record
>identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant
>for the item in your catalog (or an ISSN, etc.), unless an item in the
>catalog has no known public identifier already.

Not only is ISBN not consistently available, it's also not consistently
unique.

> - content identifiers represent publicly-known identifiers that are
>   independent of system implementations.  all systems dealing with
>   the same content item would use the same content identifier.  some
>   examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers,
>   etc.  these are probably at least "precious" or "normal", to use
>   Xiaoming's formulation.

But you're dealing with one system.

> - package and datastream identifiers represent specific-to-an-
>   application identifiers that aren't necessarily public or known
>   outside of the system itself.  maybe they are, maybe they aren't.
>   some examples would be unalog entry ids, flickr image file URLs,
>   repository bitstream uuids, etc.

>imho unAPI is all about content identifiers.  Or, rather, you could use
>the other kinds of identifiers with it, but if it really takes off as
>an cross-application spec, it will be through the common use of content
>identifiers, most of which can be usefully rendered as URIs.

Then my claim (and Jeff's claim, I think) is that you're reinventing
OpenURL.

Rob