Here is a placeholder link for the structure of jxj files.
This document intends to describe an evolution of thinking as to the concepts and metaphors which can structure a user's experience and unify the overlying services provided by museum people and departments with the underlying services provided by machines.
This thinking is inchoate: help and advice will be gratefully received. Edit away!
"Nouns" and "Verbs"
The manipulated things within a traditional CMS are typically records of various kinds, recording object entry, loans, and so on. However, SPECTRUM is organised around procedures. What does it mean to produce a SPECTRUM-oriented CMS? It seems to me that, in essence it means one which is procedure oriented (or in technical terms, workflow oriented).
Document Management Systems and Photograph Management Systems, such as Nuxeo EP, KnowledgeTree, Canto Cumulus, etc, take this to an extreme where the process of creating an object itself is largely seen as external to the application, the management software principally intervening in the procedure domain. There are two big differences between our application and DMSes.
First, there is no widely accepted, pervasive software for creating and manipulating individual museum records (though obviously there is software which could be used) (as for Photoshop with photographs, Word for documents). It would seem to many people like missing functionality if a CMS were incapable of fully editing museum records. We clearly need to provide record-editing functionality as-well as process management.
Secondly, DMSs are typically aimed at business or creative-industry buyers. This affects the terminology and structure of the application to the extent that they may be barely recognisable to the museum community.
Neither of these differences preclude the use of DMSs as underlying technology, but they differentiate a Museum CMS from DMSs as out-of-the-box applications.
Keen to avoid colliding terminology ("object", "record", "procedure" can mean so much), I'll baptise these concepts
- Nouns: things which the user sees as "the things within the CMS" which are being manipulated by the museum, typically records of various kinds.
- Verbs: processes which a user undertakes to alter the inventory of "Nouns" within the CMS.
By analogy with a spreadsheet application, a Noun would be a particular spreadsheet, whereas a Verb would include wizards which took you through transformative steps upon the data.
Here a Noun is an Object Record view which shows you an Object Record (and may allow simple editing and correction), whereas a Verb would include "Object Entry" which would guide you through the steps of creating an Object Record.
(See attached image).
Creative Bureaucracy Infrastructure
To help allow the creation of Nouns and Verbs for SPECTRUM records and procedures, we need to create an infrastructure to allow a "bureaucracy" to be created. The exact contents of the forms and procedures must be customisable, initially by CMS integrators, but ultimately through an admin user interface. So, for example, we allow a museum to write and change something like
This should be easy to support with an underlying DMS (such as Nuxeo), but needs to be exposed in a manner as clean as this, I think, to allow practical customisation. It's easy to see bits of this as workflow specification language (eg BPEL), as schema (eg XSD), as abstract UI markup, etc, and it might make sense to make the "files" described above as a bundle of a few differently formated files. The task then becomes defining the bundle and linking the parts. I'd personally be keener that we develop a schema like the above and derive-out (via XSLT?) the supported files, as a simple format with museum-y names will allow many more people to customise the app.
This approach would allow us to ship default such files which hopefully the Collections Trust would allow to be considered SPECTRUM compliant, describing the necessary procedures and records. A museum could, however, customise them.
(See attached image).