W3C home > Mailing lists > Public > public-wot-wg@w3.org > September 2020

[wot-discovery] minutes - 31 August 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 09 Sep 2020 20:01:10 +0900
Message-ID: <87a6xzfc3t.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Farshid!



      [1] http://www.w3.org/

                               - DRAFT -

                             WoT Discovery

31 Aug 2020


      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_August_2020


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





     * [3]Topics
         1. [4]Minutes
         2. [5]Mandatory oauth2 endpoints
         3. [6]PR 59
         4. [7]PR 50
         5. [8]PR 51
     * [9]Summary of Action Items
     * [10]Summary of Resolutions

   <kaz> Agenda:

     [11] https://www.w3.org/WoT/IG/wiki/WG_WoT_Discovery_WebConf#31_August_2020

   <kaz> scribenick: FarshidT



     [12] https://www.w3.org/2020/08/24-wot-discovery-minutes.html

   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> [13]wot-security issue 181

     [13] https://github.com/w3c/wot-security/issues/181

PR 59

   PR: Move requirements to Architecture

     [14] https://github.com/w3c/wot-discovery/pull/59)

   <kaz> [15]related to issue 57

     [15] https://github.com/w3c/wot-discovery/issues/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

   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

     [16] 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: [17]https://github.com/w3c/wot-discovery/issues/54

     [17] 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

     [18] 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

     [19] 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

   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
   ... 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

   <kaz> [20]Preview - Semantic search: SPARQL

     [20] https://pr-preview.s3.amazonaws.com/AndreaCimminoArriaga/wot-discovery/pull/47.html#search-semantic

   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 [21]scribe.perl version ([22]CVS log)
    $Date: 2020/09/07 07:18:54 $

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [22] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 9 September 2020 11:01:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 9 September 2020 11:01:16 UTC