Re: Thing Description for existing data sources

FYI

Here is a snapshot of my work on the semantic modeling layer using JSON-LD and RDF, with the SmartThings Capability Model as an existing model that needs to be mapped. It lines up with the TD examples I linked to last week.

I have for various reasons decided to use schema.org <http://schema.org/> as a meta-model for constructing this model. It is pretty flexible as it only defines two fundamental classes, "Type" and "Property" which simply exposes an abstraction of RDF. Properties define the relations between types.

I've constructed a very rough prototype mapping of the SmartThings Capability Model to schema.org <http://schema.org/>-like constructs.

I use the schema.org <http://schema.org/> definitions for Type and Property, and define some base types and a starting set of structural relation properties (hasAttribute...) to define a consistent model.  All capability type instances derive from the base types. 

The base model is at :
http://thingschema.org/smartthings/stCapabilityModel.jsonld <http://thingschema.org/smartthings/stCapabilityModel.jsonld>

and an example set of types for modeling lights are at:
http://thingschema.org/smartthings/examples/light-example.jsonld <http://thingschema.org/smartthings/examples/light-example.jsonld>

The above files are collections of types and properties that are split out to individual files at the URI reference endpoints, e.g. 
http://thingschema.org/smartthings/Attribute.jsonld <http://thingschema.org/smartthings/Attribute.jsonld>, http://thingschema.org/smartthings/Command.jsonld <http://thingschema.org/smartthings/Command.jsonld>, etc.

The base model directory at http://thingschema.org/smartthings/ <http://thingschema.org/smartthings/stCapabilityModel.jsonld> is populated but I haven't populated the application capabilities instances at http://thingschema.org/smartthings/capabilities/ <http://thingschema.org/smartthings/capabilities/> yet; only the first examples.

These validate on http://json-ld.org/playground/ <http://json-ld.org/playground/> you can just plug in the .jsonld URLs above to view them as triples in various formats.

It should be possible to convert these to OWL or other graph formats, or use them for constructors or validators.

For the purpose of the WoT servient prototype, these are the semantic definitions for the terms used in the capabilities TD and thing TD examples at:
https://github.com/connectIOT/iotivity-servient/tree/master/td <https://github.com/connectIOT/iotivity-servient/tree/master/td>
They would share common JSON-LD context files and CURIEs, e.g. st, stc

I'm building out the reference set of things in both schemas and TDs, and mapping these to the OCF resource model using the prototype abstract transfer layer bindings.

Comments or feedback welcome.

Best regards,

Michael

> On Jun 13, 2016, at 12:15 PM, Dave Raggett <dsr@w3.org> wrote:
> 
> To enable interoperability across platforms we need standards for a variety of metadata:
> 
> the data and interaction models exposed to applications
> the information needed to access a thing on a given platform along with the communication patterns
> the meaning of the thing in terms of its semantic model and constraints and relationships to other things
> security and privacy related information, e.g. who can access it for what purposes
> 
> The data and interaction models should be expressed in ways that are neutral in respect to application languages, e.g. C++, JavaScript, Java, Python, state machine languages and so forth. Formalising the data models in terms of JSON is thus a bad idea in my view. I further believe that the metadata terms for data models should be grounded in RDF as this can be decoupled from the serialisation formats for metadata, and provides for globally unique identifiers that can be de-referenced for further information.
> 
> The jury is out on the best ways to describe the communications metadata. This needs to evolve as we experiment with different platforms.
> 
> For the semantic models, I see a dimension from lightweight models to more complex models based on OWL ontologies.  For the lightweight end, which I expect to be very successful, I am looking at how we can create really agile standardisation processes that reflect the evolving maturity of a given set of terms. Schema.org <http://schema.org/> provides a useful precedent. This still needs to be grounded in RDF.
> 
> I am still wondering about the options for security and privacy related metadata. I am giving an invited talk on this tomorrow in Berlin as part of the IoT Tech Expo, and plan a blog post as a follow up.
> 
>> On 13 Jun 2016, at 16:20, Kovatsch, Matthias <matthias.kovatsch@siemens.com <mailto:matthias.kovatsch@siemens.com>> wrote:
>> 
>> There is no problem with Web linking techniques. I wanted to express the following clash I see:
>>  
>> On the one hand, I see a type system that defines a data structures from primitive types (a technique that I would associate with RPC-style distributed systems). It lacks the possibility to describe individual elements semantically. If two applications have the same elements, but in a different structure, I would expect that a WoT machine can automatically convert structure A into its own structure B – or in other terms, can understand the meaning of each individual element in structure A and map it to its internal data model.
>>  
>> On the other hand, I see semantic annotations that define meaning of an interaction or resource. A machine can learn what elements are important for the interaction at an information model level, but not how to serialize it. With the current type system, we can only describe how anonymous elements are structured. The explicit definition of which information-model element must go where in the structure needs to be defined in parallel to the strucuture.
>>  
>> Those two definitions need to be unified.
>>  
>> Personally, I see representation format definitions doing that (e.g., SenML defines structure and semantics in one place). However, the definitions are not machine-understandable, not even machine-readable. Thus my comment, that we should think about this “something completely new” that enables us to define representation formats in a machine-understandable way (i.e., structure and semantics of elements in one place). This would also enable the pluggable approach the Web has been relying on to be evolved: a fixed well-designed core and plugins that help with the application problems of a specific time (cf. pre-Web 2.0 vs post-Web 2.0). The type system is currently overburdening the TD. We need to divide-and-conquer…
>>  
> 
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>