JSON-LD Working Group Telco — Minutes

Date: 2019-06-28

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Ruben Taelman, Gregg Kellogg, Dave Longley, Ivan Herman, Tim Cole, Harold Solbrig, David I. Lehn

Regrets: David Newbury, Rob Sanderson, Pierre-Antoine Champin

Guests:

Chair: Benjamin Young

Scribe(s): Harold Solbrig

Content:

1. Scribe Selection

2. Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-14-json-ld

Gregg Kellogg: +1

Dave Longley: +1

Ruben Taelman: +1

Benjamin Young: +1

David I. Lehn: +1

Harold Solbrig: +0

Tim Cole: +1

Ivan Herman: +1

Resolution #1: minutes approved

3. Announcements / Reminders

Benjamin Young: copy/paste fail and earlybird expired on June 22…
… price going up again in September
… ivan will be going on vacation for a few weeks
… No meeting next week (july 5)

4. Issues

4.1. Continuing discussions from last week around “propagates”

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/174#issuecomment-504513373

Gregg Kellogg: There’s also a PR https://github.com/w3c/json-ld-api/pull/112

Gregg Kellogg: based on Rob’s proposal, but instead of “@src”, uses “@source”…
… @propagates defaults to True except for type scoped contexts, can be overrriden in either case

Benjamin Young: focus on @propagates for now

Dave Longley: https://github.com/w3c/json-ld-syntax/issues/174

Dave Longley: propagate makes sense to me, but there other considerations in type scoped contexts…
… I didn’t check whether gkellogg’s implementation addresses these.
… previous contexts can now be any context, including type scoped, where changes can occur underneath
… have to make sure that @type gets evaluated using previous contexts
… correct keyword sb @import instead of @source
… feature makes a lot of sense to bring ld 1.0 contexts into the 1.1 fold without having to rewrite
… may not make a lot of sense to import 1.1 context, so maybe we should focus on @import 1.0 context

Gregg Kellogg: May need more tests. Checks in compaction and expansion … if type scoped context is overridden to
… @source vs. @import - separate discussion. Should discuss SRI types as well

Dave Longley: It would be unexpected to evaluate @type against type scoped context – it would break round-tripping…
… expectation is that typed value will always be evaluated against previous context.

Gregg Kellogg: can dave represent concern in issue or PR?

Dave Longley: https://github.com/w3c/json-ld-syntax/issues/174#issuecomment-506747857

Gregg Kellogg: if you try to round-trip example above, it would behave as expected. If, however, we were to process @type using
… type scoped context, it would destroy its own type, which would be unexpected.

Ivan Herman: example is drastic, but even if you have a type definition in the scoped context, how does it relate to the type in the enclosing context?

Gregg Kellogg: Prior to PR, worked the way that was expected. The way to update w/ @propagates, would be to add @propagates to second embedded context….
… but question is what is controlling propagation. We need to flesh this out to understand what adding @propagate true to second context
… need to preserve processing chain independent of propagation

Benjamin Young: … appears to be consensus developing around PR

Ivan Herman: I am worried about syntax specification wrt. @propagates that is understandable to user. Would like to see PR that makes this clear spec-wise
… before I would accept API PR, I would like to seen syntax PR w/ examples

Dave Longley: @import speaks to what we can say in the spec, wrt. using @propagate for pulling LD 1.0 and protecting it

Ivan Herman: we need to see the whole story

Gregg Kellogg: JSON-LD 1.0 evolved by thinking of feature, implement and then describe syntax. Approach of syntax and then implementation is difficult. Would prefer to meet in the middle…
… would like to use sample implementation and examples to see whether this is the direction we want to to, followed by syntax spec.

Dave Longley: i’ve also thought about JSON-LD as … “here’s a feature JSON devs want/use to describe their JSON … how do we implement something to express the semantics in there properly?”

Gregg Kellogg: implementation allows us to decide what we prefer before syntax document. Lets not put this on hold

Dave Longley: +1 that both sides are important … we need to be able to describe the syntax simply enough and be able to do things in the implementation to demonstrate it’s even possible

Ivan Herman: You can get situations where awareness of implementation provides clarity, but if you aren’t familiar with the details it may not make a good story to the end user
… would like a clear story defined in document before we do the whole thing.

Dave Longley: +1

Gregg Kellogg: if you look at a grammar such as turtle or sparql, if you don’t take parsing issues into account, you’ve done a disservice. Advocate both ends

Dave Longley: +1

Ivan Herman: Need PR for syntax

Gregg Kellogg: need to agree on @imports vs. @source semantics before we do this in a syntax document. API helps us consider that

Dave Longley: If we do @import, can we add @source in the future? Would you just put both tags?

Gregg Kellogg: Could be done either way - integrity (SRI) becomes a modifier to source URL. In the presence of @sri, that value is extracted and passed to algorithm for evaluating ressults…
… would not import an array of things, so maybe @source makes this clear.

Benjamin Young: Is this more than bike shedding? Two different modes as represented by @source vs. @import. We should focus on semantics, not names.
… two terms represent two semantic categories w/ different behaviors.

Dave Longley: my view on the semantic difference: do you “update” a context you bring in (@import) or are you just making meta data assertions on it (@source) … not everyone will agree, maybe @source can do both.

Benjamin Young: importing a 1.0 context w/ a small 1.1 wrapper sounds “dreamy”…

Gregg Kellogg: agree w/ dlongley’s summary – the diffference between pulling a context in vs. referencing it. @import semantics that allow potential modification makes more sense to me

Dave Longley: using array is “process these contexts in this order”, while @imports allows re-use and modification of existing contexts

Benjamin Young: {"@context": {"@import": "http://...anno.json", "name": "https://schema.org/name"}} <– not a thing? guessing we should clarify the new limitations on @context in general…

Benjamin Young: this substantively changes what is in @context

Dave Longley: ivan brought up issue w/ @protected where people wanted to override schema.org context elements. If terms had been protected, override would fail…
… @import would allow changes before it gets defined.

Harold Solbrig: @bigbluehat: how does @import jive with verifiable credentials, etc.

Dave Longley: yes - this should not run afowl of the rules, as it would allow tweaking. What you can do is add on to array and pull in existing contexts and make them compatible with core contexts defined in specs

Ivan Herman: We need this story. I would like to see it written down and spelled out.

Dave Longley: Can do this, but can’t commit to timing

Dave Longley: “update your context before it is processed … as if the term definitions were always that way”

Benjamin Young: schema.org may change on us in the future, but maybe text –> iri change would make a good example. Does not mean that google will understand what you’ve done…

Ivan Herman: schema.org may not be a good idea. foaf?

Gregg Kellogg: I can create an example of modifying a term. @protected may require more work – another reason that @imports works better vs. @source
… @source and (possibly) @propagates w/ nothing else (except version) allowed?
… if you pull and modify a context, you are @importing it but @source wouldn’t allow mods.
… but question is whether SRI could apply to imports or …

Ivan Herman: My understanding is that SRI refers to the context I identify w/ a URL, whether used in import or source isn’t a big problem
… rob’s original proposal seemed to be simpler – we don’t know whether he would support this or not.

Gregg Kellogg: will work on syntax document and changes to PR

Dave Longley: I’m thinking this shouldn’t be used for embedded contexts, in either @source or @imports situation

Benjamin Young: {"@context": {"@import": "http://...anno.json", "name": "https://schema.org/name"}} <– not a thing?

Benjamin Young: The above should not be allowed?
… Leave github issues as they are…
… next meeting July 12. Same agenda w/o TPAC registration

Ivan Herman: vocab_ is a source of concern

4.2. Use of "@vocab": "_:" in ActivityStreams 2.0 (at least) #183

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/183

Gregg Kellogg: We haven’t removed support for blank nodes, just marked it as archaic and possibly source of warning
… we haven’t broken activity streams, but will issue warnings

Benjamin Young: whole point of this thing is to catch things that might show up in activity streams. If you do consume as json-ld, you do preserve the author’s intent …

Benjamin Young: https://github.com/w3c/activitystreams-testing/issues/4

Gregg Kellogg: if we look at the import activity streams an set @vocab to some urn, that way it doesn’t lose anything and it round-trips, which maps to issue above…

Proposed resolution: closed #183 as wontfix (Benjamin Young)

Benjamin Young: +1

Benjamin Young: they use their own media type in 1.0 to support list of lists. Should there be a follow up issue to say what should be done instead of blank node?

Ivan Herman: +1

Ruben Taelman: +1

Harold Solbrig: +1

Tim Cole: +1

Resolution #2: closed #183 as wontfix

5. Resolutions