W3C home > Mailing lists > Public > public-wot-wg@w3.org > February 2019

[wot-ig/wg] minutes - 20 February 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 21 Feb 2019 15:56:25 +0900
Message-ID: <CAJ8iq9WK1DVHL+sjYMdu8fMKS_N0tO_pvzuCYkDt5pSfJM+vMg@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Taki!

Also thank you very much for joining the call and giving thoughtful
comments, Manu!




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

                               - DRAFT -


20 Feb 2019


      [2] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#20_Feb_2019


          Kaz_Ashimura, Taki_Kamiya, Manu_Sporny,
          Matthias_Kovatsch, Kunihiko_Toumura, Michael_McCool,
          Tetsushi_Matsuda, Tomoaki_Mizushima, Zoltan_Kis,
          Toru_Kawaguchi, Yosuke_Nakamura, Daniel_Peintner,
          Ege_Korkan, Ryuichi_Matsukura


          Matthias, McCool



     * [3]Topics
         1. [4]IG extension announcement
         2. [5]Workshop
         3. [6]Finalizing the f2f minutes
         4. [7]TestFest status
         5. [8]CR schedule including testing for TD
         6. [9]Architecture
         7. [10]How to deal with JSON-LD capability within TD?
               o [11]Issue 442
               o [12]Issue 443
               o [13]Issue 444
         8. [14]TestFest call today?
     * [15]Summary of Action Items
     * [16]Summary of Resolutions

   <kaz> scribenick: taki

   <scribe> Scribe: TK

   Matthias: Let's start with quick updates.

IG extension announcement

   <kaz> [17]ac announcement (member-only)

     [17] https://lists.w3.org/Archives/Member/w3c-ac-members/2019JanMar/0018.html

   Kaz: As I reported last week, WoT IG charter extension was
   approved and announced. Until the end of June.


   Matthias: Workshop dates was changed.

   <kaz> [18]updated workshop cfp

     [18] https://cdn.staticaly.com/gh/w3c/wot/add-background-image/workshop/ws2/cfp.html

   Lagally: shifted one week back. To first week of June.
   ... CfP is getting ready. Program committee is being formed.
   ... going forward, going to have a weekly call.

   <kaz> [19]EasyChair system

     [19] https://easychair.org/

   Kaz: we had a workshop call. I updated the CfP page, had
   discussion on how to participate information (we'd like to use
   EasyChair system to manage position papers).
   ... will work with the W3C comm team for announcement.

   Matthias: Thanks. Let us know when the website is up.

Finalizing the f2f minutes

   <kaz> [20]draft minutes from f2f

     [20] https://www.w3.org/2019/01/28-0202-wot-minutes.html

   Matthias: F2F minutes is the next topic.

   Kaz: There have been no comments.

   Matthias: We need resolution.
   ... any objection?
   ... We have a resolution to publish the minutes.

   RESOLUTION: the minutes from the Princeton f2f have been

   Matthias: presentation folder.

   <kaz> [21]presentation folder

     [21] https://github.com/w3c/wot/tree/master/f2f/2019/01-princeton

   Matthias: Did everyone put presentations?

   <kaz> ACTION: kaz to add links from the minutes to the
   presentation files

   <trackbot> Created ACTION-166 - Add links from the minutes to
   the presentation files [on Kazuyuki Ashimura - due 2019-02-27].

   Lagally: We need links to presentations from the minutes.

   Kaz: I will check the sessions, and ping people for

TestFest status

   McCool: TestFest. nobody updated results yet.
   ... Please knock off remaining ones.

   Ege: No updates. I fixed some stuff. no new assertions.

   McCool: I removed unique id assertions.
   ... there are still bunch of at-risk items.
   ... I will run before TD call.

CR schedule including testing for TD

   <inserted> scribenick: kaz

   Taki: by the end of Feb for significant ones
   ... and wide review by TAG, I18N, etc., for 2 weeks from the
   beginning of March
   ... and then transition request for CR by the end of March
   ... spec change last week, e.g., observeThings, subprotocols
   ... decided to rename interaction pattern to interaction
   ... victor is looking into schema definition

   McCool: 2 more comments
   ... victor is making change for figures as well
   ... also regarding TAG review, Sebastian is generating the
   explainer document and Chairs to review it

   Matthias: tx
   ... sounds like a good plan


   <inserted> scribenick: taki

   Matthias: Architecture?

   Lagally: We just had a call today.
   ... We went over remaining issue.
   ... by the end of March, we plan to get the document ready.
   ... Contribution is needed in the next few weeks.
   ... Scripting API aspect, please take a look at the document.

   McCool: I plan to take a look at the document.

   Lagally: Also from security aspect, please review.

How to deal with JSON-LD capability within TD?

   Matthias: Sebastian is here now.

   Sebastian: There was a question about how we handle TD
   serialization, and how it relates to JSON-LD.
   ... What do you think about our current approach?
   ... we also have JSON-LD transformation section.

   <kaz> [22]TD draft - Section 7

     [22] https://w3c.github.io/wot-thing-description/#Implementation-Note-section

   Manu: I took a look at those sections and raised three issues.

   <manu> [23]https://github.com/w3c/wot-thing-description/issues

     [23] https://github.com/w3c/wot-thing-description/issues

* Issue 442


     [24] https://github.com/w3c/wot-thing-description/issues/442

   <manu> JSON-LD Best Practice - Version JSON-LD Context files

   Manu: Issue #442
   ... context can be out of date.
   ... There is a design pattern.

   <manu> publish at URL like this:

     [25] https://www.w3.org/2019/wot/td

   Manu: you publish ontology with pattern like this.

   <manu> JSON-LD context file goes here:

     [26] https://www.w3.org/2019/wot/td/v1

   Manu: It gives you a stable vocabulary that apps can rely on
   without hard-coding.
   ... Security section section touches on privacy risk, etc. The
   design pattern address those as well.
   ... V2 can make changes without breaking deployments.
   ... It is future-proofing this way.

   Sebastian: You mean we should not use generic URL, and we need
   version information.

   Manu: Yes. And we need dates in URL. So it is obvious how old
   the URL is.

   Sebastian: It is good point. we also started to discuss this
   ... we also discussed version term. URL solution looks

   <manu> Hashlink:

     [27] https://tools.ietf.org/html/draft-sporny-hashlink-02

   Manu: What if Content changes? We are creating a spec to
   address this using Hash.
   ... Hash-link specification.

* Issue 443

   <manu> Using "http" as a term is strange --

     [28] https://github.com/w3c/wot-thing-description/issues/443

   Manu: #443 next
   ... I see "http".

   <manu> http:example

   <manu> [29]http://example.com/

     [29] http://example.com/

   Manu: "http" led people to think it is a URL.

   <manu> {"htv": "[30]http://www.w3.org/2011/http#"}

     [30] http://www.w3.org/2011/http

   <manu> {"hto": "[31]http://www.w3.org/2011/http#"}

     [31] http://www.w3.org/2011/http

   Manu: Maybe "htv" can avoid such confusion.

   Sebastian: Good point.

* Issue 444

   <manu> 7.2 Transformation to JSON-LD & RDF seems unnecessary --

     [32] https://github.com/w3c/wot-thing-description/issues/444

   Manu: #444. about section 7.2.
   ... You seem to try to achieve round trip transformation.

   Sebastian: It is a desired goal.
   ... Our TD is not a JSON-LD exactly.
   ... Because of schedule issue.
   ... Format based on JSON-LD 1.1. We use @context and @type. We
   transform to JSON-LD 1.0.
   ... For semantic processing, we can use transformation.
   ... as a preprocessing.

   McCool: we are concerned with importing into RDF database, for
   ... that is main objective. exporting from database is not main

   Matthias: Producing TD can be from data model.
   ... Ideally TD conforms to JSON-LD.
   ... JSON-LD 1.1 is currently being worked on to make

   <McCool> Sorry, I will have to drop; plane is boarding; ttyl

   Matthias: We can not reference it yet.
   ... Preprocess is necessary because there are some issues we do
   not find in JSON-LD 1.1 yet.

   <Zakim> manu, you wanted to try to understand what feature is
   missing to go to valid JSON-LD 1.0

   Manu: Curious about those missing issues.
   ... JSON-LD 1.1 can be described in non-normative section.
   ... as implementation guide.
   ... "This section will be updated once 1.1 spec becomes REC"
   ... W3C allows this kind of language.
   ... So other group will be on notice.
   ... in non-normative section.
   ... Once 1.1 becomes REC, can make it normative.
   ... What specific feature WoT needs, I need to understand.
   ... Why WoT can not do with 1.1.
   ... JSON-LD to JSON transformation. JSON-LD framing is a better
   ... Template using graph to transform to JSON.
   ... I will ask JSON-LD group to check this.

   Matthias: 1.1 looked better for our use.
   ... @id is re-used with @base hierarchically.

   Manu: Tie to 1.1 non-normatively will be the right option.

   Sebastian: We should think about it. We did not think about
   this option.

   Sebastion: Normative serialization, we need it.

   Manu: There was a precedent. In hind-sight nobody noticed. The
   spec republished in 4 months with normative statements.
   ... I suggest to simplify the spec.
   ... without making extra effort to avoid the issue.

   Sebastian: I like the idea, but we need to discuss in WG.

   Manu: That's the all feedback I had.
   ... You will benefit from JSON-LD group's review.
   ... so they will understand WoT's needs.

   Sebastian: Thank you, Manu.

   <kaz> [33]latest published WD of TD

     [33] https://www.w3.org/TR/2018/WD-wot-thing-description-20181021/#Implementation-Note-section

   Kaz: My position is same as Manu's. JSON-LD 1.1 serialization
   can be non-normative.
   ... note that we used to have sections on "JSON serialization"
   and "JSON-LD 1.1 serialization", e.g., in the latest published
   WD (shown above)
   ... we can discuss it again during the TD call on Friday.

   Matthias: +1 to Kaz.
   ... we have raw JSON, and we can preprocess to convert to
   JSON-LD 1.1.

   <manu> +1 to that, sounds good.

   Manu's clarification: +1'ing in general to trying to have a
   section in the specification about "Serialization to JSON-LD",
   where the focus should be on JSON-LD 1.1 (non-normatively)...
   where that section becomes normative at some point.

   Manu: Pure JSON with @context. This is the only burden for
   developers. You can hard-code everything else.

   Matthias: There is a Media-type issue.

   <manu> "application/td+ld+json"

   <manu> "application/td+ld+json+jwt"

   <manu> "application/td+json"

   Manu: The first is a proper IETF way.

   <manu> "application/td+ld+json"

   Manu: This is a phylosophical debate.

   <manu> "application/json-ld"

   <manu> "the right way" => "application/td+ld+json"

   Manu: That's my suggestion to you.

   Matthias: we also want to treat it as a JSON.

TestFest call today?

   Matthias: do we have a TestFest call?
   ... Ege knows?

   Ege: There is no big update. We have homework.

   Kaz: Manual readme.md is necessary.
   ... for 03

   <kaz> guidelines like:

     [34] https://github.com/w3c/wot/tree/master/testfest/2019-02-princeton

   <kaz> should be added to:

     [35] https://github.com/w3c/wot/tree/master/testfest/2019-03-online

   Ege: OGC people suggested how to document test.

   Sebastian: Please share in TD meeting this week.

   Ege: OK

   Matthias: no TestFest call today.

   <kaz> [adjourned]

Summary of Action Items

   [NEW] ACTION: kaz to add links from the minutes to the
   presentation files

Summary of Resolutions

    1. [36]the minutes from the Princeton f2f have been approved

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [37]scribe.perl version 1.154 ([38]CVS log)
    $Date: 2019/02/21 06:51:22 $

     [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [38] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 21 February 2019 06:57:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:52 UTC