02 Jun 2017


See also: IRC log


Kaz_Ashimura, Daniel_Peintner, Feng_Zhang, Michael_Koster, Taki_Kamiya, Yongjing_Zhang, DarkoAnicic, Achille_Zappa


<kaz> taki: Sebastian is on vacation and asked me to lead this call

Status AIs

Collect available TD in JSON-LD format

<dape> https://github.com/w3c/wot-thing-description/pull/8

Daniel: Carsten and I got this item.
... I started with structure in general.
... Exploring different features. Realistic test cases.
... I got some examples from current specifications.
... I also sent message to public mailing list.
... I should ping each plugfest participants.

<kaz> Daniel's message

Daniel: We should do initial analysises wrt. serialization formats.
... I hope Carsten can join in the next few telecons since there is some differences in how we should proceed.
... If all people can be together in the telecon, it is better.
... I have some initial personal experiment for exercise.
... When we have mature test case set, I can generate results.

<kaz> PlugFest participants

Kaz: I can send messages to Japanese participants individually in Japanese language.

Daniel: I can also send to the rest, including Siemens people.

Ask W3C experts for advice on TD namespace

Kaz: I will do it soon, today.


Specify the expected type of JSON TD structures

<dape> https://github.com/w3c/wot-thing-description/issues/7

Daniel: During Osaka F2F, and experiments, we had issue wrt. the current spec is vague in terms of how @type and @context is not clear.
... Whether a single string or an array of strings.
... Code complexity is an issue, interoperability is also an issue.
... DR is suggesting it is a bit too early to discuss on this.
... People may have better experiences on this.

<kaz> RFC6690

Michael: Single item is a plain string, I have seen this in some specs.

Michael Koster: I don't expect complexity. In OCF, everything is an array.

Daniel: Do you mind providing a pointer to OCF spec in the thread?

Michael Koster: I will put a pointer.

Daniel: TK pointed out Canonicalization aspect.
... Issue #1 can be closed, I noticed. It is about missing figures.

<dape> https://github.com/w3c/wot-thing-description/issues/1

Kaz: Have URL?

Daniel: Here you go.

<mjkoster> https://openconnectivity.org/draftspecs/OCF_Core_Specification_v1.0.0.pdf

Kaz: I just closed that.


Semantic Annotation and Binding

Daniel: It is better to say we have use case for example on semantic annotation.

Darko: We want to implement use case where thing description is semantically annotated to support discovery.
... TD Ontology and OCF, unified model, that way we can search both devices.
... OCF side, Michael Koster and MM will contribute. On WoT side, Maria, I and Victor.

Koster: I bypassed that in my OCF experiments.
... I am assuming each resource has TD, based on OCF-WoT binding.
... I am doing mechanical tranlation.
... I had action item about protocol binding, which I will do soon.

Darko: It is enough align at protocol binding layer?

Koster: TD provides enough description for OCF.
... It is easy to map OCF. Mostly mechanical translation.
... OCF does not have semantic ontology.
... OCF defines resource types. It can fit higher layer semantics defined elsewhere.

Darko: How discovery is done?

Koster: In OCF you look for resource type.
... Temperature resource type, eg.
... We can make bridge where we can search all resource types.
... Semantic model may also be helpful.
... OneM2M devices can also be found.

Darko: That approach sounds simple.
... It assumes all OCF device has TD.

Koster: Action semantic model, for example. I am not sure...

Darko: OCF, what kind of description is this?

Koster: RAML and JSON schema, and swagger.
... Using consistent pattern, using interface type.
... Properties are readable/writable.
... Data model is defined in swagger/JSON-schema
... Read swagger, and get description properties.
... OCF data model is very consistent.
... GET/POST only, for example.
... I will need to explain more about how OCF works when I describe protocol binding.
... Collection is difficult.
... It is about batching.
... I map to action with two inputs.

Darko: Unifying discovery. Two approaches. The second item. We had discovery. Give me TD, using keyword "temperature".
... We want to extend this a bit.
... We have now WoT ontology.
... iot.schema.org also has pattern.
... Request TD by asking by saying what you need.
... and discover based on this.
... We want to extend the current discovery.
... You need to get the name of the property "mytemp1", eg.
... Enrich discovery, and help using API.

Koster: in Link, we call "title".
... there is another machine readable version.
... Each "temperature" needs to have semantic tag.
... It reminds me of Constraint-based query.

Darko: If you don't know what you need, we can use constraint-based query.

Koster: Ontological hint is useful in constraint-based query, too.

Darko: We could define use cases from linked-data point of view.

Koster: We can concretely work that way.

<Zakim> dape, you wanted to ask about sharing the annotated TD examples

Daniel: I heard quite often that if we can collaborate up front, also for serialization comparison, that would be great.

Koster: I can create starting point if we still have small examples.

Daniel: I don't have specific set of devices.

Daniel: You can make up your own devices, that would be fine.

Koster: iot.schema.org will stick with basic capabilities.

Darko: Let's define a few capabilities in schema.org.
... Let's experiment how discovery works.

Koster: Yes. and we need some examples.

Darko: We need to define use case first.
... MK and Darko will work on to define capabilities, then examples, lastly on constraint-based query.

Koster: About a year ago, we discussed orchestrating capabilities.
... ad-hoc composition of things, for example.

Darko: It will help us to search for use case first.
... An application idea MK just said.
... Discover two or three things without prior knowledge.

Koster: One is discovery. Limited prior knowledge. We can orchestrate things.

Darko: Application that connects three things.
... Output of the first thing. you need to find the second thing. Query is generated based on user decision.
... We need to help scripting guys on discovery.

Koster: Using scripting API to do orchestration is useful.
... "reaction", how do we wanna call them?

<inserted> taki: Darko, can you start an issue on GitHub about this so that interested people join the discussion?

Koster: We should first discuss on use case.
... alarm, lighting, alarm controlling system, smoke detector, etc.
... what do you wanna do given those different domain of things.
... Rule, behavior, recipes.

Darko: Can Michael write down use case?

Koster: OK.

Darko: I will do discovery part.
... Let's start as an issue.

<Zakim> kaz, you wanted to ask about current practices Osaka Release and to and to mention some idea on binding and to mention the need for PlugFest demo scenario for Dusseldorf

Kaz: Today's discussion was related to Plugfest.
... so the use cases we discusssed today should be part of the plugfest scenario for Dusseldorf, right?

Koster: Yes, good poiont.
... we want example use cases.

Kaz: and hopefully people could reuse the others' exposed properties like we did in Osaka :)
... btw, I looked at TD repository.

<kaz> current practices doc for plugfests

Kaz: but there is not the Curent Practices document snapshot for the Osaka meeting.

Daniel: Content has not been updated.
... In the future, we need to make snapshot.

Kaz: OK. We can talk about how to manage the snapshops as well.
... and then my last point.
... We talked about binding as well today.
... I've been also thinking about how binding should work.
... and started to generate some strawman image like this.
... having two layers:
... L1: TD = abstract world
... L2: device-dependent world.
... "Binding" is "getting device properties based on the device features" and "packing the properties as TD"
... each device vendor should provide concrete micro server implementation

kaz's strawman image on binding

Kaz's strawman idea on Binding

Koster: It aligns well with data model discussion by Koster, and security requirements by Zoltan.
... the Servient Internal Data Transfer should be standard WoT mechanism, e.g., TD and REST
... Is that gonna be a pull request?
... It is good to have this.
... This is related to the general architecture, though.

Kaz: Thanks!
... I was inspired by the diagrams by Koster and Zoltan :)
... should the possible pull request for this proposal go to the architecture document?

(no objections)

Kaz: I will make a pull request to the architecture document then.

[ adjourned ]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/02 08:22:15 $