- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 12 Mar 2018 12:09:55 -0700
- To: Linked JSON <public-linked-json@w3.org>
Thanks to Rob Sanderson for scribing this week! The minutes now available: https://json-ld.org/minutes/2018-03-12/index.html.
Full text of the discussion follows for W3C archival purposes.
Gregg Kellogg
gregg@greggkellogg.net
JSON-LD Community Group 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:
https://lists.w3.org/Archives/Public/public-linked-json/2018Mar/0002.html
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: PR #597
https://github.com/json-ld/json-ld.org/pull/597
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.
Gregg Kellogg: PR #603
https://github.com/json-ld/json-ld.org/pull/603
... 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
https://github.com/json-ld/json-ld.org/pull/606
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)
Gregg Kellogg: PR 609
https://github.com/json-ld/json-ld.org/pull/609
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: https://github.com/json-ld/json-ld.org/issues/610
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: https://github.com/json-ld/json-ld.org/issues/604
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:
https://github.com/json-ld/json-ld.org/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22JSON-LD+1.1%22
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
Received on Monday, 12 March 2018 19:10:27 UTC