15:36:26 <RRSAgent> RRSAgent has joined #json-ld
15:36:26 <RRSAgent> logging to https://www.w3.org/2019/05/31-json-ld-irc
15:36:27 <ivan> rrsagent, set log public
15:36:27 <ivan> Meeting: JSON-LD Working Group Telco
15:36:27 <ivan> Chair: azaroth
15:36:27 <ivan> Date: 2019-05-31
15:36:27 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0034.html
15:36:27 <ivan> ivan has changed the topic to: Meeting Agenda 2019-05-31: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0034.html
15:38:37 <azaroth> azaroth has joined #json-ld
15:46:41 <rubensworks> rubensworks has joined #json-ld
15:49:55 <gkellogg> gkellogg has joined #json-ld
15:53:17 <ivan> present+
15:53:44 <gkellogg> present+
15:53:58 <rubensworks> present+
15:55:45 <azaroth> present+
15:55:57 <pchampin> pchampin has joined #json-ld
15:59:53 <workergnome> workergnome has joined #json-ld
16:00:01 <workergnome> present+
16:00:07 <dlongley> present+
16:00:39 <azaroth> regrets+ jeff_mixter
16:00:56 <bigbluehat> present+
16:00:56 <hsolbrig> hsolbrig has joined #json-ld
16:01:02 <hsolbrig> present+ hsolbrig
16:01:24 <timCole> timCole has joined #json-ld
16:01:37 <pchampin_> pchampin_ has joined #JSON-ld
16:01:57 <azaroth> scribenick: workergnome
16:02:17 <ivan> scribe+ bigbluehat
16:02:23 <pchampin_> pchampin_ has left #json-ld
16:02:40 <timCole> present+ Tim_Cole
16:02:53 <azaroth> TOPIC: Approve minutes
16:03:07 <workergnome> azaroth: First thing: minutes!
16:03:09 <azaroth> PROPOSAL: Approve minutes of previous call   https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-17-json-ld
16:03:13 <azaroth> +1
16:03:13 <workergnome> +1
16:03:14 <rubensworks> +1
16:03:15 <bigbluehat> +1
16:03:17 <ivan> 0 :-)
16:03:18 <hsolbrig> +1
16:03:20 <gkellogg> 0
16:03:23 <dlongley> +1
16:03:41 <azaroth> RESOLVED: Approve minutes of previous call   https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-17-json-ld
16:03:59 <azaroth> TOPIC: Announcements / Reminders
16:04:14 <workergnome> azaroth: the registration for TPAC is open, and it's earlier than normal
16:04:33 <workergnome> ... we're intending to have a meeting, unless there's a lot of progress.
16:04:53 <workergnome> gkellogg: I can't come, due to other commitments
16:05:18 <workergnome> ... and will be unavailable next week
16:05:20 <azaroth> TOPIC: Issues
16:05:31 <azaroth> SUBTOPIC: Type scoped context continued; property wildcar
16:05:40 <azaroth> link - https://github.com/w3c/json-ld-syntax/issues/174
16:05:53 <ivan> s/wildcar/wildcard/
16:06:29 <workergnome> azaroth: what is the difference between type scope contexts and property scoped contexts.  Is it scoped to the properties of that class, and other thought of it as a replacement for an inline context, and would then expand beyond that class.
16:07:19 <workergnome> ... where we came to last week is that there are good use cases for both, but the only way to allow for both use cases is to have type scoped contexts be class-only, and to have a way to expand beyond them by setting a default context within.
16:07:28 <dlehn> present+
16:07:35 <ivan> present+ pchampin
16:07:43 <azaroth> q?
16:07:58 <workergnome> ... is that sufficiently detailed to explain where we are right now?
16:08:01 <gkellogg> q+
16:08:08 <azaroth> ack gkellogg
16:08:34 <dlongley> q+
16:08:37 <azaroth> ack dlongley
16:08:38 <workergnome> gkellogg: I didn't quite understand until right now.  I'm trying to think of the syntax
16:09:14 <workergnome> dlongley: my understanding is that what we're looking for is to take this other context and define it within this scoped context, and then use it for all properties within that scoped ontext
16:09:55 <workergnome> ... We want to be able to reuse existing contexts within a type-scoped context, so we don't have to be verbose typing out all of those contexts again.
16:10:24 <workergnome> ... syntactically, we can currently do this by re-writing all contexts within each of those properties, but that's verbose.
16:10:24 <azaroth> Example use case: https://preview.iiif.io/api/image-prezi-rc2/api/presentation/3/context.json type scopes in http://www.w3.org/ns/anno.jsonld for Annotation and AnnotationPage
16:10:49 <gkellogg> q+
16:11:16 <workergnome> ivan: so, if I want to have all schema properties valid within that type-scoped property, and to inherit, and do it by including the schema context file, not each property inline.
16:12:21 <workergnome> azaroth: an example: we're using type scoping within annotations to pull in the annotation context, which is a 1.0 context, and since the decision is that the annotations referred to would no longer inherit, and so this would need to be modified with a new keyword to maintain this behavior instead of retyping each property for each context
16:13:16 <workergnome> ivan: so we want has_body to remain an annotation?
16:13:45 <bigbluehat> s/has_body/hasBody
16:13:50 <pchampin> pchampin has joined #json-ld
16:13:52 <azaroth> ack gkellogg
16:13:56 <workergnome> azaroth: we want the resource that is pointed to by that property to be an annotation, even though that annotation context is only valid on that class
16:14:29 <workergnome> gkellogg: I understood that this could be for specific properties, but I thought of wildcard as applying to all properties
16:14:51 <workergnome> .. for instance, if you're traversing to FOAF, you might not want to continue to use schema.org properties
16:15:09 <workergnome> ... syntax and wildcard: we could use full wildcarding or or something like a URI prefix
16:15:11 <ajs6f> ajs6f has joined #json-ld
16:15:23 <ajs6f> present+
16:15:27 <workergnome> ... but then what happens when they have contexts defined?  I presume they're honored as well
16:15:34 <azaroth> q?
16:15:40 <workergnome> ... how deeply have we thought about the various cases
16:16:00 <workergnome> ... and would it be a property of the propriety term definition, or a propriety of the class that the class term definition that then defines those terms?
16:16:37 <workergnome> azaroth: we had not talked about globbing or real wildcarding: we'd talked about a shorthand for not retyping all properties within that context.
16:17:03 <workergnome> ...you would then need to define all schema.org contexts for every class that below need to apply
16:17:34 <workergnome> ... the question is at what level does the wildcard apply?  Is it at the ontology level, or is it at the context level?
16:17:51 <ajs6f_> ajs6f_ has joined #json-ld
16:18:01 <workergnome> ... we'd talked about it at the context level, which is consistent with how other things work
16:18:47 <workergnome> gkellogg: expanding treats properties as terms, not expanded URIs, and compacting we select terms by matching, not via URI.  Enumerating properties by terms, not URIs, is more consistent with how we do things currently
16:19:08 <workergnome> azaroth: some solution that says, for all the terms within this context, treat them as property-scoped within this class
16:19:29 <workergnome> ... like what dlongley put in the chat: for all properties, treat them as property-scoped contexts.
16:19:54 <workergnome> ... which then wouldn't need actual wildcarding, just matching
16:19:59 <workergnome> ... which seems easier
16:20:07 <workergnome> q+
16:20:11 <azaroth> ack workergnome
16:21:00 <dlongley> q+
16:21:10 <workergnome> azaroth: could we just have two keywords, one for each behavior?
16:21:11 <azaroth> q?
16:21:13 <azaroth> ack dlongley
16:21:32 <workergnome> dlongley: I don't know if it's exactly the same, because comparability differs here.
16:21:52 <workergnome> ... when we pull them in, we treat them all as if they're property-scoped terms, which is different than the behavior before.
16:21:54 <gkellogg> q+
16:21:58 <azaroth> ack gkellogg
16:22:52 <dlongley> +1 to something along the lines of what gregg is saying
16:22:55 <workergnome> gkellogg: I think that if we have a property that can appear in a type-scoped context that says that all terms within that context inherit that context, or perhaps enumerated terms inherit, and in the absence, no terms inherit, and then it could not appear only on type-scoped contexts
16:23:02 <bigbluehat> workergnome: I'm wondering if this doesn't suggest that `@type` scoping itself could be clearer and provide the approach to inheritance that people are expecting here
16:23:42 <workergnome> dlongley: I think that we're thinking that each one of these contexts would then consider the type scoping as if it were defined on all descending properties
16:23:53 <workergnome> gkellogg: and it would be recursive--this would then travel down the property chain
16:23:57 <workergnome> dlongley: yes
16:24:09 <workergnome> gkellogg: unless that property redefines its own scope
16:24:14 <workergnome> gkellogg: that seems reasonable
16:24:42 <workergnome> azaroth: can we see a straw person example?
16:24:45 <gkellogg> `@inheritPropertyScopes: true`
16:24:48 <ajs6f> ajs6f has joined #json-ld
16:25:08 <gkellogg> `@inheritTypeScopes: [‘a’, ‘b’]`
16:25:43 <workergnome> gkellogg: do those terms need to be defined within that scope, or do they just need to have been in scope at the time it's interpreted?
16:26:07 <workergnome> azaroth: that would not work for our use case, since the properties of the annotation are not known higher-up the chain
16:26:33 <workergnome> dlongley: processing:  do you see if it appears up higher to see....(lost the chain here)
16:26:46 <workergnome> gkellogg: I think your use case would be solved by using `true`
16:26:50 <workergnome> azaroth: correct.
16:27:00 <dlongley> when defining a term within a type-scoped context, look for `@inheritPropertyScopes`
16:27:10 <workergnome> gkellogg: we should come up with a better name
16:27:16 <dlongley> and if that appears, add a property-scoped context to the term definition
16:27:25 <dlongley> (unless one already appears, as that one would take precedence)
16:27:31 <workergnome> azaroth: in our case, at the high level, our use case is...
16:27:42 <azaroth> `{ 'Annotation': {"@id": "oa:Annotation", "@inheritPropertyScopes": true, "@context": "http:...anno.jsonld"}`
16:27:45 <pchampin> `@propagates` ?
16:28:13 <workergnome> `@descends` ?
16:28:30 <bigbluehat> q+
16:28:35 <azaroth> ack bigbluehat
16:28:37 <workergnome> azaroth: we can then just update the 1.1 context
16:29:31 <workergnome> bigbluehat: This is pretty ugly, but I think we can make it prettier.  Do we use that case anywhere, and you will really need to understand the plumbing to make this understandable.
16:29:33 <gkellogg> `@propagates` +1
16:29:37 <workergnome> ... we're really going to need a primer.
16:29:54 <dlongley> `@propagate: true|[terms]` seems ok
16:29:59 <workergnome> ... the more we can reduce that cognitive pain...we need something other than reading the spec to explain how this works.
16:30:13 <azaroth> q?
16:30:44 <workergnome> azaroth: there seems to be consensus around `@propagate`?
16:31:15 <hsolbrig> * 'cept no one can spell it
16:32:42 <azaroth> PROPOSAL: Create a new keyword, `@propagate`, for type scoped contexts which takes either a boolean (false is default) or an array of terms, which when present means that all or the listed terms propagate the context listed as the value of the keyword
16:33:41 <dlongley> `@propagate` "propagates" the type-scoped context as a property-scoped context for all listed terms
16:34:30 <workergnome> gkellogg: we could consider context as an array, and the first item would be `@propagate` true.  This is getting hacky...we're pulling on a thread and we can't stop pulling
16:35:43 <workergnome> gkellogg: I'm less in favor of this than making it a property of the context itself.
16:35:45 <workergnome> +q
16:35:54 <workergnome> ... if it can't work except this way...
16:35:55 <azaroth> ack workergnome
16:36:42 <workergnome> gkellogg: I think this changes the default...
16:37:00 <workergnome> ...and if you want the next one to be false...
16:37:07 <azaroth> q+ to dredge up context reference metadata :(
16:37:07 <workergnome> ...how do you inherit the default again?
16:37:15 <workergnome> ... these questions are why I'm not happy with these.
16:37:16 <azaroth> ack azaroth
16:37:16 <Zakim> azaroth, you wanted to dredge up context reference metadata :(
16:37:35 <workergnome> azaroth: This could be solved with metadata on the context, but we've deferred that conversation
16:37:55 <workergnome> gkellogg: how problematic is it to just refer to it in the context?
16:38:17 <workergnome> azaroth: it means that we can't include 1.0 contexts, which is not great.
16:38:36 <workergnome> gkellogg: you can still refer to them...
16:39:23 <ivan> q+
16:39:31 <workergnome> azaroth: for type-scoped contexts, if you want to refer to a 1.0 context, if you want to type-scope them in, you'd need to rebuild those contexts when `@property` is a property of the context, instead of the referring context
16:39:35 <azaroth> ack ivan
16:40:15 <workergnome> ivan: Red flag: we were wondering about feature freeze, and we are discussing something here that is not thought through yet, and it's a long discussion, and it's practically june
16:40:40 <workergnome> ... I am worried here.  Protected took two months, and we're approaching the same place.
16:41:14 <workergnome> azaroth: the issue is that Verifiable Credentials have assumed one way, and the spec works the other way, so there needs to be a decision one way or the other
16:41:25 <workergnome> ... hopefully a solution that works for both.
16:41:33 <dlongley> q+ to say it's not impossible, just verbose
16:41:40 <workergnome> ... we can stick with the spec
16:42:08 <workergnome> gkellogg: we can do type scope as committed, and without dealing with propagation, or we can remove the type-scoped property...
16:42:21 <workergnome> azaroth: but that chooses one use case over the other
16:42:28 <workergnome> ... we need to deal with the competing use cases
16:42:35 <azaroth> ack dlongley
16:42:35 <Zakim> dlongley, you wanted to say it's not impossible, just verbose
16:42:39 <workergnome> ... or revert back to the previous spec
16:42:57 <workergnome> dlongley: it doesn't make the previous use case impossible, just verbose.
16:43:07 <workergnome> ... the other way around was literally impossible
16:43:18 <azaroth> q+ s/impossible/implausible/
16:43:24 <azaroth> ack
16:43:59 <workergnome> azaroth: consider schema.org, you'd need to enumerate all terms in schema on each property.  It's possible, but implausible.
16:44:33 <workergnome> azaroth: a property on the 1.1 context with propagation, and define a 1.1 context, and @propegates true
16:44:36 <workergnome> q+
16:44:39 <azaroth> ack workergnome
16:44:43 <azaroth> ack workergnome
16:44:49 <azaroth> ack s/impossible/implausible/
16:44:51 <bigbluehat> workergnome: does this mean that the writer of this context
16:45:03 <ajs6f_> ajs6f_ has joined #json-ld
16:45:04 <bigbluehat> ...decides whether it propagates up or down?
16:45:18 <bigbluehat> ...wouldn't that mean the annotations group would need to define two different versions of that context?
16:45:24 <bigbluehat> azaroth: yes. that is indeed the case
16:45:28 <bigbluehat> ...which also seems...not ideal
16:45:54 <workergnome> gkellogg: I think the way to handle this is to set `@propegate changes the default to subsequent properties
16:46:14 <workergnome> ... we could including contexts judicious...
16:46:36 <workergnome> azaroth: the ugly version of a list where there are processing flags and contexts within the context definition
16:46:47 <workergnome> ...documentable, but not pretty
16:47:02 <workergnome> ... and order dependent
16:47:23 <bigbluehat> workergnome: do we have a sense of which of these inheritance models is more common?
16:47:34 <bigbluehat> ...at this point it feels like we've built in the ability to turn this on or off
16:47:39 <bigbluehat> ...or is that not correct?
16:47:40 <workergnome> azaroth: I don't think that we know
16:47:52 <pchampin> q+
16:48:00 <workergnome> ... currently, all of the inheritance models are propagate.  1.0, everything does so.
16:48:23 <azaroth> ack pchampin
16:48:24 <workergnome> ... that implies that propagation is more common, but people coming from object-oriented might think otherwise
16:48:42 <workergnome> pchampin: I'm not convinced by this, but...I don't think this has been considered.
16:48:52 <workergnome> ... another keyword for non-propagating contexts?
16:49:00 <workergnome> ... remove the flag, make it cleaner
16:49:16 <workergnome> azaroth: that does seem cleaner
16:49:50 <rubensworks> q+
16:49:53 <azaroth> ack rubensworks
16:50:19 <workergnome> rubensworks: I like the idea, but that might make context even more complicated, but now have two ways to find a context
16:50:26 <pchampin> q+
16:50:26 <gkellogg> q+
16:50:30 <workergnome> ... is feasible, but complicated
16:50:35 <azaroth> q?
16:50:36 <azaroth> ack pchampin
16:50:45 <workergnome> pchampin: Just to be clear, I share that concern.
16:50:51 <ivan> q+
16:50:55 <workergnome> ... two keywords for contexts ugly
16:51:13 <dlongley> it could be a keyword on the type definition instead
16:51:25 <workergnome> .. and I wanted to point out that considering rob's example, having `@context` always propagate, and a separate keyword for dlongley's proposal
16:51:29 <azaroth> q?
16:51:31 <azaroth> ack gkellogg
16:51:39 <ajs6f> ajs6f has joined #json-ld
16:52:12 <workergnome> gkellogg: the other thing, considering contexts as metadata, where we had metadata, and that could solve this
16:52:15 <ivan> q-
16:52:47 <azaroth> q?
16:52:50 <workergnome> ... then we could set some of these properties...
16:53:00 <bigbluehat> q+
16:53:26 <workergnome> azaroth: two routes: new keyword, context reference metadata
16:53:42 <ivan> For reference: https://github.com/w3c/json-ld-syntax/issues/108
16:53:49 <azaroth> q?
16:53:51 <azaroth> ack bigbluehat
16:54:26 <ivan> q+
16:54:28 <workergnome> bigbluehat: 1.0 propagates now, so the default is propagate true.  Then what we need is the way to prevent that, and to say that this is exclusive
16:54:29 <azaroth> ack ivan
16:54:31 <workergnome> azaroth: I would be fine with that
16:54:43 <workergnome> ivan: here is the issue where this was discussed
16:54:44 <ivan> https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-447629312
16:54:55 <workergnome> ...there's a syntax proposal there
16:55:08 <dlongley> bigbluehat: i see it differently, type-scoped contexts didn't exist in 1.0 and are a new concept ... and scoping "type-scoped contexts" to types makes perfect sense.
16:55:43 <ivan> q+
16:55:45 <azaroth> ack ivan
16:56:34 <workergnome> ivan: nobody seemed happy at the time with metadata at the time...if this is the only one we define, it allows others...I would not propose integrity now
16:56:48 <dlongley> +1 to providing a future hook
16:56:49 <azaroth> PROPOSAL: Un-defer #108 with propogation as the use case
16:57:05 <azaroth> +1
16:57:07 <workergnome> +1
16:57:07 <gkellogg> +1
16:57:08 <timCole> +1
16:57:08 <dlongley> +1
16:57:08 <rubensworks> +1
16:57:09 <hsolbrig> +1
16:57:12 <ivan> +1
16:57:13 <ajs6f> +1
16:57:15 <pchampin> +1
16:57:18 <bigbluehat> +1 (with concerns about scope creep)
16:57:20 <dlehn> +1
16:57:30 <azaroth> RESOLVED: Un-defer #108 with propogation as the use case
16:58:08 <workergnome> azaroth: we should then look at 108 over the week and come up with a proposal for contexts
16:59:56 <bigbluehat> gkellogg: it might be good if this were done through more detailed proposals in advance
17:00:10 <bigbluehat> azaroth: so, everyone who's not on a trip, please contribute to the issue
17:00:14 <bigbluehat> ...and it is the top of the hour
17:00:20 <gkellogg> https://github.com/w3c/json-ld-syntax/pull/189
17:00:35 <bigbluehat> gkellogg: also, I've updated 189 that addresses some concerns
17:00:40 <bigbluehat> ...I'm not convinced it's the best way to go
17:00:47 <bigbluehat> ...if you're satisfied with it, though, go ahead and pull it
17:00:55 <bigbluehat> azaroth: k. Greg and I will look at it asap
17:01:02 <bigbluehat> ...thanks everyone, and we'll talk again in a week!
17:01:03 <ivan> rrsagent, draft minutes
17:01:03 <RRSAgent> I have made the request to generate https://www.w3.org/2019/05/31-json-ld-minutes.html ivan
17:01:03 <ivan> zakim, bye
17:01:03 <ivan> rrsagent, bye
17:01:03 <RRSAgent> I see no action items
17:01:03 <Zakim> leaving.  As of this point the attendees have been ivan, gkellogg, rubensworks, azaroth, workergnome, dlongley, bigbluehat, hsolbrig, Tim_Cole, dlehn, pchampin, ajs6f
17:01:03 <Zakim> Zakim has left #json-ld
17:01:04 <azaroth> TOPIC: Adjourn