Towards a formal model of thing descriptions

In today’s Web of things Interest Group call, I was asked to provide a formal model of the RDF graphs for thing descriptions. The following statements provide an informal description as an initial step. The question is what formalism to codify it in. One possibility could be the Shapes Constraint Language (SHACL), see: https://www.w3.org/TR/shacl/, which defines a language for validating RDF graphs against a set of conditions. This could be used for validating a thing description against the following “grammar", for validating that a given thing description conforms to a semantic model, for validating data, and for validating service compositions to check that the components are compatible. What other formalisms would be appropriate for these tasks?

The following are based upon requirements derived from a broad range of use cases.

Each thing must have a thing description.
A thing description is a graph of RDF triples rooted in a given thing.
A thing description must have URI with which to access the description.
A thing may have meta-data, i.e. a set of predicate/value pairs.
A thing may have zero or more properties, actions and events.
Each property, action and event must have a string literal as its name.
Each property, action and event may have metadata.
A property must have a data type.
A property may have a default value.
A property may be writeable.
A property may be required.
Each property may itself have properties.
Each property, action and event may have metadata.
A data type is a core data type, or is defined in place, or by reference to a definition.
Core data types are null, boolean, integer, number, string, vector, thing, enum and union.
A property may be a stream.
A property may be a collection.
A collection is either ordered or unordered, but not both.
A enum is an unordered set of string literals.
A union is an unordered set of data types.
A vector is a set of items, where each item has a string literal for its name, and a non-negative integer for its index.
A property may have constraints, which depend on its data type.
An integer or number may have a min and a max value.
A collection may have a min and a max length.
Each action must define a request.
Each action may define a response.
A request may expect a sequence of zero, one or more responses.
Each request and response must have a data type.
Each event must has a data type.
There are predefined events for signalling updates and life cycle changes.
Metadata includes comments and communication metadata.
A comment is a string literal and may be annotated with its human language.
A thing may be associated with a service.
A service provides a means to notify updates to properties and metadata
A service provides a means to signal events, action requests and responses.
A service URI may contain named variables.
A property may be a sink or source but not a combination of these.
A sink is a stream of samples that applications can generate.
A source is a stream of samples that applications can observe.
A stream may have a sampling rate.
A stream may have a latency.
A stream may carry date stamps.
Each service, sink and source must have a URI and a protocol name.
A protocol name is used by the platform to determine what software driver to use.
A thing may be composed as a composition of things through graph unification.
A thing may be a specific instance or it may be describe a class of things.
Metadata may be inherited by traversing links back towards the root thing.
A local metadata annotation for a given predicate overrides the value defined for ancestor nodes.
Communications metadata may be specific to a particular protocol standard, e.g. OCF resource type.
Applications should be able determine what communications capabilities a given platform supports.

I tend to think abstractly rather than graphically, and would appreciate some help in diagramming the above. My next step is to try to learn more about appropriate formalisms for use in a formal specification. Any help would be much appreciated.

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>