Changes for page Application details

Last modified by lzehl on 2021/10/13 13:11
From version 40.1
edited by lzehl
on 2021/05/02 14:25
Change comment: There is no comment for this version
To version 37.1
edited by lzehl
on 2021/03/17 14:04
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -30,7 +30,7 @@
30 30  {{/code}}
31 31  
32 32  (% style="text-align: justify;" %)
33 -These additional technical properties specifically required for the JSON-LD syntax are, on purpose, not defined in the openMINDS schema templates in order to simplify the human-readability for all users. 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>>Collabs.openminds.openMINDS core.Application details.Technical details.WebHome||target="_blank"]]). Let us explain in the following why these technical JSON-LD properties are needed and how they are correctly provided for an openMINDS instance.
33 +These additional technical properties specifically required for the JSON-LD syntax are, on purpose, not defined in the openMINDS schema templates in order to simplify the human-readability for all users. 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||target="_blank"]]). However, let us explain here why these technical JSON-LD properties are needed and how they are correctly provided for an openMINDS instance.
34 34  
35 35  (% style="text-align: justify;" %)
36 36  The JSON-LD properties **##"@context"##** and **##"@vocab"##** define a common vocabulary mapping, by stating a prefix that extends all non-JSON-LD property names and **##"@type"##** values that do not correspond to an IRI or compact IRI. Within openMINDS, each metadata instance should map to the openMINDS vocabulary, meaning the **##"@context"##** and **##"@vocab"##** is the same across all metadata instances (cf. code above). If you want to learn more about the power of the openMINDS vocabulary please go to: [[Technical details>>doc:Collabs.openminds.openMINDS core.Implementation details.WebHome||target="_blank"]].
... ... @@ -50,7 +50,7 @@
50 50  **##"@id": "http:~/~/localhost/YYY/ZZZ"##**
51 51  
52 52  (% style="text-align: justify;" %)
53 -where **##YYY##** and **##ZZZ##** should be replaced with the openMINDS schema (e.g., **##ContactInformation##**) and your own collection-unique identifier (e.g. **##email_openMINDS##**), respectively. While locally this instance identifier only has to be unique within your collection or system, it has to be globally unique if you want to share your instances with the world. Within the EBRAINS Knowledge Graph (KG) this identifier is therefore replaced with an universally unique identifier (UUID) with integration of your openMINDS collection into the public graph database.
53 +where **##YYY##** and **##ZZZ##** should be replaced with the openMINDS schema (e.g., **##ContactInformation##**) and your own collection-unique identifier (e.g. **##email_openMINDS##**), respectively. Within the EBRAINS Knowledge Graph (KG) this identifier has to be a universally unique identifier (UUID), and, therefore, will be replaced accordingly with a UUID by the EBRAINS Knowledge Graph system during the integration process of your openMINDS collection.
54 54  
55 55  (% style="text-align: justify;" %)
56 56  The JSON-LD property **##"@id"##** is also used to link two different metadata instances. Let us introduce a second openMINDS instance of the openMINDS core schema Person which can link to an openMINDS instance of the openMINDS core schema ContactInformation. Here a valid JSON-LD for a person with a link to the contact information we defined above:
... ... @@ -74,7 +74,7 @@
74 74  Note that we do not use all properties defined for the schema (cf. the [[Person HTML>>https://humanbrainproject.github.io/openMINDS/core/schemas/v3/actors/person.html||rel="noopener noreferrer" target="_blank"]]), but that we only used the required property **##"givenName"##** and two optional properties **##"familyName"##** and **##"ContactInformation"##**. Please also note, that a person is allowed to link to multiple contact information instances, hence it expects a list of dictionaries, instead of a single dictionary (which would be valid if only a single link is expected).
75 75  
76 76  (% style="text-align: justify;" %)
77 -You learned now how a valid JSON-LD for an openMINDS metadata instance looks like and how linkages between openMINDS instances are defined. In the following sections you will learn about the different tools that support you to create your own openMINDS JSON-LD metadata collection.
77 +You learned now how to write a valid JSON-LD for an openMINDS metadata instance and how you can link different openMINDS metadata instances. In the following sections you will learn about the different tools that support you to create your own openMINDS JSON-LD metadata collection.
78 78  
79 79  === The openMINDS Python API ===
80 80  
... ... @@ -81,7 +81,7 @@
81 81  One possible way to write openMINDS conform JSON-LDs is to use the openMINDS Python API which will help you to interact with the EBRAINS openMINDS metadata models and schemas. It consists of two sub-modules: 
82 82  
83 83  The **openMINDS.generator** (coming soon) facilitates the translation of the openMINDS schema template syntax to other established formats, such as HTML and JSON-Schema (cf. also [[Technical details>>doc:Collabs.openminds.openMINDS core.Implementation details.WebHome]]).
84 -\\The **openMINDS.compiler** allows you the dynamic usage of openMINDS metadata models and schemas in your Python application for generating your own collection of openMINDS conform metadata representations (instances) as JSON-LDs (as described above). Please note that the openMINDS.compiler only helps you to generate correctly formatted JSON-LD metadata instances - the preparation on how you want to describe your research product with openMINDS is still up to you. If you need support in designing your own openMINDS metadata collection, check out the [[Tutorials>>openminds@ebrains.eu||target="_blank"]] which might give you hints on how to tackle your individual case or, of course, get in touch with us via [[openminds@ebrains.eu>>mailto:openminds@ebrains.eu]].
84 +\\The **openMINDS.compiler** allows you the dynamic usage of openMINDS metadata models and schemas in your Python application for generating your own collection of openMINDS conform metadata representations (instances) as JSON-LDs (as described above). Please note that the openMINDS.compiler only helps you to generate correctly formatted JSON-LD metadata instances. The preparation on how you want to describe your research product with openMINDS is still up to you, although we provide some hints on how to tackle your individual case in the [[Tutorials>>openminds@ebrains.eu||target="_blank"]] and can always be contacted for individual support via [[openminds@ebrains.eu>>mailto:openminds@ebrains.eu]].
85 85  
86 86  ===== Installation =====
87 87  
... ... @@ -121,7 +121,7 @@
121 121  {{/code}}
122 122  
123 123  (% class="wikigeneratedid" %)
124 -To learn in general about the available openMINDS metadata models and schemas including their required or optional metadata properties, please check out the HTML representations of the schemas (cf. [[Metadata models & schemas>>doc:Collabs.openminds.openMINDS core.Metadata models & schemas.WebHome]]) or the code on the corresponding GitHub.
124 +To learn in general about the available openMINDS metadata models and schemas including their required or optional metadata properties, please check out the HTML representations of the schemas or the code on the corresponding GitHub (cf. [[Metadata models & schemas>>doc:Collabs.openminds.openMINDS core.Metadata models & schemas.WebHome]]).
125 125  
126 126  Interactively you can also get an overview of the requirement of a schema and all its properties by using the **##help_##** function of the openMINDS.compiler. Here an example:
127 127  
... ... @@ -129,14 +129,16 @@
129 129  mycollection.help_core_person()
130 130  {{/code}}
131 131  
132 -
132 +===== openMINDS.compiler documentation =====
133 133  
134 +((% style="color:#7f8c8d" %)**//coming soon//**(%%))
135 +
134 134  === The openMINDS spreadsheet templates ===
135 135  
136 136  (% style="text-align: justify;" %)
137 137  ((% style="color:#7f8c8d" %)**//coming soon//**(%%)) For users with no programming experience, it is possible to provide at least openMINDS conform metadata by using the openMINDS spreadsheet templates.
138 138  
139 -=== The EBRAINS Knowledge Graph Editor ===
141 +=== The Knowledge Graph Editor ===
140 140  
141 141  (% style="text-align: justify;" %)
142 -For curators of the EBRAINS Data & Knowledge service, it is possible to register openMINDS conform metadata into the EBRAINS Knowledge Graph database by using the EBRAINS Knowledge Graph Editor.
144 +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.
Public

openMINDS