[gcs-pcs-list] on using URIs

[Daniel Chudnov]

On Mar 1, 2006, at 9:03 AM, Young,Jeff (OR) wrote:

>> Then my claim (and Jeff's claim, I think) is that you're reinventing
>> OpenURL.
>
> I agree. The intention that someone might take a unAPI identifier and
> apply it outside the context of the corresponding meta link or vice
> versa crossed the line, IMO.
>
> It also strikes me that unAPI could easily be defined in terms of  
> COinS
> in conjunction with a meta link pointing at an OpenURL resolver. Using
> this approach, a server could describe the referent any way it sees  
> fit.
>
> Given these considerations, it seems clear to me that the current
> mechanism does ultimately constitute a flavor of OpenURL Lite.

Is that good?  Is that bad?  Does it change the usefulness of unAPI?   
Does it matter?

Seriously, does it matter?

Maybe it's worth recalling where unAPI came from:

   http://curtis.med.yale.edu/dchud/log/project/rogue/rogue-no.1- 
coins-pmh

It said "use a COinS with an identifier, and redirect people to an  
OAI-PMH service."  You didn't have to implement all of OAI-PMH to  
serve COinS-PMH requests.

There were several problems with COinS-PMH.  They can be summarized  
thusly:

  - It had a terrible name
  - Nobody outside of our community gets OAI-PMH or OpenURL
  - Barely anybody implemented it, so it died

Within days of unAPI rev1 being released, we had diverse  
implementations from diverse sources:

  - in java, over OpenURL
  - in java, bare servlets
  - in php, over wordpress
  - in perl, over the unholy combination of sufficiently advanced  
technology
    indistinguishable from magic that is evergreen's supercat :)
  - in python, bare code and over disparate remote APIs and OAI-PMH

That's four languages, five web frameworks, and layerings over four  
application frameworks which include two well-known library  
specifications - OAI-PMH and OpenURL.

Lots of complexity averted for end-user/developers.  I'm just saying.

   -dc