15:04:57 <RRSAgent> RRSAgent has joined #json-ld
15:04:57 <RRSAgent> logging to https://www.w3.org/2019/06/28-json-ld-irc
15:04:58 <ivan> rrsagent, set log public
15:04:58 <ivan> Meeting: JSON-LD Working Group Telco
15:04:58 <ivan> Date: 2019-06-28
15:04:58 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0022.html
15:04:58 <ivan> ivan has changed the topic to: Meeting Agenda 2019-06-28: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0022.html
15:04:59 <ivan> Regrets+ workergnome
15:37:37 <rubensworks> rubensworks has joined #json-ld
16:00:21 <bigbluehat> present+
16:00:29 <rubensworks> present+
16:00:38 <gkellogg> present+
16:00:48 <bigbluehat> regrets+ azaroth
16:00:56 <bigbluehat> regrets+ pchampion
16:01:07 <dlongley> present+
16:01:59 <timCole> timCole has joined #json-ld
16:02:30 <ivan> present+
16:02:36 <ivan> chair: bigbluehat
16:02:54 <timCole> present+
16:03:03 <hsolbrig> hsolbrig has joined #json-ld
16:03:06 <bigbluehat> Topic: Scribe Selection
16:03:11 <hsolbrig> present+ hsolbrig
16:03:38 <bigbluehat> Zakim, pick a victim
16:03:38 <Zakim> Not knowing who is chairing or who scribed recently, I propose hsolbrig
16:04:27 <dlehn> present+
16:04:28 <ivan> scribe+ hsolbrig
16:04:48 <bigbluehat> Topic: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-14-json-ld
16:04:54 <gkellogg> +1
16:04:56 <dlongley> +1
16:04:57 <rubensworks> +1
16:04:57 <bigbluehat> +1
16:05:00 <dlehn> +1
16:05:01 <hsolbrig> +0
16:05:05 <timCole> +1
16:05:07 <ivan> +1
16:05:11 <bigbluehat> RESOLVED: minutes approved
16:05:14 <bigbluehat> Topic: Announcements / Reminders
16:05:59 <hsolbrig> bitbluehat: copy/paste fail and earlybird expired on June 22...
16:06:21 <hsolbrig> ... price going up again in September
16:06:25 <dlongley> s/bitbluehat/bigbluehat
16:06:28 <ivan> s/bitbluehat/bigbluehat/
16:06:29 <hsolbrig> ... ivan will be going on vacation for a few weeks
16:07:03 <hsolbrig> No meeting next week (july 5)
16:07:15 <bigbluehat> Topic: Issues
16:07:25 <bigbluehat> Subtopic: Continuing discussions from last week around "propagates"
16:07:36 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/174#issuecomment-504513373
16:07:58 <gkellogg> There’s also a PR https://github.com/w3c/json-ld-api/pull/112
16:08:50 <hsolbrig> gkellogg: based on Rob's proposal, but instead of "@src", uses "@source"...
16:09:23 <hsolbrig> ... '@propagate' defaults to True except for type scoped contexts, can be overrriden in either case
16:10:01 <ivan> s/propagate/propagates/
16:10:07 <dlongley> q+
16:10:11 <hsolbrig> bigbluehat: focus on @propagates for now
16:10:18 <bigbluehat> ack dlongley
16:10:43 <dlongley> https://github.com/w3c/json-ld-syntax/issues/174
16:11:02 <hsolbrig> dlongley: propagate makes sense to me, but there other considerations in type scoped contexts...
16:11:27 <hsolbrig> ... I didn't check whether gkellogg's implementation addresses these.
16:11:37 <ivan> regrets+ azaroth
16:11:45 <gkellogg> q+
16:12:11 <hsolbrig> ... previous contexts can now be any context, including type scoped, where changes can occur underneath
16:12:39 <hsolbrig> ... have to make sure that @type gets evaluated using previous contexts
16:13:14 <hsolbrig> ... correct keyword sb @import instead of @source
16:13:55 <hsolbrig> ... feature makes a lot of sense to bring ld 1.0 contexts into the 1.1 fold without having to rewrite
16:14:22 <hsolbrig> ... may not make a lot of sense to import 1.1 context, so maybe we should focus on @import 1.0 context
16:14:24 <bigbluehat> ack gkellogg
16:15:20 <hsolbrig> gkellogg: May need more tests.  Checks in compaction and expansion ... if type scoped context is overridden to
16:15:26 <dlongley> q+ to say that would be really weird
16:15:57 <dlongley> q+ to say that evaluating `@type` on a type-scoped context in any context other than the previous one would break round-trips and be unexpected
16:16:23 <bigbluehat> ack dlongley
16:16:23 <Zakim> dlongley, you wanted to say that would be really weird and to say that evaluating `@type` on a type-scoped context in any context other than the previous one would break
16:16:26 <Zakim> ... round-trips and be unexpected
16:16:30 <hsolbrig> ... @source vs. @import - separate discussion.  Should discuss SRI types as well
16:17:11 <hsolbrig> dlongley: It would be unexpected to evaluate @type against type scoped context -- it would break round-tripping...
16:17:38 <hsolbrig> ... expectation is that typed value will always be evaluated against previous context.
16:18:25 <hsolbrig> gkellogg: can dave represent concern in issue or PR?
16:18:26 <dlongley> https://github.com/w3c/json-ld-syntax/issues/174#issuecomment-506747857
16:19:29 <hsolbrig> ... if you try to round-trip example above, it would behave as expected.  If, however, we were to process @type using
16:19:50 <hsolbrig> ... type scoped context, it would destroy its own type, which would be unexpected.
16:20:02 <ivan> q+
16:20:14 <bigbluehat> ack ivan
16:20:17 <gkellogg> q+
16:20:51 <hsolbrig> ivan: 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?
16:21:03 <bigbluehat> ack gkellogg
16:21:47 <hsolbrig> gkellogg: Prior to PR, worked the way that was expected.  The way to update w/ @propagates, would be to add @propagates to second embedded context....
16:22:26 <hsolbrig> ... but question is what is controlling propagation.  We need to flesh this out to understand what adding @propagate true to second context
16:22:58 <hsolbrig> ... need to preserve processing chain independent of propagation
16:23:33 <ivan> q+
16:23:38 <dlongley> q+ to ask what people think about `@import`
16:23:43 <bigbluehat> ack ivan
16:23:55 <hsolbrig> bigbluehat: ... appears to be concensus developing around PR
16:24:32 <hsolbrig> ivan: I am worried about syntax specification wrt. @propagates that is understandable to user.  Would like to see PR that makes this clear spec-wise
16:24:53 <gkellogg> q+
16:24:59 <hsolbrig> ... before I would accept API PR, I would like to seen syntax PR w/ examples
16:25:01 <bigbluehat> ack dlongley
16:25:01 <Zakim> dlongley, you wanted to ask what people think about `@import`
16:25:54 <hsolbrig> dlongley: @import speaks to what we can say in the spec, wrt. using @propagate for pulling LD 1.0 and protecting it
16:26:01 <bigbluehat> ack gkellogg
16:26:09 <hsolbrig> ivan: we need to see the whole story
16:27:05 <ivan> regrets+ pchampin
16:27:05 <hsolbrig> gkellogg:  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...
16:27:34 <bigbluehat> s/LD 1.0/JSON-LD 1.0/
16:27:37 <hsolbrig> ... would like to use sample implementation and examples to see whether this is the direction we want to to, followed by syntax spec.
16:28:05 <dlongley> 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?"
16:28:59 <hsolbrig> ... implementation allows us to decide what we prefer before syntax document.  Lets not put this on hold
16:29:26 <bigbluehat> q?
16:29:32 <bigbluehat> ack ivan
16:30:11 <dlongley> +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
16:30:16 <gkellogg> q+
16:30:39 <hsolbrig> ivan: 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
16:30:53 <bigbluehat> ack gkellogg
16:30:57 <hsolbrig> ... would like a clear story defined in document before we do the whole thing.
16:31:46 <dlongley> +1
16:31:57 <hsolbrig> gkellogg: if you look at a grammar such as turrtle or sparql, if you don't take parsing issues into account, you've done a disservice.  Advocate both ends
16:32:06 <dlongley> +1
16:32:20 <hsolbrig> ivan: Need PR for syntax
16:32:55 <dlongley> q+
16:32:57 <bigbluehat> ack dlongley
16:32:59 <hsolbrig> gkellogg: need to agree on @imports vs. @source semantics before we do this in a syntax document.  API helps us consider that
16:33:29 <gkellogg> q+
16:33:36 <hsolbrig> dlongley: If we do @import, can we add @source in the future? Would you just put both tags?
16:33:37 <bigbluehat> ack gkellogg
16:34:51 <hsolbrig> gkellogg: 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...
16:35:10 <hsolbrig> ... would not import an array of things, so maybe @source makes this clear.
16:35:11 <bigbluehat> q+
16:35:15 <bigbluehat> ack bigbluehat
16:35:59 <hsolbrig> bigbluehat: Is this more than bike shedding?  Two different modes as represented by @source vs. @import.  We should focus on semantics, not names.
16:36:31 <hsolbrig> ... two terms represent two semantic categories w/ different behaviors.
16:36:58 <dlongley> 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.
16:37:04 <hsolbrig> ... importing a 1.0 context w/ a small 1.1 wrapper sounds "dreamy"...
16:38:30 <dlongley> q+
16:38:47 <bigbluehat> ack dlongley
16:38:55 <hsolbrig> gkellogg: 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
16:39:25 <bigbluehat> q+ bigbluehat
16:39:31 <hsolbrig> dlongley: using array is "process these contexts in this order", while @imports allows re-use and modification of existing contexts
16:39:37 <bigbluehat> ack bigbluehat
16:39:41 <bigbluehat> {"@context": {"@import": "http://...anno.json", "name": "name": "https://schema.org/name"}} <-- not a thing? guessing we should clarify the new limitations on `@context` in general...
16:39:58 <dlongley> q+ to say this could also help "correct" things in schema.org context :)
16:40:48 <bigbluehat> ack dlongley
16:40:48 <Zakim> dlongley, you wanted to say this could also help "correct" things in schema.org context :)
16:40:50 <hsolbrig> bigbluehat: this substantively changes what is in @context
16:41:30 <hsolbrig> dlongley: ivan brought up issue w/ @protected where people wanted to override schema.org context elements.  If terms had been protected, override would fail...
16:41:46 <bigbluehat> q+ bigbluehat
16:41:47 <hsolbrig> ... @import would allow changes before it gets defined.
16:41:59 <bigbluehat> ack bigbluehat
16:42:08 <ivan> q+
16:42:23 <hsolbrig> @bigbluehat: how does @import jibe with verifiable credentials, etc.
16:43:19 <bigbluehat> s/jibe/jive
16:43:35 <bigbluehat> ack ivan
16:43:37 <hsolbrig> dlongley: 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 spes
16:44:03 <hsolbrig> ivan:  We need this story.  I would like to see it written down and spelled out.
16:44:33 <hsolbrig> dlongley: Can do this, but can't commit to timing
16:45:31 <dlongley> "update your context *before* it is processed ... as if the term definitions were always that way"
16:45:36 <hsolbrig> bigbluehat: 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...
16:45:48 <hsolbrig> ivan: schema.org may not be a good idea.  foaf?
16:47:10 <hsolbrig> gkellogg: I can create an example of modifying a term. @protected may require more work -- another reason that @imports works better vs. @source
16:48:25 <hsolbrig> gkellogg: @source and (possibly) @propagates w/ nothing else (except version) allowed?
16:49:04 <hsolbrig> ... if you pull and modify a context, you are @importing it but @source wouldn't allow mods.
16:49:29 <hsolbrig> ... but question is whether SRI could apply to imports or ...
16:50:08 <hsolbrig> ivan: 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
16:50:11 <bigbluehat> q?
16:50:55 <dlongley> q+ to mention embedded contexts
16:51:01 <hsolbrig> ivan: rob's original proposal seemed to be simpler -- we don't know whether he would support this or not.
16:51:38 <dlongley> q-
16:51:57 <hsolbrig> gkellogg: will work on syntax document and changes to PR
16:53:04 <hsolbrig> dlongley: I'm thinking this shouldn't be used for embedded contexts, in either @source or @imports situation
16:53:25 <bigbluehat> {"@context": {"@import": "http://...anno.json", "name": "name": "https://schema.org/name"}} <-- not a thing?
16:54:07 <hsolbrig> bigbluehat: The above should not be allowed?
16:55:19 <hsolbrig> bigbluehat: Leave github issues as they are...
16:55:39 <hsolbrig> ... next meeting July 12.  Same agenda w/o TPAC registration
16:56:17 <gkellogg> q+
16:56:23 <hsolbrig> ivan: vocab_ is a source of concern
16:56:24 <bigbluehat> Subtopic: Use of `"@vocab": "_:" in ActivityStreams 2.0 (at least) #183
16:56:31 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/183
16:56:36 <bigbluehat> ack gkellogg
16:56:41 <bigbluehat> q+
16:56:54 <hsolbrig> gkellogg: We haven't removed support for blank nodes, just marked it as archaic and possibly source of warning
16:57:14 <bigbluehat> ack bigbluehat
16:57:31 <hsolbrig> ... we haven't broken activity streams, but will issue warnings
16:58:26 <hsolbrig> bigbluehat: 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 ...
16:59:06 <bigbluehat> https://github.com/w3c/activitystreams-testing/issues/4
16:59:18 <hsolbrig> gkellogg: 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...
17:00:34 <bigbluehat> PROPOSED: closed #183 as wontfix
17:00:37 <bigbluehat> +1
17:00:38 <hsolbrig> bigbluehat: 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?
17:00:39 <ivan> +1
17:00:42 <rubensworks> +1
17:00:43 <hsolbrig> +1
17:00:43 <timCole> +1
17:00:52 <bigbluehat> RESOLVED: closed #183 as wontfix
17:01:05 <ivan> rrsagent, draft minutes
17:01:05 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/28-json-ld-minutes.html ivan