- 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:30 UTC