<kaz> scribenick: glomb
Link Smat -> Linksmart
XML path -> JSON path
Latest version has JSON support
<McCool> add link to XPath: 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
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> https://www.w3.org/TR/xpath-31/
<McCool> look at comparison table in 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?
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
<McCool> 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> Farshid gave a comment to issue 18
<kaz> [adjourned]