<scribe> scribe: TK

<scribe> scribeNick: taki

Agenda

Sebastian: Logistics
... Issue discussion
... encoding naming, end point information...
... then short overview of all issues...
... Issues can be registered in GitHub
... If there is an issue that can be closed, we close it. If it has impact on current practice, then we open a new issue with pointer to the original issue.
... JSON-LD 1.1. One of the volunteers is not available today. He will join the meeting next week.

property and actions

Sebastian: there are view points...
... I added OneM2M viewpoint.
... Property has two kind
... One is property. static values or no-functional information. e.g. serial number.
... the other is datapoint. this is dynamic. e.g. temperature.
... also for functional information such as target temperature.
... All those discussion can be seen in issue 258.
... actions are for stateful condition, such as upvolume and downvolume.
... TD will not have hard rule, this is my impression now.
... should be flexible and powerful, and open to solution designer and developer.
... should be useful for most use cases.

Kaz: OneM2M classification uses two kind for property.
... I personally think this definition is not popular.
... Property also can have dynamic value, right?

Sebastian: Action vs datapoint. Switch on/off - use datapoint.
... I picked this information from GitHub discussion Yongjing provided.

Kaz: We can refer to this definition. We should be careful in deciding what we do.
... Static, variable, combination values, action, state. We should be careful about requirement.

Sebastian: We should be independent.
... Already there are existing technologies. Kajimoto san also provided use cases.
... we need to adapt to those.
... We should not stick to one.
... We should have flexibility so we can adapt to those
... How building blocks are used are up to applications.

Darko: I am in favor of having flexibility. But we can have rules.
... I suggest to define some rules as to when to use property, for example.
... In OneM2M, they have four.

Sebastian: Property, datapoint, action and event

Darko: Why do we not want to define similar rules?
... People are confused.
... Stateful are actions, etc.

Victor: I read OneM2M.
... I could not get good understanding yet.

Darko: Stateful and stateless. Stateless op is done instantaneously. One state to another. Stateful operation is not instantaneous. They require memorizing internal or internal stage.
... Before action is completed, there are states.

Daniel: To increase volume, you have to know the original state.

Victor: Prior knowledge.
... Whether to use property or action is also protocol binding.
... You do the operation twice, then volume up happens twice. Switch is different.
... If we define something not idempotent as property, it is a problem.

Sebastian: We suggest we not have hard rule.
... because we should not close doors to some other usages from other IoT activities.

Victor: If two servients have different interpretation, it causes problem in interoperability.

Sebastian: Server always announce what is property.
... Developer has choice.
... after it is developed, it is clear.

Darko: This is "Darko's property". This is not the point of standard.
... We should not be so flexible.

<achille-z> +1 with Darko

Darko

Darko: We should not try to define in hard way, but we should define some.

Victor: Kajimoto-san and Dom also have point of view.

Sebastian: Property and action discussion is difficult.
... victor and darko, please respond to the current outcome.
... Today, I tried to reflect current viewpoints.

Simplified Structure

Sebastian: we introduce @type.
... with value property, action, etc.
... Property vs action is a big issue that have impact on scripting and protocol bindings.

Naming of encoding

<inserted> Issue-253

Sebastian: We are using in the future MIME-Type.
... We should also think about "encoding" terminology.
... "format", "mediatype", etc

Daniel: Mediatype is actually used. contenttype is just a field in HTTP.

Victor: I propose to use mediatype.

Daniel: me too

Sebastian: If there is no complaint, I would like to select that.
... I ask them on GitHub.

Victor: we should close before next telecon?

<maxime> I just closed it then

<maxime> comment: Agreed for `mediaType`, which is a term that is independent from interaction protocols.

Sebastian: I will also announce on mailing list.

end-point information

Sebastian: TD is static about endpoint information, encoding, etc.
... How can we assign different protocols, etc?

<kaz> TD examples

Sebastian: Events, e.g. only with coap with EXI. somone want to provide JPG image as property.
... We need to provide local information.
... locally defined communication metadata.
... We should also keep global definition.
... there was such an opinion.

Kaz: Comment. I am not objecting to the proposal. We need to use values defined by IANA registry, correct?

<kaz> IANA Media Types Registry

Daniel: correct. "unknown" is ok

Victor: With "+", we can do more.
... specific, your own schema/type.

<victor> https://github.com/vcharpenay/wot/tree/master/proposals/td-vs-hydra

Victor: I share a proposal. We need to align two proposal.
... Why not keep "href" ?
... Each resource that way becomes a link.

<victor> properties : { hrefs : [ { @id: "http://example.org", "mediaType": "application/json" } ] }

Sebastian: TD should be open to OCF's handling of properties.
... we can also handle Hydra.

Victor: We could use endpoint. But we should use "id".

Sebastian: we have received from google and mozilla about use of semantics.

Victor

Victor: Hydra is not relevant in the example I gave.
... my proposal is to use different key.

Sebastian: I understand now.
... Please make an issue, so we can discuss.

Victor: ok

Sebastian: I would like to keep this issue open.

Other issues

<inserted> Issue-254

Sebastian: templates for properties, actions and events

Darko: with templates, you defined property, I also offer my property. In repository, there is a template. The two property can have same name. It will enhance interoperability.
... It does not cost.
... Michael Koster pointed to his proposal.
... I would like to propose to use template in our TD repository.

Sebastian: We need this kind of approach. It relates to lifecycle.

Darko: Kajimoto-san's suggestion is based on industry experience.
... Many things are well-standardized.
... My sensor is using existing characteristics.
... This is industry practice.

Sebastian: should we converge this into lifecycle discussion?

Darko: It can be joined into lifecycle.

Resource parameters

<inserted> Issue-264

Sebastian: Currently there is no definitions.
... how parameters are used in resources.
... parameters in URL. If you have this kind of REST approach, we provide no way to allow for that.

Sebastian explaining parameter definition ...

Victor: URL template with parameters.
... That's an approach in Hydra.
... I will comment in GitHub issue.

Compound property

<inserted> Issue-256

Sebastian: To introduce functionality of grouping.
... Please follow the issue.

Separating discussion of requirements from serialization formats

<kaz> Issue-257

Sebastian: Properties vs. action still is an open issue.
... Yongjing or Kajimoto-san will join next week.
... Talk to you later in regular meeting

<kaz> [ adjourned ]