releasing open data for illuminated manuscript collection records and research…
Modelling: ‘Sets’ and ‘Contexts’
August 31, 2012Posted by on
The Knowledge Integration’s Collections Information Integration Middleware implements a couple of very useful ‘data models’. With refinement during Open book we’ve so far not really found anything, providing is ‘object record’ centric, can’t be ‘put into’ one of these models.
This is because there are primarily three type of ‘data connections’ one might want to do in middleware:
- Augment existing object records (with related but different information);
- Group existing object records (so that arbitrary groupings of records can be made); and
- Create new data sets possibly without any object record linkage.
Referring to the diagram above there are are two models – Sets and Contexts. In the CIIM both of these are definable – in the diagram this is represented by ‘Definition’. A ‘Definition’ is a class (for the object based modellers amongst you) if you like – at its most basic it defines the field list for this type (say of, Set) and the type of ‘connections’ these (Sets’) records are allowed to make. Clearly you can create as many definitions as you like – for simplicity I am only representing a single definition of each type of model in the diagram.
With a Set you define its field list (schema) and then you can begin creating Set records of that ‘type’. Clearly you may have many Set Records for any given Set defintion. Sets’ principle characteristic is that any one Set record can be allowed to refer to as many object records as it likes. A simple practical example of this might be: the Set definition is for a Collection Level Description (RSLP schema) and then each Collection Level Description (a Set record) can refer to as many object records as it likes.
With a Context you define its field list (schema) and then you begin creating records of that ‘type’. Clearly you may have many Context records for any given Context defintion. Contexts’ principle characteristic is they may only have a one to one relationship with object records. This enforces the augmentation concept. A simple theoretical example is you have a research project generating particular metadata per object – this is clearly an augmentation issue, you have extra structured data per object (which we are assuming you dont want to store in your collections management system). So your research metadata becomes a Context Definition (defining its fields/schema) and each context record will hold the research data for an indiviual object and have a one to one linkage to that objects’ record.