Building any kind of functioning service requires an initial assemblage of assumptions. Who’s the user? What do they expect in the way of service and interaction? Where do we start to engage them in the enterprise? I’ve always been a strong believer in diverse work teams, with a variety of backgrounds and experience brought to the table. Of course the messy part of diversity comes when there’s a need to come to some consensus about priorities and approaches.

Jon and I have been playing this clash of cultures out in the planning for the NSDL Registry and I thought it would be good if we exposed these differences here where others might be tempted to weigh in on one side or another and help us move forward. At the risk of seeming stubbornly wedded to my own point of view, I’m going to give his short shrift (I made him promise to post a reply, and I’m sure he’ll do it).

One of the big questions for us is how does our view of our users and their capabilities translate into a set of development priorities? Our proposal identified a small number of NSDL projects that we knew had an interest and motivation to work with us to develop this, and they’ve been very generous, sending us some of their vocabularies (or links to them) so we could get them encoded and have a body of vocabularies and terms to start with. Early on we set up a survey that we asked folks to take that we hoped would give us a start on testing our assumptions (it’s linked on the front page of our public website: http://purl.org/nsdlregistry/). As is so often the case, we got very few responses–I think they get the notion of registries at some level, and think it’s a “good thing,” but don’t have much of an idea what it might mean for them in real terms. So we’re back to what’s in our own heads.

And what is that? Probably because I’m a librarian I tend to focus more on human usage, and for me that’s of two basic types. There’s the user who comes to the registry to search or browse for vocabularies for a project or specific need, and then there’s the user who participates as someone who registers a vocabulary or maintains same. It’s certainly the case that there will be machine interactions that roughly parallel both kinds of human user interactions, and where Jon and I usually go aground is in determining which comes first, the chicken (the human) or the egg (the machine). Trust me, I did not make this analogy up just this minute–we talk this way when we argue about it!

My reluctance to put an initial focus on input and update by files rather than via human users has two main parts. Firstly, I’d like to ensure that we have something to engage our human users fairly early on, and not just on the search/browse end. Particularly for those who gave us files to begin with (but are not, I believe, expecting to continue to interact with the registry on that basis), there will likely be changes that need to be made because of the passage of time. Introducing a simple user interface to allow them to update their vocabularies will give us a valuable opportunity to interact with them and test our model of interaction with human maintainers. We also need to know how much of the information we’ll be capturing about change in terms and concepts is important to them and needs to be displayed or easily available.

Secondly, we also need to understand better what our role is vis a vis enforcement of proper practices, and how to interact with vocabulary owners around problem issues. My usual preference is to spend some early intense learning time monitoring fairly closely what happens, and following through on things that look like problems. Once I’ve done that for a while, gotten bored and overwhelmed, I’ll hopefully know enough to be able to make some shifts in expectations and policies, and also be inclined to specify a substitute process that’s programmable. This may not be ideal, and Jon always worries that I’m going to get too used to being Empress of the Registry and not be willing to pull back when the time comes. Granted, we’ve been through a few of these cycles before, but I understand at the gut level and the intellectual level that this beast can’t be too reliant on human enforcement to work—some appropriate balance has to be achieved. For me, I can’t figure it out from 50,000 feet, I have to get in there with the hip boots, and get muddy.

I may be wrong, but getting muddy with information input by humans seems a bit more manageable than dealing with potentially large-ish files that will likely need translation and new evaluation techniques to figure out. Sure, we can do that, but I’m not sure it will give us much more than bigger numbers, and that may be too high a price to pay, and leave us no wiser.

It would sure help if we had a better read on whether users were prepared and willing to deal with update by file—but unfortunately we don’t. My concern is that those with the technical chops to work with us on file-based updating may not have sufficient knowledge or interest in vocabularies and we’ll get either nothing but lists of terms with no structure, or something that I would be tempted to put in the category of “dog’s dinner.” At least starting with a human at the wheel, I have some hope of immediate feedback, the “teachable moment” and perhaps the possibility of learning enough to get into the machine interactions with a better level of confidence.

So now we’ll just see how long it takes Jon to get his oar in …