[gcs-pcs-list] on using URIs

[Young,Jeff (OR)]

I said "Ross" but I meant "Rob". Sorry.

> -----Original Message-----
> From: gcs-pcs-list-bounces at cipolo.med.yale.edu [mailto:gcs-pcs-list-
> bounces at cipolo.med.yale.edu] On Behalf Of Young,Jeff (OR)
> Sent: Wednesday, March 01, 2006 2:52 PM
> To: Xiaoming Liu; Ross Singer
> Cc: GCS-PCS list
> Subject: RE: [gcs-pcs-list] on using URIs
> 
> If I've convinced Dan that unAPI can be easily reconciled with OpenURL
> (see previous posts), then the arguments about URIs should become
moot.
> Ross' desire for "private-data" referents might then become an easier
> sell.
> 
> Jeff
> 
> > -----Original Message-----
> > From: gcs-pcs-list-bounces at cipolo.med.yale.edu [mailto:gcs-pcs-list-
> > bounces at cipolo.med.yale.edu] On Behalf Of Xiaoming Liu
> > Sent: Wednesday, March 01, 2006 2:42 PM
> > To: Ross Singer
> > Cc: GCS-PCS list
> > Subject: Re: [gcs-pcs-list] on using URIs
> >
> > I am trying to come up a use case that unapi can be used
differently,
> > and see if it makes some sense.
> >
> > Say college A has unique course code, such as cs101, however they
all
> > appear differently in univeristy, department, faculty, and students
> web
> > site, and hence it's diffcult to find related information about a
> course.
> >
> > Now college A decides to use consistent tag URI for cs101, such as
> > tag:A,2001-01-01:/course/cs101, and all web pages support unapi when
> they
> > reference this URI. In this case, the URI is an agreement inside of
> the
> > university, and a student may install a greasymonkey script, it
> contains
> > all courses he is taking, so whenever a web page contains his
selected
> > course, the related information will highlight, and perhaps a link
to
> > unapi is added.
> >
> > I think this demonstrate two points: the chosen URI is only
meaningful
> in
> > college A, however it's very useful; and the application is a
> > simple scrips of scanning web page and highlight users' interest, I
am
> not
> > sure how close this is associated with OpenURL.
> >
> > Now maybe college B in same town may decide to share course code
with
> > college A, suddently these URIs are meaningful in more than one
> campus. So
> > this illustrates that nature of your URIs can be slowly changed, so
> > perhaps better be prepared.
> >
> > I hope this example illustrates two points: (a) the nature of your
URI
> > can be changed, so be prepared ;-) (b) unapi is simple and just do
one
> > thing well, so like unix philophy, its scope of application is not
> > strictly limited by current protocol or practice, therefore not an
> > OpenURL lite or OAI-PMH lite.
> >
> > xiaoming
> >
> >
> > On Wed, 1 Mar 2006, Ross Singer wrote:
> >
> > > There's something else to note here... In the Evergreen scenario,
> the
> > > suggestion is to use ISxN or some other standard identifier rather
> than
> > local
> > > identifier, but, frankly, this is much more complicated on, say,
> /my/
> > opac.
> > >
> > > So, are tag uris to be discouraged?  Is it functionally any
> different
> > than
> > > just using a local identifier?
> > >
> > > Also, I'm still not sure I'm buying Evergreen using
> urn:isbn:123456789X
> > in
> > > this case.  It's /not/ referring to 123456789X, it's (possibly)
> > referring to
> > > 123456789X /or something sort of like it/.  urn:isbn:123456789X
> seems
> > pretty
> > > explicit.  /Maybe/ I am just looking for the title/author, but
maybe
> I'm
> > > looking for publisher city or date.  ISBN concordance is /bad/ in
> this
> > case.
> > >
> > > It's early, though, it's probable that I read that wrong.
> > >
> > > Anyway, I need some clarity on the tag v. info uri v. url issue...
> > > Basically, I don't want to waste my time w/r/t code either over-
> > analyzing the
> > > problem or undoing 'under-analyzing' it.
> > >
> > > -Ross.
> > >
> > > On Mar 1, 2006, at 7:00 AM, Robert Sanderson 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
> > >>
> > >
> > > _______________________________________________
> > > gcs-pcs-list mailing list
> > > gcs-pcs-list at cipolo.med.yale.edu
> > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
> > >
> >
> > --
> > Xiaoming
> >
> > _______________________________________________
> > gcs-pcs-list mailing list
> > gcs-pcs-list at cipolo.med.yale.edu
> > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
> _______________________________________________
> gcs-pcs-list mailing list
> gcs-pcs-list at cipolo.med.yale.edu
> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list