JSON-LD Working Group Telco — Minutes

Date: 2018-07-06

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Rob Sanderson, Simon Steyskal, Adam Soroka, Benjamin Young, Gregg Kellogg, ChristopherA, David Newbury, Christopher Allen, Tim Cole, Harold Solbrig, Jeff Mixter, David Lehn

Regrets:

Guests:

Chair: Benjamin Young

Scribe(s): Adam Soroka

Content:


1. Approve minutes of the previous call

Resolution #1: Minutes approved

Adam Soroka: No objections raised, minutes approved.

Rob Sanderson: +1 :)

2. Announcements / Reminders

Benjamin Young: TPAC discounted rate closing soon, but registration open for more months
… JSON-LD WG meeting is at the end of TPAC week, two full days planned

ChistopherA: On Monday July 16th there will be a hackathon for a Bitcoin reference impl
… many JSON-LD tools are Javascript-centric
… assistance for working with non-JS tools would be welcomed
… ChristopherA will forward an email to the JSON-LD lists.

ChristopherA: https://w3c-ccg.github.io/announcements/#btcr-virtual-hackathon-july-16-20-2018

ChristopherA: in particular need support for C, C++ or Go.

Benjamin Young: meeting times will remain the same for the near term for this call

3. Introductions if needed

ChristopherA: co-chair of the Credentials CG, board member for rebooting web of trust, working for Blockchain Commmons, co-author of SSL TLS

Benjamin Young: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0000.html

4. Discuss design principles

Rob Sanderson: with disparate comnunities working together, easier to agree up front how we intend to work together
… so that all viewpoints are fairly and effectively represented and adjudicated
… one way to accomplish this: look first to design patterns or principles.
… they will give us a common framework for judging utility
… (and avoids people trying to shout each other down)
… nothing is perfect, but this will help us work more smoothly
… prinicples offered come from azaroth’s experience
… first: “making production and consumption of linked data as easy as possible for the widest variety of web developers”
… we will both affirm/deny and discuss each principle

Rob Sanderson: > We follow our overall mission of making production and consumption of linked data as easy as possible for the widest variety of web developers, with or without any experience of the underlying graph models.

ChristopherA: JSON-LD in the absence of canonicality will not meet any of my use cases
… we should talk about that at this level of discussion,

ChristopherA: bigbluehat: Signing covers part of “canonicality” but there is more

Rob Sanderson: +1 to “bigger and beyond” :)

Benjamin Young: re: the phrase “web developers”: there is some contention about what “web” means– just the browser, or machine-to-machine as well?/
… we want to be expansive and inclusive
… accepts suggestion to change to “developers”

Adam Soroka: ?

David Newbury: we need to find a balance

Gregg Kellogg: in 1.0, prioritization was on production, not consumption
… we chose to leave the complexity in the algorithms

Harold Solbrig: Does consumption of linked data constrain us to JSON-LD or not (or does it include YAML, et al)?

Rob Sanderson: The division is into smaller chunks– we’re not concerned with other serializations, generally.
… we are not chartered to make any changes to RDF
… we are concerned with JSON-LD, but we note that the patterns from JSON-LD 1.0 and 1.1 could be expressed in other syntaxes (syntaxen?)
… we can offer non-normative notes about how to express the same patterns in other syntaxi
… the mention of YAML is intended to call out that it is often perceived as difficult to parse formats, so the easier we make it to produce/consume JSON-LD the better adoption we will see

Benjamin Young: Our charter includes “JSON-LD 1.1 examples specified in YAML.” in Other Deliverables https://www.w3.org/2018/03/jsonld-wg-charter.html#wg-other-deliverables

Ivan Herman: two things: 1) W3C very clearly says that what we mean by “Web” is NOT just browsers
… 2) a more complicated issue: canonicalization
… during the discussion of the charter, this was discussed. and RDF canonicalization is explicitly out of scope
… the issue is that canonicalization is complex and therefore requires a different set of expertise than is found in this WG
… there are efforts to set up a group for RDF dataset normalization
… and ivan hopes that interest will be sufficient to get that group going independently.
… (but not here!)

Tim Cole: The tension between producers and consumers: timCole is more comfortable trying for an even balance, or one that favor consumers slightly
… also, is this about the easiest way to provide LD, or how LD fits in JSON-related serialziations. timCole prefers the latter
… JSON is certainly useful and widely used, and being able to express RDF in JSON is therefore useful

Rob Sanderson: re: production vs. consumption: we have a later principle that says optimize for production and consumption, not library developers. when we get there, we should revisit this

ChristopherA: https://w3c-dvcg.github.io/

ChristopherA: yes, this group is not chartered to do the signing stuff
… https://w3c-dvcg.github.io/ is a sub-part of the Credentials CG
… more specs are emerging from that CG
… but in the end we are competing against JOT and JWG family of JSON specs
… but the nature of their canonicalization causes a number of problems including security issues and doesn’t do well with LD
… the heart of it: can whatever does LD communicate to the canonicalization in and out?
… the lack of canonicalization is the only thing that keeps us doing ugly things.
… not a huge expert– looks to the tree model habitually, not the graph model
… but recognize the strength of the graph model

Gregg Kellogg: Perhaps a TPAC meetup on it, which could lead to such a group.

Jeff Mixter: sometimes the proposal to be developer-centric and the proposal to be RDF-centric may conflict
… sometimes we have instances that are not round-trippable
… we need to strike a balance between developer ease and technical qualities like round-trippability
… for practical use we need to be able to shift between syntaxes

Benjamin Young: would mixterj be able to lead a task force to look at round-tripping?

Jeff Mixter: sure can

ChristopherA: +1

Rob Sanderson: the next prinicple: use cases should be supported by real data
… a reasonable way to make decisions about what’s in, what’s not

Gregg Kellogg: do we want a use cases and requirements document

ChristopherA: Doesn’t W3C now require use cases?

Gregg Kellogg: from which we can move forward to the work of writing

Rob Sanderson: In my experience, that slows down the work no end

Jeff Mixter: +1 to azaroth

Gregg Kellogg: but will we document the use cases, and how? maybe just a wiki?

ChristopherA: +1 to document to share/publish as a WG Note

Rob Sanderson: a wiki page would be a great way to start

Ivan Herman: azaroth said most of what I wanted to say
… use case documentation slows things down tremendously
… we have a strong requirement for back-compatibility
… we are not starting from scratch– we should not behave as tho we were

Benjamin Young: agree generally. the danger of a use case document is that it can block work
… especially for new features, we can be clear about utility and back-compatibility
… which could go into a primer later

Rob Sanderson: +1 to bigbluehat ; rationale tracking and pedagogical tool

Ivan Herman: is there a record of the use cases discussed by the CG?

Gregg Kellogg: No
… more nuanced: yes, in the meeting minutes etc, but not a formal doc

Rob Sanderson: next item: require two orgs to have a use case (although those two orgs needn’t be W3C members or particpiating)

ChristopherA: fine to require this for some internal process things
… the IETF standard is not two orgs, but two different impls
… and problems have arisen because of the lack of JSON-LD implementations
… wouldn’t mind going back to the IETF standard of “heterogenous solutions must be available” to get from draft to full standarad
… if this community can’t get two impls that can talk to each other, we have probably failed

Rob Sanderson: W3C does require two independent impls to get to rec
… this is more about how we prioritize
… we don’t want a single org clamoring for a single feature that only serves them

Gregg Kellogg: two interoperable impls requirements is for Candidate Rec, which is a ways away
… there are multiple impls in multiple language ecosystems

Benjamin Young: one thing that is happening is a desire to do a lot of these things in tandem
… it’s healthy to get measures of interest, testing, etc

ChristopherA: just want to be careful not to get into a situation with one implementation that really fully interoperable
… and a bunch of others that are second-class citizens
… would want to pull features if there is only one impl for a feature

Harold Solbrig: not sure what “has a use case” means, feeling a bit bristly about it
… the org hsolbrig represents is a standards body that supports many users
… so who actually has the use cases?

Gregg Kellogg: in 1.0 and CG, the practice was to develop the test suite alongside the spec
… tricky, because it requires implementors to actually follow the ups and downs of the spec
… not just wait for a finished product
… and disagrees with the characterization of problematic interop for 1.0

Ivan Herman: to be precise, from the W3C POV, we require is that every feature is impl’d by at least two independent impls
… example– two browsers, each based on Chromium, cannot independently impl a Chromium-dependent feature
… what does feature mean? The WG defines that for itself.
… there is experience from other groups to be reused.
… and we can have very independent implementations if we want

Rob Sanderson: +1 to Ivan! Meant as guidelines to help us make decisions, not strict, objective and normative rules that we’re going to follow to the letter

Ivan Herman: a use case from a consortial org can be very strong, because it may be widely shared

Rob Sanderson: “support” for use cases is really the point
… and orgs that rep other orgs should be able to “vote” on their behalf
… so an org that offers a use case from three other orgs is fine
… this is just a way to engage with feature discussions sensible and productively
… rather than tug-of-war over feature inclusion

ChristopherA: +1

Ivan Herman: let’s get this into markdown and on the website

Rob Sanderson: Consistency is better than exceptions
… two things is easier to remember than twenty

Benjamin Young: we struggled but succeeded in making this case to the Web Annotation group
… one thing that would have benefited that community would have been a primer about how to get your use cases arranged into the common model

Rob Sanderson: Thanks to Adam for scribing!


5. Resolutions