[gcs-pcs-list] on using URIs

[Xiaoming Liu]

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