See also: IRC log
<kaz> taki: Sebastian is on vacation and asked me to lead this call
<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.
Kaz: I will do it soon, today.
<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.
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 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 ]