- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 08 May 2020 07:36:04 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/04/27-wot-discovery-minutes.html
also as text below.
Thanks a lot for taking the minutes, Christian!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Discovery
27 Apr 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#27_Apr_2020
Attendees
Present
Kaz_Ashimra, Christian_Glomb, Farshid_Tavakolizadeh,
Kevin_Olotu, Kunihiko_Toumura, Michael_McCool,
Shreekantha_Devasya, Tomoaki_Mizushima, Zoltan_Kis,
Andrea_Cimmino
Regrets
Chair
McCool
Scribe
glomb
Contents
* [3]Topics
1. [4]last meeting's minutes
2. [5]LinkSmart
3. [6]partial TDs
4. [7]Linksmart use case
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: glomb
last meeting's minutes
Link Smat -> Linksmart
XML path -> JSON path
Latest version has JSON support
<McCool> add link to XPath: [10]https://www.w3.org/TR/xpath-31/
[10] https://www.w3.org/TR/xpath-31/
XML Path = XPath
Minutes approved
Minutes from last meeting
Kevin -> invited expert (need to submit application)
Today as guest
LinkSmart
Capture LinkSmart use case as WoT use case
Fraunhofer is W3C member, have not been participant of WoT
Query mechanism based on JSON path
XPath -> W3C spec
Has section about Maps / Arrays
goessner.net has examples for JSON path
Comparison as well
Do we want "Script expression"?
<McCool> [11]https://www.w3.org/TR/xpath-31/
[11] https://www.w3.org/TR/xpath-31/
<McCool> look at comparison table in
[12]https://goessner.net/articles/JsonPath/
[12] https://goessner.net/articles/JsonPath/
Fraunhofer's thoughts: more usable than XPath
McCool: Spec discovery and search
JSON path to be aligned with our discovery spec
XPath is already fixed
Same issue as JSON schema
JSON path maybe more adopted by users
Standardized discovery API -> part of it stand. query interface
-> stand. query language
Look at pros / cons of XPath and JSON Path
<kaz> CSS selector
Kaz: CSS selector as an alternative?
Query mechanism -> support of partial TDs?
CSS selector tied to DOM
Anyhow added to list of possible query mechanisms
Issue 17
Partial TD or part of a TD?
<kaz> Kaz: that is a good question, and so I was wondering
whether we want to have DOM for TD or not
Discussion in architecture and / or TD TF
Should discovery return TDs or IDs related to TDs?
Bunch of hyperlinks instead blob of TDs
JSON offers both possibilities
JSON path
<FarshidT> Example JSONPath query from LS Thing Directory:
/td?fetch=$..href -> gives an array of hrefs compared to /td
which returns an array of full TDs
Need to compare with other query languages
SPARQL is also a W3C stand.
very powerful
Consisting with using RDF
SPARQL 1.1 latest version?
partial TDs
Resolution of April 6th to be precised
JSON path can return part of TD
<McCool> proposal: if the query mechanism supports (or
requires) it, then having the API returning only "part" of a TD
is acceptable
<McCool> proposal: if the query/filter mechanism supports (or
requires) it, then having the API returning only "part" of a TD
is acceptable
RESOLUTION: if the query/filter mechanism supports (or
requires) it, then having the API returning only "part" of a TD
is acceptable
Not partial TDs
Still not clear
Discovery returns either TD or ID (like DID)
<McCool> really meant: query might return full TDs, part of a
TD (which might just be, for example, the id fields, which
might be, for example, DIDs that can be resolved into TDs), OR
the URL of the TD resource in the directory, as known by the
directory service (this may be different from the ID in the TD)
<McCool> ... but, if we know the id, can always use a query to
get the corresponding TDs from the directory
<McCool> ... but note the above would not work unless we
support "part of a TD" being returned
Necessary to enable several discovery mechanisms
Linksmart use case
<kaz>
[13]https://raw.githubusercontent.com/wiki/linksmart/thing-dire
ctory/presentations/thing-directory-wot-call-2020-4-15.pdf
[13] https://raw.githubusercontent.com/wiki/linksmart/thing-directory/presentations/thing-directory-wot-call-2020-4-15.pdf
<McCool>
[14]https://github.com/w3c/wot-architecture/blob/master/USE-CAS
ES/use-case-template.md
[14] https://github.com/w3c/wot-architecture/blob/master/USE-CASES/use-case-template.md
<McCool> it would be helpful if Fraunhofer could copy the above
template and create a PR against
wot-architecture/USE-CASES/smartbuilding-energy-efficiency.md
for their use case
<McCool> note that this is (a) generalized to smart building,
not fraunhofer (b) discovery is part of the use case but not
all of it, and we may have other uses for wot we can document
as part of this use case
<McCool> ... but please just capture your part and we can
iterate to add additional considerations
<McCool> we are now overtime, so probably need to adjourn
Partial TDs / TD templates issue still open
To be discussed in next meeting
<FarshidT> Correct example: JSONPath query from LS Thing
Directory: /td?fetch=$..id -> gives an array of IDs compared to
/td which returns an array of full TDs. Moreover, /td/<id>
returns the full TD.
<kaz> [15]Farshid gave a comment to issue 18
[15] https://github.com/w3c/wot-discovery/issues/18
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
1. [16]if the query/filter mechanism supports (or requires)
it, then having the API returning only "part" of a TD is
acceptable
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [17]scribe.perl version 1.154 ([18]CVS log)
$Date: 2020/04/29 08:35:14 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 7 May 2020 22:35:44 UTC