proposal: thing-model-catalog: semantic validation of Thing Models

[hadjian]

          > > need to be more precise on "semantic" quality stage.

semantics is transported via @type, which (even if it originates from json-ld) is defined via the wot jschema. i.e. the semantic stage should be split into

• carries semantic information = filled @type, with namespace definition in context if needed
• carries semantic information in a industry standard ontology = i.e. "is helpful", i.e. filled @type, refering to well-known ontologies like BRICK, eclass etc, not "only" product specific/local namespace
• json-ld -loadable, i.e. can be loaded by a json-ld processor .. namespaces do not need to be resolveable
• json-ld -fully resolveable, i.e. certain json-ld / rdf operations can be performed, because all namespaces can be resolved and contain valid data

the first two points (semantics) are independent on the last two (json-ld) .. although it is hard to imagine, that a "json-ld loadable" does not use "@type".
additionally: make sure to avoid any implied staging, e.g. "runtime requires semantic"

It is not specified in more detail, because we will omit this in the first implementation. What I have in mind in the future is to validate the JSON-LD structure, i.e. can all terms be expanded by a jsonld processor and can the shape be validated against some shacl. We will probably accept everything in the first step, then run it through a jsonld processor as a second step etc.

if we already intend to implement it later (and it sounds like with rather specific tests), then we should take the time to specify.

Your test sounds more like "fully resolvable json-ld, processeable by shacl", which is far more than "semantics given, json-ld parseable/loadable (my #1,#2,#3)" because it also requires that all used namespaces are fully resolveable (#4) and processeable by shacl (and additional #5) - and therefore (probably?) needs to specified as shacl or with provided shacl rules (#6).

Your test would be one valid use and toolset of semantics, but not the only one, so we should not take assumptions (or not document them clearly as an option) ... and not leave them in a list that looks like one line building on another, i.e. later might suggest an mandatory point.

I think we should group our grades into the 3 groups defined by https://www.w3.org/TR/wot-thing-description11/#validation-serialization-json (minimal, basic, full) and detail the sub-grades explicitly

It can do basic validation of extensions, specfically that the vocabulary used is defined. --> my #3, defined

In this case, context definition files and SHACL definitions can be used to validate additional assertions and check TDs for semantic consistency. --> my #4, resolveable

In addition, if context definitions and SHACL constraints for extension vocabularies can be fetched, then these can be used to validate extensions --> your #5, shacl constraint compliant

Originally posted by @a-hennig in #8 (comment)

[hadjian]

This area is way to complex to be discussed in the basic catalog proposal, so I created a new proposal, where we can collect our thoughts.