<kaz> scribenick: kaz
McCool: typo "rate limit of" to be fixed as "rate limiting"
(fixed)
McCool: approved
McCool: McCool will be not available
Dec 14, 21 and 28. So we'll cancel those calls.
... and the first meeting in Jan 2021 should be Jan 11
Kaz: note that Jan 11 will be a bank holiday in Japan
McCool: right
... we can do Jan 4 and cancel Jan 11 instead, then
<inserted> scribenick: FarshidT
Kaz: FPWD is already released: https://w3c.github.io/wot-discovery/publication/1-fpwd/index.html
<kaz> minor editorial issues (already fixed)
Kaz: there were some minor issues (css, publication date, duplicate ID)
<McCool> proposal: publish the above document as the FPWD of the WoT Discovery deliverable
<McCool> proposal: publish https://w3c.github.io/wot-discovery/publication/1-fpwd/index.html as the FPWD of the WoT Discovery deliverable
RESOLUTION: publish https://w3c.github.io/wot-discovery/publication/1-fpwd/index.html as the FPWD of the WoT Discovery deliverable
<kaz> scribenick: kaz
McCool: cross-referenced issue on
signing
... created for wot-profile
McCool: cross referenced with a TD issue
McCool: (goes through the comments in the issue)
McCool: let's create an issue for wot-discovery as well
Farshid: doesn't LD-proof handle this?
McCool: not exactly
new issue 104 for wot-discovery
Farshid: should they handle it in a canonical way?
Kaz: so we need to define "canonicalized" here. right?
McCool: yes
... adds a comment "Alternative: the "signer" could
canonicalize internally, and this might be better (less
fragile)."
McCool: (goes through the other issues)
McCool: (adds a comment)
McCool: (adds a comment in response to Farshid's comment)
McCool: joint meeting with SDW/OGC expected on Dec 10
Farshid: (explains the examples on how to deal with geospatial queries base on the OTC SensorThings)
McCool: add "Geolocation" label to
Issue 98 above
... (also adds links for "Geolocation" label and "Timestamps"
label to the comment
updated comment including resources for Geolocation ad Timestamps
McCool: in general, SPARQL is
expensive
... problems with federation here
... delegate queries not to be allowed
Andrea: (gives some possible scenario)
McCool: let's think about several
possible scenarios
... let's wipe out what would be OK
... 3. returning link to other directories so a client can also
query them is permitted
Andrea: wondering about the model
Kaz: maybe it would make sense to have some more concrete description on the scenarios 1, 2 and 3
Andrea: ok
McCool: let's think a bit more
... 1. unclear
... 2. a client may do an introduction and get multiple
results, send queries to exploration services in parallel, and
merge the results
... update on point 1
... 1. (limited to delegated/recursive federation, where a
directory queries other directories on a client's behalf)
Andrea: if we stick with SPARQL
federation, the point 1 would be a bit problematic
... SPARQL doesn't allow "recursion" per se, delegated
endpoints must be known in advance
McCool: let's allow SPARQL delegation
for the moment, but add an editor's note regarding the DoS
concern.
... (also adds comments to option 3)
... these links may not be in a TD, so technically may be
out-of-band info
... which would allow us to associate them with a given TD
Farshid: related to 34
Farshid: link section inside TD
McCool: we need some more text to
explain those points
... any volunteers?
Andrea: can work on #1
McCool: and myself work on #2
Farshid: minor fix on JSONPath, etc.
McCool: wouldn't it effect the FPWD publication?
Kaz: no
McCool: OK
... (and merges PR 103)
[adjourned]