[gcs-pcs-list] before there was unAPI...

[Daniel Chudnov]

I'm *really* excited that so many folks I admire and respect and,
well, okay, I'll just say it, have little professional crushes on,
are interested enough to get involved in developing unAPI so quickly.
There must be something worthwhile in there, then, even if we don't
quite know what it will end up looking like.

I must have failed in setting the stage, however, and having done a lot
of blind groping at elephants in a past life (don't ask) it seems best to
just call a distressed leather fire hose a distressed leather fire hose
(or, maybe, a trunk?) and step back to non-spec objectives to be sure
we're starting from the same page.

The only reason this list exists is that a group of people working on
"personal collection systems", a.k.a. gather/create/share tools, met
at a fancy meeting in Baltimore a year and a half ago to compare notes 
and ended up agreeing we should keep comparing notes on a list.

A core requirement unearthed in the discussion we had way back when is
that there isn't any single obvious way to build personal collection
systems - by which we mean "personal library software" or anything
remotely like it, many examples of which are now in vogue - that
interoperate in obvious, simple ways.  Sure, there are RSS, WebDAV, OAI,
SCORM, METS, DIDLs, OpenURL, SPARQL, Atom, a few dozen sexy incompatible
popular-webapp-APIs, and the still-coming-any-day Shibboleth, but,
um, well, there, you see, that's the point.  We have all this stuff,
in all these systems, and people are building new ones every day with
their own takes on the above or wholly new ones.

But who wants sexy incompatible APIs?  I don't.  Sure, they're titillating
to query, dress in something flashy, and maybe connect with nightly in
a cronjob for a while, but ultimately they're incompatible.  They won't
last.  Your engine gets upgraded, or the API spec gets bloated with new
revisions, and after a while the excitement wears off, the windshield
cracks, somebody keys your car in the supermarket lot, and you're driving
around a six-year-old rustbucket with no trade-in value.

Do you see what I mean?  You started thinking I meant sex, but you
ended up wondering whether I should get on a waitlist for that new
hybrid sedan, didn't you.  Incompatible APIs are such a scourge that I
can't even keep a probably-too-risque-for-a-professional-list extended
metaphor compatible with itself.

I want compatible APIs, even if they're not sexy.  *Especially* if
they're not sexy.  I want a simple, five-minutes-to-implement way to
get something that interests me that I see over here into that other
thing over there which is where I put stuff.  You're in sakai, you're
on a journal fulltext site, you're tagging photos, you're streaming
podcasts, you're telling me about it in a syndication feed, and once
in a while something you do catches my fancy and I want to take it from
where you put it and keep a copy for myself in my own little hideaway or
sakai course site or music sharing social tagging whatever.  And then I
want to put copies in other places later on when the context of what's
interesting about that thing changes or becomes relevant again or it's
just been so long that now it seems kitschy (as in ha-hah, remember when
"library 2.0" was going to change the world?  how charming.).

The actual act of copying something from one place to another is fraught
with landmines.  A sketch of a masterpiece painting... a picture of a
not-yet-released concept car... 58,000 ripped-and-burnt copies of the new
Britnecca CD, a printed pdf of an obscure journal article.  Nobody here
needs that explained, nor an explanation of how the digital-copying
piece is "easier", whatever that means, because we all know it's not.
"Save a copy as..." my ass.  I want stuff that simply knows how to move
itself over from site A to service B when I ask it to, or for A and B
to figure it out for themselves, whatever, but I don't want to have to
think about it.

(Er, I mean, the hypothetical "i", not the me-that-is-trying-to-write
a spec-that-does-that, but the future-me-that-just-does-it-happily).

As far as I can tell, the only efficient way toward such a future is
if every site in the world supported a simple clipboard-copy function.
Just like on desktops... copy from here, then do something else with
it.  That's why the spec says:

  "We want one API for the most basic operations necessary to perform
  simple clipboard-copy functions across all sites."

Boil the oceans a degree, a little magic happens, and we can copy stuff
around.

But, you may ask:  "What of OAI-PMH?  ATOM?  The succinctly-named Z39.88?"

Good question.  They're all great specs.  They're all widely used.
They could all be made to do this, in theory.

The problem is this:  they're all different.  It is impossible to convince
the *whole* non-library world to implement OAI or OpenURL.  It is likewise
impossible to convince the library world to put everything under Atom.

Why?  Because none of them are simple.  Sure, compared to what came
before, they are simple in some ways... any competent programmer should
be able to build a working implementation of any of 'em in a few hours.
Or a fairly-robust implementation in a few days.  That that is true and
possible is a major accomplishment of each of these specifications.

The problem with that is that most competent programmers are already
getting paid doing other things.  We need something that incompetent
programmers can implement.  And forget this "few hours, few days"
nonsense... we want something that incompetent programmers can implement
in a few minutes.  That's right, I said it:  a few minutes.

Seriously, that's what I'm after.  A universal clipboard-copy API that
incompetent programmers can implement in a few minutes.  Anything less and
the ocean doesn't boil.  No magic happens.  I keep butchering metaphors,
and possibly escalate to more thorough offenses.

Nobody wants that.

OpenURL is great because it provides a convention to pass info that
identifies objects of interest and allows their movement between
applications or across service layers of a single app.  That's why we
worked on COinS, and that's why unAPI has a URI microfauxmat component.

OAI is great because it gives you direct access to disseminations of
objects in arbitrary formats.  That's why unAPI has a "formats"
function and something equivalent to GetRecord.

Atom is great because it's going to be nearly everywhere and it has an
in-html autodiscovery pattern that has already succeeded massively, and
because it gives you a synopsis of objects and a way to get back to host
services' for-human-rendering of those objects.  That's part of why unAPI
has a "go" function.  The other reason unAPI has a "go" function is that
it would save everybody a lot of time if service resolver knowledgebases
didn't have to track changing and incompatible linking syntaxeses.

The other great thing about OAI, Atom, and OpenURL is that because
there are so many implementations, it's likely that your own content-owning
applications already speak at least one of them.  That's why the 
unAPI spec says:

  "We also want this API to be able to be easily layered on top of other
  well-known APIs."

So if you already do Atom, OAI, SRU, OpenSearch, or whatever, an
incompetent programmer can layer unAPI over one or more of those in a
few minutes.  And everybody gets to copy stuff around.  And then we
can start to talk about pasting, but I don't think we can reasonably
do that yet until we get past the copying part, since the one will
drive demand for the other, but without the copy-function providing
supply, there is no demand for standard paste.  Or, maybe Atom's API
will be good enough for paste.  I don't know, because for 1.5 years
I've been beating my head against copy, and I'm tired of it and want
to move on.

That's the goal of unAPI.  Or, at least, that's what I see as the goal
of unAPI.

Does that help at all?

  -Dan


-- 
Daniel Chudnov
Yale Center for Medical Informatics
(203) 737-5789