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

[Mike Rylander]

On 3/6/06, Xiaoming Liu <liu_x at lanl.gov> wrote:
> On Mon, 6 Mar 2006, Mike Rylander wrote:
>
> > 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.
> >
>
> I indeed think many confusions arose due to the mixing of implmentation
> vs. spec.
>
> unAPI spec only describes a protocol. How to use it is out of the scope of
> spec definition. Let's take the example of Web, in one case, say if you
> run a google of all unAPI resources, you may only care about current
> snapshot and deliver a search service; in another case, say if I am
> building an Internet Archive of all unAPI resources, I do care where(unapi
> baseURL) and when (response time) that I got them; in a third case, I may
> build my own server/client inside of firewall, so how to deal with it is
> solely my business.
>

Sure.  The IA based on unAPI would be very interesting. :)

> With all those possibilities, I don't think you want to limit the
> capability of unAPI to some pre-defined profiles, such as private or
> public, or transparent. This is really a decision of unAPI server or
> service implementation. I may choose well-known URIs when I intend to have
> the world use my data; or I can choose any private URIs if I want two
> linux box talk to each other. Again, there are lots of nice discussions
> about URI beyond scope of unAPI.

I may not be explaining myself clearly ...  I don't want to resrict
what a server can produce as identifiers, and I don't want to restrict
what users can do with those identifiers.  I just want the spec to say
that the only garentee about an unAPI identifier is that it's valid
for use right now against the <LINK>ed service and no other
expectation can be made ... eg, this thing you have is known to us,
now, and at <LINK>, and that's potentially /all/ that <LINK> knows
about.  Whatever else you (the user) do is up to you.

If this is self-evident then, please, someone shoot me now.  ;)  The
non-obviousness of this point seems to me to be what today's bru-ha-ha
stemmed from (for the most part).

>
> xiaoming
>


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