Re: [TF-LD] Draft charter for Linked Data and Semantic Processing Task Force

This is interesting to explore further.  OCF and oneM2M define compositions of interfaces as a way to combine behaviours, in both cases using what is essentially syntactic composition equivalent to #include.  A complementary approach is to define a thing by the semantics classes it supports. The semantic models for each such class define constraints on instances of the class. This can be used with logical abduction to create a thing description. See:

     https://en.wikipedia.org/wiki/Abductive_reasoning <https://en.wikipedia.org/wiki/Abductive_reasoning>

I worked on abductive reasoning as part of the EU Serenoa project on model based design for context aware user interfaces. In essence you construct a thing description that satisfies the semantics you want it to support. This involves making choices based upon past experience. The process can also aim to satisfy additional constraints provided with the semantic goals. Such constraints could include details for the IoT platform and existing services.

The above is relatively ambitious, and I would recommend that we first look at the simpler case where we have a thing that includes claims on the semantics it supports via rdf:type links to semantic classes. We then need to validate that the thing description does indeed fulfil the constraints that those classes define.

I note that REST is at a lower level of abstraction than the Web of things, but the two layers are coupled through platform specific metadata that is needed by the application platform to satisfy the designer’s objectives for the given  IoT platform (such an IoT platform is REST over CoAP). Essentially, this metadata is used by the driver  for the IoT platform to determine what communication patterns to use and how to map these to the capabilities offered by the given protocol.

Would you be able to describe your use cases in more detail, as this would make it much easier to talk about concrete examples for the mapping between the abstraction layers?

Best regards,
     Dave

> On 4 Mar 2017, at 06:21, Michael Koster <michaeljohnkoster@gmail.com> wrote:
> 
> I have been looking at the idea of encapsulating behaviors within a "thing", for example a PID controller.
> 
> The PID controller would be implemented with a data model describing its inputs, outputs, settings, and tuning parameters. A REST implementation would have resources to implement the data model elements.
> 
> To operate the PID controller you set it's parameters and mode, and update its input and setpoint values on a periodic basis. The PID controller creates output values on a periodic basis. 
> 
> The input and output resources of the controller would be "wired" to sensors and actuators using "link bindings"; hypermedia controls that provide dynamic links to observe and update properties, similar to those described in:
> 
> https://tools.ietf.org/html/draft-ietf-core-dynlink-02 <https://tools.ietf.org/html/draft-ietf-core-dynlink-02>
> 
> These link bindings can have timing and DDS-style QOS parameters, and also may observe and update resource state using other protocols like MQTT or DDS.
> 
> I think there is an opportunity to describe control elements in a similar way we describe sensor and actuator elements, with a data model for the interface and description of internal behavior. 
> 
> We can also provide RDF descriptions for the link bindings.
> 
> Best regards,
> 
> Michael
> 
>> On Mar 1, 2017, at 7:26 AM, Anicic, Darko <darko.anicic@siemens.com <mailto:darko.anicic@siemens.com>> wrote
>>  
>>  
>> Von: Dave Raggett [mailto:dsr@w3.org <mailto:dsr@w3.org>] 
>> Gesendet: Montag, 27. Februar 2017 20:04
>> An: Anicic, Darko (CT RDA NEC WOS-DE)
>> Cc: Kis, Zoltan; public WoT IG
>> Betreff: Re: [TF-LD] Draft charter for Linked Data and Semantic Processing Task Force
>>  
>> Thanks for the examples, they are most helpful. It sounds like the description of modular behaviours rather than that of the information model for the objects used to expose things to applications. 
>>  
>> Procedural scripts are easy for computers to execute, but hard for them to understand and manipulate. Do you envisage machine interpretable recipes, or perhaps consider them for human use only as part of best design practices?
>>  
>> Yes, I envisage machine interpretable recipes. Therefore we need both a recipe model and information model (to annotate ingredients of a recipe).
>>  
>> How would you formalise the recipes? 
>> One possibility to formalize a recipe is to formalize its ingredients and interactions between them.
>>  
>> I can imagine a role for event-condition-action rules, and worked with those in the EU project “Serenoa” which focused on model-based context aware user interfaces.
>>  
>> One should be able to realize event-condition-action rules with recipes. But recipes should not be limited only to ECA rules. We should be able to implement any application template with recipes.  
>>  
>> I envisaged a scenario where a service designer (a human) sits at a workstation and comes up with an application that can perform a service like controlling the home environment, adapting to what devices are available in each home. This requires the device descriptions to declare what semantic modules (oneM2M sense) they support. The interfaces exposed by different air conditioners, for example, might differ, but the application would know how to adapt to each, without needing to know in advance the details of each device.
>>  
>> This is more tractable than what you describe as it just requires a way to describe the semantic modules that devices may support and does not require a standard for describing event-condition-action rules or other ways to describe behaviours.
>>  
>> Your example is also interesting. An example with ECA rules was picked by chance. Recipe is based on ingredients and interactions between them. Ingredients should be TD templates or perhaps abstract TDs (suggested by Kajimoto-san). These are similar to semantic modules you mentioned. We don’t need a standard to describe certain type of rules or behaviours. Instead we need just a format to specify a recipe with a semantic model behind. 
>>  
>> Best regards,
>> Darko    
>>  
>> Best regards,
>>      Dave
>>  
>>  
>> On 27 Feb 2017, at 17:19, Anicic, Darko <darko.anicic@siemens.com <mailto:darko.anicic@siemens.com>> wrote:
>>  
>> Hi Zoltan,
>>  
>> an example recipe would be: if the temperature gets over threshold, turn the air-condition on. Such a recipe would have 2 ingredients: temperature threshold exceeded (expressed as a TD Event or Property) and air-condition turnOn (e.g., as a TD Action) and interaction between them. In addition it may specify constraints (e.g., on location etc.)  and non-functional-properties that may be important for the discovery.
>>  
>> Recipe can be accompanied/implemented with a script. It is a semantic specification of an application template, and can, for example, be used to discover a script or to find out Things on which the script can be implemented (hosted). Further, a recipe and its script implementation can be easily modified and shared.
>>  
>> Best,
>> Darko   
>>  
>> Von: Kis, Zoltan [mailto:zoltan.kis@intel.com <mailto:zoltan.kis@intel.com>] 
>> Gesendet: Montag, 27. Februar 2017 17:58
>> An: Anicic, Darko (CT RDA NEC WOS-DE)
>> Cc: Dave Raggett; public WoT IG
>> Betreff: Re: [TF-LD] Draft charter for Linked Data and Semantic Processing Task Force
>>  
>> Hello,
>> 
>> Could you give an example for a recipe?
>> Would/could a recipe actually *contain* a script (event handlers, action definitions, request hooks etc)?
>> 
>> Thanks,
>> Zoltan
>>  
>> On Mon, Feb 27, 2017 at 6:49 PM, Anicic, Darko <darko.anicic@siemens.com <mailto:darko.anicic@siemens.com>> wrote:
>> Hi Dave,
>> 
>> In addition to the proposed charter I would like to propose one more topic related to a semantic specification of reusable application templates. These templates would enable a quick implementation of new WoT applications, and could be easily shared and extended. They are like recipes for WoT applications.
>> 
>> Recipe specifies ingredients and interactions between them. Ingredients are Thing Description Interaction Patterns (events, properties and actions), and interactions are semantic links between them. Constraints and Non Function Properties are specified in Recipes too. Recipe can be published and discovered by using Linked Data principles. Further on, one can use semantic discovery to find out Things that match ingredients of a Recipe. A Recipe should be implementable in a straightforward manner with the WoT Scripting API.
>> 
>> Best,
>> Darko
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Dave Raggett [mailto:dsr@w3.org <mailto:dsr@w3.org>]
>> Gesendet: Mittwoch, 25. Januar 2017 09:45
>> An: public WoT IG
>> Betreff: [TF-LD] Draft charter for Linked Data and Semantic Processing Task Force
>> 
>> Please find a draft charter for the proposed Linked Data and Semantic Processing Task Force for discussion in today's Interest Group call.
>> 
>>       https://github.com/w3c/wot/blob/master/TF-LD_charter.md <https://github.com/w3c/wot/blob/master/TF-LD_charter.md>
>> 
>> Note: this is a temporary location as I am expecting that Matthias will have a preferred location for task force charters.
>> 
>> --
>> Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> http://www.w3.org/People/Raggett <http://www.w3.org/People/Raggett> W3C lead for the Web of things
>> 
>>  
>> Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> http://www.w3.org/People/Raggett <http://www.w3.org/People/Raggett>
>> W3C lead for the Web of things
>>  
>>  
>>  
> 

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C lead for the Web of things