The W3C JSON-LD Community Group

JSON-LD Syntax and API

Go Back

JSON-LD CG Telecon

Minutes for 2018-03-12

Agenda
https://lists.w3.org/Archives/Public/public-linked-json/2018Mar/0002.html
Topics
  1. Charter
  2. pull requests
  3. issue #610 Allow @vocab: @id to make term expansion relative to resource's @id
  4. issue #604 @base is (still to be) ignored in remote contexts
Resolutions
  1. Allow 6 weeks for the AC review
  2. accept #597 and #606 immediately. Provisiounally accept #603 and #609 pending review, and in the case of #603, explicity feedback from Kingsley
  3. resolve as won’t fix, with brief discussion on merits of blank nodes
  4. make @base invalid within scoped contexts
  5. resolve #604 as won’t fix
Organizer
Gregg Kellogg
Scribe
Robert Sanderson
Present
Robert Sanderson, Gregg Kellogg, Ivan Herman, Benjamin Young, Niklas Lindström, David I. Lehn
Robert Sanderson: Regrets+ Niklas_Lindstrom
Robert Sanderson is scribing.
Robert Sanderson is scribing.

Topic: Charter

Ivan Herman: Gone through the W3M review. Two comments, from Phillipe and Ralph, taken care of already.
... Phillipe's resulted in a change to the charter. Ralph and Ivan were away last week, PR open for editorial issues.
... With that, we are ready to go to the next step -- the formal AC review
... Need some sort of feeling for how long to have the AC review open for. Must be at least 4 weeks, can say we prefer 6.
... Charter says June 1 for start of WG, so have ample time
... How much energy and time do we think we'll need to get 20-22 approvals from AC reps. Don't have to sign up for it, just say that it's a good idea
... On this group I see Wiley, Getty, Spec-Ops, Digital Bazaar. Still need many more. Would be good to have an approval from Google.
... Not sure if that's a given, or what has been discussed with danbri
... We might find some in the publishing group.
... Readium uses JSON-LD, so there's one more. Anyway, we need them.
Gregg Kellogg: There's also the web of things folks. Other digital library folks, eg Stanford.
... As far as danbri, he has engaged with the chartering and suggested things to help with schema.org in 1.1.
... Hopefully that translates to Google support.
... Long had engagement with Apple, but not necessarily translates to an AC vote.
Ivan Herman: Should probably not count on that one.
Gregg Kellogg: No counter feedback, no one seems to disagree.
Ivan Herman: True but not enough
... I think, we're not in a huge hurry, we can give ourselves 6 weeks instead of 4.
PROPOSAL: Allow 6 weeks for the AC review
Robert Sanderson: +1
Gregg Kellogg: +1
Ivan Herman: +1
Robert Sanderson: On the topic of danbri, he’s now in the states and has reached out to talk about JSON-LD. [scribe assist by Gregg Kellogg]
RESOLUTION: Allow 6 weeks for the AC review
Ivan Herman: Not urgent, but in those 6 weeks we should try to get together to agree on what tools we use, the URL of the WG etc. All the small things for the charter.
... Need to set up the final charter with the URLs by the time it's finished. Use w3c github for the specs, where to put hte minutes, etc etc
Gregg Kellogg: Current json-ld.org should remain as a CG resource. Doesn't have an official capacity, with the possible exception of hte test suite.
... otherwise makes sense to use the standard w3c gh setup
... minutes are on GH now ... something to be said for continuity across the CG and the RDF WG previous work. Might be able to alias it.
Ivan Herman: No need to decide now, have lots of time to figure out the details.
... Need to check what sort of announcement we need to do. Coralie will do the normal posts.
Gregg Kellogg: When should it go to the AC?
Ivan Herman: It could go out this week, but need the feedback from Ralph.

Topic: pull requests

Gregg Kellogg: Starting with #597, for omitGraph
... We changed the way it works to be false by default and the processing mode isn't taken into account.
... This has had the unfortunate side effect of muddying the waters of what @base means
... It's established traditionally by the document location
... It has been confusing for people. It's like @xml:base, which signals the document location
Ivan Herman: Two things came to the fore in the discussion. The normative text doesn't clearly say the base IRI default value is the document IRI.
... You can get to the conclusion, but it relies on non normative text
... that makes me a bit worried that we have the same mistake in other places too. That things are concluded from non-normative text.
Gregg Kellogg: Requires a much deeper read through. A big topic! There's a phrase at the beginning of the API that says processors need to follow the informative algorithm
Ivan Herman: But that's not enough
Gregg Kellogg: I agree, we need to show there's a path and look for other such paths that are missing
Ivan Herman: One specific thing I was surprised by, the webIDL is not normative.
... some things would be easier, I think, if it was normative. I wasn't part of the earlier discussions.
Gregg Kellogg: Good question as to why it's non-normative ... I guess because processors aren't expected to process it directly, but I think that's the case in other specs
... given how much we rely on the descriptions there, it's hard to see it as non normative
... We can make that normative, perhaps as part of this PR
Ivan Herman: I had looked into the normative part, and found a place where it would make things good enough.
Gregg Kellogg: If the value is @base the value of baseIRI must be used
Ivan Herman: Yes. Two more things -- the informative part should have a part for when base is not used. That would make things very clear.
... if it took us that much work to convince ourselves, others will have a hard time to realize it. However, this morning I was wondering about muddying the water even more
... when we had this discussion two weeks ago, the use case that Kingsley had, was the case when they want to have the vocab set to the doc's URL
... the idea to use base as the value for vocab was an immediate answer, but we see it to be pretty complicated
... have a feeling we need to be careful about feature creep too. Use case oriented is needed!
... so ... do we need all that or is it enough to introduce a new keyword that represents the document URI
... the minimal thing is much easier to spec, as it doesn't get mixed up with other features, and allow the full change if we only need it for other use cases
Gregg Kellogg: We did have different keywords for subject and reference, but settled on using just @id
... in this case we were looking for grammar to sya that the vocabulary relates to the document base
... this comes down to the same idea
Ivan Herman: No, because we realize that if we use @base as vocab, we do more than what the use case requires
Gregg Kellogg: (Explains base, scribe was blowing nose, sorry)
Gregg Kellogg: If you set an explicit document base and you expect the doc to be relative to the base, you expect the one it was set to, not the actual document location
... in terms of the changes needed to support it, it was trivial. It relies on the IRI expansion / compaction algorithms
Ivan Herman: I see the point, I'm still a bit uneasy
Gregg Kellogg: Suggest that we continue working on the language for this, and when ivan is okay we can merge
Robert Sanderson: +1
Ivan Herman: Fine with that
... I would like also an explicit reaction from Kingsley and Ted that this is actually what they need
Gregg Kellogg: I @ him in most comments. If they were unsatisfied, I think they would have commented back
... the use case relates directly to the example they were using
Ivan Herman: We can ask for an explicit +1 from them
Benjamin Young: Shouldn't take silence as assent
Gregg Kellogg: Merge criteria are ivan and either kingsley/ted or pchampin being explicitly okay
Gregg Kellogg: PR 606
Gregg Kellogg: There's a mismatch in expectations about what it means to add a context. It's slightly different than is laid out -- the processor behaves as if the context were placed inline -- which is always the case, but the term definition can be replaced, which would replace the original scoped context
... just as other attributes would be removed
... Ready to go?
Robert Sanderson: (Explains background, asserts good to go)
Niklas Lindström: @Ivan, re. @base and the use case (sorry for replying late); did you see my comment: https://github.com/json-ld/json-ld.org/issues/488#issuecomment-368606840 ?
Gregg Kellogg: This is one david added to clarify some issues. Haven't had a chance to test it yet. Pending review, good to go on this one too
David I. Lehn: Added support in python and JS to make these tests work
PROPOSAL: accept #597 and #606 immediately. Provisiounally accept #603 and #609 pending review, and in the case of #603, explicity feedback from Kingsley
Gregg Kellogg: +1
Robert Sanderson: +1
Ivan Herman: +1
Benjamin Young: +1
RESOLUTION: accept #597 and #606 immediately. Provisiounally accept #603 and #609 pending review, and in the case of #603, explicity feedback from Kingsley

Topic: issue #610 Allow @vocab: @id to make term expansion relative to resource's @id

Gregg Kellogg: This came in as I was leaving. Not in favor of doing something like this, but wanted to understand the use case.
... a third axis beyond base and vocab doesn't make sense. Would be better to use the document base somehow
... solution might be to use reverse properties, that they can link to something at the doc base, which was not expected to be the subject
Ivan Herman: Sometimes having a blank node is a good thing. If we had this, we'd be forced to use an id: _x
... if you don't have id, it just creates a blank node. The equivalent in turtle of using []s without an id
... Would also make a big difference between json-ld and turtle.
Gregg Kellogg: Inclination is resolve as won't fix, linking to this discussion.
PROPOSAL: resolve as won’t fix, with brief discussion on merits of blank nodes
Gregg Kellogg: +1
Ivan Herman: +1
Robert Sanderson: +1
Benjamin Young: +1
Ivan Herman: Also symmetry with turtle
Gregg Kellogg: Also, not symetry with Turtle.
RESOLUTION: resolve as won’t fix, with brief discussion on merits of blank nodes

Topic: issue #604 @base is (still to be) ignored in remote contexts

Gregg Kellogg: This is the idea of ignoring base definitions in remote contexts. We disallowed it in 1.0
... any system that brought in definitions externally would need to do it, as it would alias a lot of different documents together
... We had a way to get around it as vocabs let you do this.
Ivan Herman: ???
Gregg Kellogg: The issue was to allow base in term definitions. The way I interpret it as a term is resolved relative to the document base, rather than to the vocab
... in this case alice knows bob. As a result, we don't need to explicitly define bob, as he is defined document-relative
... the problem is how you can specify that namespace to use for knows
... equivalent to saying we have a context with a base in it.
... vocab can already do that.
Ivan Herman: Find it very confusing. Trying to fight anything that makes it more complicated!
... It sounds like they think it's a good idea, not a clear use case.
... should be careful about this.
Gregg Kellogg: I believe my example at the end shows a different way to achieve the same thing.
... but it raises base in a scoped context. We don't have a way to say that it /can't/ be in there
... the only distinction is remove vs local
... Don't have algorithm that scoped contexts in remote documents should be removed, but better to have it just invalid as a scoped context
PROPOSAL: make @base invalid within scoped contexts
Gregg Kellogg: +1
... will propose that.
Robert Sanderson: +1
Ivan Herman: +1
Benjamin Young: +1
RESOLUTION: make @base invalid within scoped contexts
Niklas Lindström: The use case is to be able to use local identifiers in a given namespace. For instance: {"classification": "XYZ"} where XYZ is resolved against e.g. id.loc.gov/subject/.
PROPOSAL: resolve #604 as won’t fix
Robert Sanderson: This also gets into confusion between @vocab and @base [scribe assist by Gregg Kellogg]
Robert Sanderson: +1
Ivan Herman: +1
Benjamin Young: +1
RESOLUTION: resolve #604 as won’t fix
Ivan Herman: For the AC vote, it would be good to have as few open issues as possible
... If there's something that's wontfix, then they'll be closed?
Gregg Kellogg: Yes
Ivan Herman: Good, we don't want reviewers coming back saying "go back and incubate and sort out the issues"
Gregg Kellogg: The best way to look at the issues is ^^^
... 26 issues, several are trivial
... also could add a `defer` label
... On the next call we can go through open issues as to which we'll explicitly defer
(+1)
... in the mean time, text for PRs to close down issues would be good. For editorial, just make the changes
Ivan Herman: Yes, just make the changes. You understand what I'm afraid of
Gregg Kellogg: If someone else has time to help resolve some of the eidtorial issues would be great of course