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

[Mike Rylander]

On 3/6/06, Daniel Chudnov <daniel.chudnov at yale.edu> wrote:
> Y'all are going to have to gang up something fierce to convince me
> that the unAPI spec itself should say *anything* about the meaning of
> URIs or the meaning of patterns of URIs and specific unAPI servers.
>

I want to say that the URIs /don't mean anything/.  Any resource you
fetch using an URI you get from me may have no relation whatsoever to
any other site's resource identified by an identical URI (where
identical is defined by strcmp (3)).

> unAPI services and clients should not be forced into a mode of
> operating on objects anywhere that is mandated to be at any specific
> node/level in the FRBR work-expression-manifestation-item model.  Or
> that any fetched object with any kind of URI from any unAPI server
> should be expected to remain identical over time or space.  Or that
> the only "correct" dissemination for some URI and FORMAT is from some
> specific server.
>

Sure.  The spec doesn't say that, and it, apparently, caused some
confusion.  It is my belief that the confusion arose due to the mixing
of implementation concepts (how a "real" OpenURL server works) versus
the actual purpose of the unAPI spec.

> My premise behind wanting to work on this and related efforts is to
> simplify movement of information across applications... not to make
> moved information more rigorous, or more verifiable, or more
> trustworthy, or more authoritative, or any of that, just simpler.
> It's up to implementors to make their own choices about expectations
> and assumptions, including whether URIs have constructable meaning or
> not, or whether objects should be expected to stay the same or not.
>

Sure.  I don't care about big-a Authoritative, just little-a
authoritative HERE (from this page).

> If this is what you meant, cool.
>

umm... I think it is.  The important part of unapi, the end result we
desire, is the resource, and /not/ the
URI/identifier/handle/pointer/thing-that-comes-after-"uri="-in-the-url.
 My point, though, is about user expectations: unAPI identifiers
embedded in a page should only be expected to "work" with the service
named in the unAPI <LINK> for the page you are viewing, and (so far as
you know) /only/ those identifiers.  More may work, and they may work
elsewhere, but from an unAPI viewpoint the user cannot know that.

If the service at <LINK> is a resolver, just use OpenURL.  If it's
specifically a retrieval mechanism for things hosted behind it
(alternate formats for things you can already get to), and exposed via
unAPI spans, then we should codify that ...

It's about the "service level", if you like.  OpenURL provides more
flexibility, but we don't want that (I think).  We want "gimme that
thing you published an identifier for as MODS (or oai_dc, or MARCXML,
or PDF, or whatever)" ... we don't want "do you have ISBN 1234567890X
in PDF format?" ... right?

> Mess is lore!
>
>    -Dan
>
>
> p.s. not that this isn't a perfect discussion for one or more FAQs... :)
>


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