- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 02 Dec 2020 18:39:54 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/11/11-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Michael McCool!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
WoT-WG - TD-TF
11 Nov 2020
Attendees
Present
Kaz_Ashimura, Andreas_Brenner, Cristiano_Aguzzi,
Daniel_Peintner, Ege_Korkan, Jack_Dickinson,
Michael_McCool, Sebastian_Kaebisch, Taki_Kamiya,
Vlad_Baluta, Kevin_Olotu, Christof_Kuestner
Regrets
Chair
Sebastian
Scribe
McCool
Contents
* [2]Topics
1. [3]Preliminaries
2. [4]Guests and patent policy
3. [5]Minutes review
4. [6]Announcements
5. [7]TD 1.1 Transition
6. [8]Thing Models
7. [9]Vorto
8. [10]Schaeffler
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<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> [13]W3C Patent Policy
[13] https://www.w3.org/Consortium/Patent-Policy-20200915/
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> [14]Nov-4
[14] https://www.w3.org/2020/11/04-wot-td-minutes.html
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
[15]https://github.com/w3c/wot/blob/master/PRESENTATIONS/2020-1
0-online-f2f/2020_TD_Topics_TPAC.pdf
[15] 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>
[16]https://github.com/w3c/wot-thing-description/issues/999
[16] 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> [17]DMs from TDs
[17] https://github.com/w3c/wot/tree/master/workshop/ws2/Demos/TDs/Oracle/DMs
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> [18]tools for conversion
[18] https://github.com/w3c/wot/tree/master/workshop/ws2/Demos/tools/Oracle
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>
[19]https://github.com/w3c/wot-thing-description/issues/999
[19] https://github.com/w3c/wot-thing-description/issues/999
<mlagally>
[20]https://github.com/w3c/wot/tree/master/workshop/ws2/Demos/t
ools/Oracle
[20] 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>
[21]https://github.com/w3c/wot-thing-description/issues/1000
[21] 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>
[22]https://github.com/w3c/wot-thing-description/issues/29
[22] 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>
[23]https://stackoverflow.com/questions/64173335/do-w3c-thing-d
escription-forms-require-an-op-key
[23] 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: [24]https://graphql.org/
[24] 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]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [25]scribe.perl version ([26]CVS log)
$Date: 2020/12/02 09:39:13 $
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 2 December 2020 09:40:01 UTC