Breakout topics 12-04-2016 13-04-2016

From Web of Things Interest Group
Jump to: navigation, search


TD Breakout 1 (12th of April)

Participants

Sebastian, Dave, Matthias, Kajimoto-san, Michael, Victor, Taki, Naka-san

Topics

  • New TD structure
  • TD templates and collections of things

Minutes

  • New TD structure
    • Sebastian reports on changes
  • Implications of current structure
    • Dave: How does the script select a specific property?
    • Matthias/Mike: URI is just the handle in the background
  • TD tempalates
    • How should manufactuerer prepare the TD?
    • URIs will be specific
    • Matthias: Relates to the lifecycle of the TD we briefy discussed in Nice. The information in the TD will grow during the different lifecycle phases.
    • Could use something liek macro pre-processing on the thing, or the $variable style string processing from PHP
    • Only works for pre-known values, cannot create new nodes
    • There should be a generator for the TD, since JSON-LD is only one serialization, there might be others.
    • Things might have an internal structure (maybe like DOM in browser), which allows to update information later.
    • Might be even more dynamic changes when TD is in a managemnt system
    • focus on TD on device for now, since we have not defined the lifecycle yet. Later, there might be need to patch in lots of metadata in some management repo.
    • Two appraoches:
      • Code first: Framework could provide means to add resources and prompt for TD field values and then generate TD
      • TD first: TD can construct code stubs; might also be useful to instantiate thing proxies
  • collections of things
    • one thing - multiple interactions
    • one thing - array of identical interactions
    • multiple things - identical interaction
    • multiple things - heterogeneous interactions


TD Breakout 2 - TD&AP: Protocol Mapping

Participants

<all>

Topics

  • Data type and restrictions
  • implicit vs explicit assumptions in TD

Minutes

  • Data type and restrictions
    • Sebastian shows usage of XSD types in TD
    • ... No support for complex types
    • ... Should this be part of encoding or where?
    • Matthias: problem of tight coupling when we enforce internal representation, that is, implementation details
    • ...
    • Schema.org has a type system with restrictions
    • Named types
    • Johannes: Would this be a working concept?
    • Dave: What about sets? They don't have them...
    • Johannes: We can build this from these scalar types.
    • Dave: What about precision?
    • ...
    • We can add more properties to these scalars to make them fit our need.
    • Agreement on "Let's use schema like solution for our data type problem".
    • Sebastian: Agree on the abstract way to define values, but allow for restrictions such as min, max to be more specific. Need to check if this is enough
    • Dave: Also have precision in this model.
    • Victor will work on a proposal.
    • Johannes: Let's now look at how to build
    • Daniel: JSON schema does not work for XML
    • Johnnes: RAML 1.0 has a generic way to describe schemas, like a minimal meta-schema
    • Mike: Arent' they using Schema.org
    • Johannes: 0.8 was Schema.org only, 1.0 now can support multiple schemas
    • Mike: Can this describe multiple elements in some kind of structure? Should we restrict to describing maps? Would make things simple.
    • Johannes: Need to make sure it works with multiple encoding, JSON, XML, etc. Let's go for the most simple solution and extend it when we hit a deadend.
    • Sebastian: Let's investigate how abstract we can make data structure descriptions. Taki, could you look into this?
    • Dave: What about more restrictions across multiple values?
    • Daniel: Not even possible in XML
    • Dave: Integrity constraints
    • Victor: It does not need to be part of the TD. There can be other channels to validate, check, etc.
    • Dave: Roadmap to have this
    • Johannes: The decision does not restrict us from doing this in the future. We need to think about this, but there is no need to solve this right now.
    • Sebastian: Let's separate this into another discussion.
    • Prepare
    • Matthias: Let's not rule out other schema concepts compeletely.
    • Kaz: The UPnP data model was integrated into OCF. So this might be a place at which to look.
    • Victor: Schema.org is nicely integrated with JSON-LD
    •  ???
    • Daniel: XSD was what we started with, so it might be a problem.
    • Sebatsian: XSD is also a schema.
    • Dave: This will be hidden in the context anyway.
  • implicit vs explicit
    • Sebastian: Properties have the implicit assumption that you need to do a GET on them.
    • ... We coud have a field explicitly stating it needs to be a GET.
    • Mike: What if it is MQTT and it should be Subscribe? Should this be a hypermedia control?
    • ... Media Type? I imagine that the hrefs point me to another Media Type that will tell me the hypermedia controls (links, forms).
    • ... It might be bad if I have to give up this flexibility when the TD instructs something directly.
    • Johannes: We experimented with this in the first Plugfest. It did not solve the problem: "what should I expect when I get there?"
    • Mike: Media Types would be my prefered way.
    • Matthias: If we leave "TD land" at this point, we need to fully understand what comes behind, e.g., "OCF land"
    • Mike:
    • Johannes:
    • Dave: Communication metadata
    • Johannes: Not everything goes into the TD.
    • Dave: I would like to work in parallel on the different aspects. People have different interests.
    • We need to at least focus this discussion on a specific issue. We decided on discussion ways to provide explicit information for clients how messages are constructed.
    • Mike: OCF uses both PUT and POST for Create
    • Matthias: If we have one action that requires a POST and another action that requires a PUT (because that is how the server/platform/thing is implemented), we need to express this in the TD.
    • ...
    • Mike: The information might need to go into the binding.
    • Sebatian: Could introduce binding-specific context.
    • ...
    • Johannes: 2 possibilities:
    • ... Generalize the different message types / protocol methods into a common abstraction used in the TD
    • ... Define binding configuration structures that are linked for each case (OCF CoAP, LWM2M CoAP, Nice Plugfest CoAP)
    • Volunteers for analysis:
      • MQTT: Mike, Soumya
      • BLE: Louay
      • OCF: Mike
      • BACnet: Matthias
    • Volunteers for implementations:
      • CoAP: Matthias, Kazuaki, Daniel
      • HTTP: Mike, Louay
      • BLE: Louay

TD Breakout 3: Explicit Protocol Binding on BTLE as an example

Participants

Sebastian, Dave, Matthias, Kajimoto-san, Michael, Victor, Naka-san, Louay

Topics

  • How to represent BLE protocol in TD?

Minutes

  • BLE/Homekit demo by Louay
  • Quick review of GATT (services, characteristics, attributes, ...)
  • Strawman for BLE-based TD
  • Action items:
    • Create GitHub Wiki
    • Document progress on all explicit Protocol Binding information (HTTP, CoAP, BLE)
    • Identify and discuss common issues in abstraction
    • Wiki also used by data type and restrictions task force (Victor, Daniel, Taki)


Proposed topics for breakout sessions

- discussion about new TD structure (also see [1])

- how to define (complex) data types and type restrictions in TD?

- discussion about a commmon vocabulary for TD

- ...

Dave suggests we consider clarifying the formal type system, and integrity constraints as a basis for robust operation. This can be formalised independently of the syntax for serialising data models. In essence, we need to allow for a superset of the types used by common IoT platforms.