WoT Discovery

31 Aug 2020



Kaz_Ashimura, Michael_McCool, Kunihiko_Toumura, Christian_Glomb, Andrea_Cimmino, Farshid_Tavakolizadeh, Tomoaki_Mizushima, Cristiano_Aguzzi


<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_August_2020

<kaz> scribenick: FarshidT



No objections. Published.

Mandatory oauth2 endpoints

endpoint will remain mandatory in TD 1.x. They can be changed for TD 2.0 if there are valid use cases.

<kaz> wot-security issue 181

PR 59

PR: Move requirements to Architecture (https://github.com/w3c/wot-discovery/pull/59)

<kaz> related to issue 57

McCool: centralizing requirements make sense. But need to discuss if it would be useful to keep them inside index.html
... requirements are placed in requirements.md file

Kaz: will these requirements be included in architecture requirements?

McCool: yes, we are still debating if they should be as part of wot use cases or part of the architecture document itself (possibly the consolidated "WoT Use Cases and Requirements" document at some point).

No objections. Merged PR.

PR 50

McCool: Add additional security schemes to directory TD (https://github.com/w3c/wot-discovery/pull/50)

Farshid: initially thought of an invalid use case which didn't require the oauth2 endpoints.
... this is now clear.

MCCOOL: commented regarding the scopes

Farshid: added an issue regarding vocab that need to be added to context: https://github.com/w3c/wot-discovery/issues/54

McCool: better change "combination" to something else to avoid using scheme name for definitions
... will change that after the merge

no objection. Merged PR.

McCool: changed "combination" to "combo_sc" on master branch

PR 51

PR: Add description of notification API (https://github.com/w3c/wot-discovery/pull/51)

McCool: the query parameter should be described in TD to tell client if the feature is provided.

Farshid: should providing diff be a mandatory feature provided by servers?

Cristiano: i don't think so

McCool: agrees, it is nice to have

Farshid: so the event will have at least "id"

McCool: need to clarify what is the identifier of TD and whether it differs from TD's ID

Cristiano: the id should be same as the identifier used to retrieve the TD

McCool: Updated index.html with semantic search (https://github.com/w3c/wot-discovery/pull/47)

Andrea: needed to do a git rebase to start from latest changes
... will add TD changes to directory.td.json and remove the other json file
... still no clear about the endpoints, whether /search is the best option
... no normative reference for JSONPath

McCool: for xpath, we can pick the particular version which has JSON support
... IETF is working on JSONPath
... references can be from respec database or local

Andrea: XPath and JSONPath as a MUST, SPARQL as a MAY

McCool: my recommendation is to pick one syntactic approach as a MUST and another as a SHOULD
... it may take time to get JSONPath as a standard, so I recommend XPath as MUST, JSONPath as SHOULD, SPARQL as MAY

Andrea: I suggest JSONPath a MUST and XPath as SHOULD, though I understand about the standardization issue

McCool: okay, we can do that for now and check the progress of JSONPath in future.

Andrea: 200 response type will be a complete TD or set of TD elements

McCool: it won't be "application/td+json" technically.

Andrea: we can use "application/ld+json" if they are partial.

McCool: yes if we can insert the context file for jsonld

Farshid: the context file may not be relevant anymore because the JSON structure may be different, i.e. different key name, array of objects
... I suggest "application/json"

McCool: perhaps the safest option for now is "application/json", and we can contact JSON-LD people to ask how they deal with such situations
... need to include the query param inside the href template
... some terms such as "JSON Path" and "SPARQL" don't need to be in code formatting.

Andrea: simplified the SPARQL text, removed normative protocol details.
... need to decide HTTP method, or allow both GET and POST

McCool: shouldn't give too much flexibility
... either require just one method, or require both

Farshid: i think having both are not technically necessary
... GET will allow caching, POST will hide the query from server logs

McCool: POST may be convenient because it doesn't need URL encoding

<kaz> Preview - Semantic search: SPARQL

McCool: we can go with MUST for GET and MAY for POST

Cristiano: agrees

McCool: TPAC planning in next meeting

<kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/09/07 07:18:54 $