-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semantic information in TDTs #898
Comments
Many thanks for this input. We should evaluate the semantic equivalence to the features
Maybe, mandatory / optional can be managed via Shape? @vcharpenay can you evaluate those points? |
@kolotu, can you elaborate on the meaning of |
From the point of view of RDF, the TD model is simply a SHACL shape, that is, a schema over an RDF graph (see The example below gives a shape that requires a certain TD to have a {
"@context": {
"@vocab": "http://www.w3.org/ns/shacl#",
"td": "https://www.w3.org/2019/wot/td#"
},
"@id": "urn:ex:TemperatureThingTemplate",
"property": {
"path": "td:hasPropertyAffordance",
"minCount": 1,
"maxCount": 1,
"node": {
"@id": "urn:ex:TemperatureAffordance",
"property": {
"path": "td:name",
"hasValue": "temperature"
}
}
}
} You can see that it uses |
It is also possible to emulate {
"@context": {
"@vocab": "http://www.w3.org/ns/shacl#",
"jsonschema": "https://www.w3.org/2019/wot/json-schema#"
},
"@id": "urn:ex:RestrictedTemperatureAffordance",
"and": [
"urn:ex:TemperatureAffordance",
{
"property": {
"path": "jsonschema:minimum",
"hasValue": -40
},
"property": {
"path": "jsonschema:maximum",
"hasValue": 40
}
}
]
} In fact, SHACL defines many more constraints than just this 'and' restriction. It roughly has the same expressiveness as JSON schema. |
You can see that SHACL shape definitions are a bit verbose. It would of course be better to simply define TDs as if they were templates and add a few keywords. This is the approach of schema.org to define But I think it would be good to at least provide some equivalence with SHACL to have a clear semantics for each keyword we add to TDTs. |
@vcharpenay |
just for information: Thing Description Template (TDT) will be called as Thing Model in the future |
Given that Thing Models are properly implemented, closing |
If you consider a TDT to describe a class of Thing Descriptions, you probably want to allow to reuse one TDT for multiple TDs that are very similar, but do not necessarily share all properties defined in the TDT.
Therefore it might be practical to define some semantic vocabulary for the TDT to describe whether a property is i.e. mandatory in every TD instance, or optional.
In Eclipse Vorto there is vocabulary that covers that adds semantic information to the defined properties:
See below for a complete figure showing the Vorto vocabulary and see here for further information about vortolang
The text was updated successfully, but these errors were encountered: