Changes for page Application details
Last modified by lzehl on 2021/10/13 13:11
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -30,27 +30,25 @@ 30 30 {{/code}} 31 31 32 32 (% style="text-align: justify;" %) 33 -The seadditional technical properties specifically required for the JSON-LD syntax are, on purpose, not defined in the openMINDS schema templatesin 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 explainherewhy these technical JSON-LD properties are needed and how they are correctly provided for an openMINDS instance.33 +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||target="_blank"]]). Let us explain 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 -The JSON-LD propert ies**##"@context"##**and **##"@vocab"##** define acommon vocabularymapping,by statinga prefixthatextendsallnon-JSON-LDpropertynamesd**##"@type"##**valuesthatdonotcorrespond to anIRIor compactIRI. Within openMINDS, eachmetadata instance shouldmapto the openMINDS vocabulary, meaningthe**##"@context"##** and**##"@vocab"##**isthesameacross allmetadata instances(cf. codeabove).If youwantto learn more about thepower ofthe openMINDS vocabulary please goto: [[Technicaldetails>>doc:Collabs.openminds.openMINDScore.Implementationdetails.WebHome||target="_blank"]].36 +The JSON-LD property **##"@type"##** expects an entry (value) of type string with the format of an IRI. Generally speaking, the **##"@type"##** defines which schema shouldbe used to validate the particular JSON-LD. Within openMINDS, each schema can be identified through its namespace (type) with the following naming convention: 37 37 38 -Generally speaking, the JSON-LD property **##"@type"##** defines which schema should be used to validate the particular JSON-LD. The **##"@type"##** expects an entry (value) of type string with the format of an IRI. Within openMINDS, the **##"@type"##** value equals the corresponding schema-namespace with the following naming convention: 39 - 40 40 (% style="text-align: center;" %) 41 41 **##"@type": "https:~/~/openminds.ebrains.eu/XXX/YYY"##** 42 42 43 43 (% style="text-align: justify;" %) 44 -where **##XXX##** and **##YYY##** should be replaced with the openMINDS sub-module (e.g., **##core##**) and corresponding schema -name(e.g., **##ContactInformation##**), respectively.42 +where **##XXX##** and **##YYY##** should be replaced with the openMINDS sub-module (e.g., **##core##**) and corresponding schema (e.g., **##ContactInformation##**), respectively. 45 45 46 46 (% style="text-align: justify;" %) 47 - In return, the JSON-LD property **##"@id"##**defines the particular metadata instance (node). For this reason, the **##"@id"##** also expects an entry (value) of type stringwiththe format ofanIRI. Inparticularwhenyouplantosubmityourmetadatacollectionlatertothe EBRAINS KnowledgeGraph,we recommendyou use the following naming conventionon your local machinefor this identifier:45 +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: 48 48 49 49 (% style="text-align: center;" %) 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. Within the EBRAINS Knowledge Graph (KG) this identifier has to be a universally unique identifier (UUID) ,and,therefore,will be replacedaccordinglywith a UUIDby the EBRAINS KnowledgeGraphsystem duringtheintegration processof your openMINDS collection.51 +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). 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. 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: ... ... @@ -78,65 +78,13 @@ 78 78 79 79 === The openMINDS Python API === 80 80 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: 79 +(% style="text-align: justify;" %) 80 +For users with at least some programming experience, one possible way to write openMINDS conform JSON-LDs is to use the openMINDS Python API. 82 82 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, 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 - 86 -===== Installation ===== 87 - 88 -The official versions are available at the [[Python Package Index>>https://pypi.org/project/openMINDS/]] and can be installed using `pip install` in your console: 89 - 90 -{{code language="console"}} 91 -pip install openminds 92 -{{/code}} 93 - 94 -The latest development version is available on the [[openMINDS generator GitHub>>https://github.com/HumanBrainProject/openMINDS_generator]]. 95 - 96 -===== openMINDS.compiler documentation ===== 97 - 98 -As stated above, 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. Here a small example: 99 - 100 -{{code language="python"}} 101 -import openMINDS.compiler 102 - 103 -# initiate the helper class for the dynamic usage of a specific openMINDS version 104 -helper = openMINDS.compiler.Helper(version="v1.0") 105 - 106 -# initiate the collection into which you will store all metadata instances 107 -mycollection = helper.get_collection() 108 - 109 -# create a metadata instance for (e.g.) the openMINDS Person schema 110 -lyuba = mycollection.add_core_person(givenName="Lyuba") 111 - 112 -# add more metadata to a created instance 113 -mycollection.get(lyuba).familyName = "Zehl" 114 - 115 -# add connections to other metadata instances 116 -email_lyuba = mycollection.add_core_contactInformation(email="openminds@ebrains.eu") 117 -mycollection.get(lyuba).contactInformation = email_lyuba 118 - 119 -# save your collection 120 -mycollection.save("./myFirstOpenMINDSMetadataCollection/") 121 -{{/code}} 122 - 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 or the code on the corresponding GitHub (cf. [[Metadata models & schemas>>doc:Collabs.openminds.openMINDS core.Metadata models & schemas.WebHome]]). 125 - 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 - 128 -{{code language="python"}} 129 -mycollection.help_core_person() 130 -{{/code}} 131 - 132 -===== openMINDS.compiler documentation ===== 133 - 134 -((% style="color:#7f8c8d" %)**//coming soon//**(%%)) 135 - 136 136 === The openMINDS spreadsheet templates === 137 137 138 138 (% style="text-align: justify;" %) 139 - ((% 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.85 +For users with no programming experience, it is possible to provide at least openMINDS conform metadata by using the openMINDS spreadsheet templates. 140 140 141 141 === The Knowledge Graph Editor === 142 142