The W3C JSON-LD Community Group

JSON-LD Syntax and API

Go Back

JSON-LD CG Telecon

Minutes for 2018-01-22

Niklas Lindström: I heard someone but I cannot be heard it seems
David I. Lehn: I can only lurk on call today, busy working on something else
Robert Sanderson: Good morning folks :)
Gregg Kellogg: Voip 03e1 is me
Robert Sanderson: I'm getting tons of echo ... everyone else is okay? Just my line?
Robert Sanderson: Will reconnect
Herm Fisher: Sounds distorted and echoing to me (dialed in voice line and on mute) - Herm
Robert Sanderson: Likewise
Robert Sanderson: Almost incomprehensible
Niklas Lindström: You're line was going crazy [scribe assist by David I. Lehn]
Niklas Lindström: Can you reconnect? you were ok before [scribe assist by David I. Lehn]
Niklas Lindström: Sure
Niklas Lindström: You have weird crackling feedback [scribe assist by David I. Lehn]
Niklas Lindström: Still? i lowered my mic volume too now
Paolo Ciccarese: Hi with, just joined SIP/ - with brittle connection and also hearing badly
Niklas Lindström: Sure
Gregg Kellogg is scribing.

Topic: WG Charter

Robert Sanderson: Over the last couple of weeks we’ve been talking with Ivan Herman at W3C on forming a WG.
Ivan Herman: My name is Ivan Herman, I’m on the W3C team, and have a long history with RDF; I was staff contact on the RDF working group where JSON-LD was standardized, also on RDFa and Annotations.
Robert Sanderson: We’ve been talking about how to charter a WG towards a next version of the JSON-LD specs (1.1 or 2.0).
… We started a very draft version of a proposed charter. We should talk though some things, the first being chairs and editors.
… There were difficulties with having the same person being both a chair and an editor at the same time; this creates a possibility for roles to be confused, so it’s best to avoid the perception.
… As a result, you’ll notice that Rob is listed as chair, but does not include gkellogg, who is chair in the CG, but without gkellogg, there is no continuity in editing the specs.
Ivan Herman: I know there was such a discussion, but it’s a more general issue, having one person playing too crucial a role. I’ve been in other groups where there is a similar situation, and there’s always a dependency on both editors and chairs.
… Having too high a dependency creates practical difficulties. However, I think this is probably not the most urgent issue.
… For those of you not involved with setting up a WG, we have a long way ahead; defining another chair can be done in a couple of weeks.
… The process is such that we should get agreement from W3C management to start at all. I need to submit a request to W3M and send a note to the AC with a draft to get feedback.
… The goal is that by the time we get to formal voting, we’ve sorted out all the issues and voting becomes easier. Of course, some people wait to object to the end anyway.
… For that to happen, we could do that very quickly, as there is already a draft charter; it doesn’t need to be fully done, I think what’s there is pretty much good to go.
… What we need is a decision by this group to go forward. If you agree, I’ll send the request to W3CM tomorrow.
… The practical step to settle is that we have a github repo, and people can submit issues there, but there are outliers that want to use email. We could use existing email address, or set up one specifically for this purpose.
Robert Sanderson: I imagine that everyone is enthusiastic about this.
PROPOSAL: Ivan to ask W3M about JSON-LD working group, as okay to send advance warning/warming to the AC
Gregg Kellogg: +1
Ivan Herman: Advance notice
Robert Sanderson: +1
Paolo Ciccarese: +1
Niklas Lindström: +1
David I. Lehn: +1
Herm Fisher: +1 (Herm)
RESOLUTION: Ivan to ask W3M about JSON-LD working group, as okay to send notice to the AC
… two process questions: can we used a non-W3C Github repo, or does it need to be a repo within the w3c org.
Ivan Herman: For now, it’s fine, when the formal vote comes, I’ll need to put the charter text on W3C space.
… For the WG as well, should we continue to use the current repos, or more to w3c?
Ivan Herman: I think the CSS people use another org, but there may be practical issues that make using the w3c oranzization useful.
… If your in a w3c org, most of the team members have access, so if ivan has a problem, you can get help from someone else. Just practical issues, nothing required.
… We can settle this later.
Robert Sanderson: We should discuss, so we can move CG work there too.
Ivan Herman: Are there other discussions that wouldn’t be of CG interest.
Robert Sanderson: The list isn’t that high a volume that charter discussions would overwhelm it.
… you may need to agree to IPR requirements to sign up for the CG mailing list.
… I agree that the visibility of using the CG list is more valuable than setting up a new list.
PROPOSAL: Use public-linked-json for the discussions of the charter
Gregg Kellogg: +1
Robert Sanderson: +1
Niklas Lindström: +1
Paolo Ciccarese: +1
Herm Fisher: +1 (Herm)
Robert Sanderson: Ivan - poll for call times:
Ivan Herman: I’ll start the process tomorrow, and put Rob on the CC list.
RESOLUTION: Use public-linked-json for the discussions of the charter
Robert Sanderson: Although this time worked for people, there are some for whom this is late, and there might be another prefereable time that would be better for people in Europe.
… further on the charter, I mentioned the chair issue, and it shouldn’t be Gregg.
… Scope is pretty well defined, which boils down to serialization and API, which would also include framing.
… The serialization spec will include discussions we’re working on now.
… the last big issue is the bit about splitting out the JSON-specific bits to enable things like YAML-LD. If we have an abstract syntax that can be made concrete as JSON-LD, YAML-LD and whatever else.
Gregg Kellogg: Also worth looking at the time line [scribe assist by Robert Sanderson]
Robert Sanderson: ... Not sure that we have 18 months of work to do. Might consider intermediate milestones, and continue work on something that follows on
Robert Sanderson: ... And how to address that in the timeline section. If we continue as now, we might have a PR in the first quarter of next year or earlier
Robert Sanderson: ... Based on 18 month overall, so finish up about Dec 2019
Robert Sanderson: In my experience, there are several months of testing and implementation, although may be simpler in our case, as we have a base of implementations to go on.
… Even so, I think 18 months is right, and we’d rather not file for an extension.
Herm Fisher: Is there a test-suite?
Robert Sanderson: Part of the process of getting the Rec is that we must have a test suite, every normative statement must be tested, and implemented by at least two implementations.
… There is a test suite already for 1.0, which may need to be updated.
… We may want to pull out the test suite from the current repo.
Gregg Kellogg: Need to look for corner cases not being tested [scribe assist by Robert Sanderson]
Robert Sanderson: ... One was pointed out this morning for using none in language maps
Robert Sanderson: ... Having an infrastructure and reasonable coverage for the features, we're in pretty good shape
Robert Sanderson: ... One issue is that there are some specific behaviors for looking at redirects and other headers that are called for in the spec, but make it difficult to run from a github repo
Robert Sanderson: ... One of the reasons why we used
Robert Sanderson: ... In w3c space, we would need an alternative way to handle that
Robert Sanderson: In the annotation work, we had a similar problem. We created a server that could be run locally to do this as well.
PROPOSAL: The scope and timing as laid out in the draft charter covers the work appropriately
Robert Sanderson: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Paolo Ciccarese: +1
Herm Fisher: +1 (Herm)
RESOLUTION: The scope and timing as laid out in the draft charter covers the work appropriately
Robert Sanderson: Comments can also be done on email.
Robert Sanderson: There’s also a doodle poll open.
Robert Sanderson: Issue: #569 maps with no keys

Topic: issue #569 maps with no keys

Robert Sanderson is scribing.
Gregg Kellogg: This resolves an issue with the representation of values without a language in language maps
... previously it would not select a value without a language to be used in a language map
... sometimes this is what you want, sometimes it makes it more difficult
... this PR addresses it for index, id, graph, and type maps to allow anything to be added to a map with the key `@none`
... (example, per Example 66 etc in the spec)
... all of these are just syntactic, there's no interpretation in RDF
... the expansion removes the maps
... it complicates the term selection algorithm. We create a prioritized set of containers to look at
... need to add the data in different places in the algorithm to prioritize @none when there is a container
... primary cost is the increased complexity and the number of options to consider during term selection
Robert Sanderson: The value of this is that language is inconsistently recorded in real data. Language maps are a great pattern, but it can lead to inconsistent experience in navigating data when data does not match the pattern. The addition of @none is quite valuable, as all values can be represented using maps now. [scribe assist by Gregg Kellogg]
Niklas Lindström: I am in favor of this PR, as I’ve seen similar use cases. I’m a bit concerned regarding the possibility of using a term bound with a null language to represent the value of something without a language in tandom. It is an existing complication, but I haven’t had time to consider changes to the PR. [scribe assist by Gregg Kellogg]
Gregg Kellogg: … I don’t think we can change previous compatibility.
Robert Sanderson: I think backwards compatibility is an open discussion, but as far as I know, this is the only time where data would be backwards incompatible. [scribe assist by Gregg Kellogg]
Gregg Kellogg: We've avoided the use of empty string as a key as PHP implementations pre 7 have difficulties with it
Paolo Ciccarese: I like the solution in a vacuum, but wondered about how empty strings are handled. [scribe assist by Gregg Kellogg]
Paolo Ciccarese: So @none means we have a key
... and an empty string would be a second way to do it
Gregg Kellogg: The algorithm would be treated as a value, and you'd end up with a value object that had a language and a language that was empty string, rather than no language at all
... You could do that in RDF (I think)
... so they're not isomorphic
... even if most systems would treat them that way
Gregg Kellogg: … So @none is a way of doing it, but would not be treated the same way.
Gregg Kellogg: Backwards compatibility ... if you have a term that allows a language map in 1.0, you would use that for all the values with a language
... and an absolute URI for things that didn't have a language
... in 1.1 it would go into the map with @none. The issue is with two different properties, one for language map and one for language of none
... want to be sure that we'd use a specific term that didn't match /no/ language, and hence compatible with 1.0
... the failing case is in not using a term at all
... the fallback to absolute IRIs is already broken :)
... if that is an issue we could change the behavior based on the version, and hence a 1.1 mode processor could do it one way and a 1.0 processor the current way
... backwards compatible with bugs isn't something I put value on, personally
Niklas Lindström: I agree that the absolute IRI case doesn’t seem intentional, I just wanted to reflect on the empty language tag: I think the lexical representation of language prohibits the use of an empty language. [scribe assist by Gregg Kellogg]
Gregg Kellogg: … Regarding the empty string, I’m pretty sure that was a PHP implementation issue which has since been fixed, I don’t think Python had the issue. Still, I think that the usage of empty strings as keys is a problem. I’ll likely map @none to something else.
Robert Sanderson: Any objections on the PR? [scribe assist by Gregg Kellogg]
Gregg Kellogg: … We can always revisit if issues come up.
PROPOSAL: Accept PR #569
Robert Sanderson: +1
Gregg Kellogg: +Q
Niklas Lindström: +0.5
Gregg Kellogg: +1
Clarification: We'll continue to address issues, but accept the majority of the change
Niklas Lindström: Thanks all!
RESOLUTION: Accept PR #569, and address concerns in new issues