[gcs-pcs-list] big day in #code4lib

[Mike Rylander]

A 4+ hour conversation started today around the real differences
between OpenURL and unAPI.  Excepting some initial ... um ...
emotional/evangelical responses from several interested parties (me
included), it was all very civil, and we managed to come to a truce,
if not an agreement, on some things.  What follows is my
interpretation of the discussion, distilled, for your viewing
pleasure, from about 400K of scrollback buffer.

1) unAPI can be implemented on top of an OpenURL resolver
2) working code shows that it seems to be useful to do this
3) working code also shows that unAPI needn't be implemented this way
(OpenILS, WP)
4) there is some confusion as to whether these implementations expose
unAPI to be a resolver in the real sense -- I contend that this is
mixing the purpose of unAPI with implementation details
5) the use of URI for resource identifiers is confusing, with regard
to identifier opacity/transparency

It is generally agreed (I think, it got a few ++s) that resource
identifiers, be they URIs or not (future debate), should be explicitly
stated to be opaque in the spec.  This solves (at least) a few
problems:

* asking for a MARC record by ISBN seems counter intuitive to some --
"shouldn't it return the full text of the item?"

* if a user sees an unqualified urn:isbn:xxxxxxxx URI, can they assume
it means the same thing across different sites?  Or for that matter,
across time on the same site? (think: upgrading a MARC record after
the Encoding Level changes)

* can a user ask an unapi server to retrieve something by handing it
an identifier for a resourse that the server did not publish along
with its <LINK>?


If the spec were to say "identifiers, regardless of format, are opaque
beyond the walls of the <link>ed server, and across time (granular to
some basic expectation of stability -- eg, today?)", then all of these
questions are moot.  The identifier has /no intrinsic meaning/, in the
unAPI sense, outside the context of the page it appeared on.

Now for some editorializing: I think there is merit in using well-know
URIs to fetch resources.  If a site has MARCXML and OAI_DC, but the
user wants MODS, they could go to Amazon (or Evergreen ;) ) to get
that representation.  But they would be fetching a /different but
similar/ thing, not an alternate representations of the unAPI-linked
item, and it's an expectation that should be explicitly outside the
scope of unAPI.

Summing up, here are my thoughts:  Should there exist any expectation,
in terms of an unAPI services' ability to retrieve resources, that an
identifier can be constructed by a client?  If not, then IMHO the
identifiers should be said to be opaque as far as their use in unAPI
goes, whether or not they are parsable/understandable by humans.

Proposal for adding a vote to the queue:  Should the unAPI spec say
explicitly that all unAPI identifiers, for the purpose of unAPI
resource retrieval, are opaque and that the user should have no
expectation that said identifiers are valid/useful/meaningful beyond
the scope of the <LINK>ed retriever, and that the identifiers served
are the extent of the known universe so far as that <LINK>ed retriever
is concerned?

I'll leave it to someone else to clarify that if we want to vote on it ...

--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org