τεχνοσοφια

Thanks to a clean patch from Sean Coates, I'm releasing v1.5 of JSONovich. It now supports code-folding. Great hack, Sean!

I can hardly believe it's been eight months since I last wrote about the NISO I2 project. A lot has changed since then[1]. I continue to work on I2 however; they won't get rid of me that easily.

In the last post, I wrote:

The next step is to build upon the report to draw yet more conclusions from the data — there's an awful lot there — and flesh out some repository use cases for institutional identifiers. The I2 core group is moving quickly towards finalizing identifier metadata elements so that a standard may be drafted, and I think having some use cases documented will help drive the standard in a direction the community can get behind.

Since that time, the three scenario groups — Electronic Resources; Institutional Repositories and Learning Management Systems; and Library Resource Management — have concluded their work. The work of the scenario groups included surveys of over 300 people working in these fields. The survey results have been analyzed and reports were posted on the NISO website. These reports have been used to flesh out use cases for an institutional identifier. Upon completion of this work, the scenario groups were disbanded and work continued in a broader I2 working group.

The I2 working group has concentrated its work on analysis of similar standards and, as I alluded to earlier, significant effort has gone into defining core metadata to identify institutions, such as institution name, institution type, location information, variant identifiers, domain name(s), URL(s), and (optionally-typed) relationships to other institutions. During these discussions it was difficult for me to hear the issues and needs around I2's metadata and identifiers without linked data springing to mind.

While we are designing a standard and not a system or a service per se, it seems useful to include in the standard an informative section about implementation and architecture[2]; I find that reading standards is much easier on the brain when you get not only the standard itself but some examples of implementation, and that will be true as well, one hopes, of I2 standard implementers. To that end, the group will be producing an XML schema of the I2 metadata elements and also an RDF schema.

I have been working on the RDF for I2 on and off for the past month or two. Below are my impressions, as someone who is new to modeling in RDF, and the procedures I used to produce the draft RDF schema.
Continue reading…

Notes

1. I've moved and changed jobs, in fact [↩]
2. This practice seems more or less common in my (admittedly limited) experience, cf. the unAPI specification. [↩]

For those of you who use JSONovich rather than, e.g., JSONView, I've tweaked the plugin (now at version 1.3) to work with Firefox 3.6.

I updated the version up on the Mozilla site as well, but things tend to stay in the sandbox for months at a time. (For instance, I submitted version 1.2 back in November, and it's not yet available.) Feel free to install via my page.

I am not certain if this is a good idea or not, but I decided to set up a "work blog" as I set off on my new path as a digital library architect. The lines between this blog and that blog are fuzzy — most lines are, in my eyes — so bear with me. I've never been a prolific writer — it's always a chore, an activity I simultaneously want to do more of, and do better, and also struggle mightily with. (It's the public school education? HAR HAR!) But even so, the posts here may slow yet more. Or maybe that will be true of the new blog. We shall see.

I've found that microblogging has largely filled the blogging gap for me; I'm more comfortable, somehow, posting smaller, more easily digestible "thoughtlets" via Twitter/identi.ca/Facebook. Perhaps I've succumbed to attention deficit disorder, flitting from one tiny undeveloped idea to the next. It's probable but I digress.

If you're interested, you can follow along as I grapple with questions about digital library architecture. Comments are most welcome, both here and there, as always.

As far as I'm concerned, the most exciting developments this year in repositories and digital curation have come out of the California Digital Library. It has been impossible not to notice their papers and presentations. Put simply, their idea is that digital curation is enabled by "micro-services" built upon well-known abstractions such as the filesystem. The benefits are obvious: filesystem tools are ubiquitous and cross-platform, and there are strong market forces to ensure the filesystem persists. The idea is radically simple and straightforward, though many questions remain about such a paradigm. I'll return to those later.

If you have not yet taken a look at CDL's curation micro-service specifications, most of which may be printed on as few as one or two sheets of paper, see the Digital Library Building Blocks.

My co-workers in the LC Repository Development Center have been chatting about these specs on and off throughout the year. After months of procrastinating, I finally read all of the specs on Thursday; it's wonderful that you can do so in the course of one reading session, I might add. Yesterday a bunch of us RDCers got together to chat (informally) about the specs: what they're for, how they work, and how they interact with one another. I learn by doing, by examples, so I combed through each of the specs in advance of our meeting and tried to construct a minimal repository[1] based on micro-services.
Continue reading…

Notes

1. Perhaps it's more in line with the specs to refer to this space as "a managed filesystem that drives repository and curation services," given the CDL philosophy that preservation is not a place/repository. But it's easier to say "repository," so there you go. [↩]