See also: IRC log
<scribe> scribe: TK
<scribe> scribeNick: taki
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.
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.
Sebastian: we introduce
@type.
... with value property, action, etc.
... Property vs action is a big issue that have impact on
scripting and protocol bindings.
<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.
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.
<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.
<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.
<inserted> Issue-256
Sebastian: To introduce
functionality of grouping.
... Please follow the issue.
<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 ]