See also: IRC log
<kaz> scribenick: MariaPoveda
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
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 ]