2.1 Walkthrough: An initial RO-Crate

In the simplest form, to describe some data on disk, a file named ro-crate-metadata.json is placed in a directory alongside a set of files or directories. This ro-crate-metadata.json file is known as the RO-Crate Metadata Document.

In the example below, a single file data.csv is placed with the RO-Crate Metadata Document in a directory named crate1:

The presence of the ro-crate-metadata.json file means that crate1 and its children can now be considered to be an RO-Crate.

{
  "@context": "https://w3id.org/ro/crate/1.2/context",
  "@graph": [
    {
      "@id": "ro-crate-metadata.json",
      "@type": "CreativeWork",
      "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"},
      "about": {"@id": "./"}
    },
    {
      "@id": "./",
      "@type": "Dataset",
      "name": "Example dataset for RO-Crate specification",
      "description": "Official rainfall readings for Katoomba, NSW 2022, Australia",
      "datePublished": "2022-12-01",
      "publisher": {"@id": "https://ror.org/04dkp1p98"},
      "license": {"@id": "http://spdx.org/licenses/CC0-1.0"},
      "hasPart": [
        {"@id": "data.csv"}
      ]
    },
    {
      "@id": "data.csv",
      "@type": "File",
      "name": "Rainfall data for Katoomba, NSW Australia February 2022",
      "encodingFormat": "text/csv",
      "license": {"@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/"}
    },
    {
      "@id": "https://ror.org/04dkp1p98",
      "@type": "Organization",
      "name": "Bureau of Meteorology",
      "description": "Australian Government Bureau of Meteorology",
      "url": "http://www.bom.gov.au/"
    },
    {
      "@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/",
      "@type": "CreativeWork",
      "name": "CC BY-NC-SA 3.0 AU",
      "description": "Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Australia"
    }
  ]
}

{
    "@id": "ro-crate-metadata.json",
    "@type": "CreativeWork",
    "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"},
    "about": {"@id": "./"}
}

{
    "@id": "./",
    "@type": "Dataset",
    "…": "…",
    "hasPart": [ {"@id": "data.csv"} ]
}

{
  "@id": "data.csv",
  "@type": "File",
  "name": "Rainfall data for Katoomba, NSW Australia February 2022",
  "encodingFormat": "text/csv",
  "license": { "@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/" }
},

{
    "@id": "./",
    "@type": "Dataset",
    "publisher": {"@id": "https://ror.org/04dkp1p98"},
    "…": "…"
 }

{
   "@id": "https://ror.org/04dkp1p98",
   "@type": "Organization",
   "name": "Bureau of Meteorology",
   "description": "Australian Government Bureau of Meteorology",
   "url": "http://www.bom.gov.au/"
}

2.2 HTML preview

An RO-Crate can be distributed on disk, in packaged format such as a zip file or disk image, or placed on a static website. In any of these cases, an RO-Crate should have an accompanying HTML version (ro-crate-preview.html) designed to be human-readable. The exact contents of the preview may vary but should correspond to the RO-Crate Metadata Document content and link to the contained data entities. The preview may be generated automatically from the RO-Crate Metadata Document (see RO-Crate tools), or even by hand (equivalent to a README).

Below is a screenshot from the preview of the running example, which was generated using the ro-crate-html package:

2.3 Overview of specification

The rest of this specification is structured as follows:

• Terminology defines terms such as Entity used in this section and the rest of the specification. You may use this section as a quick-reference, but note that most of these are also covered in detail in separate sections.
• RO-Crate Structure defines further how the ro-crate-metadata.json and data files can be organized within an RO-Crate Root directory.
• Metadata of the RO-Crate explains the connection to Linked Data principles and how RO-Crate keys are mapped to global identifiers. This is mainly of interest for readers already familiar with JSON-LD or ontologies, or which want to expand RO-Crate metadata keys.
• Root Data Entity defines the entities RO-Crate Metadata Descriptor (ro-crate-metadata.json) and Root Data Entity (./) including their required and recommended properties.
• Data Entities explores further how to describe data, including files, directories and Web references. Metadata such as file formats help inform RO-Crate consumers on which tools may be able to process the data.
• Contextual Entities shows how to describe entities used to annotate other entities, adding People and Organization referenced from author, publication, affiliation etc. Metadata like licensing, funding, locations and subjects can be described using contextual entities.
• The focus of an RO-Crate describes how an RO-Crate can indicate the most important or central entities within it.
• Provenance of Entities explores how the history of making an entity can be added to the RO-Crate using a series of actions – this may include real-world activities and instruments, as well as software executions and modifications to the RO-Crate metadata itself.
  • Subsection Digital Library and Repository content details how records in an existing repository (which may reference files, but also physical objects) can be described and published using RO-Crate.
• Workflows and Scripts explains how computional software and code can be added to an RO-Crate, possibly as part of explaining provenance, but also for providing potential usage and further processing of the data.
• Profiles formalises how a set of RO-Crates can indicate they are conforming to a specific RO-Crate profile, which may add additional requirements beyond this general RO-Crate specification. Profiles may add additional terms from schema.org and other vocabularies, or require a certain type of data entity used in a particular research domain. Profiles can themselves be expressed as an RO-Crate, which is also explored in this section.
• Appendixes contain more technical references and suggestions for developers, e.g. for deciding on @id in JSON-LD or extending RO-Crate terms. The appendix also explores how an RO-Crate can be packaged with BagIt or used as part of a repository.

Throughout the specification you will find references to the keys and types reused from schema.org through the JSON-LD context, for instance Dataset, which define many more properties than the ones highlighted by sections like Root Data Entity. The intention is that the RO-Crate specification gives a common minimum of metadata, and that producers of RO-Crates can use additional schema.org types and properties as needed. When some patterns emerge from such extensions they can be formalized in a published profile to ensure they are also used consistently.

3.1 Linked Data conventions

Throughout this specification, RDF terms (properties, types) are referred to using the keys defined in the RO-Crate JSON-LD Context.

Following Schema.org practice, property names start with lowercase letters and Type names start with uppercase letters.

In the RO-Crate Metadata Document the RDF terms use their RO-Crate JSON-LD names as defined in the RO-Crate JSON-LD Context, which is available at https://w3id.org/ro/crate/1.2/context

4.1 Table of contents

4.2 Types of RO-Crate

An RO-Crate Metadata Document is used to package data in one of two ways:

1. An Attached RO-Crate Package that defines an on-disk collection of data:

• It is defined within a file-system-like service as a directory (known as the RO-Crate Root) with the RO-Crate Metadata Document saved in a file-like entity with a file name of ro-crate-metadata.json.
• References to files and directories in the RO-Crate Metadata Document are present in the RO-Crate or available online as Web-based Data Entities.
• Typically, software processing an Attached RO-Crate Package would be passed a path to a directory or a zip file.

2. A Detached RO-Crate Package:
   • Is defined by a stand-alone RO-Crate Metadata Document which may be stored in a file or distributed via an API.
   • References to files and directories in the RO-Crate Metadata Document are all Web-based Data Entities.
   • If stored in a file, known as a Detached RO-Crate Metadata File, the filename SHOULD be ${prefix}-ro-crate-metadata.json rather than ro-crate-metadata.json where the variable ${prefix} is a human readable version of the dataset’s ID or name, to signal that on disk, the presence of the file does not indicate an Attached RO-Crate Data Package.
   • Typically, software processing a Detached RO-Crate Package would be passed a path to a file, an absolute URI, or a JSON string or object, without a directory context.

RO-Crate Metadata Documents MAY also be processed in non-packaging contexts by tools such as website generators or crate visualizers, where data entities are not processed, or in applications which use RO-Crate conventions for representing context (such as a schema definition using Schema.org conventions).

Note: Client software may provide modes which force a particular packaging mode to be assumed. For example, if the software is passed a directory, then it would assume that is processing an Attached RO-Crate Package. If passed a path to a file, it could work in Detached RO-Crate Package mode, and possibly attempt to resolve Web Based Data Entities. It could also provide a mode to simply parse the document and process it without referencing or validating Data entities in any special way.

In all crates the metadata is completed with contextual entities that further describe the relationships and context of the data to form a Research Object.

4.3 RO-Crate Metadata Document (ro-crate-metadata.json)

JSON-LD is a structured form of JSON that can represent a Linked Data graph.

• The RO-Crate Metadata Document MUST be a document which is valid JSON-LD 1.0 in flattened and compacted form.
• The RO-Crate JSON-LD MUST use the RO-Crate JSON-LD Context https://w3id.org/ro/crate/1.2/context by reference.

The graph MUST describe:

1. The RO-Crate Metadata Descriptor
2. The Root Data Entity
3. Zero or more Data Entities
4. Zero or more Contextual Entities

Any referenced contextual entities SHOULD also be described in the RO-Crate Metadata Document with the same identifier. Similarly any contextual entity in the RO-Crate Metadata Document SHOULD be linked to from at least one of the other entities using the same identifier.

The appendix RO-Crate JSON-LD details the general structure of the JSON-LD that is expected in the RO-Crate Metadata Document. In short, the rest of this specification describes the different types of entities that can be added as {} objects to the RO-Crate JSON-LD @graph array below:

{ "@context": "https://w3id.org/ro/crate/1.2/context",
  "@graph": [

  ]
}

4.4 Attached RO-Crate Package

An Attached RO-Crate Package is used to contain and describe an optional payload of files and directories as well as web-based data entities along with their contextual information.

When processing an Attached RO-Crate Package the RO-Crate Metadata Document MUST be present in the RO-Crate Root and it MUST be named ro-crate-metadata.json.

An Attached RO-Crate Package can be stored and published in multiple ways depending on its use:

• On a typical hierarchical file system (e.g. /files/shared/crates/my-crate-01/)
• Exposed as a Web resource within a folder structure (e.g. https://www.researchobject.org/2021-packaging-research-artefacts-with-ro-crate/)
• Packaged within a ZIP file, BagIt archive or OCFL structure
• Archived as a set of named files in other ways (e.g. Zenodo deposit)

A valuable feature of the Attached RO-Crate Package approach is that the metadata is preserved when a crate is transferred between these types of storage/publication systems.

The file path structure an Attached RO-Crate Package MUST follow is:

<RO-Crate root directory>/
|   ro-crate-metadata.json    # RO-Crate Metadata File containing the RO-Crate Metadata Document MUST be present 
|   ro-crate-preview.html     # RO-Crate Website homepage MAY be present
|   ro-crate-preview_files/   # MAY be present
|    | [other RO-Crate Website files]
|   [payload files and directories]  # 0 or more

The name of the RO-Crate root directory is not defined, but a root directory is identifiable by the presence of the RO-Crate Metadata File, ro-crate-metadata.json. For instance, if an RO-Crate is archived in a ZIP-file, the ZIP root directory is an RO-Crate root directory if it contains ro-crate-metadata.json.

The payload files and directories MAY be described within the RO-Crate Metadata File as Data Entities. Additional Web-based Data Entities MAY also be described, but are not considered part of the payload.

The @id of the Root Data Entity in an Attached RO-Crate Package MUST be either ./ or be a URI, such as a DOI URL or other persistent URL which is considered to be the main identifier of the Attached RO-Crate Package.

Note: Earlier versions of RO-Crate mandated an @id of ./ as a convention for identifying the Root Data Entity, but the use of the RO-Crate Metadata Descriptor means that this is no longer required, freeing-up the Root Data Entity @id to be used to indicate what should be considered the canonical URI for an RO-Crate Package. Other mechanisms for specifying the ‘main identifier’ involve multiple JSON-LD entities and may be ambiguous.

{
      "@id": "ro-crate-preview.html",
      "@type": "CreativeWork",
      "about": {"@id": "./"}
}

{
      "@id": "https://www.npmjs.com/package/ro-crate-html-js",
      "@type": "SoftwareApplication",
      "url": "https://www.npmjs.com/package/ro-crate-html-js",
      "name": "ro-crate-html-js",
      "version": "1.4.19"
}

{
      "@id": "#ro-crate-preview-generation",
      "@type": "CreateAction",
      "name": "Create HTML summary",
      "endTime": "2022-10-019T17:01:07+10:00",
      "instrument": {
        "@id": "https://www.npmjs.com/package/ro-crate-html-js"
      },
      "object": {
        "@id": "ro-crate-metadata.json"
      },
      "result": {
        "@id": "ro-crate-preview.html"
      }
}

4.5 Detached RO-Crate Package

A Detached RO-Crate Package is an RO-Crate, defined in an RO-Crate Metadata Document without a defined root directory, where the RO-Crate Metadata Document content is accessed independently (e.g. as part of a programmatic API).

Unlike an Attached RO-Crate Package, a Detached RO-Crate Package is not processed in a file-system context and thus does not carry a data payload in the same sense, but may reference data deposited separately, or purely reference contextual entities.

In a Detached RO-Crate Package the root data entity SHOULD have an @id which is an absolute URL if it is available online. If it is not yet, or will never be available online then @id MAY be any valid URI - including ./.

Any data entities in a Detached RO-Crate Package Package MUST be Web-based Data Entities.

A Detached RO-Crate Package may still use #-based local identifiers for contextual entities.

The concept of an RO-Crate Website is undefined for a Detached RO-Crate Package.

To distribute a Detached RO-Crate Package and optionally to provide an RO-Crate Website, any Detached RO-Crate Package can be saved in a directory (and zipped or otherwise bundled) and will function as an Attached RO-Crate Package with no payload data. See the appendix on converting from Detached to Attached RO-Crate Package for further guidance on this.

5.1 Table of contents

RO-Crate aims to capture and describe the Research Object using structured metadata. Specifically, an RO-Crate is described using JSON-LD by an RO-Crate Metadata Document. As explained in section RO-Crate Structure this may be stored in an RO-Crate Metadata File.

The RO-Crate Metadata Document contains the metadata that describes the RO-Crate and its content, in particular:

• Root Data Entity - the RO-Crate Dataset itself, a gathering of data
• Data Entities - the data payload, in the form of files and folders
• Contextual Entities - related things in the world (e.g. people, organizations, places), providing provenance for the data entities and the RO-Crate.

This machine-readable metadata can also be represented for human consumption in the RO-Crate Website, linking to data and Web resources.

5.2 RO-Crate uses Linked Data principles

RO-Crate makes use of the Linked Data principles for its description. In particular:

1. (Meta)data should be made available as Open Data on the web.
2. (Meta)data should be machine-readable in a structured format.
3. (Meta)data should not require proprietary software packages.
4. (Meta)data should use open standards from W3C, such as RDF and SPARQL.
5. (Meta)data should link to other people’s data to provide context, using URIs as global identifiers

RO-Crate realizes these principles using a particular set of technologies and best practices:

1. The RO-Crate Metadata Document can be stored in an RO-Crate Metadata File. The RO-Crate Metadata File and an RO-Crate Website can be directly published on the web together with the RO-Crate payload. In addition, a data package (e.g. BagIt Zip archive) that contains the RO-Crate can also be published on the web.
2. The RO-Crate Metadata Document is based on the structured data format JSON-LD.
3. Multiple open source tools/libraries are available for JSON and for JSON-LD.
4. The RO-Crate Website is HTML 5, and the RO-Crate Metadata Document is JSON-LD, one of the W3C RDF 1.1 formats.
5. The RO-Crate Metadata Document reuses common vocabularies like Schema.org, and this specification recommends identifiers it should link to.

5.3 Common principles for RO-Crate entities

For all entities listed in an RO-Crate Metadata Document the following principles apply:

1. The entity MUST have an @id (see Describing entities in JSON-LD).
2. The entity MUST have a @type, which MAY be an array.
3. The @type SHOULD include at least one Schema.org type that accurately describes the entity. Thing or CreativeWork are valid fallbacks if no alternative external or ad-hoc term is found (see Extending RO-Crate).
4. The entity SHOULD have a human-readable name, in particular if its @id does not go to a human-readable Web page.
5. The properties used on the entity SHOULD be applicable to the @type (or superclass) according to their definitions. For instance, the property publisher can be used on a Dataset as it applies to its superclass CreativeWork.
6. Property references to other entities (e.g. author property to a Person entity) MUST use the { "@id": "..."} object form (see JSON-LD appendix).
7. The entity SHOULD be ultimately referenceable from the root data entity (possibly through another reachable data entity or contextual entity).

5.4 Base metadata standard: Schema.org

Schema.org is the base metadata standard for RO-Crate. Schema.org was chosen because it is widely used on the World Wide Web and supported by search engines, on the assumption that discovery is likely to be maximized if search engines index the content.

Note: As far as we know there is no alternative, well-maintained linked-data schema for research data with the coverage needed for this project - i.e. a single standard for expressing all the examples presented in this specification.

RO-Crate relies heavily on Schema.org, using a constrained subset of JSON-LD, and this specification gives opinionated recommendations on how to represent the metadata using existing linked data best practices.

Tip: The main principle of RO-Crate is to use a Schema.org term whenever possible, even if its official definition may seem broad or related to every day objects. For instance, IndividualProduct can describe scientific equipment and instruments (see Provenance of entities). RO-Crate implementers are free to use additional properties and types beyond this specification (see also appendix Extending RO-Crate).

5.5 Additional metadata standards

RO-Crate also uses the Portland Common Data Model (PCDM version https://pcdm.org/2016/04/18/models) to describe repositories or collections of digital objects and imports these terms:

• RepositoryObject mapped to http://pcdm.org/models#Object
• RepositoryCollection mapped to http://pcdm.org/models#Collection
• RepositoryFile mapped to http://pcdm.org/models#File
• hasMember mapped to http://pcdm.org/models#hasMember
• hasFile mapped to http://pcdm.org/models#hasFile

Note: The terms RepositoryObject and RepositoryCollection are renamed to avoid collision between other vocabularies and the PCDM terms Collection and Object. The term RepositoryFile is renamed to avoid clash with RO-Crate’s File mapping to http://schema.org/MediaObject.

RO-Crate uses the Profiles Vocabulary to describe profiles using these terms and definitions:

• ResourceDescriptor mapped to http://www.w3.org/ns/dx/prof/ResourceDescriptor (definition)
• ResourceRole mapped to http://www.w3.org/ns/dx/prof/ResourceRole (definition)
• Profile mapped to http://www.w3.org/ns/dx/prof/Profile (definition)
• hasArtifact mapped to http://www.w3.org/ns/dx/prof/hasArtifact (definition)
• hasResource mapped to http://www.w3.org/ns/dx/prof/hasResource (definition)
• hasRole mapped to http://www.w3.org/ns/dx/prof/hasRole (definition)

From Dublin Core Terms RO-Crate uses:

• conformsTo mapped to http://purl.org/dc/terms/conformsTo
• Standard mapped to http://purl.org/dc/terms/Standard

From the IANA link relations registry:

• cite-as mapped to http://www.iana.org/assignments/relation/cite-as (defined by RFC8574)

These terms are being proposed by Bioschemas profile ComputationalWorkflow 1.0-RELEASE and FormalParameter 1.0-RELEASE to be integrated into Schema.org:

• ComputationalWorkflow mapped to https://bioschemas.org/ComputationalWorkflow
• FormalParameter mapped to https://bioschemas.org/FormalParameter
• input mapped to https://bioschemas.org/properties/input
• output mapped to https://bioschemas.org/properties/output

Note: In this specification the proposed Bioschemas terms use the temporary https://bioschemas.org/ namespace; future releases of RO-Crate may reflect mapping to the http://schema.org/ namespace.

To support geometry in Places, these terms from the GeoSPARQL ontology:

• Geometry mapped to http://www.opengis.net/ont/geosparql#Geometry
• asWKT mapped to http://www.opengis.net/ont/geosparql#asWKT

From CodeMeta 3.0:

• buildInstructions mapped to https://codemeta.github.io/terms/buildInstructions
• developmentStatus mapped to https://codemeta.github.io/terms/developmentStatus
• continuousIntegration mapped to https://codemeta.github.io/terms/continuousIntegration
• embargoEndDate mapped to https://codemeta.github.io/terms/embargoEndDate
• hasSourceCode mapped to https://codemeta.github.io/terms/hasSourceCode
• isSourceCodeOf mapped to https://codemeta.github.io/terms/isSourceCodeOf
• issueTracker mapped to https://codemeta.github.io/terms/issueTracker
• readme mapped to https://codemeta.github.io/terms/readme
• referencePublication mapped to https://codemeta.github.io/terms/referencePublication
• softwareSuggestions mapped to https://codemeta.github.io/terms/softwareSuggestions

Warning :As of 2025-01-09, the CodeMeta URIs do not resolve correctly, but are used here to match the Codemeta JSON-LD context https://w3id.org/codemeta/3.0 (issue #275). The CodeMeta terms maintainer and funding are not mapped, as these are already defined by schema.org.

5.6 Custom RO-Crate terms

The RO-Crate community maintains a common namespace for terms not covered by other vocabularies. This is mainly used by RO-Crate profiles, but the following term is included in the core RO-Crate context:

• localPath mapped to https://w3id.org/ro/terms#localPath

5.7 Summary of Coverage

RO-Crate is simply a way to make metadata assertions about a set of files and folders that make up a Dataset. These assertions can be made at two levels:

• Assertions at the RO-Crate level: for an RO-Crate to be useful, some metadata should be provided about the dataset as a whole (see minimum requirements for different use-cases below). In the RO-Crate Metadata Document, we distinguish the Root Data Entity, which represents the RO-Crate as a whole, from other Data Entities (files and folders contained in the RO-Crate) and Contextual Entities, e.g. a person, organisation, place related to an RO-Crate Data Entity.
• Assertions about files and folders contained in the RO-Crate: in addition to providing metadata about the RO-Crate as a whole, RO-Crate allows metadata assertions to be made about any other Data Entity.

This document has guidelines for ways to represent common requirements for describing data in a research context, e.g.:

• Contact information for a data set.
• Descriptive information for a dataset and the files within it and their contexts such as an abstract, spatial and temporal coverage.
• Associated publications.
• Funding relationships.
• Provenance information of various kinds; who (people and organizations) and what (instruments and computer programs) created or contributed to the data set and individual files within it.
• Workflows that operate on the data using standard workflow descriptions, including ‘single step workflows,’ executable files, or environments such as Singularity containers or Jupyter notebooks.

However, as RO-Crate uses the Linked Data principles, adopters of RO-Crate are free to supplement RO-Crate using Schema.org metadata and/or assertions using other Linked Data vocabularies (see Extending RO-Crate).

5.8 Future coverage

A future version of this specification will aim to cater for variable-level assertions: in some cases, e.g. for tabular data, additional metadata may be provided about the structure and variables within a given file. See the use case Describe a tabular data file directly in RO-Crate metadata for work-in-progress.

5.9 Recommended Identifiers

RO-Crate JSON-LD SHOULD use the following IDs where possible:

• For a Root Data Entity, an identifier which is RECOMMENDED to be a https://doi.org/ URI.
• For a Person participating in the research process: ORCID identifiers, e.g. https://orcid.org/0000-0002-1825-0097
• For Organizations including funders, Research Organization Registry URIs, e.g. https://ror.org/0384j8v12
• For entities of type Place, a geonames URL, e.g. http://sws.geonames.org/8152662/
• For file formats, a Pronom URL, for example https://www.nationalarchives.gov.uk/PRONOM/fmt/831.

In the absence of the above, RO-Crates SHOULD contain stable persistent URIs to identify all entities wherever possible.

6.1 Table of contents

The Root Data Entity is a Dataset that represents the RO-Crate as a whole; a Research Object that includes the Data Entities and the related Contextual Entities.

6.2 RO-Crate Metadata Descriptor

The RO-Crate Metadata Document MUST contain a self-describing RO-Crate Metadata Descriptor with the @id value ro-crate-metadata.json (or ro-crate-metadata.jsonld in legacy crates for RO-Crate 1.0 or older) and @type CreativeWork. This descriptor MUST have an about property referencing the Root Data Entity’s @id.

{ "@context": "https://w3id.org/ro/crate/1.2/context", 
  "@graph": [
    {
        "@type": "CreativeWork",
        "@id": "ro-crate-metadata.json",
        "about": {"@id": "./"},
        "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"}
    },
    
    {
      "@id": "./",
      "@type": "Dataset",
      ...
    }
  ]
}

Note: Even in Detached RO-Crate Packages, where the RO-Crate Metadata File may be absent or named with a prefix, the identifier ro-crate-metadata.json MUST be used within the RO-Crate JSON-LD.

The conformsTo of the RO-Crate Metadata Descriptor SHOULD have a single value which is a versioned permalink URI of the RO-Crate specification that the RO-Crate JSON-LD conforms to. The URI SHOULD start with https://w3id.org/ro/crate/.

Note: In RO-Crates conforming to version 1.1 and earlier, conformsTo MAY be an array and can include RO-Crate profiles in addition to the base specification. In version 1.2, it is now recommended that profile declarations are included on the Root Data Entity instead (see Direct Properties of the Root Data Entity).

metadata_entity = entity_map["ro-crate-metadata.json"]
root_entity = entity_map[metadata_entity["about"]["@id"]]

6.3 Direct properties of the Root Data Entity

The Root Data Entity MUST have all of the properties listed below. Each property also has requirements that apply to its value:

• @type: MUST be Dataset or an array that contains Dataset
• @id: SHOULD be the string ./ or an absolute URI (see below)
• name: SHOULD identify the dataset to humans well enough to disambiguate it from other RO-Crates
• description: SHOULD further elaborate on the name to provide a summary of the context in which the dataset is important.
• datePublished: MUST be a single string value in ISO 8601 date format, SHOULD be specified to at least the precision of a day, and MAY be a timestamp down to the millisecond.
• license: SHOULD link to a Contextual Entity or Data Entity in the RO-Crate Metadata Document with a name and description (see section on licensing). MAY, if necessary, be a textual description of how the RO-Crate may be used.

Note: These requirements are stricter than those published for Google Dataset Search which requires a Dataset to have a name and description.

Warning :The properties above are not sufficient to generate a DataCite citation. Advice on integrating with DataCite will be provided in a future version of this specification, or as an implementation guide.

Additional properties of schema.org types Dataset and CreativeWork MAY be added to further describe the RO-Crate as a whole, e.g. author, abstract, publisher. See sections contextual entities and provenance for further details.

If the RO-Crate conforms to one or more profiles, this should be described following the guidance in the section Declaring conformance of an RO-Crate profile.

6.4 Minimal example of RO-Crate

The following RO-Crate Metadata Document represents a minimal description of an RO-Crate that also follows the identifier recommendations above for use in an Attached RO-Crate Package.

{ "@context": "https://w3id.org/ro/crate/1.2/context", 
  "@graph": [

 {
    "@id": "ro-crate-metadata.json",
    "@type": "CreativeWork",
    "about": {"@id": "./"},
    "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"}
 },  
 {
    "@id": "./",
    "@type": "Dataset",
    "identifier": {"@id": "https://doi.org/10.4225/59/59672c09f4a4b"},
    "cite-as": "https://doi.org/10.4225/59/59672c09f4a4b",
    "datePublished": "2017",
    "name": "Data files associated with the manuscript:Effects of facilitated family case conferencing for ...",
    "description": "Palliative care planning for nursing home residents with advanced dementia ...",
    "license": {"@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/"},
    "creditText": "Agar, M. et al., 2017. Data supporting \"Effects of facilitated family case conferencing for advanced dementia: A cluster randomised clinical trial\". https://doi.org/10.4225/59/59672c09f4a4b"
 },
 {
    "@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/",
    "@type": "CreativeWork",
    "description": "This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Australia License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/au/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.",
    "identifier": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/",
    "name": "Attribution-NonCommercial-ShareAlike 3.0 Australia (CC BY-NC-SA 3.0 AU)"
 },
 {
    "@id": "https://doi.org/10.4225/59/59672c09f4a4b",
    "@type": "PropertyValue",
    "propertyID": "https://registry.identifiers.org/registry/doi",
    "value": "doi:10.4225/59/59672c09f4a4b",
    "url": "https://doi.org/10.4225/59/59672c09f4a4b"
  }
 ]
}

Alternatively the following is also valid, this time using the DOI as the @id of the Root Data Entity:

 {
    "@id": "ro-crate-metadata.json",
    "@type": "CreativeWork",
    "about": {"@id": "https://doi.org/10.4225/59/59672c09f4a4b"},
    "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"}
 },  
{
    "@id": "https://doi.org/10.4225/59/59672c09f4a4b",
    "@type": "Dataset",
    "cite-as": "https://doi.org/10.4225/59/59672c09f4a4b",
    "datePublished": "2017",
    "name": "Data files associated with the manuscript:Effects of facilitated family case conferencing for ...",
    "description": "Palliative care planning for nursing home residents with advanced dementia ...",
    "license": {"@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/"},
    "creditText": "Agar, M. et al., 2017. Data supporting \"Effects of facilitated family case conferencing for advanced dementia: A cluster randomised clinical trial\". https://doi.org/10.4225/59/59672c09f4a4b"
 }

7.1 Table of contents

The primary purpose for RO-Crate is to gather and describe a set of Data Entities in the form of:

• Actual files which are datastreams available on the local file system or over the web – when represented in the RO-Crate Metadata Document, these have the type File.
• Folders (or directories) of files – represented using the type Dataset.

An entity which has File or Dataset as one of its @type values:

• Is considered to be a Data Entity if its @id is an absolute URI or a relative URI.
• MAY have an @id which is a local identifier beginning with a #, in which case it is not considered to be a Data Entity.

The requirements for File and Dataset are set out below.

The Data Entities can be further described by referencing contextual entities such as persons, organizations and publications.

7.2 Referencing files and folders from the Root Data Entity

Where files and folders are represented as Data Entities in the RO-Crate JSON-LD, these MUST be linked to, either directly or indirectly, from the Root Data Entity using the hasPart property. Directory hierarchies MAY be represented with nested Dataset Data Entities, or the Root Data Entity MAY refer to files anywhere in the hierarchy using hasPart.

Data Entities representing files MUST have "File" as a value for @type. File is an RO-Crate alias for http://schema.org/MediaObject. The term File includes:

• Resources which are available locally (applicable only in the context of Attached RO-Crate Packages) and
• Web-based Data Entities which can be downloaded and saved as a file.

The rules for the @id property of Files are set out below.

In all cases, @type MAY be an array to also specify a more specific type, e.g. "@type": ["File", "ComputationalWorkflow"]

There is no requirement to represent every file and folder in an RO-Crate as Data Entities in the RO-Crate JSON-LD. Reasons for not describing files would include that the files: - are described in some other way, for example a manifest or another package management system, - are supporting files for a software application, - have metadata embedded in their filenames or paths which can be documented whithout having to describe every file, - have a purpose that is unknown to the crate author, but they need to be preserved as part of an archive.

In any of the above cases where files are not described, a directory containing a set of files MAY be described using a Dataset Data Entity that encapsulates the files with a description property that explains the contents. If the RO-Crate file structure is flat, or files are not grouped together, a description property on the Root Data Entity may be used, or a Dataset with a local reference beginning with # (e.g. to describe a certain type of file which occurs throughout the crate). This approach is recommended for RO-Crates which are to be deposited in a long-term archive.

7.3 Encoding file paths in @ids

Note that all @id identifiers must be valid URI references. Care must be taken to express any relative paths using / separator, correct casing, and escape special characters like space (%20) and percent (%25), for instance a File Data Entity from the Windows path Results and Diagrams\almost-50%.png becomes "@id": "Results%20and%20Diagrams/almost-50%25.png" in the RO-Crate JSON-LD.

In this document the term URI includes international IRIs; the RO-Crate Metadata Document is always UTF-8 and international characters in identifiers SHOULD be written using native UTF-8 characters (IRIs), however traditional URL encoding of Unicode characters with % MAY appear in @id strings. Example: "@id": "面试.mp4" is preferred over the equivalent "@id": "%E9%9D%A2%E8%AF%95.mp4"

7.4 Example Attached RO-Crate Package

The following is an example of an Attached RO-Crate Package linking to a file and folders.

The file layout of the example is:

<RO-Crate root>/
  |   ro-crate-metadata.json
  |   cp7glop.ai
  |   lots_of_little_files/
  |    | file1
  |    | file2
  |    | ...
  |    | file54

An example RO-Crate JSON-LD for the above would be as follows.

This example contains both a File Data Entity and a Directory Data Entity.

{ "@context": "https://w3id.org/ro/crate/1.2/context",
  "@graph": [
    {
      "@type": "CreativeWork",
      "@id": "ro-crate-metadata.json",
      "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"},
      "about": {"@id": "./"}
    },  
    {
      "@id": "./",
      "@type": [
        "Dataset"
      ],
      "name": "Example Dataset",
      "datePublished": "2016-02-01",
      "author": "https://orcid.org/0000-0003-4953-0830",
      "license": "CC-BY",
      "hasPart": [
        {
          "@id": "cp7glop.ai"
        },
        {
          "@id": "lots_of_little_files/"
        }
      ]
    },
    {
      "@id": "cp7glop.ai",
      "@type": "File",
      "name": "Diagram showing trend to increase",
      "contentSize": "383766",
      "description": "Illustrator file for Glop Pot",
      "encodingFormat": "application/pdf"
    },
    {
      "@id": "lots_of_little_files/",
      "@type": "Dataset",
      "name": "Too many files",
      "description": "This directory contains many small files -- the name of the file is a date in YYYY-MM-DD.csv, each file contains daily temperature readings, sampled hourly for the Glop Pot cave."
    },
    {
      "@id": "https://orcid.org/0000-0003-4953-0830",
      "@type": "Person",
      "name": "Michael Lake",
    }
  ]
}

7.5 Core Metadata for Data Entities

{
    "@id": "./",
    "@type": [
        "Dataset"
    ],
    "hasPart": [
        {
            "@id": "#ai-files"
        }
    ],
},
{
    "@id": "#ai-files",
    "@type": "Dataset",
    "name": ".ai Files",
    "description": "This dataset contains some files with the extension '.ai' which despite their extension have an encoding format of 'application/pdf'. These have yet to be catalogued."
}

{ "@context": "https://w3id.org/ro/crate/1.2/context",
  "@graph": [
    {
        "@type": "CreativeWork",
        "@id": "ro-crate-metadata.json",
        "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"},
        "about": {"@id": "./"}
  },  
  {
    "@id": "./",
    "@type": [
      "Dataset"
    ],
    "hasPart": [
      {
        "@id": "survey-responses-2019.csv"
      },
      {
        "@id": "https://zenodo.org/record/3541888/files/ro-crate-1.0.0.pdf"
      }
    ]
  },
  {
    "@id": "survey-responses-2019.csv",
    "@type": "File",
    "name": "Survey responses",
    "contentSize": "26452",
    "encodingFormat": "text/csv"
  },
  {
    "@id": "https://zenodo.org/record/3541888/files/ro-crate-1.0.0.pdf",
    "@type": "File",
    "name": "RO-Crate specification",
    "contentSize": "310691",
    "description": "RO-Crate specification",
    "encodingFormat": "application/pdf"
  }
]
}

  {
    "@id": "https://zenodo.org/record/3541888/files/ro-crate-1.0.0.pdf",
    "@type": "File",
    "name": "RO-Crate specification",
    "contentSize": "310691",
    "encodingFormat": "application/pdf",
    "sdDatePublished": "2020-04-09T13:09:21+01:00Z"
  }

  {
    "@id": "https://zenodo.org/record/3541888/files/ro-crate-1.0.0.pdf",
    "localPath": "docs/ro-crate-1.0.0.pdf",
    "@type": "File",
    "name": "RO-Crate specification",
    "contentSize": "310691",
    "encodingFormat": "application/pdf",
    "sdDatePublished": "2020-04-09T13:09:21+01:00Z"
  }

  {
    "@id": "survey-responses-2019.csv",
    "@type": "File",
    "name": "Survey responses",
    "encodingFormat": "text/csv",
    "contentUrl": "http://example.com/downloads/2019/survey-responses-2019.csv",
    "subjectOf": {"@id": "http://example.com/reports/2019/annual-survey.html"}
  },
  {
    "@id": "http://example.com/reports/2019/annual-survey.html",
    "@type": "WebPage",
    "name": "Survey responses (landing page)"
  }

  {
    "@id": "lots_of_little_files/",
    "@type": "Dataset",
    "name": "Too many files",
    "description": "This directory contains many small files, that we're not going to describe in detail.",
    "distribution": {"@id": "http://example.com/downloads/2020/lots_of_little_files.zip"}
  },
  {
    "@id": "http://example.com/downloads/2020/lots_of_little_files.zip",
    "@type": "DataDownload",
    "encodingFormat": ["application/zip", {"@id": "https://www.nationalarchives.gov.uk/PRONOM/x-fmt/263"}],
    "contentSize": "82818928"
  }

  {
    "@id": "./",
    "@type": "Dataset",
    "identifier": {"@id": "https://doi.org/10.48546/workflowhub.workflow.775.1"},
    "cite-as": "https://doi.org/10.48546/workflowhub.workflow.775.1",
    "name": "Research Object Crate for Jupyter Notebook Molecular Structure Checking",
    "distribution": {"@id": "https://workflowhub.eu/workflows/775/ro_crate?version=1"},
    "…": ""
  },
  {
    "@id": "https://workflowhub.eu/workflows/775/ro_crate?version=1",
    "@type": "DataDownload",
    "encodingFormat": ["application/zip", {"@id": "https://www.nationalarchives.gov.uk/PRONOM/x-fmt/263"}],
    "conformsTo": { "@id": "https://w3id.org/ro/crate" }
  }

7.6 Adding detailed descriptions of File encodings

The above example provides a media type for the file cp7glop.ai – which is useful as it may not be apparent that the file is readable as a PDF file from the extension alone. To add more detail, encodings SHOULD be linked using a PRONOM identifier to a Contextual Entity with @type array containing WebPage and Standard.

  {
    "@id": "cp7glop.ai",
    "@type": "File",
    "name": "Glop Plot map",
    "contentSize": "383766",
    "description": "Illustrator file for Glop Pot",
    "encodingFormat": ["application/pdf", {"@id": "https://www.nationalarchives.gov.uk/PRONOM/fmt/19"}]
  },
  {
    "@id": "https://www.nationalarchives.gov.uk/PRONOM/fmt/19",
    "name": "Acrobat PDF 1.5 -- Portable Document Format",
    "@type": ["WebPage", "Standard"]
  }

If there is no PRONOM identifier (and typically no media type string), then a contextual entity with a different URL as an @id MAY be used, e.g. documentation page of a software’s file format. The contextual entity SHOULD NOT include Standard in its @type if the page does not sufficiently document the format. The @type SHOULD include WebPage, or MAY include WebPageElement to indicate a section of the page.

For example, .trr is a an internal GROMACS file format that is not further documented as a standard, but is referenced from a WebPageElement adressable by an #anchor:

 {
    "@id": "traj.trr",
    "@type": "File",
    "name": "Trajectory",
    "description": "Trajectory of molecular dynamics simulation using GROMACS",
    "contentSize": "45512",
    "encodingFormat": {"@id": "https://manual.gromacs.org/documentation/2021/reference-manual/file-formats.html#trr"}
  },
  {
    "@id": "https://manual.gromacs.org/documentation/2021/reference-manual/file-formats.html#trr",
    "@type": "WebPageElement",
    "name": "GROMACS trajectory of a simulation (trr)"
  }

If there is no web-accessible description for a file format it SHOULD be described locally in the RO-Crate, for example in a Markdown file:

 {
    "@id": "some-file.some_extension",
    "@type": "File",
    "name": "Some file",
    "description": "A file in a non-standard format",
    "contentSize": "120",
    "encodingFormat": ["text/plain", {"@id": "some_extension.md"}]
  },
  {
    "@id": "some_extension.md",
    "@type": ["File", "CreativeWork"],
    "name": "Description of some_extension text-based file format",
    "encodingFormat": "text/markdown"
  }

7.7 File format profiles

Some generic file formats like application/json may be specialized using a profile document that defines expectations for the file’s content as expected by some applications, by using conformsTo to a contextual entity with types CreativeWork and Profile:

 { 
  "@id": "attributes.csv",
  "@type": "File",
  "encodingFormat": ["text/csv", {"@id": "https://www.nationalarchives.gov.uk/PRONOM/x-fmt/18"}],
  "conformsTo": {"@id": "https://docs.ropensci.org/dataspice/#create-spice"}
 },
 {
  "@id": "https://docs.ropensci.org/dataspice/#create-spice",
  "@type": ["CreativeWork", "Profile"],
  "name": "dataspice CSV profile"
 }

Tip: Profiles expressed in formal languages (e.g. XML Schema for validation) can have their own encodingFormat and conformsTo to indicate their file format.

Note: The Metadata Descriptor ro-crate-metadata.json is not a data entity, but is described with conformsTo to an implicit contextual entity for the RO-Crate specification, a profile of JSON-LD. RO-Crates themselves can be specialized using Profile Crates, specified with conformsTo on the Root Data Entity.

7.8 Referencing other RO-Crates

A referenced RO-Crate is also a Dataset Data Entity, but where its hasPart does not need to be listed. Instead, its content and further metadata is available from its own RO-Crate Metadata Document, which may be retrieved or packaged within an archive. An entity representing a referenced RO-Crate SHOULD have conformsTo pointing to the generic RO-Crate profile using the fixed URI https://w3id.org/ro/crate.

This section defines how a referencing RO-Crate (“A”) can declare Data Entities within A’s RO-Crate Metadata Document, in order to indicate a referenced RO-Crate (“B”). There are different options on how to find the identifier to assign to B in A, and how a consumer of A finding such a reference can find the corresponding RO-Crate Metadata Document for B.

{
  "@id": "https://pid.example.com/another-crate/",
  "@type": "Dataset",
  "conformsTo": { "@id": "https://w3id.org/ro/crate" }
}

{
  "@id": "http://example.com/another-crate/",
  "@type": "Dataset",
  "conformsTo": { "@id": "https://w3id.org/ro/crate" },
  "subjectOf": { "@id": "http://example.com/another-crate/ro-crate-metadata.json" }
},
{
  "@id": "http://example.com/another-crate/ro-crate-metadata.json",
  "@type": "CreativeWork",
  "encodingFormat": "application/ld+json",
  "sdDatePublished": "2024-08-22T23:57:03+01:00"
}

{
  "@id": "https://doi.org/10.48546/workflowhub.workflow.26.1",
  "@type": "Dataset",
  "conformsTo": [
    { "@id": "https://w3id.org/ro/crate" },
    { "@id": "https://w3id.org/workflowhub/workflow-ro-crate/1.0"}
  ]
},
{ "@id": "https://w3id.org/workflowhub/workflow-ro-crate/1.0",
  "@type": ["CreativeWork", "Profile"],
  "name": "Workflow RO-Crate Profile",
  "version": "1.0"
}

8.1 Table of contents

The RO-Crate SHOULD contain additional information about Contextual Entities for the use of both humans (in ro-crate-preview.html) and machines (in ro-crate-metadata.json). This also helps to maximize the extent to which an RO-Crate is self-contained and self-describing, in that it reduces the need for the consumer of an RO-Crate to refer to external information which may change or become unavailable over time.

8.2 Contextual vs Data entities

RO-Crate distinguishes between contextual entities and data entities.

Data entities primarily exist in their own right as a file or directory (which may be in the RO-Crate Root directory or downloadable by URL).

Contextual entities however primarily exist outside the digital sphere (e.g. People, Places) or are conceptual descriptions that primarily exist as metadata, like GeoCoordinates and ContactPoint.

Some contextual entities can also be considered data entities – for instance the license property refers to a CreativeWork that can reasonably be downloaded, however a license document is not usually considered as part of research outputs and would therefore typically not be included in hasPart on the root data entity.

Likewise, some data entities may also be described as contextual entities, for instance a File that is also a ScholarlyArticle. In such cases the contextual data entity MUST be described as a single JSON-LD object in the RO-Crate Metadata JSON-LD @graph and SHOULD list both relevant data and contextual types in a @type array.

Tip: Files in the RO-Crate Root are not necessarily data entities – the RO-Crate Metadata Descriptor is a file in the RO-Crate Root, but is considered a Contextual Entity as it is describing the RO-Crate, rather than being part of it. On the other hand, the Root Data Entity is a data entity within its own metadata file.

The RO-Crate Metadata JSON-LD @graph MUST NOT list multiple entities with the same @id; behaviour of consumers of an RO-Crate encountering multiple entities with the same @id is undefined.

8.3 Identifiers for contextual entities

A challenge can be how to assign identifiers for contextual entities, that is deciding on their @id value.

If an existing permalink (e.g. https://orcid.org/0000-0002-1825-0097) or other absolute URI (e.g. https://en.wikipedia.org/wiki/Josiah_S._Carberry) is reasonably unique for that entity, that URI SHOULD be used as identifier for the contextual entity in preference of an identifier local to the RO-Crate (e.g. #josiah or #0fa587c6-4580-4ece-a5df-69af3c5590e3).

Care should be taken to not describe two conceptually different contextual entities with the same identifier - e.g. if https://en.wikipedia.org/wiki/Josiah_S._Carberry is a Person it SHOULD NOT also be a CreativeWork (although this example is a fictional person!).

Where a related URL exists that may not be unique enough to serve as identifier, it can instead be added to a contextual entity using the property url.

See the appendix on JSON-LD identifiers for details.

8.4 People

A core principle of Linked Data is to use URIs to identify important entities such as people. The following is the minimum recommended way of representing an author of an RO-Crate. The author property MAY also be applied to a directory (Dataset), a File or other CreativeWork entities.

{
  "@type": "Dataset",
  "@id": "./",
  "...": "...",
  "author": {
    "@id": "https://orcid.org/0000-0002-8367-6908"
  }
},
{
  "@id": "https://orcid.org/0000-0002-8367-6908",
  "@type": "Person",
  "affiliation": "University of Technology Sydney",
  "name": "J. Xuan"
}

This uses an ORCID to unambiguously identify an author, represented as a Contextual Entity of type Person.

Note the string value for the organizational affiliation. This SHOULD be improved by also providing a Contextual Entity for the organization (see example below).

8.5 Organizations as values

An Organization SHOULD be the value for the publisher property of a Dataset or ScholarlyArticle.

{
  "@type": "Dataset",
  "@id": "./",
  "...": "...",
  "publisher": {
    "@id": "https://ror.org/03f0f6041"
  }
},
{
  "@id": "https://ror.org/03f0f6041",
  "@type": "Organization",
  "name": "University of Technology Sydney",
  "url": "https://ror.org/03f0f6041"
}

An Organization SHOULD also be used for a Person’s affiliation property.

{
  "@type": "Dataset",
  "@id": "./",
  "...": "...",
  "publisher": {
    "@id": "https://ror.org/03f0f6041"
  },
  "author": {
    "@id": "https://orcid.org/0000-0002-3545-944X"
  }
},
{
  "@id": "https://ror.org/03f0f6041",
  "@type": "Organization",
  "name": "University of Technology Sydney"
},
{
  "@id": "https://orcid.org/0000-0002-3545-944X",
  "@type": "Person",
  "affiliation": {
    "@id": "https://ror.org/03f0f6041"
  },
  "email": "peter.sefton@uts.edu.au",
  "name": "Peter Sefton"
}

8.6 Contact information

An RO-Crate SHOULD have contact information, using a contextual entity of type ContactPoint. Note that in Schema.org Dataset does not currently have the corresponding contactPoint property, so the contact point would need to be given through a Person or Organization contextual entity which are related to the Dataset via a author or publisher property.

{
  "@id": "./",
  "@type": "Dataset",
  "...": "...",
  "author": {
    "@id": "https://orcid.org/0000-0001-6121-5409"
  }
},
{
  "@id": "https://orcid.org/0000-0001-6121-5409",
  "@type": "Person",
  "contactPoint": {
    "@id": "mailto:tim.luckett@uts.edu.au"
  },
  "familyName": "Luckett",
  "givenName": "Tim",
  "identifier": "https://orcid.org/0000-0001-6121-5409",
  "name": "Tim Luckett"
},
{
  "@id": "mailto:tim.luckett@uts.edu.au",
  "@type": "ContactPoint",
  "contactType": "customer service",
  "email": "tim.luckett@uts.edu.au",
  "identifier": "tim.luckett@uts.edu.au",
  "url": "https://orcid.org/0000-0001-6121-5409"
}

8.7 Publications via citation property

To associate a publication with a dataset the RO-Crate JSON-LD MUST include a URL (for example a DOI URL) as the @id of a publication using the citation property.

For example:

{
  "@id": "./",
  "@type": "Dataset",
  "...": "...",
  "citation": {
    "@id": "https://doi.org/10.1109/TCYB.2014.2386282"
  }
}

The publication SHOULD be described further as an additional contextual entity of type ScholarlyArticle or CreativeWork.

{
  "@id": "https://doi.org/10.1109/TCYB.2014.2386282",
  "@type": "ScholarlyArticle",
  "author": [
    {
      "@id": "https://orcid.org/0000-0002-8367-6908"
    },
    {
      "@id": "https://orcid.org/0000-0003-0690-4732"
    },
    {
      "@id": "https://orcid.org/0000-0003-3960-0583"
    },
    {
      "@id": "https://orcid.org/0000-0002-6953-3986"
    }
  ],
  "identifier": "https://doi.org/10.1109/TCYB.2014.2386282",
  "issn": "2168-2267",
  "name": "Topic Model for Graph Mining",
  "journal": "IEEE Transactions on Cybernetics",
  "datePublished": "2015",
  "creditText": "J. Xuan, J. Lu, G. Zhang and X. Luo, \"Topic Model for Graph Mining,\" in IEEE Transactions on Cybernetics, vol. 45, no. 12, pp. 2792-2803, Dec. 2015, doi: 10.1109/TCYB.2014.2386282. keywords: {Data mining;Chemicals;Hidden Markov models;Inference algorithms;Data models;Vectors;Chemical elements;Graph mining;latent Dirichlet allocation (LDA);topic model;Graph mining;latent Dirichlet allocation (LDA);topic model}"
}

citation MAY also be used with other data and contextual entities:

{
  "@id": "communities-2018.csv",
  "@type": "File",
  "name": "Snapshot of RO Community efforts",
  "citation": {
    "@id": "https://doi.org/10.5281/zenodo.1313066"
  },
  "encodingFormat": "text/csv"
}

A data entity MAY provide a published DOI identifier that primarily captures that file or dataset. A citation MAY also be provided:

{
  "@id": "figure.png",
  "@type": ["File", "ImageObject"],
  "name": "XXL-CT-scan of an XXL Tyrannosaurus rex skull",
  "identifier": {
    "@id": "https://doi.org/10.5281/zenodo.3479743"
  },
  "citation": {
    "@id": "http://ndt.net/?id=19249"
  },
  "encodingFormat": "image/png"
},
{
    "@id": "https://doi.org/10.5281/zenodo.3479743",
    "@type": "PropertyValue",
    "propertyID": "https://registry.identifiers.org/registry/doi",
    "value": "doi.org/10.5281/zenodo.3479743",
    "url": "https://doi.org/10.5281/zenodo.3479743"
},
{
  "@id": "http://ndt.net/?id=19249",
  "@type": "ScholarlyArticle",
  "url": "http://ndt.net/?id=19249",
  "name": "An XXL-CT-scan of an XXL Tyrannosaurus rex skull. 19th World Conference on Non-Destructive Testing (WCNDT 2016)",
  "creditText": "Reims, N., Schulp, A., Böhnel, M., & Larson, P. (2016). An XXL-CT-scan of an XXL Tyrannosaurus rex skull. 19th World Conference on Non-Destructive Testing (WCNDT 2016), 13-17 June 2016 in Munich, Germany. e-Journal of Nondestructive Testing Vol. 21(7). https://www.ndt.net/?id=19249"
}

8.8 Publisher

The Root Data Entity SHOULD have a publisher property. This SHOULD be an Organization though it MAY be a Person.

{
  "@id": "./",
  "@type": "Dataset",
  "...": "...",
  "publisher": {
    "@id": "https://ror.org/03f0f6041"
  }
},
{
  "@id": "https://ror.org/03f0f6041",
  "@type": "Organization",
  "identifier": "https://ror.org/03f0f6041",
  "name": "University of Technology Sydney"
}

8.9 Funding and grants

To associate a research project with a Dataset, the RO-Crate JSON-LD SHOULD contain an entity for the project using type Organization, referenced by a funder property. The project Organization SHOULD in turn reference any external funder, either by using its URL as an @id or via a Contextual Entity describing the funder.

Tip: To make it very clear where funding is coming from, the Root Data Entity SHOULD also reference funders directly, as well as via a chain of references.

{
  "@id": "https://doi.org/10.5281/zenodo.1009240",
  "@type": "Dataset",
  "funder": {
    "@id": "https://ror.org/038sjwq14"
  }
},
{
  "@id": "https://eresearch.uts.edu.au/projects/provisioner",
  "@type": "Organization",
  "description": "The University of Technology Sydney Provisioner project is ...",
  "funder": [
    {
      "@id": "https://ror.org/03f0f6041"
    },
    {
      "@id": "https://ands.org.au"
    }
  ],
  "identifier": "https://eresearch.uts.edu.au/projects/provisioner",
  "name": "Provisioner"
},
{
  "@id": "https://ror.org/03f0f6041",
  "@type": "Organization",
  "identifier": "https://ror.org/03f0f6041",
  "name": "University of Technology Sydney"
},
{
  "@id": "https://ands.org.au",
  "@type": "Organization",
  "description": "The core purpose of the Australian National Data Service (ANDS) is ...",
  "identifier": "https://ands.org.au",
  "name": "Australian National Data Service"
}

8.10 Licensing, Access control and copyright

If a Data Entity has a license that is different from the license on the Root Data Entity, the entity SHOULD have a license property referencing a Contextual Entity with a type CreativeWork to describe the license. The @id of the license SHOULD be its URL (e.g. a Creative Commons License URL) and, when possible, a summary of the license included using the description property.

The below Data Entity has a copyrightHolder which is different from its author. There is a reference to an Organization describing the copyright holder and, to give credit, a sameAs relation to a web page. The license property here refers to https://creativecommons.org/licenses/by/4.0/ which is expanded in a separate contextual entity.

{
  "@id": "SciDataCon Presentations/AAA_Pilot_Project_Abstract.html",
  "@type": "File",
  "contentSize": "17085",
  "copyrightHolder": {
    "@id": "https://www.idrc.ca/"
  },
  "author": {
    "@id": "https://orcid.org/0000-0002-0068-716X"
  },
  "description": "Abstract for the Pilot Project initial findings",
  "encodingFormat": "text/html",
  "license": {
    "@id": "https://creativecommons.org/licenses/by/4.0/"
  },
  "sameAs": "https://www.scidatacon.org/2016/sessions/56/paper/265/"
},
{
  "@id": "https://creativecommons.org/licenses/by/4.0/",
  "@type": "CreativeWork",
  "name": "CC BY 4.0",
  "description": "Creative Commons Attribution 4.0 International License"
},
{
  "@id": "https://orcid.org/0000-0002-0068-716X",
  "@type": "Person",
  "identifier": "https://orcid.org/0000-0002-0068-716X",
  "name": "Cameron Neylon"
},
{
  "@id": "https://www.idrc.ca/",
  "@type": "Organization",
  "description": "Canadian Frown Corporation and funder of development research",
  "identifier": "IDRC",
  "name": "International Development Research Center"
}

{
  "@type": "CreativeWork",
  "@id": "ro-crate-metadata.json",
  "identifier": "ro-crate-metadata.json",
  "about": {
    "@id": "./"
  },
  "license": {
    "@id": "https://creativecommons.org/publicdomain/zero/1.0/"
  }
},
{
  "@id": "./",
  "@type": "Dataset",
  "...": "...",
  "license": {
    "@id": "https://creativecommons.org/licenses/by/4.0/"
  }
}

8.11 Extra metadata such as Exif

Schema.org has a generic extension mechanism for encoding arbitrary properties and values which are not available as Schema.org properties. An example of this is the Schema.org recommended way (see example 2) of including Exif technical image metadata.

To include EXIF, or other data which can be encoded as property/value pairs, add an array of references to Anonymous Entities which encode each property. This example shows one property of several hundred.

{
  "@id": "pics/2017-06-11%2012.56.14.jpg",
  "@type": ["File", "ImageObject"],
  "contentSize": "5114778",
  "author": {
    "@id": "https://orcid.org/0000-0002-3545-944X"
  },
  "description": "Depicts a fence at a disused motor racing venue with the front part of a slightly out of focus black dog in the foreground.",
  "encodingFormat": "image/jpeg",
  "exifData": [
    {
      "@id": "#2eb90b09-a8b8-4946-805b-8cba077a7137"
    },
    {
      "@id": "#c2521494-9b94-4b23-a713-6b281f540823"
    }
  ]
},
{
  "@id": "#c2521494-9b94-4b23-a713-6b281f540823",
  "@type": "PropertyValue",
  "name": "InternalSerialNumber",
  "value": "4102011002108002"
}

8.12 Places

To associate a Data Entity with a Contextual Entity representing a geographical location or region, the entity SHOULD have a property of contentLocation or spatialCoverage with a value of type Place.

To express point or shape geometry it is recommended that a geo property on a Place entity SHOULD link to a Geometry entity, with an asWKT property that expresses the point or shape in Well Known Text (WKT) format. This example is a point, POINT ($longitude, $latitude), but other asWKT primitives, LINESTRING & POLYGON SHOULD be used as required.

This example shows how to define a place, using a geonames ID:

{
  "@id": "./",
  "@type": "Dataset",
  "...": "...",
  "contentLocation": {
    "@id": "http://sws.geonames.org/8152662/"
  }
},
{
  "@id": "http://sws.geonames.org/8152662/",
  "@type": "Place",
  "description": "Catalina Park is a disused motor racing venue, located at Katoomba ...",
  "geo": {
    "@id": "_:Geometry-1"
  },
  "identifier": "http://sws.geonames.org/8152662/",
  "uri": "https://www.geonames.org/8152662/catalina-park.html",
  "name": "Catalina Park"
},
{
  "@id": "_:Geometry-1",
  "@type": "Geometry",
  "name": "Geometry-1",
  "asWKT": "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POINT (150.301195 -33.7152)"
}

Tip: To find the @id and identifier corresponding to a GeoNames HTML page like https://www.geonames.org/8152662/catalina-park.html, click its .rdf button to download the RDF metadata (https://sws.geonames.org/8152662/about.rdf). In the RDF metadata, find the line that looks like the following: <gn:Feature rdf:about=\"http://sws.geonames.org/8152662/\">. The part in the quotes is the identifier (in this case, http://sws.geonames.org/8152662/).

Tip: Note the use of a JSON-LD blank node identifier here (starting with _:) - this indicates to an RO-Crate presentation application that the entity does not stand in its own right, and may be displayed inline (in this case as a map).

Tip: It is considered best practice to include the explicit mentioning of the CRS (Coordinate Reference System) identified through its opengis URI at the start of the asWKT field. This provides the essential context to have the numbers in the remainder of the string correctly be plotted on the map. Note, however, that many GIS related tools expect that information to be fed in via a separate configuration setting or API call. Handling these strings in any app that interacts with such systems might therefore require some extra processing.

Note: Any of the schema.org geographical classes and entities MAY be used on a Place element to describe geographical points and shapes, and previous versions of this specification did show examples of using latitude and longitude properties and entities such as GeoCoordinates. However, this results in very verbose JSON-LD, and there is some imprecision in the Schema.org specification that makes this approach hard to implement in applications for analysis or presentation of RO-Crates. We found that developers were resorting to embedding escaped GeoJSON as string values in RO-Crate; instead of this, WKT format is more compact and easier to implement and is recommended for use in RO-Crate as shown above.

8.13 Subjects & keywords

Subject properties (equivalent to a Dublin Core Subject) on the root data entity or a data entity MUST use the about property.

Keyword properties MUST use keywords. Note that by Schema.org convention, keywords are given as a single JSON string, with individual keywords separated by commas.

{
  "keywords": "Gibraltar, Spain, British Overseas Territory, city, map",
  "about": { "@id": "http://dbpedia.org/resource/Gibraltar" }
}

8.14 Time

To describe the time period which an RO-Crate Data Entity (or the root data entity) is about, use temporalCoverage:

{
  "@id": "photos/",
  "@type": "Dataset",
  "name": "Photos of Gibraltar from 1950 till 1975",
  "about": {"@id": "http://dbpedia.org/resource/Gibraltar"},
  "temporalCoverage": "1950/1975"
}

8.15 Thumbnails

A File or any other entity MAY have a thumbnail property which references another file.

For example, the below RepositoryObject is related to four files which are all versions of the same image (via hasFile), one of which is a thumbnail. The thumbnail MUST be included in the RO-Crate.

If thumbnails are incidental to the data set, they need not be referenced by hasPart or hasFile relationships, but they must be in the BagIt manifest if in a Bagged RO-Crate.

{
  "@id": "https://omeka.uws.edu.au/farmstofreeways/api/items/383",
  "@type": [
    "RepositoryObject",
    "ImageObject"
  ],
  "identifier": [
    "ftf_photo_stapleton1"
  ],
  "description": [
    "Photo of Eugenie Stapleton inside her home"
  ],
  "license": [
    "Content in the Western Sydney Women's Oral History Project: From farms to freeways collection is licensed under a Creative Commons CC BY 3.0 AU licence (https://creativecommons.org/licenses/by/3.0/au/)."
  ],
  "publisher": [
    "University of Western Sydney"
  ],
  "hasFile": [
    {
      "@id": "files/383/original_c0f1189ec13ca936e8f556161663d4ba.jpg"
    },
    {
      "@id": "files/383/fullsize_c0f1189ec13ca936e8f556161663d4ba.jpg"
    },
    {
      "@id": "files/383/thumbnail_c0f1189ec13ca936e8f556161663d4ba.jpg"
    },
    {
      "@id": "files/383/square_thumbnail_c0f1189ec13ca936e8f556161663d4ba.jpg"
    }
  ],
  "thumbnail": [
    {
      "@id": "files/383/thumbnail_c0f1189ec13ca936e8f556161663d4ba.jpg"
    }
  ],
  "name": [
    "Photo of Eugenie Stapleton 1"
  ],
  "copyrightHolder": [
    { "@id": "https://westernsydney.edu.au"}
  ],
},
{
  "@type": "File",
  "@id": "files/384/original_2ebbe681aa6ec138776343974ce8a3dd.jpg"
},
{
  "@type": "File",
  "@id": "files/384/fullsize_2ebbe681aa6ec138776343974ce8a3dd.jpg"
},
{
  "@type": "File",
  "@id": "files/384/thumbnail_2ebbe681aa6ec138776343974ce8a3dd.jpg"
},
{
  "@type": "File",
  "@id": "files/384/square_thumbnail_2ebbe681aa6ec138776343974ce8a3dd.jpg"
}

9.1 RO-Crates with a “main entity”

An RO-Crate may have a single main entity that is considered the point, or focus of the RO-Crate. This may be referenced from the Root Data Entity using the mainEntity property.

{
    "@id": "./",
    "@type": "Dataset",
    "name": "Example Workflow",
    "description": "An example workflow RO Crate",
    "license": "Apache-2.0",
    "datePublished": "2023-01-01",
    "mainEntity": {
      "@id": "example_workflow.cwl"
    },
    "hasPart": [
      {
        "@id": "example_workflow.cwl"
      },
      {
        "@id": "diagram.svg"
      },
      {
        "@id": "README.md"
      }
    ]
}

{
    "@id": "./",
    "@type": ["Dataset", "RepositoryObject"],
    "name": "Reibey, Mary (1777 - 1855)",
    "...": "...",
    "mainEntity": {
        "@id": "https://en.wikipedia.org/wiki/Mary_Reibey"
    },
    "hasPart" : [
        {"@id": "photo1.jpg"},
        {"@id": "photo2.jpg"}
    ]
}

{
    "@id": "https://en.wikipedia.org/wiki/Mary_Reibey",
    "@type": "Person",
    "name": "Mary Reibey",
    "description": "Mary Reibey née Haydock (12 May 1777 – 30 May 1855) was an English-born merchant, shipowner and trader ..."
}

9.2 RO-Crates which focus on multiple Contextual Entities

RO-Crates may describe Contextual Entities which are linked to the Root Data Entity via mentions relationships.

For example, RO-Crates can be used as containers for Schema.org-style vocabularies (here also extending the RO-Crate JSON-LD context to define the namespace for txc:):

{ "@context": [
    "https://w3id.org/ro/crate/1.2/context",
    {"txc": "https://purl.archive.org/language-data-commons/terms#"}
  ],
  "@graph": [
    {
      "@id": "ro-crate-metadata.json",
      "@type": "CreativeWork",
      "description": "RO-Crate Metadata File Descriptor (this file)",
      "conformsTo": {"@id": "https://w3id.org/ro/crate/1.2"},
      "about": {"@id": "./"}
    },
    {
      "@id": "./",
      "@type": "Dataset",
      "description": "This is an experimental language data ontology based on OLAC terms for use in the ATAP and LDaCA projects",
      "hasPart": [],
      "name": "Language Data Ontology",
      "mentions": ["txc:Annotation", "txc:CollectionEvent"]
    },
    {
      "@id": "txc:Annotation",
      "@type": "rdfs:Class",
      "name": "Annotation",
      "sameAs": "http://www.language-archives.org/REC/type-20020628.html#annotation",
      "rdfs:comment": "The resource includes information which annotates some other linguistic record.",
      "rdfs:label": "Annotation",
      "rdfs:subClassOf": {
        "@id": "schema:CreativeWork"
      }
    },
    {
      "@id": "txc:CollectionEvent",
      "@type": "rdfs:Class",
      "name": "CollectionEvent",
      "rdfs:comment": "A description of an event at which one or more PrimaryTexts were captured, e.g. as video or audio",
      "rdfs:label": "CollectionEvent",
      "rdfs:subClassOf": [
        {
          "@id": "schema:Event"
        },
        {
          "@id": "schema:CreateAction"
        }
      ]
    }
  ]
}    

The following example shows how both mainEntity and mentions can be used together, in this case to describe a workflow with a test suite:

• the mainEntity is the workflow file, a Data Entity
• the test suite #test1 is a Contextual Entity highlighted using mentions.

{
    "@id": "./",
    "@type": "Dataset",
    "name": "sort-and-change-case",
    "description": "sort lines and change text to upper case",
    "license": "Apache-2.0",
    "mainEntity": {
        "@id": "sort-and-change-case.ga"
    },
    "mentions": [ {"@id": "#test1"} ],
    "hasPart": [
        {
            "@id": "sort-and-change-case.ga"
        },
        {
            "@id": "test/test1/sort-and-change-case-test.yml"
        }
    ]
},
{
    "@id": "#test1",
    "name": "test1",
    "@type": "TestSuite",
    "instance": [
        {"@id": "#test1_1"}
    ],
    "definition": {"@id": "test/test1/sort-and-change-case-test.yml"}
},
{
    "@id": "#test1_1",
    "name": "test1_1",
    "@type": "TestInstance",
    "runsOn": {"@id": "#jenkins"},
    "url": "http://example.org/jenkins",
    "resource": "job/tests/"
},
{
    "@id": "test/test1/sort-and-change-case-test.yml",
    "@type": [
        "File",
        "TestDefinition"
    ],
    "conformsTo": {"@id": "#planemo"}
},
{
    "@id": "#jenkins",
    "@type": "TestService",
    "name": "Jenkins",
    "url": {"@id": "https://www.jenkins.io"}
},
{
    "@id": "#planemo",
    "@type": "SoftwareApplication",
    "name": "Planemo",
    "url": {"@id": "https://github.com/galaxyproject/planemo"},
    "version": ">=0.70"
}

10.1 Table of contents

10.2 Equipment used to create files

To specify which equipment was used to create or update a Data Entity, the RO-Crate JSON-LD SHOULD have a Contextual Entity for each item of equipment which SHOULD be of @type IndividualProduct. The entity SHOULD have a serial number and manufacturer that identify the equipment as completely as possible. In the following case the equipment is a bespoke machine. The equipment SHOULD be described on a web page, and the address of the description SHOULD be used as its @id.

{
  "@id": "https://confluence.csiro.au/display/ASL/Hovermap",
  "@type": "IndividualProduct",
  "description": "The CSIRO bentwing is an unmanned aerial vehicle (UAV, commonly known as a drone) with a LIDAR ... ",
  "identifier": "https://confluence.csiro.au/display/ASL/Hovermap",
  "name": "Bentwing"
}

Use the CreateAction and UpdateAction types to model the contributions of Contextual Entities of type Person or Organization in the creation of files.

In the example below, the CreateAction has a human agent, the object is a Place (a cave) and the Hovermap drone is the instrument used in the file creation event.

{
  "@id": "#DataCapture_wcc02",
  "@type": "CreateAction",
  "agent": {
    "@id": "https://orcid.org/0000-0002-1672-552X"
  },
  "instrument": {
    "@id": "https://confluence.csiro.au/display/ASL/Hovermap"
  },
  "object": {
    "@id": "#victoria_arch"
  },
  "result": [
    {
      "@id": "wcc02_arch.laz"
    },
    {
      "@id": "wcc02_arch_traj.txt"
    }
  ]
},
{
    "@id": "#victoria_arch",
    "@type": "Place",
    "address": "Wombeyan Caves, NSW 2580",
    "name": "Victoria Arch"
}

10.3 Software used to create files

To specify which software was used to create or update a file, the software application SHOULD be represented with an entity of type SoftwareApplication, with a version property, e.g. from tool --version.

For example:

{
      "@id": "https://www.imagemagick.org/",
      "@type": "SoftwareApplication",
      "url": "https://www.imagemagick.org/",
      "name": "ImageMagick",
      "version": "ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org"
}

The software SHOULD be associated with the File(s) (or other data entities) it created as an instrument of a CreateAction, with the File referenced by a result property. Any input files SHOULD be referenced by the object property.

In the below example, an image with the @id of pics/2017-06-11%2012.56.14.jpg was transformed into an new image pics/sepia_fence.jpg using the ImageMagick software application as “instrument”. Actions MAY have human-readable names, which MAY be machine generated for use at scale.

{
  "@id": "#Photo_Capture_1",
  "@type": "CreateAction",
  "agent": {
    "@id": "https://orcid.org/0000-0002-3545-944X"
  },
  "description": "Photo snapped on a photo walk on a misty day",
  "endTime": "2017-06-11T12:56:14+10:00",
  "instrument": [
    {
      "@id": "#EPL1"
    },
    {
      "@id": "#Panny20mm"
    }
  ],
  "result": {
    "@id": "pics/2017-06-11%2012.56.14.jpg"
  }
},
{
  "@id": "#Sepia_Conversion_1",
  "@type": "CreateAction",
  "name": "Convert dog image to sepia",
  "description": "convert -sepia-tone 80% test_data/sample/pics/2017-06-11\\ 12.56.14.jpg test_data/sample/pics/sepia_fence.jpg",
  "endTime": "2018-09-19T17:01:07+10:00",
  "instrument": {
    "@id": "https://www.imagemagick.org/"
  },
  "object": {
    "@id": "pics/2017-06-11%2012.56.14.jpg"
  },
  "result": {
    "@id": "pics/sepia_fence.jpg"
  }
}

Tip: If representing command lines, double escape \\ so that JSON preserves the \ character.

If multiple SoftwareApplications have been used in composition, such as from a script or workflow, then the CreateAction’s instrument SHOULD rather reference a SoftwareSourceCode which can be further described as explained in the Workflows and scripts section.

10.4 Recording changes to RO-Crates

To record an action which changes an entity’s metadata, or changes its state in a publication or other workflow, a CreateAction or UpdateAction SHOULD be associated with a Data Entity or, for the RO-Crate itself, with the root data entity.

A curation Action MUST have at least one object which associates it with either the root data entity Dataset or one of its components.

An Action which creates new Data entities - for example, the creation of a new metadata file - SHOULD have these as results.

An Action SHOULD have a name and MAY have a description.

An Action SHOULD have an endTime, which MUST be in ISO 8601 date format and SHOULD be specified to at least the precision of a day. An Action MAY have a startTime meeting the same specifications.

An Action SHOULD have a human agent who was responsible for authorizing the action, and MAY have an instrument which associates the action with a particular piece of software (for example, the content management system or data catalogue through which an update was approved) which SHOULD be of @type SoftwareApplication.

An Action’s status MAY be recorded in an actionStatus property. The status must be one of the values enumerated by ActionStatusType: ActiveActionStatus, CompletedActionStatus, FailedActionStatus or PotentialActionStatus.

An Action which has failed MAY record any error information in an error property.

UpdateAction SHOULD only be used for actions which affect the Dataset as a whole, such as movement through a workflow.

To record curation actions which modify a File within a Dataset - for example, by correcting or enhancing metadata - the old version of the File SHOULD be retained, and a CreateAction added which has the original version as its object and the new version as its result.

{
    "@id": "#history-01",
    "@type": "CreateAction",
    "object": { "@id": "https://doi.org/10.5281/zenodo.1009240" },
    "name": "RO-Crate created",
    "endTime": "2018-08-31",
    "agent": { "@id": "https://orcid.org/0000-0001-5152-5307" },
    "instrument": { "@id": "https://stash.research.uts.edu.au" },
    "actionStatus":  { "@id": "http://schema.org/CompletedActionStatus" }
},

{
    "@id": "#history-02",
    "@type": "UpdateAction",
    "object": { "@id": "https://doi.org/10.5281/zenodo.1009240" },
    "name": "RO-Crate published",
    "endTime": "2018-09-10",
    "agent": { "@id": "https://orcid.org/0000-0001-5152-5307" },
    "instrument": { "@id": "https://stash.research.uts.edu.au" },
    "actionStatus":  {"@id":" http://schema.org/CompletedActionStatus" }
},

{ 
    "@id": "#history-03",
    "@type": "CreateAction",
    "object": { "@id": "metadata.xml.v0.1" },
    "result": { "@id": "metadata.xml" },
    "name": "metadata update",
    "endTime": "2018-09-12",
    "agent": { "@id": "https://orcid.org/0000-0001-5152-5307" },
    "instrument": { "@id": "https://stash.research.uts.edu.au" },
    "actionStatus": { "@id": "http://schema.org/CompletedActionStatus" }
},

{
    "@id": "#history-04",
    "@type": "UpdateAction",
    "object": { "@id": "https://doi.org/10.5281/zenodo.1009240" },
    "name": "RO-Crate published",
    "endTime": "2018-09-13",
    "agent": { "@id": "https://orcid.org/0000-0001-5152-5307" },
    "instrument": { "@id": "https://stash.research.uts.edu.au" },
    "actionStatus": { "@id": "http://schema.org/FailedActionStatus" },
    "error": "Record is already published"
},


{
    "@id": "https://stash.research.uts.edu.au",
    "@type": "IndividualProduct",
    "name": "Stash",
    "description": "UTS Research Data Catalogue",
    "identifier": "https://stash.research.uts.edu.au"
}

10.5 Digital Library and Repository content

To describe an export from a Digital Library or repository system, RO-Crate uses the Portland Common Data Model (PCDM).

A Contextual Entity from a repository, representing an abstract entity such as a person, or a work, or a place SHOULD have a @type of RepositoryObject, in addition to any other types.

Objects MAY be grouped together in RepositoryCollections with hasMember pointing to the RepositoryObject.

Note: The terms RepositoryObject and RepositoryCollection are renamed in RO-Crate to avoid collision between other vocabularies and the PCDM terms Collection and Object. The term RepositoryFile is renamed to avoid clash with RO-Crate’s File mapping to http://schema.org/MediaObject.

Warning :PCDM specifies that files should have only technical metadata, not descriptive metadata, which is not a restriction in RO-Crate. If the RO-Crate is to be imported into a strict PCDM repository, modeling of object/file relationships will be necessary.

For example, this data is exported from an Omeka repository:

{
   "@id": "https://omeka.uws.edu.au/farmstofreeways/api/collections/6",
   "@type": "RepositoryCollection",
   "title":  "Project Materials",   
   "description": [
      "Materials associated with the project, including fliers seeking participants, lists of sources and question outline.   "
   ],
   "publisher": {"@id": "University of Western Sydney"},
   "rights": "Copyright University of Western Sydney 2015",
   "hasMember": [
      {
         "@id": "https://omeka.uws.edu.au/farmstofreeways/api/items/166"
      },
      {
         "@id": "https://omeka.uws.edu.au/farmstofreeways/api/items/167"
      },
      {
         "@id": "https://omeka.uws.edu.au/farmstofreeways/api/items/168"
      },
      {
         "@id": "https://omeka.uws.edu.au/farmstofreeways/api/items/169"
      }
   ]
},
{
   "@id": "https://omeka.uws.edu.au/farmstofreeways/api/items/166",
   "@type": "RepositoryObject",
   "title": [
      "Western Sydney Women's Oral History Project: Flier (illustrated)"
   ],
   "description": [
      "Flier (illustrated) seeking participants for the project."
   ],
   "publisher": { "@id": "https://westernsydney.edu.au"},
   "rights": "Copyright University of Western Sydney 2015",
   "originalFormat": "Paper",
   "identifier": "FTF_flier_illust",   
   "rightsHolder": [
      "Western Sydney University"
   ],
   "license": { 
     "@id": "https://creativecommons.org/licenses/by/3.0/au/"
   },
   "hasFile": [
      {
         "@id": "content/166/original_eece70f73bf8979c0bcfb97065948531.pdf"
      },
     ...
   ]
},
{
   "@type": "File",
   "@id": "content/166/original_eece70f73bf8979c0bcfb97065948531.pdf"
}