This page follows on from the team meeting of 2008 July 2nd, and outlines initial thoughts on the application level for three reasons.
- To Share
- For critique
- To explain
At the moment, as this page is immature, it represents the perspectives of a limited cross-section of the team, so bear that in mind for now.
Essentially the application layer acts as a business logic or workflow glue between the backend layers and the user-interface components. It doesn't actually "do" any sophisticated operations, nor does it richly "present" information. Instead, it marshalls information between the two layers, and helps encapsulate the working practices of a museum, and so is strongly functionally dependent. It acts primarily as a broker, forwarding information, making simple transformations, and assembling knowledge. For those of you who like pseudo-code here's the sort of thing this layer might do (if not, skip this grey box)
The idea is that it's like a "script" as what to do, when, and is a bit like a procedure manual in other institutions, and so is heavily influenced by SPECTRUM, etc. It doesn't actually do any of the operations it describes. It's also been described as choreography or orchestration, which I think are good metaphors.
It's something which needs to be heavily configurable through the user interface by administrators, developing a kind of drag-and-drop what happens here perspective, but ultimately will need to be code configurable for specialist objectives (given the long tail, almost everyone will end up tinkering with this in the end, I think).