<kaz> scribe: Daniel

<kaz> scribenick: dape

Logistics

SK: Let's start with some logistics
... weekly call until first of November
... re-structering used in next PlugFest
... use Github for discussions
... plan for today: start with property and actions
... also finalize mediatype proposal
... handle feedback we got about JSON-LD

Properties vs. Actions

SK: lets wait for Kaijimoto-san..
... switch topic

Specify encodings

UNKNOWN_SPEAKER: SK: github issue #251
... propose to use mimetypes instead of XML, JSON, ...
... seems to be agreement about this topic

<kaz> GitHub Issue 251

SK: OK for everybody to integrate this comment?

All: silence (--> agreement)

<AZ> encoding is almost universally used in computer sciecnce to talk about "character encoding"

SK: related issues whether to use term "encodings"
... Maxime proposed to use format, representationType et cetera

<inserted> GitHub Issue 253

<AZ> content type sounds good

MK: mediaType and contentType is commonly used

<maxime> +1 for contentType

<AZ> media type is fine for me too

VC: Shall we use mediaType then?

MK: guess mediaType makes sense
... should check IANA for a registered term

<AZ> +1 mediaType

SK: Let's think about and comment... will make decision next week
... ask Daniel to close issue

DP: OK

JSON-LD 1.1

SK: related to issue #259

Dave's proposal not aligned with JSON-LD specification

<kaz> GitHub Issue 259

scribe: Gregg Kellogg mentioned new work is done in JSON-LD context
... happy to integrate feedback
... think we identified missing parts and should report it back to the JSON-LD group

<kajimoto> I faced audio trouble...

scribe: I am very thankful that we can provide feedback

DP: any timeline for JSON-LD 1.1?

VC: No timeframe

SK: I think they are currently collecting issues and proposals
... will try to invite Gregg to one of our next meetings

<kajimoto> i can speak now, i hope...

SK: should check back with Gregg

AZ: JSON-LD 1.1 is not on standard track
... developed in community group
... unlikely to become standard

<kaz> JSON-LD CG

SK: Doesn't sufficient support mean that creating a standard would be feasible

AZ: Yes, .. but there is no timeframe yet

VC: Do see AZ's concern... using new features in TD might be problematic

AZ: Within interest group looking at it is fine.. in WG we should focus on standards

SK: Let's check with Gregg
... uncertainty is not good

Properties vs. Actions

SK: Difficult topic.... ongoing discussion on Github #247

<inserted> GitHub Issue 247

SK: tried to summarize viewpoints in my slide (TODO LINK)
... current WoT assumption... property has static/dynamic states
... e.g., read temperature, read/set RGB
... Actions is more for function which has start and end
... e.g. fadeIn
... Dom's proposal only readable states
... functions to enable/disable etc

Kajimoto-San: internal software status is property
... hardware is action
... another proposal is based on API Level
... low level is property

<Yongjing> the latest comment i made on this issue is to recommend people to look at the current practice of information modeling in oneM2M/SDT, where clear rules are made for reference. we don't need to suffer again the similar debate that people already experienced somewhere else.

Kajimoto-San: complex API is actions
... another proposal is to say we don't need a separate property and action

SK: Unsure about what "we" should use/pick?

Kajimoto: another proposal was about object-oriented analogy
... read/change was property
... function was action
... my proposal seems similar to OO-analogy

<Yongjing> q

SK: sometimes we do have something in between

<Yongjing> q me in plz

SK: not sure in that case

Yongjing: according to my oneM2M experience.. different ways out there.. suggest to look at them
... hard for developers to impose strict rules
... our way should be flexible and powerful enough to handle different protocols

SK: do you have the same issue in oneM2M (action vs property)

Yongjing: yes
... in oneM2M there are clear rules
... we could adapt them
... oneM2M has 2 terms for properties: property (static e.g, device id) vs data-points (dynamic e.g, measurements)
... the latter is functional
... difference between data-points and actions: property is stateless
... action is stateful... e.g, increase temperature by X
... this is just a rule.. people might choose different rule

MK: had same discussion in OCF
... difficult to specify hard rules
... leave it to the designer
... agree we should try to come up with a descriptive category...

SK: ask Yongjing to add input to github

Yongjing: just did

MK: looking at semantic annotations... client should be able to know which pattern to use
... no concrete idea yet
... looks at least promising to me

SK: discussion is ongoing...

Kajimoto: like Yongjing's proposal

General TD discussions

SK: Simplify the way how actions/properties and events are presented in TD
... going back to original TD version
... generic interaction container

<kaz> GitHub Issue 258

SK: use @type to mark interaction
... even allow @type to be property and event
... github issue #258, please comment

Kajimoto: not sure about @type proposal
... purpose of TD is also about designer and which API to use
... would like to see some API examples
... should consider the combination of TD and API

SK: Thanks. Will provide some examples on Github

MK: have an example of another pattern
... mapping smart things to schema.org
... have type and id (== command)
... will provide example on Github
... very much RDF-like

VC: is there a link we could look at?

MK: Will share link

SK: next is Github issue #254

<inserted> GitHub Issue 254

SK: Darko proposes to think about templates
... not deeply discussed so far
... propose to have abstract description of TD
... start with abstract TD and enhance it later
... please comment
... fits also with TD lifecycle
... next is Github issue #255

<inserted> GitHub Issue 255

SK: move encodings and base url to resource/interaction
... idea is to move global definitions to local definitions (being self-contained)
... please comment
... next is Github issue #256 from Dave

<inserted> GitHub Issue 256

SK: about compound properties

MK: will add comment... e.g. thing with 6 buttons..
... notion of collection

SK: related to template?

MK: yes, I think we need both

SK: will link those 2 issues
... next is Github issue #257
... about separating requirements from serialization formats
... Dave is looking for volunteers to work with him on that

MK: careful to sign up.... but looks interesting
... workflow is important to look at

SK: That should be it for today..
... will ask Gregg to join next meeting

<kaz> [ adjourned ]