search

w3c / wot-thing-description

Web of Things (WoT) Thing Description
http://w3c.github.io/wot-thing-description/
Other
131 stars 63 forks source link

Validation of extensions and fetching from context URLs #1181

Open mmccool opened 3 years ago

mmccool commented 3 years ago

It would be useful to have a convention to relate context URLs to validation files, including JSON Schemas and SHACL, in addition to ontology files. Also, we should set up the context URLs so that fetching from them produces actual ontology definitions (at least) and our "baseline" context URLs should also satisfy the conventions suggested (via SHOULD) for extensions.

mmccool commented 3 years ago

Need to define:

  1. How to fetch Schemas (ideally as an extension of SHACL mechanism)
  2. How to merge Schemas (that needs top support mutliple extensions)
  3. Extension schemas should be simple
  4. We need to define a way to catch typos and perhaps disallow "additionalProperties": true in the final schema.
relu91 commented 3 years ago

Another point:

  1. Support for meta-schemas in extensions: some vocabulary may extend JSON schema with domain-specific keywords. In modbus we have to extend json-schema to support other type keywords like int8, uint16, etc.
AndreaCimminoArriaga commented 3 years ago

I think this will be hard to be done in the @context of a JSON-LD file. Can't we have a field that is an array for the shapes and another for the schemas which content of both is a set of URLs where to find the documents (schemas or shapes) ?

mmccool commented 3 years ago

I have been looking for a specification of how SHACL files are supposed to be distributed. I haven't found anything but do understand there is a convention so if anyone has information on that it would be great, or knows of a contact we can ask...

mmccool commented 3 years ago

Anyway, my general thought was that we would not ADD new things to @context (or the TD/TM), but would define rules for how the various validation files can be fetched given the URL in the @context. Possibilities include:

  1. Content negotation. Using GET on the context URL with a particular content type should fetch the appropriate validation file. One problem is that the separate validation files don't necessarily have separate context types so we might have to use parameters or something to distinguish them (e.g. if you fetch json-ld, well, that could be the ontology, or it could be the shacl file...)
  2. Convention for extending the URL. For example, given a URL https://example.org/myvocab/ in the @context, perhaps we can say that the JSON Schema can always be found at https://example.org/myvocab/schema.json or the like.

We could also do both.