[gcs-pcs-list] on using URIs

[Young,Jeff (OR)]

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