CSMD: the Core Scientific Metadata Model

Abstract

CSMD, the Core Scientific MetaData model, is an model of metadata to capture a description of Scientific "activities" (e.g. experiments, observations, simulations etc) which are characterised by an event where the application of resources (e.g. equipment, instruments) to a subject item (e.g. a chemical, geological or materials sample or biological specimin) causes a signal which is detected via sensors, and results in the the collection of data.

The CSMD is currently used largely within the context of large-scale scientific facilities (e.g. Photon and Neutron Sources) and has some characterisitics which are specialised to those contexts. However, the model is intended to have a general applciation and thus these features are kept to a minumum.

A metadata model for Facilities Science

The Core Scientific Metadata Model (CSMD) is a metadata model oriented towards facilities science which has been developed at STFC over the last 12 years; for earlier work see [Sufi and Matthews 2004] [Sufi and Matthews 2005] [Matthews, B., et. al 2009]. The CSMD is being used as the core metadata model within the data management infrastructure which is being developed for the large scale scientific facilities supported by STFC including the ISIS Neutron Source and the Diamond Light Source, and now being used across the PaN-Data consortium and elsewhere. It has been the result of an analysis of science practice over a number of years and a number of projects to allow the user to manage their own data, and have access to other interesting data.

The currently version is CSMD v.4.0, and the ICAT data catalogue is based on this version, though the database schema of ICAT has a number of modifications and additions to accommodate the practical implementation of the database.

The model is intended to capture high level information about investigations undertaken at facilities and the data that they produce. However, it is designed to be generic across scientific disciplines and has application beyond facilities science, particularly in the "structural sciences" (such as chemistry, material science, earth science, and biochemistry) which are concerned with the molecular structure of substances, and within which systematic experimental analyses are undertaken on material samples.

The core metadata model

CSMD is organised around the notion of Studies, a study being a body of scientific work on a particu-lar subject of interest. During a study, a scientist would perform a number of activities e.g. experiments, observations, measurements and simulations. Results from these activities usually run through different stages: the collection of raw data, the generation of analysed or derived data through the application of software tools, and end results. Data should be grouped accordingly, and associated with the appropriate experimental parameters. Not all information captured in specific metadata schemas would be used to search for this data or distinguish one data set from another, giving the possibility to select special parameters. The CSMD is designed to be a common general format/standard for Scientific Studies and their associated data holdings.

Thus this model:

• Forms a specification for the types of metadata which should be captured during Scientific Studies.
• Allows citation, collaboration, exploitation and integration of information on scientific studies.
• Allows easy integration of distributed heterogeneous metadata systems into a homogeneous (albeit virtual) platform.

The CSMD has been developed to be a core system which is extensible and can be specialised to particular scientific domains, so it does not make assumptions about the specific terminology of the domain.

The use of the CSMD for facilities is focused on capturing the activities associated with the facilities science lifecycle as detailed in [PaNData-ODI D6.1], which generically is called an Investigation . Thus the Investigation concept represents those activities and research outputs associated with one approved application for use of the facilities. In practise, this may involve a number of visits to use a number of instruments, analysing a number of samples and generating a number of resultant data sets.

The model thus defines a hierarchical model of the structure of scientific research around studies and investigations, with their associated information, and also a generic model of the organisation of data sets into collections and files. Specific data sets can be associated with the appropriate experimental parameters, and details of the files holding the actual data, including their location for linking. This provides a detailed description of the study, although not all information captured in specific metadata schemas would be used to search for this data or distinguish one data set from another.

Figure 1: Main entities of the CSMD

The metadata within the general structure is laid in a series of classes and subclasses. We do not describe the whole model in detail for reasons of space, but rather select some areas of particular interest. The core entities of the CSMD for a study are given in Figure 1, and are summarised as follows.

Study

The fundamental unit of the CSMD Model, collecting togehter an aggregation of associated scientific activities, data collecting events, artefacts (e.g. instruments, samples, dataset) and people.

Investigation

The fundamental unit of a facility study, associated with an accepted proposal for use of the facility to undertake a series of experiments. Attributes including a title, abstract, dates, and unique identifiers referencing the particular investigation.

Facility

The facility which is used within the investigation, hosting the instrument and experiments.

Instrument

The instruments the investigation uses to carry out experiments.

Sample

Information on the material sample analysed within the investigation. The model has attributes for a sample's name, chemical formula and any associated special information, such as specific safety information on a toxic material.

Dataset

One or more datasets can be associated with an investigation, representing different runs or analyses on a sample. Initially a raw data set can be attached to the investigation, but subsequently, analysed datasets can also be added.

Datafile

The CSMD takes a hierarchical view of data holdings, as data sets may contain other dataset as well as units of storage, typically datafiles. Each datafile has more detailed attributes, including its name, version, location, data format, creation and modification time, and fixity information such as a Checksum.

Parameter

Parameters describe measureable quantities associated with the investigation, such as temperature, pressure, or scattering angle, describing either the parameters of the sample, the environment the data was collected in, or the parameters being measured. Parameters can be associated at different levels: the investigation, the sample, dataset or the datafile, and have attributes for names, units, values, and allowable data ranges. These different type of parameter are all represented as subclasses of the general Parameter class. Parameters in CSMD are thus a very general data holding component (essentially a key-value pair table)/ Parameters thus provides a highly flexible and tailoroable mechanims for representing information about many type of study.

InvestigationUser

A user (represented as a separate entity, omitted for clarity) associated with a role in the investigation.

Additionally, a number of other entities are defined to capture for example, associated publications, data format used, sample types (representing the class of material under analysis, of which the sample is a particular instance), parameter types (representing the classes of parameters of which the parameters are particular instances).

Further entities capture specialist facility concepts, such as "shifts" (representing a daily time period within which the experiment was undertaken) and "cycles" (representing a period of weeks or months where the facility is in active operation between "shutdown" periods of maintenance).

A full UML class diagram of the model is given in Figure 2.

Figure 2: UML Class Diagram for the full CSMD

OWL representation

We support this metadata model by providing a representation as an OWL ontology. This allows us to represent metadata as RDF triples within triple stores (or provide a triple based front end onto metadata databases such as ICAT via for example a SPARQL endpoint. We can also publish data about experiments into Linked Open Data, furthering the publication, exchange and sharing of metadata about facilities experiments, as well as its combination with other metadata items. We give a sample of the OWL representation, for reasons of brevity. The full model can be found on the ICAT Google Code site.

The OWL representation has a base URI: http://www.purl.org/net/CSMD/4.0#

The OWL representation reflects the UML model closely. Thus for each UML there is a corre-sponding OWL Class, as below (using RDF/XML notation):

   
    <!-- csmd:Investigation -->



    <owl:Class rdf:about="csmd:Investigation">

        <rdfs:label>Investigation</rdfs:label>

        <rdfs:comment>An investigation or experiment</rdfs:comment>

    </owl:Class>



    <!-- csmd:Facility -->



    <owl:Class rdf:about="csmd:Facility">

        <rdfs:label>Facility</rdfs:label>

        <rdfs:comment>An experimental facility</rdfs:comment>

    </owl:Class>



    <!-- csmd:Dataset -->



    <owl:Class rdf:about="csmd:Dataset">

        <rdfs:label>Dataset</rdfs:label>

        <rdfs:comment>A collection of data files and part of an investiga-tion</rdfs:comment>

    </owl:Class>



    <!-- csmd:Datafile -->



    <owl:Class rdf:about="csmd:Datafile">

        <rdfs:label>Datafile</rdfs:label>

        <rdfs:comment>A data file</rdfs:comment>

    </owl:Class>

For each Class attribute in the UML model, there is a corresponding OWL DatatypeProperty, conventionally named by prefixing the domain Class name with the attribute name as in the below:

    <!-- csmd:investigation_startDate -->



    <owl:DatatypeProperty rdf:about="csmd:investigation_startDate">

        <rdf:type rdf:resource="&owl;FunctionalProperty"/>

        <rdfs:label>investigation_startDate</rdfs:label>

        <rdfs:comment>The time at which the investiation was initiat-ed</rdfs:comment>

        <rdfs:domain rdf:resource="csmd:Investigation"/>

        <rdfs:range rdf:resource="&xsd;dateTime"/>

    </owl:DatatypeProperty>

    

    <!-- csmd:investigation_summary -->



    <owl:DatatypeProperty rdf:about="csmd:investigation_summary">

        <rdfs:label>investigation_summary</rdfs:label>

        <rdfs:comment>Summary or abstract</rdfs:comment>

        <rdfs:domain rdf:resource="csmd:Investigation"/>

        <rdfs:range rdf:resource="&xsd;string"/>

    </owl:DatatypeProperty>

    

    <!-- csmd:investigation_title -->



    <owl:DatatypeProperty rdf:about="csmd:investigation_title">

        <rdfs:label>investigation_title</rdfs:label>

        <rdfs:comment>Full title of the investigation</rdfs:comment>

        <rdfs:domain rdf:resource="csmd:Investigation"/>

        <rdfs:range rdf:resource="&xsd;string"/>

    </owl:DatatypeProperty>

Similarly, for each association in the UML model, there are two corresponding OWL ObjectProperties which form a pair of inverse Properties , conventionally named by prefixing the domain Class name with the range Class name. This is because whilst the associations in UML are not directed, properties in OWL are. This results for example in the below:

    <!-- csmd:facility_instrument -->



    <owl:ObjectProperty rdf:about="csmd:facility_instrument">

        <rdfs:label>facility_instrument</rdfs:label>

        <rdfs:comment>An Instrument supported by a facility.</rdfs:comment>

        <rdfs:domain rdf:resource="csmd:Facility"/>

        <rdfs:range rdf:resource="csmd:Instrument"/>

        <owl:inverseOf rdf:resource="csmd:instrument_facility"/>

    </owl:ObjectProperty>



    <!-- csmd:instrument_facility -->



    <owl:ObjectProperty rdf:about="csmd:instrument_facility">

        <rdf:type rdf:resource="&owl;FunctionalProperty"/>

        <rdfs:label>instrument_facility</rdfs:label>

        <rdfs:comment>The facility which has this instrument.</rdfs:comment>

        <rdfs:range rdf:resource="csmd:Facility"/>

        <rdfs:domain rdf:resource="csmd:Instrument"/>

    </owl:ObjectProperty>



    <!-- csmd:investigation_dataset -->



    <owl:ObjectProperty rdf:about="csmd:investigation_dataset">

        <rdf:type rdf:resource="&owl;InverseFunctionalProperty"/>

        <rdfs:label>investigation_dataset</rdfs:label>

        <rdfs:comment>A data set which is the result of an investiga-tion</rdfs:comment>

        <rdfs:range rdf:resource="csmd:Dataset"/>

        <rdfs:domain rdf:resource="csmd:Investigation"/>

    </owl:ObjectProperty>



    <!-- csmd:dataset_investigation -->



    <owl:ObjectProperty rdf:about="csmd:dataset_investigation">

        <rdf:type rdf:resource="&owl;FunctionalProperty"/>

        <rdfs:label>dataset_investigation</rdfs:label>

        <rdfs:comment></rdfs:comment>

        <rdfs:comment>The investigation associated with an da-taset</rdfs:comment>

        <rdfs:domain rdf:resource="csmd:Dataset"/>

        <rdfs:range rdf:resource="csmd:Investigation"/>

        <owl:inverseOf rdf:resource="csmd:investigation_dataset"/>

    </owl:ObjectProperty>

Note also that some object properties are declared as OWL Functional (or inverseFunctional) properties; this reflects the cardinality constraints of the UML model into the OWL model.

Supporting Provenance

In order to support provenance, we need to relate the model of facility experiments encapsulated in the "data-centric" view expressed in the CSMD with a notion of scientific activity, so that we can provide a notion of the further processes and outputs involved with managing the data. We relate the model with the general notion of a process given in the W3C Prov model [PROV-O], which gives a high level view of a process step as in Figure 3

Figure 3: High level view of the structure of Prov records

Thus the Prov model defines three general classes :

• Entities are "physical, digital, conceptual, or other kinds of thing. ... Provenance records can describe the provenance of entities, and an entity's provenance may refer to many other entities".
• Activities are "how entities come into existence and how their attributes change to become new entities. ... They are dynamic aspects of the world, such as actions, processes, etc".
• Agent which take "a role in an activity such that the agent can be assigned some degree of responsibility for the activity taking place. An agent can be a person, a piece of software, an inanimate object, an organization, or other entities that may be ascribed responsibility".

Then the general properties relate these class instances together to represent the relationships between entities and how they were processed by whom to form a record of provenance. Note that, in common with many approaches to representing provenance, these relationships take the point of view of an historical record of the origins of entities, asking the question "where does this entity come from", so the arrows point from the future to the past.

In the CSMD model, Entities include datasets, datafiles, samples, and indeed, investigations themselves as a conceptual object representing the entirety of the experiment while the InvestigationUser and instruments are Agents. We can add these relationships into the OWL model by making the appropriate CSMD OWL classes subclasses of the PROV-O classes.

The provenance step for which we have the most immediate need is the use of an analytic software package on datasets or specific data files, to generate new datasets and datafiles. Consequently, a new class Job has been added to CSMD to represent the Activity (in the PROV sense) of running a software package on a set of input data to derive a set of output data. We represent this in UML as in Figure 4.

Figure 4: Modelling jobs in CSMD

Thus a Job is an Activity which is associated with a software application as an Agent (again in the PROV-O sense) and takes a number of input data sets and data files within those data sets as inputs, and outputs data files and dataset as output. These data set are themselves linked into the Investigation. Thus inputDataSet and inputDataFile are associations which are specialisations of the PROV-O uses property, and outputDataSet and outputDataFile are associations which are specialisations of the PROV-O wasGeneratedBy property (with appropriate directionality).

Generalising the Activity Model

We can generalize this notion of Scientific Activity in the CSMD model to add a general class of activities, and add other types of activity. Thus we can add a "Run" activity to the CSMD representing the particular activity of generating a dataset from a sample using an instrument (an agent), as in Figure 5.

Figure 5: A Run model for CSMD

We would also relate the Investigation to the Run. Adding a Run entity to the CSMD is not included within CSMD 4.0, and is still under discussion as it not as yet accepted that this adds to the current use of ICAT; however, it would make the model more consistent in the representation of provenance.

Description of classes and properties

We give a complete description of the classes and properties in the CSMD model.

Ontology Classes

Data Properties

Object Properties

References

[Matthews, B., et. al 2009]

Matthews, B., et. al. Using a Core Scientific Metadata Model in Large-Scale Facilities. 5th International Digital Curation Conference, London, UK, (2009)

[PROV-O]

PROV-O: The PROV Ontology, W3C Recommendation 30 April 2013, http://www.w3.org/TR/prov-o/

[PaNData-ODI D6.1]

Matthews, B. et al., Model of the data continuum in Photon and Neutron Facilities. PaNdata ODI, Deliverable D6.1. (2012). http://pan-data.eu/sites/pan-data.eu/files/PaNdataODI-D6.1.pdf

[Sufi and Matthews 2004]

Sufi, S., Matthews, B. CCLRC Scientific Metadata Model: Version 2. DL Technical Reports, DL-TR-2004-001, (2004). http://epubs.cclrc.ac.uk/work-details?w=30324

[Sufi and Matthews 2005]

Sufi, S., Matthews, B. The CCLRC Scientific Metadata Model: a metadata model for the exploitation of scientific studies and associated data. In Contributions in Knowledge and Data Management in Grids, eds. Domenico Talia, Angelos Bilas, Marios Dikaiakos, CoreGRID 3, Springer-Verlag, (2005).