<kaz> scribenick: MariaPoveda

Current TD deliverable version .

updates from Sebastian

<kaz> TD deliverable document on github

<kaz> sebastian: goes through the draft

<kaz> sebastian: Introduction, Namespaces and Conformance

Conformance. Based on SHACL or more structure validation?

structure defined based on DCAT vocabulary

<kaz> scribenick: MariaPoveda

question: how do we should validate a thing description?

when is a valid thing description?

dsr: in the RDF we require certains properties, as names. Then we need a choice how to define them.

names refers to human languages, no serializations

DarkoAninic: we can use also SHAPES.
... Structure validation understand by stating the properties in the right place.
... Some semantic validation should be possible even though no reasoning is done.

right, I was actually thinking of the name lenght

sebastian: are there mandatory parts that always need to show up?

yes, miniminun parts can be defined, said Darko

About the vocabular definition, script from Victor

dape: does the RDF validation come for free when you have done json validation?

<kaz> https://www.w3.org/TR/html5/

kaz: before diving into the detailed validation methods, we might want to think about the target of the conformance. For example, HTML5 has several sections including check tools, conformance for authors, users, etc.
... so we might want to have those kinds of categorized sections depending on the purposes of conformance validation

dsr: 1) no make it harder for people to understand it. 2) do not include the default context in the text but as a reference so that it can be updated

DarkoAninic: SHACL takes as practical thing to provide rathen than normative of the specification

dsr: decide what is informative or normative

sebastian: Vocabulary section
... links to the ttl ontology and the description
... HTML generated with Victor script. Not very happy, some modifications are needed.

<victor> note: it is not aligned with the Turtle document that is online but the one on Github

sebastian: change order in the class definitions
... the datatypes is missing

sebastian: next section, serialization. Concrete examples in json-ld and links to the vocabulary. We need to align with the latest version of the current practices
... from Wednesday's meeting, the idea now is to have one single document, the current practices + the thing description deliverable. Do not duplicate the thing description

(not sure about the merged documents final decision)

dsr: we agreed to use the json schema types but not all of them necessarily
... we need to define which types we are using and from which namespace

sebastian: list at least the single types

dsr: have a look at the commercial interest

dape: we should try to use the current practices to show the differences about the specification and what is intended to to in plug fests
... keep it more practical

<Zakim> kaz, you wanted to suggest we clarify which issues need to be resolved before fpwd

kaz: question on the next step
... at this moment (expected to publish the fpwd shortly), it is important to clarify which issues need to be resolved before the publication of the fpwd. also can we ask the security tf to review this draft? if not which sections need to be updated before the review?.

sebastian: regarding security nothing new will be in there
... review and make proposal about the security part to clarify it

kaz: there is a security call today, shall we ask them to start the review?
... or next week?

sebastian: next week is holiday in Germany

<kaz> kaz: in that case, let's check the progress during the Editors call next Wednesday (Aug. 16), and make some decision at that time (e.g., starting the security review on Aug. 18th)

<kaz> sebastian: ok

TD Events

Michael Koster's slides on TD Events

sebastian: progress on Events

Michael Koster shares the screen. Slides: TD Events

MichaelKoster: list of event protocol bindings: CoAP observe, MQTT other Pub/Sub, Websocktes, HTTP EventSource, HTTP long poll, Link Bindings using web callback, scripting API

MichaelKostar: how do we repersent conditional notification in a TD?

<Zakim> dsr, you wanted to talk on eventing

dsr: Separate communication and programming aspects.
... groups of events to subscribe to (from Michael slides)
... allow for metadata on events

<Zakim> kaz, you wanted to ask Michael Koster to send these slides to the group list and to mention there are several kinds of Events, e.g., DOM UI events and MMI application lifecycle

kaz: 1) could you send the slides?
... 2) there are several related work on event handling within w3c, e.g., DOM UI Event, MMI Lifecycle event and Vehicle API/Server specs. We migh want to look at those existing specifications.

<kaz> https://www.w3.org/TR/DOM-Level-3-Events/ DOM UI Events

<kaz> https://www.w3.org/TR/mmi-arch/#LifeCycleEvents MMI Lifecycle Events

<kaz> https://www.w3.org/TR/vehicle-information-api/ Vehicle Information API Spec

<kaz> https://www.w3.org/TR/vehicle-information-service/ Vehicle Signal Server Spec

sebastian: when we have particular protocols do we say the given protocol is able to do X and Z but not Y?
... Does some protocols directly disable some interaction patterns? (maria: Was this what you meant?)

<dsr> In response to Sebastian’s comments on events over HTTP, I note that HTTP is fine for events, either pushing events to the cloud, or pulling via Server-Sent events where you subscribe with the HTTP GET, just like CoAP GET with observe.

<dsr> The event metadata could indicate whether events may be dropped or must be delivered in sequence etc.

MichaelKoster: You might have more than one protocol. Using scheme is very useful in terms of restrictions. Let's be practical and see how useful are a few pieces of metadata.

yongjing: How to suscribe? How to get notified? providing a link? In other cases the subscriber specify a notifier URI
... we need to think about the definition and different types of events. Predefined as read only and others like when the device provides you a way to subscribe to many that can be customized

DarkoAninic: what is the vocabulary we need to specify events? property values? timestamps? should they be optional?

<dsr> Timestamps could be part of the data type description for an event

DarkoAninic: min and max levels. Use specific ontology to specify, but not really in TD?

<Zakim> kaz, you wanted to mention (1) the vehicle information API spec describes APIs to subscribe events and (2) the vehicle signal server spec describes underlying mechanism on event

kaz: automotive wg has 2 specifications.
... (1) the vehicle information API spec describes APIs to subscribe events (including min/max range as well)
... and (2) the vehicle signal server spec describes underlying mechanism on event based on websocket (message structure including timestamp)
... so again I'd suggest we look into those specs

iot.schema.org topic for next week

<kaz> sebastian: looking into automotive specs would be useful

<kaz> kaz: we can have joint discussion again during TPAC

<kaz> sebastian: right. but would be nicer to review their work earlier

<kaz> ... we're over the time by 15 mins, maybe we should consider extending the call by 30mins

[ adjourned ]