15:46:57 <RRSAgent> RRSAgent has joined #json-ld
15:46:57 <RRSAgent> logging to https://www.w3.org/2019/10/04-json-ld-irc
15:46:58 <ivan> rrsagent, set log public
15:46:58 <ivan> Meeting: JSON-LD Working Group Telco
15:46:58 <ivan> Date: 2019-10-04
15:46:58 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0000.html
15:46:58 <ivan> ivan has changed the topic to: Meeting Agenda 2019-10-04: hhttps://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0000.html
15:46:59 <ivan> Chair: bigbluehat
15:49:08 <gkellogg> gkellogg has joined #json-ld
15:51:20 <rubensworks> rubensworks has joined #json-ld
15:51:53 <pchampin> pchampin has joined #json-ld
15:58:13 <gkellogg> present+
15:58:33 <ivan> present+
15:58:48 <pchampin> present+
15:58:51 <dlongley> dlongley has changed the topic to: Meeting Agenda 2019-10-04: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0000.html
15:59:30 <dlongley> present+
15:59:51 <rubensworks> present+
16:00:49 <bigbluehat> present+
16:02:04 <dlehn> present+
16:02:12 <bigbluehat> scribenick: pchampin
16:02:21 <bigbluehat> Topic: Approve all the minutes of several previous calls
16:03:23 <bigbluehat>     https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-06-json-ld
16:03:23 <bigbluehat>     TPAC day 0 (Wednesday breakout): https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-18-json-ld
16:03:23 <bigbluehat>     TPAC day 1: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-19-json-ld
16:03:23 <bigbluehat>     TPAC day 2: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-20-json-ld
16:03:28 <bigbluehat> PROPOSAL: approve the past four call minutes: 09/06, 09/18, 09/19, 09/20
16:03:34 <bigbluehat> +1
16:03:37 <rubensworks> +0.25
16:03:37 <gkellogg> +1
16:03:37 <ivan> +1
16:03:38 <pchampin> +1
16:03:41 <dlongley> +1
16:03:53 <bigbluehat> RESOLVED: approve the past four call minutes: 09/06, 09/18, 09/19, 09/20
16:04:08 <dlehn> +1
16:04:14 <bigbluehat> Topic: Announcements / Reminders
16:04:44 <timCole> timCole has joined #json-ld
16:05:29 <bigbluehat> Subtopic: How're those implementations coming?
16:05:34 <ivan> present+ tcole
16:05:48 <pchampin> bigbluehat: no real announcement this week.
16:05:56 <bigbluehat> known implementations https://json-ld.org/#developers-description
16:05:57 <pchampin> ... Any feedback on implementations?
16:07:45 <bigbluehat> scribe+ bigbluehat
16:08:00 <bigbluehat> ... existing implementations could use help at least with running tests.
16:08:10 <bigbluehat> ...so that's an easier way to contribute perhaps.
16:08:35 <pchampin> dlehn: the tests are no longer in the same reposity,
16:08:48 <pchampin> ... need some advice on how to run the 1.1 test suite,
16:08:52 <hsolbrig> hsolbrig has joined #json-ld
16:09:00 <pchampin> ... and know which ones are 1.0 and which ones are 1.1
16:09:06 <ivan> present+ hsolbrig
16:09:12 <hsolbrig> present+ hsolbrig
16:09:17 <pchampin> gkellogg: there are currently two locations, API and Framing
16:09:52 <pchampin> ... There may be an option block in each test, to indicate the spec version (1.0 or 1.1).
16:10:09 <rubensworks> q+
16:10:10 <pchampin> ... A 1.1 processor should not run the tests marked 1.0 ;
16:10:22 <pchampin> ... Those with no specific version should be run by all processors.
16:10:40 <bigbluehat> ack rubensworks
16:10:47 <rubensworks> https://github.com/rubensworks/rdf-test-suite.js
16:10:57 <pchampin> ... Some may change as we are moving to the lazy evaluation for processing mode.
16:11:11 <pchampin> rubenworks: I made a JS tool for my own parser;
16:11:21 <pchampin> ... should be reusable by other JS implementations.
16:11:44 <pchampin> gkellogg: I have a similar tool for Ruby.
16:12:18 <pchampin> bigbluehat: several people may have problem with running the tests,
16:12:30 <pchampin> ... not realizing that they have moved from the CG to the WG.
16:12:44 <pchampin> gkellogg: the 1.0 repository has been updated to point to the WG repo.
16:13:18 <bigbluehat> https://github.com/json-ld/tests
16:13:24 <pchampin> ... There was mostly a directory containing all the tests.
16:13:30 <pchampin> ... The current structure is quite similar.
16:14:11 <pchampin> bigbluehat: what's the best way for developers to know how to run the tests?
16:14:27 <pchampin> gkellogg: the spec points to the test manifest
16:14:40 <pchampin> ... includes instructions about how to run the tests.
16:15:03 <pchampin> bigbluehat: most people come first to the syntax document,
16:15:10 <pchampin> ... and that one has no test suite.
16:15:23 <pchampin> gkellogg: we can put a link from the syntax doc to the api test suite.
16:15:51 <gkellogg> action: gkellogg to add test suite links to syntax doc
16:16:04 <pchampin> bigbluehat: recommendations are welcome, about how to make this process smoother.
16:16:09 <pchampin> ... as issues on one of the repos.
16:16:21 <pchampin> gkellogg: the test suites now live on github,
16:16:37 <pchampin> ... where we can not set some specific HTTP headers.
16:16:55 <pchampin> ... There was a suggestion to mirror them on the W3C website.
16:17:07 <pchampin> ivan: I can put it somewhere.
16:17:21 <pchampin> ... But I don't know how to automatically synchronize them.
16:17:23 <rubensworks> q+
16:17:33 <bigbluehat> q+
16:17:55 <bigbluehat> ack rubensworks
16:18:36 <pchampin> rubenworks: CI tools (e.g. Travis) can be used to automatically deploy the tests on each commit.
16:18:54 <pchampin> ivan: but that would mean that Travis has access to the W3C server.
16:19:09 <pchampin> rubenworks: you can put some secret information that only Travis can see.
16:19:32 <pchampin> ivan: we have to be very clear about the process before we contact the admin team.
16:19:33 <bigbluehat> ack bigbluehat
16:19:36 <bigbluehat> https://github.com/web-platform-tests/wpt
16:20:06 <pchampin> bigbluehat: the Wev Platform Tests use WPT-serve
16:20:16 <pchampin> s/Wev/Web/
16:20:42 <pchampin> ... a python-based server that allows to set up headers
16:20:47 <pchampin> ... used by Web Annotation
16:21:56 <gkellogg> q+
16:22:37 <bigbluehat> ack gkellogg
16:22:48 <pchampin> ivan: we should go that way
16:23:27 <pchampin> gkellogg: the manifest they use is incompatible with our needs
16:23:55 <pchampin> ... Their needs are browser-centered.
16:24:17 <pchampin> bigbluehat: I was envisionning a hybrid solution,
16:24:33 <pchampin> ... this is what the Web Annotation group did.
16:24:37 <bigbluehat> https://github.com/w3c/web-annotation-tests/
16:25:37 <pchampin> gkellogg: really what we need is moving a subtree around, with an .htaccess file for headers.
16:25:45 <hsolbrig_> hsolbrig_ has joined #json-ld
16:26:30 <bigbluehat> action: bigbluehat to run down where best to host JSON-LD tests with a proper HTTP server going forward
16:27:05 <gkellogg> q+ to suggest we archive https://github.com/json-ld/tests
16:27:07 <pchampin> s/rubenworks/rubensworks/
16:27:15 <bigbluehat> ack gkellogg
16:27:15 <Zakim> gkellogg, you wanted to suggest we archive https://github.com/json-ld/tests
16:27:47 <pchampin> gkellogg: I suggest we archive the obsolete test depo  https://github.com/json-ld/tests
16:27:55 <rubensworks> q+
16:27:56 <bigbluehat> rust implementation wip https://github.com/kroeg/jsonld-rs
16:27:56 <pchampin> s/depo/repo/
16:28:47 <pchampin> bigbluehat: this repo might be referenced, as a submodule, by existing repos,
16:28:55 <pchampin> ... like kroeg's Rust implementation
16:29:21 <bigbluehat> ack rubensworks
16:29:24 <pchampin> gkellogg: working from a local copy is common,
16:29:32 <pchampin> ... but it should work the same on HTTP
16:29:49 <pchampin> rubensworks: old implementations might still be bound on those tests,
16:30:02 <pchampin> ... we might break them by archiving the repo
16:30:22 <pchampin> ... rather keep it live, with a big disclaimer
16:31:21 <bigbluehat> https://help.github.com/en/articles/archiving-a-github-repository
16:31:27 <pchampin> bigbluehat: archived depo are still accessible, they are just closed for contribution
16:31:55 <pchampin> gkellogg: this is exactly what we want to do
16:32:13 <pchampin> q+
16:32:17 <bigbluehat> ack pchampin
16:32:35 <bigbluehat> pchampin: it might be a good idea to commit an OBSOLETE file before archiving it
16:32:48 <bigbluehat> ...so that folks know they should change
16:33:16 <bigbluehat> Topic: Horizontal Review Updates/Status
16:33:32 <ivan> q+
16:33:35 <bigbluehat> ack ivan
16:34:04 <pchampin> ivan: there is a separate PR on the `@direction` by gkellogg
16:34:19 <pchampin> ... appart from a minor comment on the i18n namespace,
16:34:28 <pchampin> ... Alison seems happy with the PR
16:34:37 <dlongley> s/Alison/Addison/
16:35:15 <bigbluehat> Topic: Issues
16:35:21 <bigbluehat> Subtopic: `@direction` progress and future
16:35:27 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/11
16:35:34 <bigbluehat> Pending PR https://github.com/w3c/json-ld-syntax/pull/276
16:36:16 <pchampin> bigbluehat: no much to discuss; just to make sure everyone is aware of the PR
16:36:29 <pchampin> gkellogg: I will only merge it when the tests pass;
16:36:38 <pchampin> ... currently working on my implementation;
16:36:55 <pchampin> ... maybe only merge when we have an API PR.
16:37:43 <dlongley> q+
16:37:51 <pchampin> ... The syntax PR does not address the ability for a language map to contain value objects with `@value` and `@direction`.
16:38:01 <ivan> q+
16:38:03 <pchampin> ... Currently they only support strings.
16:38:18 <bigbluehat> ack dlongley
16:38:18 <pchampin> ... So there is no way to override the direction in a language map.
16:38:31 <dlongley> q+ dlongley
16:39:12 <bigbluehat> ack ivan
16:39:19 <pchampin> ivan: I think we can defer this to a future version.
16:39:24 <bigbluehat> q+ to ask if we need an issue for the language map, value object situation
16:39:45 <bigbluehat> q-
16:39:48 <pchampin> bigbluehat: is there an issue for this already?
16:40:01 <bigbluehat> ack dlongley
16:40:05 <pchampin> ivan: raise an issue, so we can make it clear if we decide to postpone it.
16:40:28 <gkellogg> action: gkellogg to create issue on values of language maps not including `@direction`
16:40:46 <pchampin> dlongley: the syntax doc proposes 2 or 3 ways to represent this in RDF in order to roundtrip.
16:40:53 <pchampin> ... We should only recommend one.
16:41:10 <pchampin> ... We would have to maintain them for many years.
16:41:18 <ivan> q+
16:41:27 <pchampin> ... My preferred option would be to drop the `@direction` by default,
16:41:49 <pchampin> ... with an option to serialize it in the way we think is the best for future RDF.
16:42:26 <pchampin> ... That would force people to update their RDF lib,
16:42:39 <pchampin> ... but that what we were expecting if a dedicated WG had been created.
16:42:42 <bigbluehat> ack ivan
16:42:53 <pchampin> ivan: half of your wishes are already fullfilled:
16:43:02 <pchampin> ... by default, the `@direction` is dropped.
16:43:33 <pchampin> ... We picked two options for roundtripping:
16:43:41 <pchampin> ... * the i18n family of datatypes,
16:43:55 <pchampin> ... * the "compound literal" approach (not a very good name).
16:44:08 <pchampin> ... At the meeting in Fukuhoka, even around the table,
16:44:19 <pchampin> ... there was no clear consensus about which one was the best option.
16:44:28 <dlongley> q+
16:44:40 <bigbluehat> ack dlongley
16:44:47 <pchampin> ... The idea is to let the community decide which one they want to use.
16:45:19 <pchampin> dlongley: Why not a 3rd option where we add a property to a literal?
16:45:25 <pchampin> ivan: because this is not valid RDF.
16:46:10 <pchampin> ... The failure to create a WG shows that the RDF community is not willing to change the core of RDF.
16:46:30 <pchampin> ... The advantage of the two proposed approaches is that they work with the deployed RDF infrastructure,
16:46:39 <bigbluehat> q+
16:46:43 <bigbluehat> ack bigbluehat
16:46:54 <pchampin> ... even though they require some application-level knowledge to be used.
16:47:15 <dlongley> q+
16:47:45 <bigbluehat> ack dlongley
16:48:05 <pchampin> dlongley: What I'm hearing is "more technical depts, and no interop"
16:48:21 <ivan> q+
16:48:24 <pchampin> q+
16:48:39 <bigbluehat> ack ivan
16:48:45 <pchampin> ... If this is something that people need, and we introduce a hack to get it work,
16:48:56 <dlongley> q+
16:48:56 <pchampin> ... people will adopt the hack.
16:49:38 <pchampin> ivan: you can call it a hack, but this is the only thing that people seem ready to accept.
16:50:05 <pchampin> ... Trying to force RDF to change is a bigger hack in my opinion.
16:50:57 <pchampin> dlongley: JSON-LD 1.0 did influence the RDF WG at the time, to extend RDF.
16:51:16 <pchampin> ivan: this is the big differente; there *was* an RDF WG at the time.
16:51:33 <pchampin> ... There is none at the moment, nor can I foresee one in the near future.
16:51:40 <dlongley> q+
16:51:53 <bigbluehat> ack pchampin
16:52:01 <gkellogg> q+
16:52:34 <pchampin> dlongley: sometimes, standard follow implementations, rather than the opposite.
16:52:41 <dlongley> q-
16:52:51 <bigbluehat> pchampin: i'd argue that the proposed solutions are not so hacky from and RDF point of view
16:52:55 <bigbluehat> ...I prefer the datatype solution
16:53:00 <bigbluehat> ...but none of them seem a scandal to me
16:53:18 <bigbluehat> ...if there was an RDF WG working on this, they would consider one of these as the future standard
16:53:21 <bigbluehat> ack gkellogg
16:53:24 <ivan> +1 to pchampin
16:54:05 <pchampin> gkellogg: I agree, these solutions are reasonable from the point of view of RDF.
16:54:19 <pchampin> ... Also, the default option is to drop direction.
16:54:40 <pchampin> ... The majority of data will not use direction, and not produce RDF differently than today.
16:55:31 <pchampin> dlongley: dropping it is a good default;
16:55:43 <pchampin> ... but I expect Digital Bazaar being force to keep it in some way.
16:55:58 <pchampin> ... For example, in VC, when the graph is signed, we need to keep the whole information.
16:56:25 <pchampin> gkellogg: from a digital signature point of view,
16:56:29 <dlongley> q+
16:56:36 <pchampin> ... I would not consider the direction to be relevant.
16:56:47 <bigbluehat> ack dlongley
16:56:56 <pchampin> ... Would two values differing only by direction be really different?
16:57:13 <pchampin> dlongley: this is scary; that could be turned into a terrible vulnerability.
16:57:24 <ivan> q+
16:57:37 <bigbluehat> ack ivan
16:58:15 <pchampin> ivan: I would like a resolution to allow Greg to merge the direction PR;
16:58:41 <pchampin> ... this has lingered for too long.
16:59:04 <ivan> Propose: the WG is happy to merge #276, but leaves it to the editors whether they do it now or after the API changes is also in a PR
16:59:19 <ivan> +1
16:59:19 <gkellogg> +1
16:59:21 <hsolbrig_> +1
16:59:21 <pchampin> +1
16:59:23 <bigbluehat> +1
16:59:24 <timCole> +1
16:59:24 <dlongley> +0
16:59:24 <rubensworks> +1
16:59:37 <ivan> resolved: the WG is happy to merge #276, but leaves it to the editors whether they do it now or after the API changes is also in a PR
17:00:21 <ivan> rrsagent, draft minutes
17:00:21 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/04-json-ld-minutes.html ivan
17:00:22 <ivan> zakim, bye
17:00:22 <ivan> rrsagent, bye
17:00:22 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2019/10/04-json-ld-actions.rdf :
17:00:22 <RRSAgent> ACTION: gkellogg to add test suite links to syntax doc [1]
17:00:22 <RRSAgent>   recorded in https://www.w3.org/2019/10/04-json-ld-irc#T16-15-51
17:00:22 <RRSAgent> ACTION: bigbluehat to run down where best to host JSON-LD tests with a proper HTTP server going forward [2]
17:00:22 <RRSAgent>   recorded in https://www.w3.org/2019/10/04-json-ld-irc#T16-26-30
17:00:22 <RRSAgent> ACTION: gkellogg to create issue on values of language maps not including `@direction` [3]
17:00:22 <RRSAgent>   recorded in https://www.w3.org/2019/10/04-json-ld-irc#T16-40-28
17:00:22 <Zakim> leaving.  As of this point the attendees have been gkellogg, ivan, pchampin, dlongley, rubensworks, bigbluehat, dlehn, tcole, hsolbrig
17:00:22 <Zakim> Zakim has left #json-ld