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
-
... ... @@ -33,22 +33,25 @@ 33 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 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:36 +The JSON-LD property **##"@type"##** expects an entry (value) of type string with the format of an IRI. 37 37 38 +(% style="text-align: justify;" %) 39 +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: 40 + 38 38 (% style="text-align: center;" %) 39 39 **##"@type": "https:~/~/openminds.ebrains.eu/XXX/YYY"##** 40 40 41 41 (% style="text-align: justify;" %) 42 -where **##XXX##** and **##YYY##** should be replaced with the openMINDS sub-module (e.g., **##core##**) and corresponding schema (e.g., **##ContactInformation##**), respectively. 45 +where **##XXX##** and **##YYY##** should be replaced with the openMINDS sub-module (e.g., **##core##**) and corresponding schema-name (e.g., **##ContactInformation##**), respectively. 43 43 44 44 (% style="text-align: justify;" %) 45 - The JSON-LD property **##"@id"##** expects an entry (value) of type string thatprovidesauniqueidentifierforthecreatedmetadata instance.On yourlocalmachine,youshoulduse the following naming convention for this identifier:48 +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 string with the format of an IRI. In particular when you plan to submit your metadata collection later to the EBRAINS Knowledge Graph, we recommend you use the following naming convention on your local machine for this identifier: 46 46 47 47 (% style="text-align: center;" %) 48 48 **##"@id": "http:~/~/localhost/YYY/ZZZ"##** 49 49 50 50 (% style="text-align: justify;" %) 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 generateda openMINDS metadata collection, youruser-defined**##"@id"##**will beautomaticallyreplaced with a UUIDinallyourJSON-LDs iftheyareuploadedtotheKG.54 +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. 52 52 53 53 (% style="text-align: justify;" %) 54 54 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: