JSON-LD Working Group Telco — Minutes

Date: 2018-07-13

See also the Agenda and the IRC Log

Attendees

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

Regrets: Ivan Herman

Guests:

Chair: Benjamin Young, Rob Sanderson

Scribe(s): Tim Cole

Content:

1. Minutes from 6 July

Proposed resolution: Approve minutes: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0010.html (Rob Sanderson)

Rob Sanderson: +1

Benjamin Young: +1

Gregg Kellogg: +1

Jeff Mixter: +1

Tim Cole: +1

Resolution #1: Approve minutes: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0010.html

2. Announcements/Reminders?

Benjamin Young: Any announcements or reminders
… TPAC discount ends at the end of July for registration
… hotel discounted rates are first come first serve

Adam: what was TPAC rate?

Rob Sanderson: rate is 110 Euros per day (including VAT)

Jeff Mixter: I was on last call but not listed in minutes

Benjamin Young: will fix

Benjamin Young: if you are on the nickname list, it is sufficient to just do present+
… if not in nickname list, then need to present+ full_name

Benjamin Young: https://github.com/w3c/json-ld-wg/blob/main/assets/nicknames.json

Rob Sanderson: either do pull request or ping Rob, Ben, or Ivan to add you, if not already in the nickname list

Rob Sanderson: no need for introductions this week

3. Discussion of Guiding Principles

Rob Sanderson: https://github.com/w3c/json-ld-wg/pull/6

Rob Sanderson: not absolute rules but things we think are useful / important
… we will keep walking our way down the document today, hopefully getting through the remaining issues today.

Rob Sanderson: rendered: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md

Rob Sanderson: starting with first item starting ‘Proposed:…

Benjamin Young: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-simplicity-is-determined-by-end-users-not-library-implementers

Rob Sanderson: related to previous, but also focused on helping developers generally
… so if you are a Webmaster you determine what simpler more than the spec writers

Gregg Kellogg: this is how we did it for json-ld 1.0
… we have gotten feedback on the complexity of the algos, but this is result of making it easier for end-users

Adam Soroka: ‘usability’ may be a little more on point than simplicity
… could we go to usability or ease of use to make principle more pointed. Agree with main point.

Rob Sanderson: should we replace simple with usable above as well?

Adam Soroka: I would not suggest doing that now, because this current principle focuses on the audience at hand

Rob Sanderson: +1 to adam

David Newbury: going back to question last week - are data producers different than data consumers?

Rob Sanderson: I think there is an additional distinction between audience using data as JSON and audience using data as RDF
… given target audience is software developers generally
… could be explicitly that we mean both Web developers and developers that work more broadly
… is it easy for developers who have RDF to use vs. an IIIF developer who thinks of it as JSON (RDF is a side-effect)

David Newbury: In IIIF we’ve worked on issues like do we allow arrays or just an object
… do we make it simple to make appropriate documents, even if difficult consume

Benjamin Young: https://www.w3.org/TR/html-design-principles/#priority-of-constituencies

David Newbury: or do we make it easier to consume and harder to produce

Benjamin Young: what to connect to HTML design principles
… this prioritize groups in a fashion similar to what Rob mentioned

Action #1: Add priority of constituencies to guiding principles doc

Action #2: add Jeff Mixter (jeff_mixter) to last weeks present list in the minutes

Adam Soroka: almost no one wants to do RDF , or even JSON
… they want to focus on their business. JSON (or RDF) is a means to an end

Benjamin Young: +1 to ajs6f’s conjecture that devs don’t “want” formats, they want things to work / be done (etc)

Adam Soroka: so if we distinguish between consumers and producers we should prioritize consumers

Rob Sanderson: I want to assert that we should not be opiniated about JSON patterns
… so for example in IIIF if there can ever be multiple values it’s always an array. But this is not the only pattern.
… So, for example schema.org does not do it this way - allows strings and arrays as object for a given property

Adam Soroka: +1 to JSON pattern agnosticism

Rob Sanderson: this puts the oneous back on the context designer for a particular community

David Newbury: The HTML design principles expresses exactly what I want to get at

Benjamin Young: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-provide-on-ramps

Rob Sanderson: next principle is to provide on-ramps (important in LA)
… allows features to be incrementally

Benjamin Young: +1

Rob Sanderson: not sure how often it comes up, but it does help with managing complexity

Adam Soroka: +1

David Newbury: Where this tends to come is up is in sense that complicated patterns build on simple ones

Rob Sanderson: And +1 to workergnome

David Newbury: this can make the complex patterns a little more complex (essentially for backward compatibility)

Benjamin Young: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-define-success-not-failure

Rob Sanderson: next - define success, not failure
… means specify conformance rather than non conformance
… the few NOT constraints the easier our lives will be in the future and the easier to add extensions

Gregg Kellogg: this overlaps with 1.0 decisions that came back to bite us
… for example we decided to be more perscriptive in the context, but we weren’t perscriptive enough about @ signs etc.
… when we later wanted to add type containers, because we had not identified the list of possible containers
… we had to add the @id
… if we had avoided saying that containers had to be one of those listed, it would have been easier

Simon Steyskal: not entire clear what we’re trying to do. Is it like closed vs. open world? or what is the difference?

Rob Sanderson: yes, the open vs. closed world is exactly on point
… if we are silent then you are not out of conformance if you add that feature on your own
… it remains undefined, but it is avoids non-conformance
… like being rigorous with what you send, not what you get
… but on the flip side of being overly prescriptive on 1.0, @type does constrain

Gregg Kellogg: when looking schema.org examples, I came across an example that used @Url where @id was clearly meant

Rob Sanderson: Also there’s a proposal for @label as thinking the @ is magical

Gregg Kellogg: 1.0 processor is okay with this, although would have been nice if we had been more prescriptive in this case

Rob Sanderson: @type as @container:@set issue: https://github.com/w3c/json-ld-syntax/issues/34

Rob Sanderson: @label for rdfs:label issue: https://github.com/w3c/json-ld-syntax/issues/6

Rob Sanderson: next, follow existing standards and best practices where possible

Benjamin Young: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-follow-existing-standards-and-best-practices-where-possible-and-where-they-do-not-conflict-with-other-principles

Rob Sanderson: allows us to ignore a standard that has gone bad, but we should not reinvent

Benjamin Young: +1

Adam Soroka: +1

David Newbury: +1

Rob Sanderson: between new and reuse, pick reuse unless reuse creates a problem

Benjamin Young: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-the-underlying-data-model-is-rdf

Rob Sanderson: last, the underlying data model is RDF - this may be controversial and we may decide to leave off
… Manu has already objected, noting that 1.0 used generic graph set data model (rather than including RDF constraints on graph model)
… so this also has to do with round-tripping discussion
… if we stay with RDF, we then would defer non-RDF compatible features to future
… for example, assuming RDF, would mean not allowing blanknodes as predicate, direction of strings

Gregg Kellogg: Manu is on record that json-ld data model is not same as RDF
… allowing blanknodes as predicates allows creating new identifiers (ala CURIE).

Benjamin Young: here’s our current “Relationship to RDF” section https://w3c.github.io/json-ld-syntax/#relationship-to-rdf

Gregg Kellogg: this does not seem a very useful use case, so the WG could decide that this is an obsolete pattern
… the other use case is data indexing, e.g., data value as key - when json-ld is compacted value becomes subject…
… this is an area of json-ld where it is difficult to create a round trip
… went back and looked at list of list issue history, we abandoned because we didn’t have a use case and at time looked not to be worth it
… but perhaps we should revisit if we have a use case now
… so the main issue right now seems to be the @data issue
… regarding where RDF might go, we probably do not want to get ahead of RDF
… so that we could defer to future.

Jeff Mixter: from a practical standpoint when we do ingest linked data, we tend to normalize to triples to facilitate ingest into triple store or process
… so if json-ld didn’t align with RDF might cause problems
… in library community there is a growing interest in RDF (BibFrame, etc.) so not being able to stay consistent would be a problem

David Newbury: agree with Jeff, if we really were doing a json serialization of graph would look significantly different

Adam Soroka: +1

David Newbury: since we are already 95% with RDF, we really should go whole hug and be 100%

Simon Steyskal: +1

Harold Solbrig: this proposal is slightly confusing, seem to be two possible understandings
… one is RDF needs to be able to represent everything we say with json-ld
… the other interpretation is json-ld needs to be able say everything you can say in RDF.
… the second interpretation may not be all that useful for our users

Rob Sanderson: I agree previous speakers, so as a way forward, can we call out when there’s a 1.0 non-RDF feature
… we have to stay backward compatible, but we can make it very obvious why not to use that feature
… and for any new features we don’t add anything to 1.1 that would be non-RDF
… so the principle becomes a gating one rather than normative. What features should we not add

Rob Sanderson: +1 to understanding costs of adding / not adding

Benjamin Young: may also want to consider the cost of adding / not adding
… we also want to understand who’s using parts of 1.0 that are not expressible in RDF
… we also want to be aware how json developers are using json-ld without caring about RDF
… want avoid letting RDF data model become our albatross
… practically we’ll have to weigh the trade-offs and do the best we can

Rob Sanderson: +1 as well

Rob Sanderson: Are there changes to text that would make this last principle clearer?
… something that would sound less like we want to stop the trains

Gregg Kellogg: to drive this (it will be contentious) should we create a proposal for the WG to adopt as a way of making clear what we’re doing

Rob Sanderson: +1 to being clear about rdf 1.1

Jeff Mixter: +1 for rdf 1.1

Gregg Kellogg: e.g., make clear features from 1.0 that we might deprecate
… alternatively we could propose that the underlying data model is not RDF as a way to provoke feedback
… we need to put stakes in the ground and promote them to get healthy feedback

Rob Sanderson: +1!

Harold Solbrig: following-up it rolls back to a fundamental issue that we need to be able to speak to. We used to say its
… a RDF serialization format. But we need a better answer to what is json-ld?

Rob Sanderson: defer process items on agenda to next week
… Rob will revise PR and tag all of us as reviewer
… if discussion and changes are okay with you, then ignore, otherwise comment
… we need to find happy medium between it’s just a graph and it’s rdf

Benjamin Young: +1 to merging with review on github

Rob Sanderson: do we need a resolution or will we make do with gitHub review

Benjamin Young: will be in touch about upcoming calls

Tim Cole: adjourn

Action #3: Rob to merge changes from the discussion into guiding principles doc

Rob Sanderson: Aye

4. Resolutions

5. Action Items