- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 11 Mar 2025 00:03:23 +0900
- To: group-wot-ngsi-ld@w3.org
- Cc: public-wot-ig@w3.org, public-wot-wg@w3.org
available at: https://www.w3.org/2025/02/17-wot-ngsi-ld-minutes.html also as text below. Thanks a lot for taking notes, Michael Koster! Kazuyuki --- [1]W3C [1] https://www.w3.org/ �V DRAFT �V WoT and NGSI-LD 10 March 2025 [2]Agenda. [3]IRC log. [2] https://www.w3.org/WoT/IG/wiki/WoT-NGSI-LD#March_10,_2025 [3] https://www.w3.org/2025/03/10-wot-ngsi-ld-irc Attendees Present Dave_Raggett, Franck_LE_GALL, Frederic_LE, Kaz_Ashimura, Martin_Bauer, Michael_Koster, Michael_McCool Regrets - Chair McCool Scribe mjk Contents 1. [4]Minutes review 2. [5]Review Proposed Use Cases 1. [6]McCool's Use Case 2. [7]Martin's Use Case 3. [8]AOB Meeting minutes Minutes review <kaz> [9]Mar-3 [9] https://www.w3.org/2025/03/03-wot-ngsi-ld-minutes.html McCool: working on use cases Martin: also working on use cases McCool: any objection to publish? �K no objection, approved Review Proposed Use Cases McCool's Use Case <kaz> [10]PR 14 - Define Onboarding Use Case example [10] https://github.com/w3c/wot-ngsi-ld/pull/14 McCool: PR #14 Defining onboarding use case McCool: this PR review can be used to agree on a template McCool: (review the use case md document in the examples directory) <kaz> [11]rendered MD [11] https://github.com/w3c/wot-ngsi-ld/blob/b680316fe2dc801d41ecc2928a44b3b6a00009b4/examples/onboarding.md McCool: the format includes a user story: as a (stakeholder) I need (a feature) so that I can (do something of value) , in other words who-what-why �K also includes a section for design alternatives and a section for applications McCool: (refactoring the document headings) �K how does it look now? Martin: looks OK <kaz> [12]updated MD [12] https://github.com/w3c/wot-ngsi-ld/blob/d0452640b140d95fb758f19144f3cf74f253449e/examples/onboarding.md McCool: (explain the use case) McCool: how can we import TDs and use them? �K the primary use case is to describe devices and services �K TDs are linked data; it's important to re-export TDs (northbound API) �K We will use TDs to onboard devices �K there are 3 options here �K one is direct graph extension, what is the root of the extended graph? �K another option is to translate TDs into a more suitable format for the graph �K yet another option is through RDF annotation of the TD for connecting the TD to the graph as properties of nodes - similar to option one McCool: ... an example use case is getting real time data from a temperature sensor in a lake �K are there any changes or additions we should make? Martin: the template is fine, the detailed assumptions need further review and discussion �K we need to look at options 1 and 3 for potential mismatch McCool: there are some details we need to prepare detailed examples Martin: the question is how NGSI-LD and TD relate, where NGSI-LD is a description of the thing (the lake) and the temperature (a property) and the TD could be used as a method for obtaining the value of the property �K we can't just add arbitrary RDF to the graph, so TDs are not a good fit like option one �K Option 3 needs some working out �K maybe there is a conceptual problem with the use case Martin: what is a thing and what is a Thing Description? McCool: physical things and software services can be Things in WoT Martin: how do we then map that into the NGSI-LD world McCool: there can be non-device entities in NGSI-LD Martin: maybe entities don't represent network devices McCool: at the high level example, I want to locate a temperature value onto a map �K NGSI-LD and WoT do different things, and we want to bring them together, the question is how do they connect Kaz: the discussion is a good direction, for further discussion we should determine what kind of devices and entities we are looking at, some specific entities and devices Martin's Use Case <kaz> [13]Issue 15 - Use Case: Thing Description for Thing using NGSI-LD API [13] https://github.com/w3c/wot-ngsi-ld/issues/15 Martin: this use case is about the northbound API �K what would a TD look like to describe how to access the thing? McCool: if you already have an affordance to an entity, the TD would describe how to use the affordance Martin: need to construct an example TD, how do I map the NGSI-LD operations in the TD? �K how to use the HTTP binding with JSON-LD content �K We map Properties to NGSI-LD Attributes �K there is an issue in that the API currently returns an entire set of Attributes �K We always send full JSON-LD documents in responses �K There may be a Patch interface possible McCool: another option (2 above) would define a whole new API to mitigate the conceptual differences �K a layer to translate concepts McCool: we should do a detailed design Martin: not clear how links and relationships are used �K we don't have actions per se, use updates of Attributes �K looking into Service Execution, which is more easily mapped to TD Actions �K looking at how to make Service Execution more like TD Actions �K for Events, we have Subscriptions which may map to TD Events McCool: Events and Actions are not described in detail in TD �K but we do have Profiles that can be used to refine the mechanisms Kaz: suggest that we clarify what specifically, Entities, Things, Services, Applications, etc., is being mapped from NGSI-LD to TD McCool: we are running out of time, so everyone add comments to the issue �K also add more use cases now that we have more of a template McCool: The use cases should correspond to northbound and southbound API patterns AOB McCool: AOB? �K reminding that we are meeting every week except for some cancellations �K the time offset jumps back at the end of the month McCool: Any other business? �K Adjourned Minutes manually created (not a transcript), formatted by [14]scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC). [14] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 10 March 2025 15:03:26 UTC