Original trac page
Each Observation should describe a particular discrete part of the archive, which in turn may be part of one or more data collections described by an Observation Collection.
Also note: the publication of the dataset and the Observation record should go hand-in-hand
|Field ( bold = mandatory field )||Description||Checklist/*Controlled vocab explanations/ Notes||Y/N|
|Title||Short text title for the dataset.|| Do you understand the title?
Is the title brief and simple?
Does the title contain unexplained technical terms or acronyms?
Does the title describe the resource rather than the activity/project which produced it?
Is the title in sentence case?
Is the title in English?
Does the title contain non-standard characters (e.g. © ° ± ² ³ µ)?
|Abstract||Short text only entry that will be the first information that users will see about the text.|| Do you understand the abstract?
Is the abstract written in plain English?
Does the abstract describe the resource rather than an activity/project which produced it?
Do the first few sentences summarise the contents of the resource?
Does the abstract also explain 'Where', 'When', 'How', 'Why' and 'Who' (if appropriate)?
Does the abstract contain unexplained technical terms or acronyms?
Does the abstract contain non-standard characters (e.g. © ° ± ² ³ µ)?
|Data Status||Controlled vocab to indicate the status of the data production|| * Completed
* Historic archive
* Under development
|Publication State||There is a drop down box for the publication state of the data in the archive (and also the Observation record). Options are|| * Old
* working - use this while preparing the record prior to dataset release
* published - dataset details are available to users, but the content of the dataset and/or metadata may still be changing
* Citable - this is ONLY to be used for dataset that are static and thus have a DOI assigned to them
|Data publication date||Date-Time of the data publication - i.e. moved publication status to "published" for the first time||should be set once and NOT changed. Not to be used for DOI date!|
|Latest Data Update||Date-time when the data were last updated in the archive||in due course this should hopefully be automated. Ignore this for the time being|
|Data update frequency||Controlled vocab to indicate the frequency by which the data are updated for this dataset.|
|Permissions||Used to specify if the access constraint and usage permissions (licence) details|| Simply click through to edit the permissions. The drop down list will allow you to set the access type as: public, reguser or restricted. If it is a restricted dataset then you'll also need to give the access groups in the box underneath. [hopefully we can drive this from the security DB and userDB in due course]
NOTE - if you re-use one of the existing permissions be VERY careful about changing it as it may also be used by other datasets!
|Keyword||freetext field to enter csv keywords|
|Language||Language of the dataset||default is English, but we could expand this to a controlled iso list in due course (ISO 639)|
|Image details||link to an image to be used as the logo|
|GEMINI2 related domain/feature||For exporting to NERC DCS we need to specify the related domain/feature. This needs to be a controlled list and we will utilise defaults based on our MOLES2 -> NERC DCS export to fill this in|
|Result||This is where to specify the connection to the data||This should be unique so don't re-use any of the existing options. Instead either edit the existing entry or create a new one if there isn't an existing entry. Specify the internal path to the point in the archive that is uniquely specified by this Observation record and this one alone! For resources not in the badc or neodc archives ask Graham for advice (there is work needed here)|
|Data quality statement||A free text entry to give a description of the quality of the data||Create a new one only. Most fields are pre-filled to conform to the standard - leave those as given. Simply provide the required free text in the top box|
|Data valid date/time||This is for forecast data to show the period for which the data are valid. Rarely (if at all?) used|
|Data Temporal Extent||temporal range of the dataset in the archive||State date is required, but end date is optional. Leave the end date blank if the dataset is being added to. This should reflect the true date range in the archive, not the anticipated end date. [note - we should hopefully be able to drive this with FAtCat in due course]. DON'T reuse existing options - create a new entry if needed|
|Geographic Extent||geographic bounding box encompassing all the available data in the archived dataset to date||DON'T reuse existing options - create a new entry if needed|
|Data Lineage||Free text field to explain the providence of the data that we hold. E.g. produced by X, processed by Y who delivered to BADC for ingestion into the archive following standard checks.|
|Procedure||Select the appropriate type of procedure for this dataset: observational data are covered by Acquisitions ; simulations covered by Computations. Composite processes are used when there are 2 or more computation or acquisitions, or a combination thereof to be described (e.g. satellite data collection described by acquisition, but processing algorithm described by computation)||Below Acquisition there are Instruments and Platform (and details of mobile platform operations) given. For Computations there is a way to link to external descriptors of the algorithm/model - e.g. CIM record, so only outline details are needed there.|
|Projects that data were collected in support of||Select (or create) the appropriate Project record(s) for which these data were principally collected/generated.|| Only select more than one project if the data were produced for either:
i) multiple, unconnected projects (e.g. FAAM flights operated for two concurrent, unrelated projects)
ii) change in funding line for ongoing facility
Please use the Project's parent-child relationship to capture relationships such as programme-project-campaign and ONLY link to the relevant record!
See this video for more info: https://www.youtube.com/watch?v=pfCVVXmLwPI
|Phenomena Measured or Simulated||This is the parameter list! This needs to be driven from FAtCat to complete this.||for each entry there should not only be a title, but also a link to the controlled vocab list from which this comes. E.g. air_temperature from the CF names list.|
|Related Observation||Other observations can be selected that this one related to, apart from being in the same collection (that is covered by the Observation Collections referring to the files)||Note - this needs more work to allow the relationship to be specified, to cover: "X superceeds Y"; "B is a continuation of A".|
|Identifiers||Unless adding a DOI, or a new abbreviation, please leave these as given.||the moles2 url is to ensure that users who find an reference in a paper to a MOLES2 record using the URLs given then can confirm to themselves that they are on the equivalent MOLES3 page.|
|Parties|| A list of people/organisations (called collectively a "party") involved with the data creation or curation.
Select (or create) a named party from the list, select their role from the controlled vocabulary and, if more than one party carrying out that role, use the priority number to sequence them in this role.
| * Author - party who contributed to the dataset authoring
* CEDA Officer - internal CEDA person responsible for the record/resource in question
* Curator - party responsible for curating the content (data centre)
* Custodian - party responsible for maintaining the resource (data centre)
* Distributor - party responsible for distributing/providing access to the resource (data centre)
* Metadata Owner - party maintaining this metadata record (data centre)
* Point of Contact - default is the data centre, but may be used in due course for a named person from the author list too
* Publisher - organisation that published the data first (most of the time one of our data centres, but could be external group where we are mirroring the data only)
|Notes||present and past news items particular to the record||latest news item will be at the top of the user view, with past items listed in the main body of the record|
|Online Resources|| Online link to relevant resource - e.g. documentation, WPS, TOOLS
There are set categories that should be used.
Do NOT use: DMP, Download, Apply for Access - these are handled elsewhere.
Internal resource type - used to tag a specific entry with a given tag: DMP should only be used on Project pages! FAT Cat link will be dropped; Sample data link - should be added in in due course, along with link to sample plots, but not implemented properly within CEDA.
| Do resource locators include titles which are concise, accurate accounts of the resource in question?
Do resource locators include descriptions which fully explain their purpose?
Permitted options to use here:
* documentation - any grey literature that is relevant to support the use of these data
* data service - any tool to help users make use of the data, e.g. link to WPS, station search NOT for data provider tools! those should be on the Project page!!!
* Metadata - link to folder with relevant metadata files, e.g. MIDAS station metadata
* search - link to some deeper search tool, e.g. Elastic search, EUFAR flight tool
*image and logo - at present use the image details to record these. Eventually we need to refine things to allow a specific logo to be selected and use the same mechanism to also link to other relevant links
|Reviews||For carrying out metadata content reviews - not in proper operation just yet.||For the time being please refer all new records to Anabelle or Graham for a review before they are published. This is to ensure consistent quality checks are carries out|
|Migration Properties||All the old legacy content from the MOLES2 "Content" section is in here - split into the various div tags.||Please leave the "moles2citation" at present, but look to move other items into other parts of MOLES if possible - e.g. add items under the links section to the online resources section. Once migrated feel free to delete content|