<kaz> scribe list

<kaz> scribenick: taki

<scribe> Scribe: TK

<scribe> ScribeNick: taki

Logistics

Sebastian explains that the TD TF have decided to use this new slot because the previous slot had problem with Asian participation.

Kaz mentions that WebEx recently has got WebRTC capability, so people can get connected using WebRTC by clicking the "Join by browser! NEW!" link on the right side of the green "Join" button on the WebEx page.

Yongjing mentioned there was some problem with his environment

Kaz will send an announcement to the group about this change, and it would be useful to get any feedback from you all.

TD model discussion

Sebastian: I am showing slides that I used in Santa Clara
... JSON-LD is quite nice to describe thing description. Readable, and provides semantic anotation, actiona and event
... We used thing description in plug fests. Very successful.

<kaz> Sebastian's slides (Feb version)

Sebastian: It has a lot of restrictions. There are structure requirement, guidelines as to how it has to be difined and so on.
... Web developer may want to use it as like JavaScripts.

<kaz> [ March version slides to be distributed later ]

Sebastian: What will be the best serialization formats?
... In Santa Clara, what would like to see in TD?
... Things name, interaction patterms (events, properties and actions). Names and datatypes.
... and communication protocols. And most importantly security aspects. Hooks to security.

<kaz> discussion during the Santa Clara f2f meeting

Sebastian: Most interesting part is semantics enrichment.
... I ha ve written down in the slides. We may need to have more.
... What is the first idea of thing descriptiion?
... We have thing. Thing has name. and three kind of interections.
... inputs and outputs.
... not very professional representation but is a first step.
... OCF and M2M. Dave can elavorate.

DR: Property, action and events
... Everything is a thing

<kaz> Dave's slides

DR: Property, evnets and actions
... types are importamt
... Application types. and combines thme together
... We need what metadata is required by a platform.
... Names is necessary. Structure, such as array. Collections. Links constraints.

MC: Homogeneous collection and non-homogeneous collections

Sebastian: We can always reference JSON schema.

DR: I am talking about functional requirements.
... Actions. requests and responses.
... Numbers, strings, booleans.
... strings. such as patterns.multi-lingual conetxts. Alternatives in laguagages. enumerations
... unions
... un-homogeneous is possible
... vectors are helpful.
... metadata. such as location, owner
... serial number in echonets.
... only part description is possible.
... instance of a class, imports. Using RDF.

Fernando: Are there hierachies?

DR: Yes, it is useful.

MC: Has to have names. URL. ie. human-readable label.
... Useful for data-modeling. Which ones are useful for TD?
... Short label vs. longer name. But unique label, we should specify.

DR: We need to make it expicit.

MC: Instance and Classes.

DR: This action is an instance of a class.

MC: I would vote for that. It is useful to have software that has model.
... Streams
... Media streams and websockets.
... Implementations. Audio streams are important.
... What does action mean? We should be more specific
... As to what names mean

Sebastian: We discussed what streams mean.
... I do not know what is the current status

DR: I did not talk about streams
... property is updated. Where streams come from. All anout metadata.

MC: Sources and sync. flow of data. They are different from evnets.
... Events follow event model
... Streams is opaque. I am talking about this case.

DR: Blobs. We do not know what that is.

MC: Maybe video formats. Delegations.

DR: Binary blobs with bute sequences.

MC: We can table this for now

Sebastian: We also have presentation by Maria

DR: Information model is important.
... Diagram needs to expterss choice and conjucntions.

Sebastian: This is mostly same as what I presented. Property. Request and response. I used input and output.
... We should may be more concrete for TD>
... We do not need to invent new.

DR: We need to make sure information madel matches requirements.
... OneO2M, for example. We should drive by requirements.

Kaz: I have two comments
First, it seems to me that Dave's suggestion includes both human language portion and machine/programming language portion at once. Is my understanding correct?

DR: Yes. We need human-readable label. Desried by many platforms.

Kaz: OK. That's fine and we should think how to deal with them within TD
... my second comment is that we need concrete use case descriptions for that (=combining both human language portion and machine language portion within TD)
... for example, TV broadcasters and TV vendors are interested in how to reuse WoT mechanisms for advanced TV services (in addition to HTML5, MSE/EME and related APIs).
... that could be a good use case for WoT
... We need to think about concrete use cases before diving into the detailed mechanism/solutions

DR: Right.
... but please note that we already have requirements from existing IoT standards, e.g., OCF and OneM2M.

Kaz: Right.
... so I'm not objecting to you and agree it is one direction to think about requrirements from existing standards
... on the other hand, we need to think about our own use cases and requirements for abstract layer to interconnect existing IoT mechanisms using TD.

DR: Right.

<yongjing> Regarding TV use cases, I think IP-camera is more convincing than TV broadcast as an Web of Things use case :)

Sebastian: Data input and output make sense.

WoT ontology development - Maria

Maria's slides

Sebastian: We still have presentation from Maria
... would you like to start?

MP: Can you see my slides?
... I am going to present our model
... We are building ontology for vicinity projects.
... We need to have ontologies for different domains. Buildings. etc.
... We rely on cross-domain ontologies. But we did not have WoT ontology.
... We put all requirements that came from your documents.
... Maintenance of ontologies. We are sharing ontologies in github public.
... We get requirements from your documents. We provide examples. We also looked at emails.
... In order to build ontology, we used protege.
... We can include actions. annotaions are pointing to standards.
... RDF. We are providing three different serializations.
... URI proivides content negotions.
... Properties are defined by URL
... We didn't include protege.
... If you want to adopt this ontology, we can rename it.
... We have thing. It has one more interaction pattern. Weitable? Required?
... properties can take input.
... Unit of measures, we already have ontologies for those.
... XML datatype. Dave proposed collections and lists.
... I have not addressed that.
... Vicinity use cases. SOme cases that uses end-points that i turn uses another end-points.
... Relations. We should with ISO standard.
... JSON to RDF model. Thing, isnsance and URI.
... We describe name.
... it is a triple. a data may lead to more that one triple.
... We could include int of measure and dataype.
... Next, you have to reference it.
... Unit of measure is also defined somewhere else.
... Scope. HTTP. Href, each has media type.
... You have all repositries.

MC: We should decide on one propocol. Whether it can support multiple mode.

DR: we need additional budger,

Sebastian: we need more clarificarions.

MC: If we have classes, it would be easier.

Sebastian: we snould dedine what kind of vacbulary.

DR: We need to broaden it. That's why I am suiporting kinked data iiceneses

Sebastian: Is it possible to join next meeting, Maria?

MP: Yes, I think so

Sebastian: I will send a list of questions.

<dsr> we shouldn’t talk about protocols in thing descriptions as that bridging too many abstraction layers. Instead we should describe the metadata for the next layer down, i.e. for the IoT platforms. We also need to broaden the scope to encompas security, access control, privacy, service level agreements, and other terms and conditions.

Sebastian: I like your ontology-based model.
... I will list questions.
... We discuss it next weel.
... Are there more questions?
... Thank you everyone. Dave and Maria. Have a nice day!

<kaz> [ adjourned ]