[gcs-pcs-list] on using URIs

Wed Mar 1 10:18:06 EST 2006

I believe Rob hits on an important base decision point for unAPI: Should the
idea of identifier-to-resource persistence be accommodated in the spec? If
so, I don¹t think the current spec accomplishes that, because resources may
change over time, even if their identifiers remain the same. I was of the
mindset that unAPI accomplished a copy-by-value function, not a
copy-by-reference, but maybe I¹m wrong about the intent. If we are looking
at a copy-by-reference, then the spec needs to include a more complicated
identifier scheme, and I think that¹s opening up a can of worms.

That being said, there may be overlaying applications, which, used on top of
unAPI, provide additional functions, such as identifier-to-resource
persistence. If we look at how unAPI might be extended through the
additional layering of applications, as opposed to extending the spec
itself, we can keep it simple and clean.

-- jaf

On 3/1/06 4:00 AM, "Robert Sanderson" <azaroth at liverpool.ac.uk> wrote:

> 
> 
> 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
> _______________________________________________
> gcs-pcs-list mailing list
> gcs-pcs-list at cipolo.med.yale.edu
> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
> 

-- jaf

===============================================
Jeremy Frumkin
The Gray Chair for Innovative Library Services
121 The Valley Library, Oregon State University
Corvallis OR 97331-4501

Jeremy.Frumkin at oregonstate.edu

541.737.9928
541.737.3453 (Fax)
541.230.4483 (Cell)
===============================================
" Without ambition one starts nothing. Without work one finishes nothing. "
- Emerson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060301/c5329d1b/attachment.htm