Meeting minutes
(Some more photos from the WoT Meeting Day 2 are available online (Member-only))
Joint discussion with SDW
<McCool shows today's agenda>
McCool: I will start about WoT then we will go to Spatial Data on the Web
WoT Overview
<McCool shows WoT slides>
McCool: Thing Description build a bridge about What you can do and How
… we have a lot smart building systems using WoT
… there is a relation to spatial data
… e.g., for spatial data discovery use cases
… there are many WoT discovery mechanism such as DND-based, using DID documents, or simple well-known URIs
Ringo: How about RFID? There are use cases for the Digital Product Passport
Sebastian: it is covered by direct discovery mechanism
Sebastian: lets postpone this discussion to our later session
Spatial Data Issues in TDs
McCool: location data may be static or dynamic
… use links to identify source of data
McCool: or, location data can have various representation and options
… can be coordinate-based, semantic or optional data
Rob: we have timestamps to the positions
McCool: yes, time of last update is important
McCool: we should not make it complicated in the TD
Kaz: we need semantic annotation and mapping for advanced coding like GeoPose. Also probably need for managing the history of the movement (of the devices and the users)
McCool: we need to identify common use cases
… we have some example TDs using geolaction
<McCool shows an example>
… example uses schema.org
… another example uses links that provide specific location information
<examples are linked in the slides>
<Rob-OGC> can we see the json-ld mapping to ontology for location objects?
<Rob-OGC> i.e. how far from GeoSPARQL are we and how do we bridge the gap?
Sebastian: there are also indoor location systems
<Rob-OGC> OK - lets see if we can get needs or testing into next GeoSPARQL update... or define an intermediate
Rob_Warren: a device comes with a barcode with own serial number
Rigo: Phil Archer has a good solution for this
<rigo> ... by creating digital link to transform QR codes as an example of how to transform very constraint numbers into a URI that can then be consumed by the system. The Specification should just mention that possibility
McCool: here are some next steps
… identify geospatial information
… find TDs using Geospatial search
Kaz: we need to identify use cases, e.g, such as inside and outside geo locations
Rob_Warren: we should also consider BIM, used in buildings a lot
Kaz: we should talk with the LBD CG guys about that point
McCool: we should be exchange with ETSI ISG CIM
<kaz> McCool's slides
McCool: we have a simple liaison. There are bi-weekly meetings.
SDW updates
Rob: SDW re-charter, GeoDCAT, Integration of OGC and app domains
… would like to see methodology to handle the geolocation data appropriately
… we can support application domain models
SDW WG recharter
Rob: joint work by W3C and OGC
… purpose is allow W3C and OGC to collaborate in spec development
… original charter was mainly for SSN aligned with OGC/ISO Observations and Measurements
… derived basic ontology, SOS
… the charter has expired
… then rechartering needed
-> 2024/sdw-wg.html
… work with OGC standard WG to jointly evelop, maintain and promote geopatial Web standards and geospatial profiles of more general Web standards
… would publish SOSA/SSN, DCAT, GeoDCAT
… bunch of other things
… how might WoT relate to connected systems - OpenAPI version of "Sensor Web Enalement" model
-> link@@@
… note on alignment? JSON-LD contexts? Testing?
… might be of mutual interest
… then can align better around Sensor Things API v2
… also Digital Twins space
… City GML and Digital Twins WG
Bert: quick update on the Charter
… horizontal review required
… will start it right away
… then W3C Member review for 1 month
… then can start the WG again
… don't see anything problematic within the draft Charter
… but the procedure would take some time
McCool: joint work with OGC again?
Bert: yes
McCool: wondering about WoT's joint work with OPC UA
… any other SDOs you collaborate for geo info?
Rob: this is specifically with OGC
Sebastian: want to understand whether you handle building topics or not
Rob: absolutely considering it
… not currently, though
Rigo: relationship with SAREF
Rob: good question
… what we do is talking with the SAREF community
… some priority work on W3C and OGC
… inteoperability with SAREF and NGSI-LD to be considered
… should be aligned with each other
… please help us by commenting
Kaz: during the Smart Cities breakout, Kasuya-san mentioned they were working with some SDO about building information
… so we could work with them too
GeoDCAT
Rob: DCAT doesn't define any specific profiles or profiling mechanism
… GeoDCAT is a WIP of a Geospatial Profile
McCool: would talk about Profile
Rob: no inter-Profile mechanism
… but may need some mechanism for DCAT, etc.
… EU already publised a GeoDCAT-AP
… but Europe-centric and limited in scope
… GeoDCAT will be a core and register of extension profiles of DCAT
<Zakim> rigo, you wanted to talk about GeoDCAT-AP
Rigo: will talk with EU guys next week in Budapest
Rob: we have contacted them already
… test case for compatibility from our viewpoint
… (shows a diagram "DCAT - a family of profiles")
… (blue node is GeoDCAT implementation using OGC)
… (green node is OGC BUilding Bloks for STAC)
… (red node is OGC API Records)
… (then another diagram on "W3C foundations for domain models")
… with demeter, lliad and 4d@@
… (then diagram on "Systems of Systems View")
… semantic traceability
… whole bunch of challenges of architecture
… [Aligning and learning]
… want to get aligned with WoT TD
… [Building Blocks]
… better data model and API design framework
Rob: [Traceability & Transparency]
… copy.paste.modify
… invent your own
… [Scalability]
… centric approach where specs work together
… systematically
… [Complex Applications]
… [Extended NZ example]
… JSON, JSON-LD and RDF/TURTLE
… [Testing]
… reusing modules in other OGC projects
… significant merit with the process
… [Rules]
… complex, reusable, and automated
… define SHACL rules
McCool: would like to come back to the NGSI-LD collaboration
… and generation of SHACL rules
… also semantic interoperability
Rob: [Future Proofing]
… more APIs to b applied
… collaboration needed
… with OGC engineers
… we're definitely thinking about that
McCool: ok
… any possible collaboration with ETSI/FIWARE about NGSI-LD?
Rob: definitely
… [Quick example]
-> @@@link
… (shoes the Web page)
… External Schema (Smart Data Models)
… OGC features via GeoJSON
… related to one of the FIWARE activities
… (then shows the Schema)
… JSON-LD context
… (the example code can be shown as JSON, JSON-LD and RDF/TURTLE)
… joint work is critical
… compiling building blocks
… the process of understanding the set of components
… there is a GitHub also
… we can have much more explicit dependency
… important to make the technology neutral
Kaz: clarification questions
… could please provide the slides later?
Rob: ok
Kaz: there are GeoDCAT-AP by EU and generalized GeoDCAT by SDW WG?
Rob: right
Rigo: our discussion with FIWARE/ETSI on NGSI-LD
… there are some mismatches but they would like to fix it
<Zakim> rigo, you wanted to ask whether they have already contacted FIWARE to have the context directly into the FIWARE structure?
Rob: please consider to give feedback
<rigo> rigo: please consider raising the JSON schema issue with FIWARE.
McCool: we, WoT WG, will have the NGSI-LD liaison meetings
<rigo> McCool said that this also concerns the API and when to move from raw data to JSON schema to JSON-LD. It is ok to inject that into the discussion with FIWARE
McCool: simple action might be setting up a joint meeting including SDW
McCool: what's the timeframe of your rechartering?
Rob: depending the comments we'll get
… but by the end of this year
McCool: would reach out to you about the NGSI-LD meeting
Kaz: so we'd like to invite SDW guys as well to the WoT/NGSI-LD liaison meeting. right?
McCool: right
… would consult with the NGSI-LD guys at the next liaison meeting on Oct 14
… would be good place to get linked up
Sebastian: we have a section within TD about geolocation already
… so need to update it based on our collaboration at some point
McCool: yeah, need to update it
… but note that the section is informative at the moment
… need further input
<rwarren2> Thanks guys.
[joint meeting adjourned]
<sebastian> https://
<EgeKorkan> live slides for the TD part: https://
TD, Profiles and Bindings
Ege: shows agenda
Overall progress
Ege: less features and more getting ready
… resource management on wot-resources
… errata handling
… toolchain and LinkML, breakout session as well
… (shows the huge diagram of the whole toolchain)
… started to use LinkML as the schema language
<EgeKorkan> https://
Ege: Vision
… multiple sources to be consolidated
McCool: question about CBOR
… make sure resources to be frozen
… we should revisit our policy for resources
Ege: resources to be extended in the future
McCool: we can use versioning
… the issue is that the ontologies need to be frozen/versioned to get consistent ids assigned for CBOR-LD
<EgeKorkan> td PR 1969 - WIP: Concrete Versioning Proposal
Sebastian: take over the plan on binding template?
… what about the existing binding document?
Ege: existing binding document would describe the registry
Ege: TD TF is quite active
… working on project management using GitHub projects
Ege: shows the workflow
… so far working well
<EgeKorkan> workflow
Resource management
Ege: next, resource management
… discussion ongoing
McCool: freezing comment of mine applies to the Ontology
Ege: schema too
McCool: yeah
Registry
Ege: then registry discussions
… going into the document here
<EgeKorkan> https://
<EgeKorkan> PR 378 - Registry Requirements Update
Feature discussions
<EgeKorkan> w3c/
Ege: one on reusable connection container
… then data mapping
… and degraded consumption / gradual enhancement
Bindings
Ege: improved CoAP and Modbus bindings
… also new BACnet binding
Sebastian: we have end of Nov Plugfest
… what kind of features to be handled there?
Ege: reusable connection to be got clearer
… additional responses from app viewpoint
… understood better by implementations
McCool: what about OPC UA stuff?
Sebastian: liaison session about OPC UA
… would except first draft for testing
McCool: would be nice to have a few devices ready there
Sebastian: not sure but need servers and clients
<EgeKorkan> https://
WoT week plugfest
McCool: email from David asking about the setting
David: core team here
McCool: new people participating
David: don't know specific IoT protocols but will clarify
McCool: there are Plugfest and Testfest
… adding new requirements is welcome
Kaz: November one is a Plugfest
McCool: still would test the feasibility :)
McCool: also would identify the potential problem with our specs
Ege: potential features to be added
… would make sure implementations are interoperable
Use Case Extraction from Issues
McCool: we talked about the basic procedure yesterday
… would try to discuss some more details today
… what's the use case and what's the requirement, etc.
Ege: ok
… [Use case extraction from issues]
… [Handling future issues]
… (shows workflow)
<EgeKorkan> w3c/
Ege: (excerpt from the above issue 2039)
… people outside can also participate
… topic is returning value
… technical description within the use case
McCool: my wrote "user story" is intended for "why we need that from the user's viewpoint"
… would confirm the value
… what we care is "Why we need this"
Sebastian: not 100% sure about the motivation
… feedback you wrote is accessible or not?
… in addition to the HTTP error code?
Ege: error code + JSON payload
Sebastian: what is the "JSON payload" here?
Ege: depending on the use case
McCool: the question is if the user care
Sebastian: would except the property value as the same data type of the property definition within TD
McCool: endpoint definition property
Sebastian: otherwise it would not be RESTful
Ege: do we need to dive into the detail of this specific use case?
McCool: sorry diving into the detail...
Zoltan: several possible issues here
… if you want to keep synchronized
… one problem is transaction
… some kind of transaction logic to be applied
… on the other hand, device precision to be solved
Kaz: so for today, we should concentrate on what kind of description to be included in each section of the template. right?
McCool: right
… should not dive into the detail
… would look at another example too
Ege: ok
… think the template is not ready to use yet
<EgeKorkan> w3c/
McCool: yeah, need to clarify the problem
Ege: Jan's example next
@link here
McCool: this is the one I used
… connected to the requirements template
… very long section on proposed solution
… related to the test process
Ege: limitation of the spec to be improved
McCool: solution proposal is not main purpose at the moment
… should be split out from the use case template
Jan: wondering if we should revert the solution proposal
McCool: two questions
… capturing UC itself
… then what/how to describe it
Jan: how to handle the description then?
McCool: probably having several bullet points would suffice
… user's problem and motivation first for the use case
Sebastian: there is a past work on security and privacy
… need to consider those points too for wide reviews
McCool: let's not think about for today
<EgeKorkan> w3c/
Ege: another one from Luca
… around Profiles
… written from scratch
… then another one from McCool
McCool's slides on Requirements
McCool: (shows slide 4)
… three items: Persona, Capability and Purpose (=Who, What and Why)
McCool: original use case example on slide 5
… and rewritten one on slide 6
… all the affordances of TD use the same security scheme
… then Requirements example
… those are about TD Producer
• As a producer of WoT TDs, I want to be able to specify simple security schemes inline so that TDs are less verbose and easier to write in simple cases. • As a producer of WoT TDs, I want to be able to depend on security scheme parameter defaults so that TDs are less verbose and easier to write in simple cases. • As a producer of WoT TDs, I want the “no security” scheme to be the default so that TDs are less verbose and easier to write in simple cases.
McCool: some user story connected with what we should do
… still implementation-oriented, though
Ege: who would write what, submitter or TF?
McCool: very carefully write a better example
… at least the title is not enough
Kaz: the second line is functional requirement and the third line is technical requirement. right?
McCool: actually, the first line is persona, 2nd line is capability, and 3rd line is purpose
Ege: it mimics value proposition
… but you've already written requirements by use story
McCool: we need a document describing the process
Kaz: in that case, I'm OK with starting with this proposal
… but would suggest we explicitly mention "Persona (who)" for 1st line, "Capability (what)" for 2nd line, nd "Purpose (why)" for 3rd line
McCool: could be a 3-column table
Ege: like this formulation
… good to start with for spec editors
… will take over
Relationship between Bindings and Profiles
Ege: don't have Luca or Ben here
… so just briefly
… (shows an example of Bluetooth as a profile)
… (then Luc's diagram on "How much can we constrain?")
<EgeKorkan> wot-profile Issue 416 - Discuss All the layers profiles can cover
Ege: profiles provide "out of box"interoperability warranties
… Bindings extend TD, while Profiles restrict TD
McCool: we might be going to use extension vocabulary based on OPC UA, etc.
… note that Binding is informative while Profile is normative
Sebastian: it would be confusing if features not included in the core spec are used by Profiles
McCool: need to be careful about what "restrict" means here
Sebastian: for example, there was discussion about asynchronous actions defined by Profile
McCool: limitation on how much Profiles could handle
Kaz: I think we're kind of sure about Binding as extension for TD
… but not really sure about Profile as restriction for TD
… for today, I'd suggest we should clarify what "restriction" for Profiles here means
<koster> We may need semantic model bindings
Ege: (mentions a possible "Profile" within the Matter world)
… but we need some more discussion including Luca, Ben and Koster
McCool: one issue here is the language here on the slide is a bit too strong
… for example, guaranteeing the out-of-box interoperability is too much
… the problem here is that we'd like to cross-protocol interconnection
Policies
McCool: would like to open up another one
Issue 1166
<EgeKorkan> TD PR 1969 - WIP: Concrete Versioning Proposal
Ege: there is a PR for TD repo also
Kaz: do we want to talk about this now?
Ege: let's talk about IE policy instead
Issue 1171
wot Issue 1171 - [Policy Proposal] Invite Expert Selection Procedure
McCool: not clear here is the decision process
Kaz: would suggest we start with the description on what we've been doing
… asking the IE applicant to join the main call and make presentation
… also what that person could make contribution for
McCool: would add "may be in response to a nomination"
… also take into account the group input
… then Chairs and Team Contact must have consensus
Kaz: I'm ok with the updated basic policy
They are invited by the chairs and the team contact together. This may be in response to a nomination. They should show their expertise in a call, e.g. making a presentation They should explain their commitment to WoT deliverables and meetings Chairs and team contact must have consensus to accept an IE, taking into account the group input
David: should be careful about the IP policy
McCool: should we make a resolution about that today?
Koster: would make a resolution during the next main call
Issue 1117
wot Issue 1117 - [Policy Proposal] Roles and responsibilities within the WG/IG
McCool: W3C has guidelines for roles
McCool: maybe guideline roles for TF leads is missing
Kaz: TF Lead's roles should be similar to the ones of Chairs
… but we need to explicitly redefine that
… that is McCool's point, I think
McCool: right
Closing
Sebastian: good discussions including joint meeting with JSON-LD and SDW
McCool: yes
… should create GitHub Issues based on the discussion and add label, e.g., "TPAC followup"
… otherwise, thanks a lot for your participation!
<jets> jets: thank you for having us!
Kaz: including the remote participants
[WoT meeting is adjourned]