WoT-WG - TD-TF

<kaz> scribenick: McCool

Preliminaries

Sebastian: some guests today, need to review patent policy, then will review transition
... and then hopefully we can discuss the TM, with contributions from Oracle and Bosch, if they join us as planned

Guests and patent policy

<kaz> W3C Patent Policy

Sebastian: please be aware this discussion is public, and participation requires agreement with the linked policies

Minutes review

Sebastian: Nov 4, during vacation time

<kaz> Nov-4

Sebastian: short session, just dealing with some transition request technicalities
... also discussion around issues but decisions postponed
... and binding doc status update
... any objections to accepting and publishing these minutes?
... no objections, will be published

Announcements

Sebastian: next week will have another guest from LBD group
... already had a short meeting, relevant, esp around semantics for building use cases
... will be joining our next TD call

TD 1.1 Transition

Kaz: submitted, approved, working with web master now for publication
... after checking docs, there might be some minor editorial changes needed
... will reach out to editors tomorrow

Thing Models

Sebastian: can share slides from TPAC for context

https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-10-online-f2f/2020_TD_Topics_TPAC.pdf

Sebastian: expectation of TD is that all data is available for immediate interaction
... not the case for TM, they are more abstract, for use earlier in the lifecycle
... for example, during development
... can also be seen as a template for TDs
... when you instantiate it you have to provide the missing information

Sebastian: next steps is we need to look at some use case examples
... examples from Oracle and in Vorto
... would like to start with Oracle example

Lagally: oracle example comes out of the plugfest

<sebastian> https://github.com/w3c/wot-thing-description/issues/999

Lagally: this an example exported from iot cloud service
... from Festo plant that we have used in several plugfests
... see in particular Festo_Shard.jsonld
... can import this model and build simulators for it
... and there are additional device models
... for example for Intel devices
... also there were scripts to generate device models from TDs

<kaz> DMs from TDs

Lagally: (note "DM" is Oracle term for their format)
... there are simulated devices where we generated TDs from DMs
... and vice-versa, where we generated DMs from TDs for existing things

<kaz> tools for conversion

Lagally: slight differences in structure and syntax between TDs (TMs) and DMs
... but in general a DM is a "blueprint" for a class of devices

Sebastian: how do you plan to distinguish between live and simulated data?

Lagally: devices include the device models they implement
... TDs have instance ids, DMs

McCool: on issue that came up in directory discussion is that it would be good to have an @type for TMs
... so they can be easily distingushed from TDs
... rather than having to infer from the fact some fields are missing

Lagally: note that DMs predate WoT

Cristiano: so attributes are properties?

Lagally: right, but note that names are different since defined before WoT
... do not necessarily exact correspond in some places

Sebastian: are these 1:1 mapping?

Lagally: about 80% mapping; scripts are fairly basic
... so not clear that all information would be retained when converting back and forth in all cases
... but this was just a simple test for the plugfest, and done 17 months ago
... not updated since

Sebastian: regarding the scripts, I see you also add some additional information as part of the conversion, eg IP address
... and ID
... (IP address/base URL/DNS name)
... so in TM we are talking about "placeholders" where information needs to be filled in
... I think this is a good match to what we are talking about

Lagally: agree

McCool: agree, we just need a way to easily identify the "placeholders"

Ege: would like to see protocols, etc. in addition in TMs

Lagally: do like the @type using "ThingModel" proposal

McCool: discovery group would like to see TMs extended to include security and form templates
... right now we just have a "TD example", would rather have a TM
... these would be optional, but if included would constrain the TDs instantiated from the TM

<mlagally> https://github.com/w3c/wot-thing-description/issues/999

<mlagally> https://github.com/w3c/wot/tree/master/workshop/ws2/Demos/tools/Oracle

McCool: anyway, I just want to point out that TDDs are a "use case" for TMs

Vorto

Kevin: (issue 1000)

<sebastian> https://github.com/w3c/wot-thing-description/issues/1000

Kevin: see model in public repo (insert link)
... different function blocks, semantic modelling capability
... using Vorto DSL
... example provided in issue above for a washing machine
... can define a set of capabilities, information models, and function blocks
... can extend function blocks, but single inheritance/extension only; also, no overriding
... in other words, can extend, but not restrict
... which implies no name conflicts
... in real life, though, we see composite designs more often used than extension
... no examples of platform-specific information, eg IP address
... but it is possible to add that information

McCool: can you compare with the ASDL object model?

Kevin: haven't really looked at it, can't comment at this point

Sebastian: have "using" declaration, what does this mean?
... importation?

Kevin: yes, for referring to other definitions, e.g. to inherit from another model
... everything that has a reference to another model needs to be imported

Sebastian: so same concept as programming lang

Kevin: correct
... in the past has tried converting Vorto model to a TD, in both directions
... but since TD is an instance, don't have IP address, etc.
... mapping to a TM is more logical

Sebastian: please add this as an example for TM conversion in the issue
... good start to have these concrete examples
... I expected some additional examples from Michael Koster from ASDL
... then we should identify what is missing from TMs to fill any gaps in conversion
... whether we need to add any new features, or use context extensions, whichever is appropriate
... e.g. a special feature only used for Vorto conversion may use a special extension to express

Schaeffler

Sebastian: they have use the WoT approach and are applying in the context of a Digital Twin project
... also had several questions
... let's start with introductions, then slides, then questions

Vlad: (Vlad Baluta) am a solution architect at Schaeffler
... have developed some DT solutions using WoT standard

Christof: (Christof Kuestner) (audio issues)

Andreas: (Andreas Brenner) also in the same team at Schaeffler, working on DT project
... one component is data transfer

Christof: also a member of the DT, data architect
... focusing on integrating products that access/produce/expose data to DT system

Sebastian: do you want to show your slides?
... I think it would be useful to have the context

Vlad: unfortunately can't show slides since this is a public forum
... however, we can talk a bit, and then show the example
... basically S. produces a number of mechanical/electrical components
... and then we provide an API to get access to data about that component
... first phase, mostly quality data, mostly static
... for example, a bearing; has weight, material, etc.
... static properties
... in TD we see "properties", but these can change, are network interactions, etc.
... so what we want more is static metadata
... easiest to show an example
... (shares screen - link available?)
... use properties section, have URLs, can access URL to get values
... API is hosted in a cloud service
... use the OM measurement ontology
... but although we can fetch these from a URL, still static
... and it is useful to have the multilanguage description associated with the properties
... which customers appreciate
... main issue right now is a way to mark properties as being "static" would be useful
... two ways to do it; embed value directly in TD, or embed in key-value map

Sebastian: multiple solutions for this, let's go to the queue

Ege: valid example, pretty common that things are constant
... would suggest simply use the "const" keyword
... just under type, can put value into the property itself, using "const: value"
... this embeds the value in the TD, but can still have information about type, etc.
... can also put it in the data model

Vlad: is const a feature of TDs?

Ege: yes, and also a JSON schema concept

Sebastian: comes from JSON Schema, and includes almost everything from there

McCool: do we want to use the API to get the value?
... then maybe we need a "static" keyword similar to "readOnly" etc.
... that would not give the value, you would still have to use "GET" to retreive it

Sebastian: still, a "const" example would be helpful

Cristiano: our use case have something similar, want to give the weight
... can embed it into the TD, as additional vocabulary, using a vocabulary extension
... in our use case, made sense to move to the root level

Vlad: so you mean add them as custom attributes, etc.

Sebastian: this is basically a "parameter", set up once per instance, would never change; is a kind of metadata, not an interaction
... of course a vocab extension also needs a context file, although that is not absolutely necessary

Vlad: we did not do it that way since we'd need to define a general ontology for every product
... was a bigger effort
... and also like having it under properties with a URL; makes it easier to do automation

Sebastian: as you have show it, data will get embedded in TD, so is JSON based, need to parse etc

Vlad: like use of forms to control security

McCool: need to consider when security is checked; if data is embedded in TD, then it's the security for access to the TD that matters, not what the TD says about the endpoint

<Zakim> dape, you wanted to mention we used to have stability term but decided to drop it

<dape> https://github.com/w3c/wot-thing-description/issues/29

Daniel: did have a similar flag in the past
... did have a "stability" flag
... but it was dropped due to observe

Cristiano: if security is an issue, then about metadata, have "public" and "private" version, and "public" is a subset, then link one to the other
... also... what about the timestamp?

Vlad: actually, just a name for the production date, not the date of last update, etc.

McCool: (note we should then have a link relation type for public/private relation)

Cristiano: was to advertise have created a tag on stack overflow, could use to discuss things like this

<Ege> https://stackoverflow.com/questions/64173335/do-w3c-thing-description-forms-require-an-op-key

Cristiano: web-of-things is the tag

McCool: be careful you are referring to the W3C specification
... as there are number of older specs that used the same name; I am aware of at least three

Sebastian: is there another question?

Vlad: yes, do we have time?

Sebastian: probably for at least one more
... also we should probably talk about membership, invited expert, etc.

Vlad: for the membership issue, need to wait
... let's do the additional technical question
... looking at this same example...
... this is for one product
... but consumers may get batches, may want to get properties from batch
... say have property a and property b, want URL to get properties from all the things
... for example, getting all the values back in an array
... implemented by using a URL template in the API

McCool: I would suggest looking at what we are doing in WoT Discovery
... JSONPath can do this
... also there is an implementation from Fraunhofer (LinkSmart) you can look at

Daniel: what about GraphQL

McCool: sure, but not in our standard, but if compiles to SPARQL

Sebastian: what about readallproperties?

Vlad: we are using, in fact
... but gets all the properties from one Thing; but what we want are all the properties from a SET of things

Sebastian: could define a virtual thing that has links to the other Things

<kuestner> Just to name it also here: https://graphql.org/

Vlad: how would that work exactly?

Cristiano: we actually defined something similar
... set of accelerometers
... for reading the set of all properties, defined a special property
... not a standard way, but a way
... but still have to define a special property

Vlad: similar to what we did, built a virtual thing

McCool: worth thinking about, but perhaps overreach to add to discovery; but maybe a new topic, for a standardized "smart proxy"

<kaz> kaz: wondering if it's possible for us to generate a concrete use case based on this discussion

<kaz> ... also wondering about how to proceed

McCool: we can generate a use case for discovery next steps, follow up with discovery TF, McCool to organize
... also, membership, etc, should be followed up with the W3C Team

<kaz> kaz: yeah, we could invite them to the Discovery call as well, but would be nice if they could become a W3C Member. Let's have discussion offline.

<kaz> [adjourned]