Add @context to schemas

[apdavison]

I think all terms used in openMINDS should resolve to valid URIs. Probably the easiest way to implement this is to make the schemas JSON-LD docs. At the least, we should add a @context field to each document, e.g.

@context: {
    "schema": "https://schema.org/",
    "name": "schema:name",
   ...
}

[lzehl]

Hi Andrew. I agree that the schemas should resolve in valid URIs ($id & @type needs to be discussed; should be ebrains.eu schemas).

The @context is part of json-LD not of json-schema, though. The schemas should be written in json-schema (to separate them very clearly from the content holding json-LDs in the KG) and I would like to keep the json-schemas as light as possible to keep them human-readable (especially for naive users).

As far as I understood the @context is used in json-LD to clarify the validation context (please correct me if I'm wrong). The validation context for the json-LDs in the KG should be the here defined json-schemas, which is currently given by the @type" (not resolving to a valid URI which I would like to change; this is an open discussion with Oli). I would like to validate only against the here defined json-schemas, not e.g., schema.org, although I agree, that the link to related or other matching schemas is still missing.

I would like to discuss this with you and Oli in more detail. We should schedule a meeting for this asap. What do you think?

[apdavison]

Hi Lyuba, I'd be happy to discuss this in more detail with you and Oli.

A few comments on your reply, in the meantime (-:

JSON schema documents can be written as JSON-LD, it seems (https://www.w3.org/2019/wot/json-schema).

My feeling is that adding the @context makes the schemas more human readable, as it gives links to clear definitions for each of the terms. It is not in itself related to validation, all it does is map the terminology used in a JSON document to global identifiers (URIs). These URIs don't always resolve to helpful definitions, but often they do.

[lzehl]

This is json-schema draft 10. We used draft 7 until now (that was the newest one when we started, and I think that wasn't an option for this draft version).

I'm glad to revise the draft 10 option for openMINDS v3, especially if it makes the json-LD conversion more simple. I'll have a look at it.

So far @context is not used in the json-LDs of the KG (at least I can't find it as a used keyword...), but maybe it's somehow hidden in the specs...

@olinux : are you up for a discussion about this?

[lzehl]

Hey. If I understood this now correctly the draft your referring to is not from https://json-schema.org. I guess it will therefore not pass any standard json-schema validation tool. Also : (from my point of view as, I guess, a naive programmer) the schemas of this draft do not look more simple to me, but way more complicated to read... I'm glad to be shown otherwise though ;) Let's wait for Oli's comment and then schedule a meeting for this. My personal opinion: for now (also time wise for the integration) I would like to stick to what I've done so far which has proven to work with v1. Nonetheless I would like to discuss this now, to see if I overestimate a possible revision of all the work/discussion that was done already. Thanks for bringing it up :)

[lzehl]

Seems like we are not the only ones discussing this:
json-schema-org/json-schema-vocabularies#13

[lzehl]

After some more discussions with @olinux I would like to implement for all schemas and their properties links to other related schema definitions, but not over the typical @context which is not part of json-schema.

On the one hand, because this allows for multiple relations to be made to the same term. On the other hand, because in most cases I'd like to prioritize our definitions and context of the terms.

I suggest to do the following: Add to objects (schemas) and properties the key relatedDefinitions expecting a list with URIs (e.g., http://schema.org/name]. That way we can link our properties/schemas to as many contexts as we want and allow a user to choose for him/herself what type of context he/she prefers or even want. The additional keys should not be a problem for json-schema because they should just be ignored in the draft during a validation. In the best case we could modify the draft to hold these keys as well.

@olinux does this fit with what we discussed?
@apdavison would you agree with this approach?

[apdavison]

@lzehl sure. I never understood the motivation for choosing JSON schema over SHACL, but that ship has long sailed...

[lzehl]

I'm closing this issue now. We'll include the references to other schemas or schema properties in the vocabulary (to keep the schema templates light for the untrained user).