This is a rather ephemeral statement of position-of-the-month on the future of interoperability standards, for the CETIS meeting on 24th September. I have just three things to note: two issues from helping to create the EuroLMAI CEN Workshop Agreement (moving towards an EN European Standard) and one issue from Leap2A.

1. Keep pressing for those URIs.

For EuroLMAI, we want URIs for our classes and properties, so that we can be good citizens of the Semantic Web. How hard is that? Well, first, whose domain are they going to be in? As this is a prospective CEN standard, one would have thought they would be keen to help by providing suitable URIs. Maybe they are, and maybe they will provide them, but, being a European institution, it does seem to take time, and plenty of it! It looks like we will have to use a PURL server like purl.org instead, at least for the time being. That is sort of OK, but there is a time penalty for accessing things through a PURL server, so it does slow things down and have the potential for increased frustration. And it doesn’t look half as official: there is some PR cost.

2. Do keep a clear conceptual model, as it helps later on as well.

In the EuroLM work, I was always keen on, and played a large part in, getting a good conceptual model with good definitions, meant to serve as a relatively firm foundation on which to build the specifications and standards. Recent experience suggests that not only is this useful in the initial work, but it is also useful to have the conceptual model to hand when checking the detail of the spec. My own experience reflects what may be obvious, that it is easy, when revising a draft much later on, to forget why something was done in a certain way. A little doubt in the mind, and it is too easy to edit something back to what looks like a common-sense position, but actually represents something that you carefully argued against on the basis of having taken the pains to build that clear and agreed conceptual model. (The problem being that we all habitually take our own personal cognitive short cuts, which may seem like common sense, and too often these end up being represented in formal structures when they shouldn’t be.)

3. Prepare better for people building on your spec.

OK, so your new spec is really gaining ground. You’ve done a fair job of capturing requirements and representing structures that everyone can relate to. You’ve not built a monster, but something that covers more or less just what it needs to cover, coherently. So now you shouldn’t be surprised that people want to take your spec and adapt it to their needs. Perhaps they will need to add a class or two of their own, perhaps some of their own properties, perhaps some categories or vocabularies, which may overlap with the default ones you have provided with the spec. How are you going to recommend that they proceed, in each case? This is a real question that is taxing me with Leap2A at the moment, and is a learning experience, as I find I am not as well prepared as I would have liked to be. I’d like to be able to document a page on “Building on Leap2A”, which might perhaps refer to the DCMI “Singapore Framework”.