[gcs-pcs-list] on using URIs

[Ross Singer]

One more thing... couldn't the standard identifier be gleaned from the 
unAPIed data?

Also, I remembered how my boss pronounced it:
You-un-appy.

-Ross.

On Mar 1, 2006, at 7:48 AM, 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
>