16:37:08 <RRSAgent> RRSAgent has joined #json-ld
16:37:08 <RRSAgent> logging to https://www.w3.org/2019/02/01-json-ld-irc
16:37:09 <ivan> rrsagent, set log public
16:37:09 <ivan> Meeting: JSON-LD Working Group Telco
16:37:09 <ivan> Chair: bigbluehat
16:37:09 <ivan> Date: 2019-02-01
16:37:09 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0017.html
16:37:09 <ivan> ivan has changed the topic to: Meeting Agenda 2019-02-01: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0017.html
16:55:59 <bigbluehat> present+
16:57:27 <workergnome> workergnome has joined #json-ld
16:57:46 <azaroth> azaroth has joined #json-ld
16:58:42 <Zakim> Zakim has joined #json-ld
16:59:38 <pchampin> pchampin has joined #json-ld
17:00:39 <gkellogg> present+ Gregg_Kellogg
17:00:46 <simonstey> simonstey has joined #json-ld
17:01:00 <dlongley> present+ Dave_Longley
17:01:15 <workergnome> present+
17:01:20 <simonstey> present+
17:01:23 <pchampin_> pchampin_ has joined #json-ld
17:01:40 <azaroth> present+ Rob_Sanderson
17:02:31 <timCole> timCole has joined #json-ld
17:02:38 <ivan> present+
17:02:44 <bigbluehat> Topic: Scribe Selection
17:03:01 <bigbluehat> scribenick: workergnome
17:03:11 <bigbluehat> Topic: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-25-json-ld
17:03:26 <bigbluehat> +1
17:03:31 <workergnome> bigbluehat: Time to approve the minutes.
17:03:35 <bigbluehat> PROPOSAL: approve minutes
17:03:36 <bigbluehat> +1
17:03:36 <gkellogg> +1
17:03:37 <dlongley> +1
17:03:38 <workergnome> +1
17:03:41 <azaroth> +1
17:03:43 <simonstey> +1
17:03:44 <ivan> +1
17:03:47 <bigbluehat> RESOLVED: approve minutes
17:03:55 <workergnome> bigbluehat:
17:04:02 <jeff_mixter> jeff_mixter has joined #json-ld
17:04:06 <bigbluehat> Topic: Face to Face - Feb 7 & 8
17:04:08 <ajs6f> ajs6f has joined #json-ld
17:04:09 <workergnome> bigbluehat:  next topic, Face to Face!
17:04:10 <jeff_mixter> present+
17:04:14 <ajs6f> present+
17:04:34 <workergnome> ... note that the location did Change to the Folger Shakespeare Library, which is in the same area of the national mall
17:04:56 <workergnome> azaroth: Rob's double-checking that we just show up at 10 to 9am.
17:05:03 <workergnome> ivan: should we have IDs?
17:05:13 <workergnome> azaroth: won't hurt.  I'll confirm.
17:05:27 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2019.02.DC
17:05:34 <workergnome> bigbluehat: show up at the Folger
17:05:56 <workergnome> gkellogg:  let's organize a dinner wednesday night.
17:05:57 <bigbluehat> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit
17:06:01 <hsolbrig> hsolbrig has joined #json-ld
17:06:09 <hsolbrig> present+ hsolbrig
17:06:11 <workergnome> bigbluehat: if you're into that, add your name to the agenda doc and someone will pick a location.
17:06:32 <pchampin__> pchampin__ has joined #json-ld
17:06:50 <bigbluehat> Topic: Review the F2F agenda
17:07:00 <workergnome> \me lost audio for a sec
17:07:10 <bigbluehat> s/\me lost audio for a sec//
17:07:35 <bigbluehat> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit#heading=h.1ryfaao4cgcc
17:07:40 <workergnome> bigbluehat:  let's review the agenda for F2F
17:08:03 <workergnome> ... this is based on very rough estimates, but there's a list of issues to address
17:08:22 <workergnome> ... hope you've all looked through that, but we've talked about them over the past six months
17:08:38 <workergnome> ... queue up if you want to add new things to that agenda
17:08:52 <azaroth> +1 to the list :)
17:09:30 <azaroth> q+
17:09:39 <bigbluehat> ack azaroth
17:10:07 <workergnome> azaroth:  note one thing...pretty soon, we'll need to close the issue list for new features.
17:10:20 <workergnome> ...if we're going to meet august timeframe, we can't keep adding things.
17:10:44 <workergnome> ... if there are things that have come up in your work, get them in now.  You've got three weeks or so.
17:10:54 <bigbluehat> q+
17:11:01 <dlehn> present+ David_Lehn
17:11:06 <pchampin> pchampin has joined #json-ld
17:11:29 <bigbluehat> ack bigbluehat
17:11:30 <workergnome> ... the intent of the f2f is to knock out the big ones like sealed context, contexts with metadata, and things we've talked about, but haven't come back to, circular contexts, unmppped JSON, etc.
17:11:44 <workergnome> bigbluehat:  can we go over the rough timeline for CR?
17:11:44 <ivan> q+
17:11:49 <bigbluehat> ack ivan
17:12:21 <workergnome> ivan: we have to count backwards..the charter goes til June 20
17:12:49 <workergnome> ... we should wait 6,7 weeks, so we should publish a reccomendation in May, so the rest is what we think we'll need to go through CR.
17:12:58 <bigbluehat> s/June 20/June 2020
17:13:14 <workergnome> ... if you're not familiar with the Jargon, that's Candidate recommendation.  At that point, no new technical features
17:13:36 <workergnome> ... but we need to prove to the world that all features can be implemented by two independent implementations.
17:13:59 <workergnome> ... doing implementations, technical issues may come up, so we may have to republish a CR, but hopefully that won't happen
17:14:14 <workergnome> ... we need to think about how much time will we need to generate two implementations.
17:14:26 <workergnome> ... ideally, it would be nice to have 3 or 4 implementations. 5, even!
17:14:40 <workergnome> ... we should discuss at some point the testing procedure, test suites, reporting, etc.
17:14:46 <workergnome> ... this is usually a complicated thing to do
17:15:02 <workergnome> ... we are lucky that gkellogg has done this before
17:15:31 <workergnome> ... what we've said is that to be one the safe side we should be in CR by TPAC in Sept. 2019 in Japan
17:15:45 <workergnome> ... that's a reasonable goal, so we have six months to go through testing
17:15:57 <workergnome> ... knowing that there are some implementations, so we're not starting from scratch.
17:16:36 <workergnome> ... for CR to be published in September, taking into account the editorial work, clarity, etc, I would think that we should have things solved or postponed by early mid-summer this year
17:16:37 <bigbluehat> q+ to confirm that CR === "feature freeze" period
17:16:41 <bigbluehat> ack bigbluehat
17:16:41 <Zakim> bigbluehat, you wanted to confirm that CR === "feature freeze" period
17:16:59 <workergnome> bigbluehat: Based on what Rob said, then feature freeze is TPAC?
17:17:11 <workergnome> ivan: sort of, we need editorial work before hand.
17:17:31 <workergnome> bigbluehat:  That gives us sixish months.
17:17:44 <workergnome> ... that's the target.  other questions?
17:17:44 <gkellogg> q+
17:17:47 <bigbluehat> ack gkellogg
17:18:18 <workergnome> azaroth: if you could all look through the issues before showing up, it'll make it quicker to discuss
17:19:43 <workergnome> gkellogg: we inherited a robust testing structure from 1.0, and we've maintained tests, my implementation is tracking them, the primary thing is to migrate that to W3 space so we can get redirect access.
17:19:58 <workergnome> ivan: is this true for framing?
17:20:18 <workergnome> gkellogg: framing doesn't need HTTP magic, but it would still be good to move it to W3 space
17:20:33 <workergnome> ivan: is the test suite for framing available?
17:20:58 <workergnome> gkellogg: yes--I bifurcated the tests so they're in two repositories, but it's up to implementations to figure out how to run them themselves.
17:21:05 <bigbluehat> q+ to ask about moving to W3C infra
17:21:07 <bigbluehat> ack bigbluehat
17:21:07 <Zakim> bigbluehat, you wanted to ask about moving to W3C infra
17:21:09 <workergnome> ... we've got reporting structure
17:21:31 <workergnome> bigbluehat: don't we need to move that to W3C testing space?
17:21:32 <dlehn> ye olde implementation report: https://json-ld.org/test-suite/reports/
17:22:08 <workergnome> ivan: the w3c test evironment is geared toward testing browser components/features, and may not be suitable for this.  We had the same issue with Annotations.
17:22:22 <workergnome> gkellogg:  we're closer to what's been used for RDF/Sparql tests
17:22:28 <workergnome> ... you can run them off of GitHub now
17:22:55 <workergnome> ... for something with a base URI, having a good uri would be nice.  But it has nothing to do with the browser test implementations
17:23:24 <workergnome> bigbluehat: do we go that route, like annotations, or do we move to w3c?  We can take it offline, but we should try it out, to encourage early testing
17:23:52 <workergnome> gkellogg: encourage people to try other people's software, and ping the implementers who may not have been involved in this process
17:24:39 <workergnome> azaroth: regarding the list:  we haven't talked about circular imports.  What should we do?  issue 14.  108, 86...those two are about assertions in one context about an external context?
17:24:52 <workergnome> ... f you load schema.org, can you expect a hash for changes
17:25:18 <workergnome> ... take various nodes from the graph and put them in a set location (includes), rather than have them show up in various locations via walking the tree
17:25:38 <workergnome> ... support JSON values not mapped, includes JSON within a JSON-LD document, not in a string
17:25:49 <workergnome> ... these are the ones that are good to do in person
17:25:54 <pchampin_> pchampin_ has joined #json-ld
17:25:54 <gkellogg> q+
17:26:01 <workergnome> ... that means that we should be able to close out all the open issues
17:26:12 <bigbluehat> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit#heading=h.cuj1fpex2b35
17:26:17 <bigbluehat> ack gkellogg
17:26:18 <workergnome> bigbluehat: I missed the 4 friday issues, and check out the real agenda items
17:26:49 <workergnome> gkellogg: something that is related is the ability to reference a context without needing it to be loaded, which in hash link etc address a lot of the usecases
17:27:14 <workergnome> ... I din't know if hash links addresses Schema.org
17:27:50 <workergnome> ... if you assume that what they want to see is no way to change the way that it looks, and the context is the same, without making a lot of more complex things, it seems unlikely they'd want to go there
17:28:22 <workergnome> ivan: maybe we should try and get danbri online?
17:29:23 <bigbluehat> Topic: Review Pierre-Antoine’s proposal for sealed context processing
17:29:28 <bigbluehat> https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0016.html
17:29:37 <workergnome> gkellogg: I can represent pchampin's issue, since he can't call in due to internet connectivity problems
17:29:51 <workergnome> ... There's an issue, and discussion in the PR
17:30:10 <ivan> https://github.com/w3c/json-ld-syntax/pull/119
17:30:15 <gkellogg> https://github.com/w3c/json-ld-syntax/issues/20
17:30:27 <workergnome> ... the pricbple issue in #20, and pchamin's work is around syntax
17:31:06 <workergnome> ... basically, he suggests sealing contexts, not terms, though it's not design limited that way
17:31:26 <workergnome> ... and sealing a context, the term definitions are tagged with an identifier associated with that context
17:31:41 <workergnome> ... an implementation, for each term def., you know which context it comes from (for sealed contexts)
17:31:44 <ivan> -> the proposed text for the syntax draft: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/119.html#sealed-contexts
17:32:01 <workergnome> ... so if you attempt to update that within a sealed mode, you can only update it if the update is coming from the sealing context
17:32:07 <workergnome> ... this would happen for embedded contextx
17:32:20 <ajs6f> s/mode/node
17:32:34 <workergnome> ... so if I define a term foo, and that context wants to update a term in that context, you can see the terms that the updated terms came from the same context
17:32:45 <workergnome> ... that would allow terms defined in other sealed contexts to not interfere
17:32:58 <workergnome> ... so you cannot create a term that interferes with a different sealed contexts.
17:33:05 <azaroth> q+ to ask if the seal id needs to be separate from the URI of the context
17:33:22 <workergnome> ... there is a list of active sealed contexts active during expansion...
17:33:39 <workergnome> ... that effectively unseals all the other contexts when processing
17:34:03 <workergnome> ... if you were to descend into another property not associated, that would have the effect of unsealing all contexts.
17:34:20 <workergnome> ... if you use a term from a context, even if it's unsealed, you now enter a mode where the context is sealed.
17:34:55 <ivan> q+
17:35:00 <workergnome> ... what this means for sealing contexts or terms, since you're tagging the context info per-term, it seems straightforward to do that per-term.  There is no support for sealing part of a term, say the ID, but not the container
17:35:02 <bigbluehat> ack azaroth
17:35:02 <Zakim> azaroth, you wanted to ask if the seal id needs to be separate from the URI of the context
17:35:03 <workergnome> ... no use cases
17:35:45 <workergnome> azaroth: does the seal ID need to be different than the context ID? is it specified explicitly?
17:36:08 <workergnome> ... does this mean that the top context might be sealed, but an embedded one might be unsealed?
17:36:12 <bigbluehat> q+
17:36:16 <bigbluehat> ack ivan
17:36:54 <dlongley> q+
17:36:54 <workergnome> ivan: he also put a text into the syntax document which describes things and makes it clear and easy to understand
17:37:27 <workergnome> ... there was also an issue: what happens if you do something that is not kosher?  one possibility is a warning and you ignore, the other is to throw an error
17:37:43 <workergnome> ... and some of the examples will change based on that answer.  It's a decision
17:37:46 <bigbluehat> ack bigbluehat
17:38:06 <workergnome> bigbluehat:  This felt a lot like one context being last
17:38:42 <workergnome> ...it would be super if we could have our use cases written up, both verifiable claims and web of things
17:38:45 <bigbluehat> ack dlongley
17:38:48 <workergnome> ... have use cases
17:39:36 <workergnome> longley: I am thinking about this and reviewing it, and looking at it, I'm not sure how it would impact caching of active contexts.
17:39:41 <bigbluehat> API PR https://github.com/w3c/json-ld-api/pull/60
17:39:53 <workergnome> ... I haven't thought through how it works...can we keep track of an ancestry tree?
17:40:01 <ivan> q+
17:40:06 <bigbluehat> q+
17:40:10 <bigbluehat> ack ivan
17:40:13 <workergnome> ... whatever we put in the spec, whatever's matches the output, it's OK.  Still thinking through it
17:40:37 <workergnome> ivan: I am worried that what's described is an implementation strategy, not a requirement for a spec
17:40:39 <gkellogg> q+
17:40:43 <azaroth> +1 to Ivan
17:41:01 <workergnome> ... we should make sure that we don't define the process, but instead what we need to have as normative
17:41:13 <bigbluehat> ack bigbluehat
17:41:13 <dlongley> +1 to Ivan
17:41:14 <workergnome> ... informatively, we can put in examples.  What counts is the test cases
17:41:40 <workergnome> bigbluehat:  we currently don't track term overriding and who overwrote what in what order
17:42:20 <dlongley> +1 ... that would be a helpful tool
17:42:23 <bigbluehat> ack gkellogg
17:42:26 <workergnome> ... so if you have two contexts and one overrides it, there's no awareness of that in the code.  So in a context dev, and to keep sealing in, it would be helpful to know what happened and in which order.  that could clear a lot of confusion
17:42:48 <workergnome> gkellogg:  My feeling tis that we've been overly perscriptive to ensure interoperability
17:43:14 <workergnome> ...embedded contexts cerate a new ID and inherit from the one embedded
17:43:18 <azaroth> q+ to ask about external embedded contexts
17:44:12 <workergnome> ... so I think we need to try and describe that in a way that stays as close as possible to the behavior, and the mental model has to be described in the syntax doc to understand orders of operatins
17:44:22 <bigbluehat> ack azaroth
17:44:22 <Zakim> azaroth, you wanted to ask about external embedded contexts
17:44:31 <workergnome> ...but adding more complexity threatens to degrade performance
17:45:18 <gkellogg> q+
17:45:24 <workergnome> azaroth:  in the proposal, does that include externally referenced, but scoped contexts?  So if I had a doc that had sealing at the top level, and I scoped in schema.org within a term, would that then seal schema.org?
17:45:50 <dlongley> `{"@context": {"sealed": true, "foo": {"@context": "http://schema.org"}}}`?
17:45:57 <workergnome> ... does that seal by reference schema.org?  if you had it as an externally reference, sealed context.
17:46:02 <workergnome> ... what dave said in the chat
17:46:05 <workergnome> ... what happens?
17:46:05 <bigbluehat> ack gkellogg
17:46:28 <ivan> q+
17:46:29 <workergnome> gkellogg:  my feeling is that scoped context is not explicitly sealed.  So, no.  schema.org would not be sealed in that example.
17:46:53 <dlongley> q+
17:47:04 <bigbluehat> ack ivan
17:47:09 <workergnome> ... what you need to know is there is a reference, and we might restrict that to being things in a local/embedded context, have the ability to affect things that were defined in the outer context, but not implicitly seald
17:47:13 <dlongley> q-
17:47:37 <workergnome> ... does the sealing act valid for everything, or are there parts like vocab that are not sealed?
17:47:58 <workergnome> gkellogg:  three top-level directives: version, vocab, language, and base
17:48:15 <workergnome> ... context is not a member of a context, it's a member of a term definition
17:48:57 <bigbluehat> q+
17:48:57 <dlongley> i'll just say -- my view of "sealed contexts" is that someone made a specification for a bunch of terms (a "sealed context") and JSON-only devs will read that spec and apply the rules therein -- not running any JSON-LD processing after that... and we should consider how sealed contexts according to that line of reasoning.
17:49:00 <workergnome> ... the body is an object that contains term definitions, default vocabs...a term definition can itself be sealed, and if that includes an embedded context, and if that's sealed, then the context that it defined in not implicitly sealed
17:49:29 <workergnome> ... I can't update the context with a new context...otherwise the use of context within a context is in the document, and....
17:49:39 <workergnome> .... too many uses of the word "context".
17:49:44 <dlongley> so if we want to allow people to write specs that say: "everything under this term will use schema.org's context" ... that's what JSON devs would expect, no changes
17:49:46 <dlongley> q+
17:49:52 <ivan> q+
17:50:07 <dlongley> we could of course, require those spec writers to redefine all those terms manually if need be
17:50:09 <bigbluehat> ack bigbluehat
17:50:21 <ivan> q-
17:50:36 <bigbluehat> ack dlongley
17:50:37 <workergnome>  bigbluehat: the top level directives...is it imagined that those would be sealed?
17:51:29 <workergnome> gkellogg:  we don't seal base, vocab.  if you want to seal, seal a term. if the default vocab is schema.org, and can't override it...
17:52:04 <workergnome> dlongley: the main use is a spec, like W3c, and they're defining terms in the spec, and will provide the context, and will only apply the rules in the spec.
17:52:24 <azaroth> I agree with that too, but then to me it's going to be clearer if the individual terms are sealed, rather than the terms defined in a context that's sealed, but other features (e.g. base and vocab) are not sealed in that context
17:52:26 <workergnome> ... first, you're using JSON-LD to enable extensibility and semantics.  that means that you want other terms to be created.
17:52:45 <workergnome> ... so I think that losing .vocab won't work.  Sealed contexts should not be constrain things not defined.
17:52:58 <workergnome> ... we should think of how they should behave within that domain.
17:53:21 <workergnome> ... if we want to figure out how it should work, we should think about it in the context of a spec--if there's a term not in the spec, you can ignore them.
17:53:39 <workergnome> ... none of these term definitions will change.  If you' followed the path in the spec, nothing will change.
17:53:47 <workergnome> ... that's what the feature should guarantee
17:54:10 <workergnome> ... everything else is outside of what people who care bout JSON will care about.
17:54:23 <bigbluehat> +1
17:54:25 <workergnome> ... think about this domain through the lens of JSON-only developers
17:54:30 <azaroth> Also +1
17:54:46 <workergnome> ivan: what would happen if Schema.org sealed that context?
17:54:57 <bigbluehat> q+
17:55:26 <workergnome> dlongley: all that would happen is that the terms wouldn't change.
17:56:07 <workergnome> ivan:  using schema.org, some of the terms are underspecified.  So what we do is add our own context that defines, with the same URL, we add additional constraints to the term.
17:56:11 <workergnome> ... this would prevent this
17:56:30 <workergnome> dlongley: if you're redefining these terms, this would lock that possibility.
17:56:31 <gkellogg> q+
17:56:49 <workergnome> ivan: even if I use the URL, but I specify the type..
17:57:00 <workergnome> dlongley: that's a separate issue, but an important one
17:57:17 <workergnome> ivan: this happens a lot with schema.org a lot.  Often I want to make them more precise
17:57:20 <bigbluehat> ack bigbluehat
17:58:14 <workergnome> bigbluehat:  maybe, given large vocabs, sealing many terms, this maybe an API thing, but not a syntax thing?  Can the processor seal/not-sealed to create a processor that says that this context is sealed
17:58:22 <workergnome> ... but the developer chooses
17:58:31 <workergnome> ... and then these terms are sacrosanct
17:58:34 <dlongley> q+
17:58:39 <bigbluehat> ack gkellogg
17:58:40 <workergnome> ... these are the terms my processor must understand
17:58:44 <dlongley> q-
17:59:14 <workergnome> gkellogg: echoing ivan, schema.org author:  Values are expected to be an org or person, but that's defined without a type.  JSON-LD processor will allow a string value there
17:59:19 <dlongley> i'll just say that's interesting (doing this via an API mode/flags) Benjamin ... and worth considering further.
17:59:20 <workergnome> ... not a URI.
17:59:32 <dlongley> q+
17:59:42 <dlongley> interesting, but i don't think will work :)
17:59:52 <workergnome> ... that's a case for updating it for author is explicitly a URI.
18:00:00 <bigbluehat> ack dlongley
18:00:28 <azaroth> +1 to dlongley, agree it needs to be syntactic
18:00:30 <workergnome> dongley:  a good idea, but there will be people who won't know to read the spec and flip on the flags.  it needs to be in the data.
18:00:49 <workergnome> bigbluehat:  we'll see you in a week or less.  look through it, add your notes, etc.
18:01:44 <ivan> rrsagent, draft minutes
18:01:44 <RRSAgent> I have made the request to generate https://www.w3.org/2019/02/01-json-ld-minutes.html ivan
18:01:44 <ivan> zakim, bye
18:01:44 <ivan> rrsagent, bye
18:01:44 <RRSAgent> I see no action items
18:01:44 <Zakim> leaving.  As of this point the attendees have been Gregg_Kellogg, Dave_Longley, workergnome, simonstey, Rob_Sanderson, ivan, jeff_mixter, ajs6f, hsolbrig, David_Lehn
18:01:44 <Zakim> Zakim has left #json-ld