FAIR from the field
Your data is yours. Nothing is shared or published unless you choose to share it. If you do work under the Findable, Accessible, Interoperable, and Reusable (FAIR) principles or another openness mandate, FAIR-readiness is built in at the point of data capture, rather than something you reconstruct later.
Metadata at three levels
The Notebook Editor’s INFO tab captures project-level metadata: a project name, project lead, lead institution, a description, and a notebook version. Below those you can add any number of custom entries as a name and a value, so a project DOI, the researchers’ ORCIDs, a protocol statement (or DOI pointing to it), or a data licence can be recorded there.
Dedicated metadata fields can be added at the level of the record. Each record creation or revision names who created it and when. More on provenance.
A distinctive feature of Fieldmark® is that each field can carry its own metadata. Annotation adds a free-text note beside the value, under a label you choose. Use this field for additional context or qualifications. Think of it as the margin of the page or the back of the form. Uncertainty adds a tick box that flags the value as doubtful, so you do not have to put a question mark into the data field itself. Both export as columns of their own beside the value. Where possible, fields capture metadata automatically. A GPS point captured in the field, for example, carries accuracy, altitude, and a timestamp alongside the coordinate.
Identifiers
A notebook can give each record a human-readable identifier built from other field values, so records read as something recognisable rather than as a bare UUID.
Identifiers issued by a registry are scanned in. The workflow for IGSNs, built with CSIRO, works from a pre-registered batch of identifiers, printed as books of tear-off labels carrying a QR code and human-readable text. The user affixes a label to the sample as it is bagged, and scans it into the record with the Scan QR Code field in the mobile app. The identifier travels with the record from then on, and can be retrieved by scanning the QR code again. Fieldmark does not mint identifiers, the registry does that, but the notebook is where an identifier meets its sample.
Project-level identifiers, a RAiD, ORCIDs, and DOIs for protocols or permits, are recorded in the notebook metadata.
Relationships and export
A link between two records carries a vocabulary pair, a forward label shown in the current record and a reverse label shown in the related one: “cuts” and “is cut by”; “fills” and “is filled by”; “is above” and “is below”. A cross- reference says what the relationship is, not merely that one exists. Pairs are set when the notebook is designed.
Full export produces one ZIP holding CSV, attachments, GeoJSON, KML, GeoPackage,
and a file named ro-crate-metadata.json. That file is an RO-Crate 1.1
document. It declares the export as a dataset, names the account that ran it and
the time it ran, and lists every file in the archive as its own entity, with the
record count against each CSV and the attachment count against each attachment
folder. It carries no licence, and the notebook definition is not in the ZIP: it
is downloaded separately.
The notebook definition is paradata, documentation of the process by which the data were captured as well as the structure they were captured into. It is a machine-readable file in a standard, open format (JSON) that records the recording protocol and the data structure: every form, section, and field, each field’s type and options, what was required, what appeared only under a condition, and how records of one form relate to records of another. It holds no records. Read by a person, it documents how the data were collected. A technically savvy user can write a script to build a data dictionary, an entity- relationship diagram, or a workflow diagram (tooling of this sort is on our roadmap). Re-importing the same file in the Dashboard recreates the notebook. Templates work this way.
Against the GO FAIR principles
| Principle | What Fieldmark does | Where it sits |
|---|---|---|
| F1. (Meta)data are assigned a globally unique and persistent identifier | Every record has a UUID, and a notebook can give each record a human-readable identifier built from field values. A carefully designed locally unique identifier can be used as the seed for a DOI or other PID. Registry identifiers such as IGSNs are pre-registered, printed as tear-off labels, and scanned in from the sample. | Fieldmark, for local identifiers or applying pre-generated PIDs. The registry, for generating PIDs. |
| F2. Data are described with rich metadata | Metadata at three levels: the project or notebook (the INFO tab’s fields plus any number of custom entries), the record (who created and revised it and when, plus any metadata fields the designer adds), and the field (an annotation and an uncertainty flag beside any value). | Fieldmark |
| F3. Metadata clearly and explicitly include the identifier of the data they describe | Every exported row carries its record’s identifiers, registry identifiers such as IGSNs are stored in the record they describe, and field metadata exports in columns named for the field it qualifies. Project-level identifiers, a RAiD, DOIs, and ORCIDs, are recorded in the notebook metadata. | Fieldmark |
| F4. (Meta)data are registered or indexed in a searchable resource | Fieldmark registers nothing. Export puts the dataset in open formats for the cleaning and analysis that precede deposit. | The repository you deposit in |
| A1. (Meta)data are retrievable by their identifier using a standardised communications protocol | Fieldmark exports the dataset and serves records through its API to an authenticated client. A locally unique identifier can be used as a persistent identifier seed. Retrieval by a persistent identifier happens where the dataset is deposited. | The repository you deposit in |
| A1.1 The protocol is open, free, and universally implementable | Export is in open formats, and the platform is open source under the Apache 2 licence. How a deposited dataset is retrieved is set by the repository. | The repository you deposit in |
| A1.2 The protocol allows for an authentication and authorisation procedure, where necessary | A property of the retrieval protocol of the repository holding the deposited data. Whilst the data are live in Fieldmark, access runs by invitation and by role. | The repository you deposit in |
| A2. Metadata are accessible, even when the data are no longer available | A repository responsibility: the metadata record persists there after the data are withdrawn. | The repository you deposit in |
| I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation | The export’s RO-Crate metadata file is JSON-LD, so the dataset description is already RDF. The record schema is Fieldmark’s own: a script can express it as an RDF schema, but mapping its fields and option lists to shared vocabularies is not trivially automatable, as per the vocabulary gap below. | Fieldmark, in part; improvements on roadmap |
| I2. (Meta)data use vocabularies that follow FAIR principles | Currently limited. Option lists are defined in the notebook itself. Published vocabulary cannot yet be imported or linked. | On roadmap |
| I3. (Meta)data include qualified references to other (meta)data | Linked relationships carry a forward and reverse label pair, so a cross-reference states the relationship, and parent-child relationships nest one record under another. | Fieldmark |
| R1. (Meta)data are richly described with a plurality of accurate and relevant attributes | Captured attributes join the designed ones: a GPS point carries accuracy, altitude, and a timestamp, every revision carries who and when, and every value can carry an annotation and an uncertainty flag. | Fieldmark |
| R1.1. (Meta)data are released with a clear and accessible data usage licence | A data licence can be recorded as an entry in the notebook metadata. The licence itself is applied on deposit. | Fieldmark records it; the repository applies it |
| R1.2. (Meta)data are associated with detailed provenance | The datastore keeps a full version history. Every revision is kept with the person, the time, and the fields changed, and a deletion is a revision too. | Fieldmark |
| R1.3. (Meta)data meet domain-relevant community standards | Full export carries an RO-Crate 1.1 metadata file, and notebook metadata can carry the entries a domain-specific, a generalist repository, or a RAiD record requires. Record-level metadata can be defined to domain standards. Field-level metadata remains free text plus an uncertainty boolean. | Fieldmark, in part |
Option lists are defined in the notebook itself, and importing or linking a published vocabulary is on our roadmap. Other gaps remain, and partners are the best way to close them, as funded work or as collaboration, particularly on vocabulary services and persistent identifiers. If your project has a requirement that Fieldmark does not yet meet, talk to us about building it.
Why uncertainty is a tick box rather than a slider
FAIMS Mobile recorded certainty as a number on a 0 to 1 scale, set with a slider. Users said a simple certain or uncertain flag would be more useful, a finding published in Ross et al. 2022 (DOI 10.5334/jcaa.96). Fieldmark ships the flag.
Why there is no export straight to a repository
There was one. FAIMS Mobile, the platform Fieldmark was rebuilt from, had repository export built at considerable cost, and nobody used it. Every project wanted to process and analyse their data in a third system between the field and the archive, and deposit happened from there. Fieldmark therefore puts its effort into export in open formats, with the metadata and identifiers captured in the field travelling with the data, so that whatever sits between capture and deposit inherits them.
The platform’s own account of FAIR data in the field, including the features researchers did not use, is published. More on publications.
See also
- Shared on your terms for invitations, roles, and the open-source platform underneath.
- Built to keep your records safe for the full version history and a record’s History tab.
- Shaped to your protocol for the Notebook Editor, where the metadata, identifiers, and relationships above are configured.
- Publications for the dated evidence trail, including the FAIR paper.