Finally had more time to work on the unAPI copy / Atom paste implementation in unalog. At this point, unalog will examine a "robust" jsondidl object [1] saved with a unalog entry for alternate unAPI-formats, will provide links back out to them (with proper attributes rel="alternate" and type="[mimetype as per unapi]" on the anchors), and will display a small image for every saved entry if the entry contains at least one image of size 100x100 or smaller. Here's a screenshot:

• [2]

I've tweaked the jsondidl model and the output from OPA [3] (and updated the version running at opa.onebiglibrary.net [4]) to now also include attributes "url" and "unapi_source" on resources. "unapi_source" is a direct link back to the unAPI URL from which the resource (in its specific format) came. "url" is a direct link to the original URL to which OPA redirects for unAPI format redirects. This allows unalog to both (a) provide links back to unalog users to the unAPI service for every format, and (b) render an item directly from its source link if that source link is public, rather than having to bounce back through the unAPI service.

Perhaps unalog should publish that image to the world right from its own stored copy. But, I'm not sure if that's a good idea... I don't want people using unalog.com to republish arbitrary data objects -- especially images -- for which they might not have the rights to do so. Users *themselves* should be able to see their own saved data, and maybe small groups of their friends or colleagues (unalog's had public and private groups since early 2004, so that shouldn't be hard to implement). But not arbitrary users looking at other users' images. But then again, there's nothing wrong with one user being given unAPI links back to an image; if the user can obtain rights to see the source data, they can navigate to it for themselves.

Working on this raises tons of issues. Here's a working list.

• Should users who've saved robust objects get sub-object bitstream access via a public url? How would that even work?
• Need to reconcile the distinction between the URI for entries to show arbitrary entries and the URI for Atom-GET. I'm very confused about whether these are the same things or not, and that unalog entries are going to become jsondidl objects just confuses me further w/r/to this issue.
• Which file formats other than images should receive "extra rendering treatment" in the public unalog UI? Like, if there's dublin core metadata, should it just render that inline?
• I think I will likely break down and agree with the sentiment that unAPI needs to be able to handle UNAPI?uri=FOO&uri=SPAM&uri=BAKEDBEANS calls with multiple format lists in the response. Separate hits for each of multiple URIs per page is just evil waiting to happen.
• Metadata pass-through: when additional metadata is available on a unAPI source object like a flickr image (description, "owner", created/updated dates, tags, etc.), what is the proper way for OPA to pass it through to the unAPI client? For flickr images, for instance, I want the option to auto-populate the unalog tags for an entry with that image source's flickr tags. Or the same for a blog entry marked up in hAtom, etc. What's the best approach... should the flickr metadata blob become another jsondidl resource, or a parallel item in its own right? For the hAtom blog entry, should OPA translate to AtomAtom? If not, should unalog translate to AtomAtom and render metadata from that? It gets tricky that way.

Not to mention that I still need to drop everything for a few days to completely rewrite the unalog "save this page/link" screen to incorporate all these features for pages with unAPI URIs and microformats, to newly bundle all the data up into a jsondidl via javascript and paste via Atom, among other things.

But first, let us retell the story of Exodus...