JSON-LD Working Group Telco — Minutes

Date: 2019-10-04

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Ivan Herman, Pierre-Antoine Champin, Dave Longley, Ruben Taelman, Benjamin Young, David I. Lehn, Tim Cole, Harold Solbrig

Regrets:

Guests:

Chair: Benjamin Young

Scribe(s): Pierre-Antoine Champin, Benjamin Young

Content:

1. Approve all the minutes of several previous calls

Benjamin Young: Telco : https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-06-json-ld

Benjamin Young: TPAC day 0 (Wednesday breakout): https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-18-json-ld

Benjamin Young: TPAC day 1: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-19-json-ld

Benjamin Young: TPAC day 2: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-20-json-ld

Proposed resolution: approve the past four call minutes: 09/06, 09/18, 09/19, 09/20 (Benjamin Young)

Benjamin Young: +1

Ruben Taelman: +0.25

Gregg Kellogg: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Dave Longley: +1

David I. Lehn: +1

Resolution #1: approve the past four call minutes: 09/06, 09/18, 09/19, 09/20

2. Announcements / Reminders

2.1. How’re those implementations coming?

Benjamin Young: no real announcement this week.

Benjamin Young: known implementations: https://json-ld.org/#developers-description

Benjamin Young: Any feedback on implementations?
… existing implementations could use help at least with running tests.
… so that’s an easier way to contribute perhaps.

David I. Lehn: the tests are no longer in the same repository,
… need some advice on how to run the 1.1 test suite,
… and know which ones are 1.0 and which ones are 1.1

Gregg Kellogg: there are currently two locations, API and Framing
… There may be an option block in each test, to indicate the spec version (1.0 or 1.1).
… A 1.1 processor should not run the tests marked 1.0 ;
… Those with no specific version should be run by all processors.

Ruben Taelman: https://github.com/rubensworks/rdf-test-suite.js

Gregg Kellogg: Some may change as we are moving to the lazy evaluation for processing mode.

Ruben Taelman: I made a JS tool for my own parser;
… should be reusable by other JS implementations.

Gregg Kellogg: I have a similar tool for Ruby.

Benjamin Young: several people may have problem with running the tests,
… not realizing that they have moved from the CG to the WG.

Gregg Kellogg: the 1.0 repository has been updated to point to the WG repo.

Benjamin Young: https://github.com/json-ld/tests

Gregg Kellogg: There was mostly a directory containing all the tests.
… The current structure is quite similar.

Benjamin Young: what’s the best way for developers to know how to run the tests?

Gregg Kellogg: the spec points to the test manifest
… includes instructions about how to run the tests.

Benjamin Young: most people come first to the syntax document,
… and that one has no test suite.

Gregg Kellogg: we can put a link from the syntax doc to the api test suite.

Action #1: add test suite links to syntax doc (Gregg Kellogg)

Benjamin Young: recommendations are welcome, about how to make this process smoother.
… as issues on one of the repos.

Gregg Kellogg: the test suites now live on github,
… where we can not set some specific HTTP headers.
… There was a suggestion to mirror them on the W3C website.

Ivan Herman: I can put it somewhere.
… But I don’t know how to automatically synchronize them.

Ruben Taelman: CI tools (e.g. Travis) can be used to automatically deploy the tests on each commit.

Ivan Herman: but that would mean that Travis has access to the W3C server.

Ruben Taelman: you can put some secret information that only Travis can see.

Ivan Herman: we have to be very clear about the process before we contact the admin team.

Benjamin Young: https://github.com/web-platform-tests/wpt

Benjamin Young: the Web Platform Tests use WPT-serve
… a python-based server that allows to set up headers
… used by Web Annotation

Ivan Herman: we should go that way

Gregg Kellogg: the manifest they use is incompatible with our needs
… Their needs are browser-centered.

Benjamin Young: I was envisioning a hybrid solution,
… this is what the Web Annotation group did.

Benjamin Young: https://github.com/w3c/web-annotation-tests/

Gregg Kellogg: really what we need is moving a subtree around, with an .htaccess file for headers.

Action #2: run down where best to host JSON-LD tests with a proper HTTP server going forward (Benjamin Young)

Gregg Kellogg: I suggest we archive the obsolete test repo https://github.com/json-ld/tests

Benjamin Young: rust implementation wip https://github.com/kroeg/jsonld-rs

Benjamin Young: this repo might be referenced, as a submodule, by existing repos,
… like kroeg’s Rust implementation

Gregg Kellogg: working from a local copy is common,
… but it should work the same on HTTP

Ruben Taelman: old implementations might still be bound on those tests,
… we might break them by archiving the repo
… rather keep it live, with a big disclaimer

Benjamin Young: https://help.github.com/en/articles/archiving-a-github-repository

Benjamin Young: archived depo are still accessible, they are just closed for contribution

Gregg Kellogg: this is exactly what we want to do

Pierre-Antoine Champin: it might be a good idea to commit an OBSOLETE file before archiving it
… so that folks know they should change

3. Horizontal Review Updates/Status

Ivan Herman: there is a separate PR on the @direction by gkellogg
… appart from a minor comment on the i18n namespace,
… Addison seems happy with the PR

4. Issues

4.1. @direction progress and future

Benjamin Young: See Issue Syntax#1§1

Benjamin Young: See Pending PR on @direction

Benjamin Young: no much to discuss; just to make sure everyone is aware of the PR

Gregg Kellogg: I will only merge it when the tests pass;
… currently working on my implementation;
… maybe only merge when we have an API PR.
… The syntax PR does not address the ability for a language map to contain value objects with @value and @direction.
… Currently they only support strings.
… So there is no way to override the direction in a language map.

Ivan Herman: I think we can defer this to a future version.

Benjamin Young: is there an issue for this already?

Ivan Herman: raise an issue, so we can make it clear if we decide to postpone it.

Action #3: create issue on values of language maps not including @direction (Gregg Kellogg)

Dave Longley: the syntax doc proposes 2 or 3 ways to represent this in RDF in order to roundtrip.
… We should only recommend one.
… We would have to maintain them for many years.
… My preferred option would be to drop the @direction by default,
… with an option to serialize it in the way we think is the best for future RDF.
… That would force people to update their RDF lib,
… but that what we were expecting if a dedicated WG had been created.

Ivan Herman: half of your wishes are already fulfilled:
… by default, the @direction is dropped.
… We picked two options for roundtripping:
… * the i18n family of datatypes,
… * the “compound literal” approach (not a very good name).
… At the meeting in Fukuoka, even around the table,
… there was no clear consensus about which one was the best option.
… The idea is to let the community decide which one they want to use.

Dave Longley: Why not a 3rd option where we add a property to a literal?

Ivan Herman: because this is not valid RDF.
… The failure to create a WG shows that the RDF community is not willing to change the core of RDF.
… The advantage of the two proposed approaches is that they work with the deployed RDF infrastructure,
… even though they require some application-level knowledge to be used.

Dave Longley: What I’m hearing is “more technical depts, and no interop”
… If this is something that people need, and we introduce a hack to get it work,
… people will adopt the hack.

Ivan Herman: you can call it a hack, but this is the only thing that people seem ready to accept.
… Trying to force RDF to change is a bigger hack in my opinion.

Dave Longley: JSON-LD 1.0 did influence the RDF WG at the time, to extend RDF.

Ivan Herman: this is the big difference; there was an RDF WG at the time.
… There is none at the moment, nor can I foresee one in the near future.

Dave Longley: sometimes, standard follow implementations, rather than the opposite.

Pierre-Antoine Champin: I’d argue that the proposed solutions are not so hacky from and RDF point of view
… I prefer the datatype solution
… but none of them seem a scandal to me
… if there was an RDF WG working on this, they would consider one of these as the future standard

Ivan Herman: +1 to pchampin

Gregg Kellogg: I agree, these solutions are reasonable from the point of view of RDF.
… Also, the default option is to drop direction.
… The majority of data will not use direction, and not produce RDF differently than today.

Dave Longley: dropping it is a good default;
… but I expect Digital Bazaar being force to keep it in some way.
… For example, in VC, when the graph is signed, we need to keep the whole information.

Gregg Kellogg: from a digital signature point of view,
… I would not consider the direction to be relevant.
… Would two values differing only by direction be really different?

Dave Longley: this is scary; that could be turned into a terrible vulnerability.

Ivan Herman: I would like a resolution to allow Greg to merge the direction PR;
… this has lingered for too long.

Proposed resolution: 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 (Ivan Herman)

Ivan Herman: +1

Gregg Kellogg: +1

Harold Solbrig: +1

Pierre-Antoine Champin: +1

Benjamin Young: +1

Tim Cole: +1

Dave Longley: +0

Ruben Taelman: +1

Resolution #2: 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

5. Resolutions

6. Action Items