[gcs-pcs-list] on using URIs

[Daniel Chudnov]

Though tit-for-tat is a fine strategy in game theory, forgive me for  
not going fully point by point again here. :)


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'

I think unAPI is about asking "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.

I think that's right.  Especially in that it's not a hard-and-fast  
rule... it's just less appropriate.



>> - 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?

Oh isn't it a little young to be assigning labels? :P

If it's a resolver, it's primarily a direct content resolver, not a  
deferred service resolver.  But does that matter?


>> - 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.

Er, no, I rather like openurl as it is, thank you, though I could  
stand it being a little simpler. :)

I think it might be a mistake for all of us to be so focused on this  
right now when we haven't built any apps that move data around.  The  
issues will become much clearer after those start popping up.


> Not only is ISBN not consistently available, it's also not  
> consistently
> unique.

No, it's not, and we can't solve either problem, but we can use it  
when it's appropriate.


>> - 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.

Um, no, I'm not.  I just haven't been able to show you the other  
system yet. :)

   -Dan