The word ’technical’ hasn’t always had a great reputation. Think of phrases like ’technically correct’, ’technical details’, or ‘acquitted on a technicality’. It’s easier to think of more negative uses than positive ones. I think there are a couple of reasons for that.
Technical vs technological
People often mix up technical with technological. Scholarly metadata systems are software, and software developers need to know about a huge range of topics, from algorithms to databases to cloud infrastructure, let alone the domain they are working in. It can be difficult for ‘outsiders’ to tell where the internal boundaries lie. This can create a fog of uncertainty, which makes it hard for ’non-technical’ stakeholders to participate.
For example, the performance of a database is dependent on the infrastructure (CPU, RAM, network, disk) but also on the characteristics of the data (data modelling and index performance, based on the the real-world size and shape of the data). Some of these are the sole concern of the developer. But understanding the real-world data depends on an understanding of how the community uses it and why.
Developers must understand the whole spectrum. There’s a healthy overlap with the domain knowledge of stakeholders. Developers are responsible for translating this domain knowledge, but they should do so in an accessible way.
Stuck in the details
The second reason is that once people start building systems, the construction activity takes on a life of its own. If there’s a demand for widgets, there’s a demand for widget-makers. And the widget-makers will develop their own language and techniques that get right into the core details of widgets.
In order to build a metadata system, you have to encode structure and understanding of the task to be done. To represent metadata about books, you need to know how books are structured, how chapters get published, and build that into the software.
This encoding can get stuck, which can lead to frustrating inflexibilities. If you built a model of book metadata and didn’t know that different chapters can have different authors, for example, then it would break the first time you encounter such a book. Sometimes you can foresee these situations, sometimes you can’t. But the real test of the implementation is whether it’s possible to change the model after you started. If you get this wrong, you can exclude new or more diverse stakeholders from participation.
In the world of scholarly publishing infrastructure, the API schema is technical, as it’s concerned with how concepts from scholarly publishing are represented.
But is it technological and beyond the reach of non-developers?
I’d argue that the code to make the API work is, but the actual API schema isn’t.
Skills for the job
Oxford Learners Dictionary (we’re all learners!) defines ’technical’ as:
connected with the skills needed for a particular job, sport, art, etc.
No mention of infernal machines. Just what you need to know to do the job.
For system-building, an understanding of the scholarly publishing domain is necessary. So is an understanding of how you translate that understanding into technology. There’s a lot to cover, including metadata formats, publishing workflows, identifier types, and the reason things are the way they are.
It’s this overlap of scholarly publishing and software engineering expertise that I want to explore here. Get in contact if you want to discuss scholarly metadata, or need some help on your project!