- 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