Wiki source code of Application details
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | (% class="box infomessage" %) | ||
2 | ((( | ||
3 | (% style="text-align: justify;" %) | ||
4 | The metadata representation (instance) of each openMINDS metadata schema has to be provided as JSON-LD. For a graph database and correspondingly designed metadata models, a full metadata description of a research product includes multiple, interlinked metadata instances representing various schemas. | ||
5 | |||
6 | (% style="text-align: justify;" %) | ||
7 | [[JSON-LD>>https://json-ld.org/]] is a powerful, lightweight Linked Data format, ideal for storing such collections of interlinked metadata instances of a graph database (e.g., the EBRAINS Knowledge Graph). | ||
8 | |||
9 | (% style="text-align: justify;" %) | ||
10 | Please find below, a general description of a typical JSON-LD as used in the EBRAINS Knowledge Graph and the different approaches in place for writing a metadata description for your research product in form of an openMINDS conform JSON-LD metadata collection. | ||
11 | ))) | ||
12 | |||
13 | === JSON-LD - the openMINDS serialization format === | ||
14 | |||
15 | (% style="text-align: justify;" %) | ||
16 | As stated above, openMINDS supports JSON-LD as serialization format for the metadata representations (instances) of its schemas. In the following we will briefly explain the JSON-LD syntax necessary for writing a correct openMINDS instance. | ||
17 | |||
18 | (% style="text-align: justify;" %) | ||
19 | Let us first start with the most simple example: the openMINDS core schema ContactInformation. According to its schema template (cf. [[ContactInformation HTML>>https://humanbrainproject.github.io/openMINDS/core/schemas/v3/actors/contactInformation.html||rel="noopener noreferrer" target="_blank"]]), the only required property for a contact information instance is **##"email"##**. However, every valid JSON-LD needs two more technical properties: **##"@type"##** and **##"@id"##**. Here, as example, a valid JSON-LD for a contact information instance: | ||
20 | |||
21 | {{code language="json"}} | ||
22 | { | ||
23 | "@type": "https://openminds.ebrains.eu/core/ContactInformation", | ||
24 | "@id": "http://localhost/contactInformation/email_openMINDS", | ||
25 | "email": "openminds@ebrains.eu" | ||
26 | } | ||
27 | {{/code}} | ||
28 | |||
29 | (% style="text-align: justify;" %) | ||
30 | To simplify the human-readability for all openMINDS users, technical properties specifically required for the JSON-LD syntax are, on purpose, not defined in the openMINDS schema templates. Instead, these technical properties are first added to the required property list of all openMINDS schemas after their template is transformed into an established, full-blown metadata schema format, such as JSON-Schema (cf. [[Technical details>>Technical details]]). | ||
31 | |||
32 | (% style="text-align: justify;" %) | ||
33 | The JSON-LD property **##"@type"##** expects an entry (value) of type string that defines which schema is used to validate the particular JSON-LD. Within openMINDS each schema can be identified through its namespace (type) with the following naming convention: | ||
34 | ##"@type": "https:~/~/openminds.ebrains.eu/XXX/YYY"##, where **##XXX##** and **##YYY##** should be replaced with the openMINDS sub-module (e.g., ##core##) and corresponding schema (e.g., ##ContactInformation##), respectively. | ||
35 | |||
36 | The JSON-LD property **##"@id"##** expects an entry (value) of type string that provides a unique identifier for the created metadata instance. On your local machine, you should use the following naming convention for this identifier: | ||
37 | ##"@id": "http:~/~/localhost/YYY/ZZZ"##, where **##YYY##** and **##ZZZ##** should be replaced with the openMINDS schema (e.g., ##ContactInformation##) and your own collection-unique identifier, respectively. Within the EBRAINS Knowledge Graph (KG) this identifier has to be a universally unique identifier (UUID). Assuming you locally generated a openMINDS metadata collection, your user-defined **##"@id"##** will be automatically replaced with a UUID in all your JSON-LDs if they are uploaded to the KG.. | ||
38 | |||
39 | === The openMINDS Python API === | ||
40 | |||
41 | (% style="text-align: justify;" %) | ||
42 | For users with at least some programming experience, one possible way to write openMINDS conform JSON-LDs is to use the openMINDS Python API. | ||
43 | |||
44 | === The openMINDS spreadsheet templates === | ||
45 | |||
46 | (% style="text-align: justify;" %) | ||
47 | For users with no programming experience, it is possible to provide at least openMINDS conform metadata by using the openMINDS spreadsheet templates. | ||
48 | |||
49 | === The Knowledge Graph Editor === | ||
50 | |||
51 | (% style="text-align: justify;" %) | ||
52 | For curators of the EBRAINS Share Data service, it is possible to register openMINDS conform metadata into the EBRAINS Knowledge Graph database by using the Knowledge Graph Editor. |