<inserted> scribenick: mlefranc

Proposals for PlugFest - preparation

Darko's slides

JSON-LD examples

DarkoAnicic: <showing list of thing drescription for plugfest 2017-dusseldorf>

<kaz> TD repo

DarkoAnicic: <shows slide on IoT Schema Layer>
... datatypes -> interation patterns -> capabilities
... datatypes specified in iot.schema.org could be reused in different interaction patterns
... which could be in turn be reused by different capabilities
... as an example, datatype could be temperature data that has unit = degree celsius
... interaction pattern could be one of an observable temperature
... capability could be a thermostat
... <now showing the TemperatureSensing.jsonld document>
... for now temperature interaction patterns are written again and again in all documents

DarkoAnicic: one need a website to navigate in the list of interaction patterns
... in the json-ld document one sees that temperature is a property and provide an output data that is a temperature data
... in this case temperature data is a subclass of schema:PropertyValue with datatype float and some temperature unit
... also, currently all datatypes are repeated again and again in thing descriptions
... the iot:TemperatureUnit datatype is a class, that has for instance iot:Unit and iot:Kelvin
... this is defined in Unit.jsonld
... and aligned to QUDT
... there is iot:reference that links to some ISO standard code, that many in the IoT domain actually use

mjkoster: possible multiple definitions like book catalogs, e.g., ISBN and other codes

DarkoAnicic: even Siemens doesn't always rely on real standards for units
... there are definitions for capabilities in different ontologies, we are currently investigating this
... e.g., Temperature, TargetTemperature, ThermostatTemperature
... iot:TargetTemperature has input data a iot:TemperatureData and output data a iot:TemperatureData
... <this is in interaction-patterns.jsonld>
... then iot:TemperatureData has schema:uniCode, schema:minValue and schema:maxValue that describe what the thermostat accepts
... currently the namespace iot is http://iot.schema.org/core#
... that contains some datatype definition, interaction patterns, and capabilities
... which namespace will be chosen at the end of the day is something we need to discuss further
... <looking at Airconditioner.jsonld>
... we defined iot:Home and a few interaction patterns for iot:AirConditioner:
... iot:SleepMode, iot:CountDown etc.
... <these are defined in interaction-patterns.jsonld>
... there will probably be many different time data depending on (e.g., if they are defined in hours, minutes,...)

kaz: This is one possible example of Thing Description, how can we make sure that Panasonic etc woudn't want their own ?

DarkoAnicic: Indeed, it's an ongoing effort to create the app level semantics, that we really need for the sem interoperability at the end of the day
... need to see with plugfest users if they manage to conform to these proposal.
... concern about whether plugfest users will manage to implement these capabilities as described here
... I hope yes, now I understand there will be many different interaction patterns

mjkoster: different layers of things happening here:
... first choose property naming
... second how to implement interaction patterns,
... we are targeting 99% of device that implemetn interaction patterns the same way
... at least for properties
... actions will be harder
... then a last level of composing capabilities together to create a "super-capability"
... a set of common features that certain kind of products share
... all of these levels are usefull and we might not want to be too prescriptive there
... else users might just use something else

DarkoAnicic: yes, <taking example of thing description b36d96.jsonld> --> this td example is very difficult to reuse

<kaz> Matsukura-san's draft document

mjkoster: yes, not enough semantic annotations in the td sometimes, which makes them hard to be understood

<kaz> kaz: agree

kaz: where do you think these generic TD descriptions should be hosted with respect to Matsukura-san's types of servients ?

<kaz> https://github.com/w3c/wot/raw/master/plugfest/2017-burlingame/images/4layered_model.png

DarkoAnicic: where the TD should be hosted ? good question

<kaz> s/Matsukura-san's types of servients/4 types of servients proposed by Koster and Matsukura/

mjkoster: what would be great at the next level: should take one property and one action to do something
... a device that discovers a td could then recognize that property interaction pattern because it knows the URI for instance

DarkoAnicic: in the discovery process, one could implement some capability search functionality

kaz: so generic thing description could be hosted in a central TD repo as a template ?

mjkoster: iot.schema.org could host templates for raw complex templates such as "a generic thermostat"
... without specifying the exact capabilities it has
... the purpose is to encourage reusability

DarkoAnicic: another point: how to use these specifications for the plugfest
... if one creates something useful for the plugfest user, then how to explain it well and promote it ?

mjkoster: ideally, these would be templates that would help someone to create a td for a specific kind of device
... a bit like schema.org works
... if I search for a thermostat, then I would see that it should have a bunch of capabilities,
... then I can search for those capabilities, if I'm lucky and I find them, then I can incorporate them in my TD
... and would just need to add the links to the actual href where these interactions can be triggered
... the point is to help users to browse the capabilities, event, action, properties, and how they go together
... help the user combine such templates to ultimately create a TD and upload it in their device

DarkoAnicic: good question whether something like that can be done before the plufest
... we may ask during the main call to encourage users to reuse / create those capabilities

mjkoster: like the idea of reusable interactions !

DarkoAnicic: capabilities have coarse granularity, interesting to provide finer granularity

mjkoster: ok for Properties, might be more difficult for Actions
... next step would be to make some TDs and annotate them
... someone else that we could engage in TD development ?
... iot.schema.org doesn't require a capability to have an instance

DarkoAnicic: so far we proposed a model for capabilities that is compliant with our model,
... we haven't really thought in dept about reusability/modularity yet

mlefranc: would like to work on actual examples where capabilities are shared by different thing descriptions

Namespaces for the TD vocabulary (WoT ontology)

DarkoAnicic: for now we have td, rdf, rdfs, xsd,
... do we need another namespace ?
... this requires looking at TD ontology right now

victor: xsd namespace is needed because it appears in the datatype schema definition (minExclusive, etc.)

DarkoAnicic: if someone thinks that something is needed or missing w.r.t. namespaces, please discuss the issue on github

mjkoster: one might want to look at the protocol binding to include namespace such as the http namespace http://www.w3.org/2011/http#

DarkoAnicic: we will work on the schema.org capabilities for the next plugfest

<kaz> [adjourned]