Meeting minutes
Opening
Erich: (gives remarks)
Sebastian: (starts the meeting)
… would like to ask you all about your impressions
… took many photos myself
McCool: saw the photos from the WoT Conference yesterday
… we might want to think about WoT catalog as a possible deliverable
Sebastian: (shows photos from the meeting room and also the Christmas Market)
… great work with much fun!
… (also shows photos from the Gala Dinner last night)
… had Johannes Hund, etc., there
Erich: will the video publicly published later?
Sebastian: need to check with the Siemens Communications Team
Thing Model Catalog
Sebastian: (shows the Thing Model Catalog repo)
… we might want to invite them to one of our calls
<sebastian> Thing Model Catalog Repository
Agenda for today
Sebastian: (updates the agenda)
… (then goes through the items, and add concrete time for each item)
… would move "Coordination with External Groups" topics to tomorrow
… Cloud-Edge-Client Coordination CG, Smart Citeis IG and WoT CG to be moved to tomorrow
… what about "Use Cases and Requirements"
McCool: either is fine, today or tomorrow
Sebastian: 30 mins for today then
… some chat about today's dinner :)
… liaison discussion including OPC tomorrow
… what about "Marketing"?
Ege: yeah
Erich: probably we should have the Coffee Break a bit earlier, e.g., around 3:00pm
Sebastian: (move the Coffee Break before "Use Cases and Requirements")
… who is interested in the dinner tonight?
(8 people raises their hands)
Sebastian: who is leaving earlier tomorrow?
… maybe we can close the meeting by 2pm
Plugfest Summary
Sebastian: subtopic: Generating the report
Ege: empty slides to record the results
Daniel: report for the Plugfest and/or the demo?
Sebastian: both
… everybody to write down their report now (till 10:50 CET)
(then morning coffee break at 10:50-11:15)
Kaz: maybe we can reuse the 1-pager from the pitch yesterday as the first page, and add "what was done" as the second page?
Sebastian: yes and know
… would like to see "what was verified from the WoT technical viewpoint"
McCool: where to put the slides?
Kaz: under the wot repo or the wot-testing repo?
<sebastian> please upload your Plugfest outcome slides here: https://github.com/w3c/wot/tree/main/PRESENTATIONS/2024-11-wot-week/Plugfest-Outcomes/
<sebastian> or send the files to Kaz per email
Michael McCool
McCool: WoT AI services and gaps
… (goes through the report)
Cristiano: didn't get the detail
McCool: using HTTP
… request some text and new line
… can keep the connection open and then refresh that
Cristiano: about JSON Schema
… deal with the JSON Schema itself?
McCool: manage to close it
… (shows TD Issue 1464)
Ege: content encoding
… for binary
… interesting dimension is two possible different content types
… no way to handle that within TD at the moment
TD Issue 1464 - How to describe multipart/form-data in TDs
Ege: was also thinking about uploading binary data
McCool: common with Web services
Cristiano: definitely need to handle this
Sebastian: JSON Schema has its own media type information
McCool: discussion should take place on the issue 1464
<McCool> w3c/
McCool's recent comments on Issue 1464
Luca: it's not an issue for JSON
McCool: other related issue there
… there was a standard describing more general way
Luca: we have a situation with JSON Schema
… we need to describe binary format that JSON doesn't represent
... we can look at other kind of schema mechanism
McCool: will continue to talk with Ege
Ege: you should create a new issue
Josh Thomas
Josh: (gives his report)
… TD playground allows validation of TD
… but maybe should validate the data too
… our demo kept expanding
… kudos to everyone involved
… super venue and organization
Sebastian: what do you mean by data to be validated?
… runtime data?
Josh: yes
Sebastian: not the task for the Playground itself?
Cristiano: right
Ege: multiple things to be done there
TD issue 1044 - somewhat relevant issue for streaming but not exactly
tum-esi testbench might be used for that purpose
Sebastian: maybe it would have been good to have a dedicated empty room for the setting
… but there was logistical difficulty due to the WoT Conference setting
Daniel Peintner
Daniel: discovered some technical issues and problems
… type vs @type
Mahda: good to have another joint meeting with the JSON-LD WG again
Ege: spec problem from my viewpoint
Sebastian: we can talk with Greg and Benjamin again
… can talk with Manu also
Ege: not a new issue, though
Sebastian: we should follow up this
Matthias: same as the @type annotation
… must have a sub class
… if you use a different predicate class
… nicely referenciable
… we need to create a different sub IRI
… external context file
… this could be easily fixed from the process viewpoint
… there are two parts about this issue
… point of instance
… and RDF triple handling
Daniel: need to find the documentation
Sebastian: like we do for Modbus
… need to know the mapping
Erich: types have node IDs
… connecting to a real node on the server
… need to have an actual namespace to be used also
Daniel: should be fixed by us
Sebastian: should have an issue about node-wot
… OPC UA has its own pattern
… should handle the namespace too
Erich: let me show something...
… (shoes "OpenAI auto-generated WoT TD file" slide)
… maybe there is an error here
(around "opcua:type")
Erich: this is a map for
Matthias: what is the definition of "opcua:type" here?
… must be agreed on somewhere
Erich: that is a global definition
Matthias: using inbound information would be problematic
Erich: this is an OPC UA companion spec
… uploaded to some cloud server
… it's loaded dynaimcally
… in this case, the type is being referred to base on "http://
Matthias: all the mapping detail to be exposed to the TD
Daniel: mixing opcua and modbus is also weird
Erich: this syntax for "opcua:type" can be decided
… based on the OPC UA companion spec
Matthias: what would be the bridging ecosystem?
Erich: how about adding "@type" here?
… and array for multiple "@type"s
Erich: (shows the OPC Cloud Library)
… (and its Swagger interface)
Matthias: need to have a semantic representation
… has to be a peer again
Erich: we could specify the instance in the form
… the flow now is OK
… when we had the discussion, the server react differently
Matthias: some resolution to be done
… if it's not easy to handle dynamic binding, you can automate it
Sebastian: realistic to generate TD automatically?
Erich: for binding?
… you could do that
Sebastian: but very expensive process...
Matthias: you need to convince the customer
… and get them onboard
Erich: would be difficult...
… used to work with an automotive company
… it's dangerous to do this
Sebastian: time check
… tx for your feedback, Daniel!
Matthias Kovatsch
Matthias: support for a sleeping device
… a battery powered device working for 5 years
… hard to expect those devices are "ON" always
… opportunity to get connected every 10 mins, for example
Salvatore: KNX devices?
Matthias: TD to describe the devices
Salvatore: let's think about a sensor on the KNX side and a switch on the WoT side
… who would be sending the command?
Matthias: central logic could be handled somewhere
Salvatore: someone to translate the data?
Matthias: you need more things to consider
… all the media types to be known
Salvatore: can imagine some KNX device which is not designed for ETS
Matthias: then Secure Schemes for OSCORE and SPAKE2+
… security bootstrapping
… how to set it up?
… key configuration to be described
… combinations with different security bootstrapping mechanisms
… then Discovery
… binding to existing ecosystem discovery mechanisms
… a the moment, mDNS is popular
… service to be recorded
… then additiona findings
… network configuration for TBR SLAAC, prefix delegation and DHCPv6
… dual stack DNS: mDNS/IPv4 prevents mDNS/IPv6 resolution
… then
… TD semantic annotations: KNX information model to BRICK and ??? (gaps)
… BRICK is growing
Sebastian: question about sleepy devices
… would expect the driver manages some cache
Matthias: it's an impact for applications
… common recommendation to be clarifed
… linear back up would not make sense
McCool: would like to security briefly
… modular security scheme
… need to write a schema
… can see whether we can bind that or not
… if we want a new subscription mechanism
Matthias: yeah
… independent security setting would be nice
… but hard to combine static model and dynamic model
… need some consideration
McCool: have to reopen the WoT Discovery discussion
… but there is a binding issue also
Cristiano: also sort of work within academia
… protocol with LORA
… you can get connection with one devce
Kaz: so you suggest we look into LORA, etc.?
Cristiano: right
David: would like to see our suggestion
… sounds like pretty straight-forward
Kunihiko Toumura
Toumura: lessons learned
… TD and its directory are good for consolidate onboarding knowledge
… using Web browser as a Consumer, we need some workaround toaccess the properties
… there are various difficulties in connecting the remote VPN vs local network
McCool: regarding the human readable annotation
… useful to encourage people to have TD for humans and also AIs
Sebastian: would involve the Web browser vendors more
… some hope we can get reviews
Matthias: don't think only about the machine side
McCool: let's involve the browsers
… various context about HTTPS
Matthias: played around localhost name
… discussion by the IETF ANIMA WG
Cristiano: node-wot could handle the localhost name
Matthias: if you have something hosting the localhost name
Cristiano: would work on the possible implementation
… we can do it by default
Luca: .local is not fully supported
… you have another issue to handle the browsers
Matthias: people can write an application to bypath the problem
McCool: another approach is using the IP address
Matthias: that's not a big hurdle
McCool: we have some possible solutions
… and can give recommendations
… but I think mDNS is working
… then using a static IP address would be another option
… in various situations, mDNS doesn't work
Sebastian: would suggest we handle one more report before lunch?
… or need to be on time?
Erich: yeah
Sebastian: then let's go for lunch
… (shows the agenda again)
14:00-15:00 Plugfest Summary (II/II) 15:00-15:30 Discussion around DTDL and WoT usage at Microsoft 15:30-15:45 Coffee break 15:45-16:15 Topics around Scripting 16:15-17:00 Thing Description and Protocol Bindings 17:00 End of day
[ lunch ]
Mahda Noura
<kaz> Mahda's report
Mahda: For me, the setup I had for the plugfest was testing the Siemens Web of Things servient
… was interesting to investigate potential issues
… with MQTT, it was working well
… but with OPC UA, it did not work as well, it worked with node-wot, with sayWot!, I was able to see the properties, but I was not able to read it
Daniel: We did not really have time to investigate the issue
… might be because we had one property that could only be read and one that could only be written to
Mahda: The property that was readable was working, but I did not have time to look into it
… also tested it with BACnet
… since sayWoT! is not supporting BACnet, we tested it with HTTP interface
… noticed that sayWoT! is somewhat unstable
… syntax issues, need to communicate that to the development team
… also there are some expectations regarding object encoding which did not work
… I was wondering whether this needs to be defined in the TD
… does the structure need to be defined in the TD?
Cristiano: Generally yes, but if it is just an object, then it should work
Mahda: The server was always complaining about an invalid object
… sayWot! expects an encoding of an object within another object as string, with strings and numbers it worked
… with regard to interoperability issues, we encounted the JSON-LD issues that we discussed before
… also the CoAP sleep time issue
Sebastian: Was the interaction with KNX sometimes successful?
Mahda: It did not work at all, as sayWoT! expected the devices to be always on
… did not fully work even when Matthias enabled the always-on mode
… I am also working on an LLM-based knowledge graph implementation
… noticed that the LLM is not providing really helpful descriptions of ontologies, with HTML and other tags included in the output, should discuss whether we can improve here
McCool: Should be easy to strip out the tags
… same applies to ReSpec tags
… could also convert them
Mahda: Tags were not that much of a problem, the descriptions are not as accurate
McCool: Can make the ontologies more LLM friendly
Ege: Problem might go away when the tooling improves
McCool: Might also improve the human-readability
… for AI, we probably should also improve the human-readable web version
McCool: I had this problem for a while
… we have the descriptions in the TD, unclear whether this is for the end user or for the developer
… need to clarify this and also provide the purpose, might provide different kinds of descriptions
Ege: Comments vs descriptions
McCool: AI is somewhere in between users and developers, need to make sure that the descriptions serve both
David: We worked on hundreds on TDs with AI, noticed that the documentation is really bad generally
… highlights how important the documentation is, otherwise the AI only comes up with total gibberish
… one thing I did was when there were a lot values that I wanted to show up in the result, was prompt engineering and indicating that the "payment" for the AI depends on the result
McCool: Maybe we need a separate meeting to talk about the AI topic
Sebastian: There was also a breakout session during TPAC, right?
McCool: There were several, but not on this particular topic
… potentially, JSON-LD could be used for this as well, as it represents a knowledge graph, as Mahda mentioned
… other aspects concern ontologies, problem is that AI is unreliable
<McCool> (AI is unreliable, but if we use it to generate content e.g. JSON-LD that can be validated, we can mitigate this)
Erich: Some it was already covered before, but my experience on the plugfest was that the expertise was very high
… what surprised me a bit was the variety of applications that were being shown
… shows how flexible the technology really is
… I really think that we see wide adoption and a critical mass
… I increasingly hear from customers that they already know Web of Thigns
… regarding the things to improve, we can definitely figure out the network issues before the event
… also got the feedback from a user who was wondering why it takes so long, but standardization just takes long
… and adoption takes even longer
… and takes longer than the average term of an executive
… you can always invent something yourself, but then you don't have interoperability
… (mentions example that highlights the importance of teams vs individuals)
… this community is awesome, Salvatore already solved a BACnet problem I was encountering earlier
Sebastian: I have to say that the network worked last week, but apparently all the things brought it down
McCool: We can definitely learn from this, maybe we need to do the setup on the saturday before
Sebastian: Apparently, there is also a bandwith problem, the network in Siemens is not designed for this
… we will have a call with the network team and hope that they will improve it
… as this will probably not be the last time we will have such an event
Kaz: In any case, we probably should become better prepared even earlier
Erich: I would like to have such an event every year, would even be willing to host it, to give the community a boost
Sebastian: Before the pandemic, we actually did this type of event every six months
McCool: Should prepare a VPN bridge, and test it in a couple of months
Kaz: Note that there is going to be TPAC in Kobe(?), Japan, in November
Jan Romann
<kaz> Jan's slides
<Jan Romann is showing its result>
Jan: worked together with Luca Barbato
<McCool> (think having the F2F in Nov this year was an outlier, we should aim for the early summer next year, e.g. May/June - I said July, but many can't do that for vacation reasons)
Jan: worked on Rust no_std applications for microcontrollers (ESP32)
… interact with node-wot, TDD, and KNX
… there was some issues:
… identified some bugs in dart_wot and domos TDD
<Jan shows an issue in the TD repo #1780>
… there was also issues with the OPC UA TDs, causing discovery to fail
Erich: it is not easy to parse TDs if there multiple options of, e.g., being a string or array of a string
Daniel: this is what JSON-LD allows
Erich: we should think about to limit this
McCool: TDs should be validated before used
Luca: TD is not a flat JSON
… JSON-LD force to do additional processing
… if you build your own JSON parser, you can deal with it
… with the most Things you can use simple JSON parser
Kaz: please upload the slide
Jan: created a PR
McCool: there are multiple issues which we need to consider: array, name values, default values, inline definitions
SEBASTIAN: please create an issue within the TD repo to talk about this issue and to make decissions
Jan: we should not throw away a whole TD if there, e.g., one action is not working
<McCool> (validation may also need to fetch TMs - is a TD considered valid in TDD if it is not consistent with a TM it links to?)
Jan: interaction with the KNX IoT devices via CoAP was unreliable
… binding template should support indicating non-confirmable request and "sleep schedule" pattern
… no_std with Rust was challlenging
… there was no much progress
Luca: if would have more time such as one week more, we would reach better result
Kaz: The sleeping device discussion made me think about keep-alive
… we need more use case discussion on this in general
David Ezell
<kaz> David's report
David: We came to figure out whether our system would work at all
… to give an example, in Europe all gas pumps are using a standard called LONWorks
… we first tested out RESTful services
… for a long time I thought that WoT can replace
both LONWorks (Europe) and two-wire protocol (US), also called
current loop protocol.
Of particular interest are next generation EV Chargers, like the
Wayne PWR, designed to fit in with the existing estate of fuel dispensers.
… it's very exciting for us, as we only have greenfield devices
… in the beginning, we had a very simple TD
… but we ended up in an echo chamber of our own precautions about which protocol to use
… we wanted to automatically generate tests and documentation
… I think we can something like that here
… all of our systems are edge systems, but we are moving toward the cloud
… we might move to WebSockts at some point
… we are probably not going to use MQTT
… we are having some restrictions, in particular PoS systems can call out but cannot accept connections, that are applying to credit card payments
… the question is how all of these message choreographies are going to work
… we are using SSEs at the moment, complicated but it works
… we need to make a lot of decisions about security and transport schemas
… we agree that OAuth 2.0 is the gold standard, but the question is who runs the service
… we are using the $ref approach, using a macro and a preprocessor, the question is where a definition came from, however
… we are using AJV for validation, which works really well for us
Erich: There is one part of me that says that you should talk to Siemens, also you should rather consider charging stations instead of gas pumps
David: There is a charging system that looks like a gas pump
Erich: Regarding the missing charging station link that loos like a gas pump, this doesn’t actually exist yet but we would want to make this with WoT.
Sebastian: This protocol is quite similar to OPC
Erich: There are regulations that are built into the OCPP standard, this screams for WoT
David: Open Charge Point Protocol is maintained by the Open Charge Alliance. It allows control of ‘Charging Stations’ from ‘Charging Station Management Systems.
Erich: I am surprised that you chose REST in the first place
… you do have a REST server in every gas pump now, right?
David: Not in every pump
… Europe is moving faster in this regard
Erich: There is now the regulation that all EV chargers need to support electronic payments, since people don't want to download a specific payment app
McCool: What is your feedback on ip cameras?
Josh: Due to the network but it did not work but it worked in my computer
McCool: we should get that information needed to set up video streaming
… it should be very relevant in retail, like detecting people
David: You are 100% right. We had a demo some time ago but you could only see it in their dashboard.
McCool: Frigate can be used for this kind of purposes. Will get us 90% of the way
… we will follow up on that
Cristiano's Negative Comments :)
<kaz> Cristiano's report
Cristiano: for us it was important to send data to the cloud. The network was a slowdown factor
Cristiano: there wasn't enough time to show demos. People had to go back to the conference
Ege: people had to grab coffee etc. and did not go to the demos quickly
Cristiano: it would have been nice to know that there would be monitors
… We brought monitors ourseles.
… a longer introduction round would have been nicer, explaining the available TDs
… showcasing room vs hacking room would have been nicer
… we found that we needed to disable validation of packets.
… modeling data is tricky. The data modeler should think of the consumer and make it easy for the consumer application
Josh: we modeled string but then the data that came was number
McCool: The consumer should be flexible but the thing should be strict
Cristiano: transactions as an event would have been a better experience
Cristiano: sharing links of TDs was easier than TDD
McCool: a simple html that shows the list of TD links would improve the situation a lot
Cristiano: we noticed some errors in node-wot like longpolling giving events twice
Cristiano: Also Vignesh needed MQTT over ws
<McCool> (created issue for renderable landing page for domus TDD: https://
Daniel: I think we can organize "tours" of demos
… that would also save the pitching time
<McCool> (every ten minutes have a bell to move to the next demo?)
Roman Binkert
<kaz> Roman's report
Roman: it was really nice to have physical meetup
Roman: sadly lost time fixing issues
… longer Thing pitches would have been nice and also showing if a Thing is available or not
… like it is waiting for someone to interact with
… not many people visiting, only at the end yes but then they had to go to the talks
… it would be nice to have a standardization on linking the real and digital version of the Thing
… data streaming would be also nice
McCool: we should consider the link relation type. Both are services, one is real and the other is the digital counterpart
McCool: Also I want to follow up with some people
David: starting at 10am would help
Ege Korkan
<kaz> Ege's report
Ege: I did not really have a demo, but I observed some interesting stuff
… with the network, I agree that there were some issues
… with Siemens, we did not have the ability to really connect to the network
… before, we had a Plugfest at the University, which allowed us to use any port, without many restrictions
… not sure whether this is still possible with TUM, but it should be
Erich: At Microsoft, we have totally different network for our labs
… as an alternative, you could also use a 5G router and set up a WoT network with that
<McCool> (issue created for "Standardize mechanism to specify a Digital Shadow": https://
<Zakim> dezell, you wanted to talk about initial questions
Ege: We actually had a router with a telekom SIM card, but that also had connectivity issues within the building
<McCool> (maybe use a "real computer" rather than a Pi for the VPN bridge?)
Ege: regarding the RPi for the VPN, it was probably not powerful enough
… should get a more "beefy" one maybe
McCool: Or maybe a "real computer"
Ege: Regarding, the plugfest preparations, what we discussed before the plugfest did not really materilize
<McCool> (maybe we should rotate seats every half day?)
Ege: instead, it was much more organic, with spontaneous collaborations
… I was also talking about this with Salvatore with regard to BACnet plugfests, they do the plugfest with this goal, also with different networks that are planned in advance
… could be one source of inspiration
… but for this to work, people need the stuff of the others beforehand
Salvatore: In BACnet, people do not need to know the details of the products of others, as all products are being certified on the basis of profiles
… so that you know what you can expect, as everyone needs to specify the device profiles beforehand
Josh: It speaks about the power of the standard if you don't need to specify details beforehand
Ege: So maybe some more planning beforehand would be nice, and then based on that spontaneous collaboration can happen
Ege: I was not able to really work on initial connection and other topics
… would also be nice to have more time for showcasing
… people were mostly focused on creating a demo, though, so they did not really have the time to test out new features
Ege: It was really nice to see CALA Laster and Müller-BBM
… the person representing Müller-BBM proposed a new binding for NATS
… which is used by a lot of companies, including Siemens and Schäffler
… there is a lot of companies that are using it
… it is quite similar to MQTT
Sebastian: I also suggested to him to create a binding
… he will take inspiration from Modbus etc.
Ege: I also mentioned to him that he should suggest that to NATS
… it was not as obvious how easy the integration was in the end in general
… I think it was similar with Mahda, Ganesh, and the person from St. Gallen
Mahda: It worked quite well, but they left a bit early, and then they gave their devices to Kai
Discussion around DTDL and WoT usage at Microsoft
Erich: (Explains how Microsoft came to using OPC UA together with Web of Things)
… OPC UA has an asset creation and deletion API where you can upload/remove a WoT file which can be used for onboarding and mapping WoT properties to OPC UA nodes
… that can then be used for OPC UA connectivity
… the companion specification has been published earlier this year
… I heard from Siemens that they implemented it but I have yet to see it
Sebastian: It was actually shown at the plugfest
Erich: What does that mean for our architecture? We have a southbound interface for edge apps and a northbound interface based on MQTT and we integrated that with the WoT connectivity interface
… it is now integrated with Kubernetes, the system has been renamed to Connector for OPC UA (?)
… there is a new release pending
… should be released sometime early next year
… then we have WoT connectivity in both our products
… Azure IoT (?) is more focused on consumers, while Azure Industrial IoT (?) is more focused on businesses
… to be scalable, you want some kind of gateway solution, which you could replace if you need to
… both solutions support OPC UA and will WoT some time soon
… in the next binding meeting, we can discuss the how to use the @type for the OPC UA binding
<kaz> Digital Twin Consortium's GitHub repo/
Erich: Now to DTDL
… you can see Web of Things in this repository's README
… we have a conversion tool to convert DTDL to WoT TMs
… we were able to convert all of the 150+ models to TMs with this tool
… then we have a specific document that specifies the mapping between the two description formats
<kaz> ManufacturingOntologies
Erich: we worked on this for over a year, no changes to the WoT specification were needed
Sebastian: There are just some inputs for the TD specification, like the comment vocabulary term
Ege: This relates to what Michael McCool said earlier
McCool: I think we need something for a developer
… we should discuss this, we should add another field for that role and make the two roles destinct
… I am surprised that you did not find any gaps in DTDL
<kaz> DTDLv3 and W3C WoT Thing Model 1.1 Comparision
Erich: The thing that DTDL never had were protocol bindings
… so I said to the people at Microsoft that we should not reinvent this
… I was able to tell them that we are not abandoning DTDL, only that WoT is more capable
… there were two features that did not exist in WoT
… but Pedram found a way to describe them using JSON-LD anyway
… could be an option to add these terms later, but for now a WoT consumer would just ignore them
Erich: The most important ontology that we described with DTDL was ISO 59, and that worked fine
… I cannot mandate the use of WoT at Microsoft, I can only recommend it
… but I will recommend to never use it again (laughs)
McCool: What I see is that DTDL has comment
Erich: People tended to use the same string for both
… in the repository, we have an upload tool to create processes etc.
… it has an Excel plugin, which people just love
… all of this is open source, it is free to use, is a very popular repository
… it is a good conversation starter, helped us fill a gap in the market
McCool: Let me ask: Is there an interesting ontology to look at here?
<kaz> ManufacturingOntologies
Erich: You can go to the ontology page at Microsoft Learn
… there you have ontologies for smart cities or manufacturing and map them to WoT as well
McCool: Kaz, take note
Kaz: There are actually a lot of smart citiy ontologies
Erich: That is true
… but you could convert all of these ontologies that are all standards-based, so using these would be a great win for you
<kaz> TD issue 2060 - Standardize mechanism to specify a "Digital Shadow"
McCool: Regarding digital twins generally, we had this in our charter and wanted to explore this
… after our earlier discussion, I created an issue regarding digital shadows
… is there anything we could use here?
… for example, a tool that uses a TD to create a shadow
Erich: Having such a tool would be very nice, converting from JSON to JSON-LD is relatively easy
(A tool from AWS is mentioned)
Kaz: We should talk to AWS, Amazon is a W3C member
Erich: Regarding DTDL, there was some work on spatial data, that could be used
McCool: Would be happy if there was a tool that we could build upon
… I think there is geospatial and geoSPARQL
Erich: The one I was thinking about was GeoJSON, which is an IETF RFC
Ege: The company of Cristiano used it for their demo yesterday
Cristiano: Yeah, it is quite easy to use
McCool: We had discussions in the past, question what to standardize here, should talk about this as an incubator, this is not just next-charter thoughts
Kaz: I just wanted to mention that WoT itself is already a kind of a mechanism for digital twins, so should clarify the requirements for what we need to do here
Ege: At TUM, we dealt with something like this, also with regard to state, need to link to other documents
… this could blow up the complexity
McCool: Part of the problem with digital twins is that there, specifically for the collaboration with DTDL. are many different definitions
… I think we should not put everything in the TD but leverage the linking feature
… but even then, we should rely on existing resources, does not necessary need to be a standard, could also be a comunity group activity
Kaz: Just a very quick questions: Are the slides available?
Erich: I will send them to you
McCool: Just wanted to mention that it is great that you are contributing so much
Sebastian: I have to second that
Erich: You are making my work a lot easier, you can consider Microsoft an active part of the working group although I am not able to always participate
Agenda for Day 2
Sebastian: Let's have quick look
… we will start at 10 AM
… in the morning session I would come to the Scripting and TD topics
… then we are going to discuss Use Cases and Requirements, then we will have the coffee break, talk about marketing and then about liasons
… we can spend some time on OPC, we have already slides
… after lunch, we will also have the coffee break
Kaz: Is it possible to move ECHONET before lunch?
Ege: We can swap with marketing
Salvatore: I have a similar problem
Sebastian: Then we can just swap the two liason sessions
… (edits the wiki)
… (shows the latest version)
… question is whether we will have meetings next week, also about the frequency of the plugfest
… does this plan look good to you?
(The group agrees)
Sebastian: (explains what the plan for dinner is tonight)
[adjourned]