15:34:25 <RRSAgent> RRSAgent has joined #json-ld
15:34:25 <RRSAgent> logging to https://www.w3.org/2019/05/17-json-ld-irc
15:34:32 <Zakim> Zakim has joined #json-ld
15:34:39 <azaroth> zakim, this is json-ld
15:34:39 <Zakim> got it, azaroth
15:34:53 <azaroth> rrsagent, set log public
15:34:58 <azaroth> Chair: azaroth
15:35:06 <azaroth> Date: 2019-05-17
15:35:10 <azaroth> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0024.html
15:35:46 <azaroth> Regrets+ ivan, ruben_taelman, pchampin, tim_cole, adam_soroka
15:36:01 <azaroth> present+
15:56:08 <simonstey> simonstey has joined #json-ld
15:59:59 <workergnome> workergnome has joined #json-ld
16:01:02 <simonstey> present+
16:01:13 <workergnome> present+
16:01:46 <bigbluehat> present+
16:01:49 <dlongley> present+
16:02:57 <azaroth> regrets+ gkellogg
16:04:54 <azaroth> scribenick: bigbluehat
16:05:05 <azaroth> TOPIC: Approve minutes of previous call
16:05:29 <azaroth> PROPOSAL: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-10-json-ld
16:05:34 <azaroth> +1
16:05:34 <dlongley> +1
16:05:38 <bigbluehat> +1
16:05:39 <simonstey> +1
16:05:45 <workergnome> +2
16:05:51 <azaroth> RESOLVED: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-10-json-ld
16:05:58 <azaroth> TOPIC: Announcements
16:06:09 <bigbluehat> azaroth: I sent the notification about TPAC registration being open
16:06:25 <bigbluehat> ...currently we're scheduled to meet
16:06:31 <bigbluehat> ...if everything goes very smoothly
16:06:35 <bigbluehat> ...we might not meet
16:06:39 <bigbluehat> ...but we'll know closer to the time
16:06:46 <bigbluehat> ...any other announcements or reminders?
16:06:51 <azaroth> TOPIC: Issues
16:07:06 <azaroth> SUBTOPIC: Type-scoped contexts: https://github.com/w3c/json-ld-syntax/issues/174
16:07:09 <bigbluehat> azaroth: dlongley the first one of timeliness for you is type scoped contexts
16:07:13 <bigbluehat> ...would you like to summarize?
16:07:28 <bigbluehat> dlongley: I went to use type scoped contexts to create the Verifiable Credentials context
16:07:32 <bigbluehat> ...but immediately hit issues
16:07:45 <bigbluehat> ...these actually bleed beyond being scoped to a particular type
16:07:56 <bigbluehat> ...I fixed our implementation...and gkellogg fixed his implementation
16:08:04 <bigbluehat> ...this issue is about fixing the text to match the implementations
16:08:39 <bigbluehat> azaroth: so what you've described definitely sounds like a bug
16:08:43 <workergnome> q+
16:08:45 <bigbluehat> ...it shouldn't bleed outside of that type
16:09:15 <jeff_mixter> jeff_mixter has joined #json-ld
16:09:21 <bigbluehat> ...so, because `name` is defined in Person, it's scoped to Person
16:09:30 <jeff_mixter> present+
16:09:31 <bigbluehat> ...but you can also have `name` in Library and have that be scoped to Library
16:09:39 <bigbluehat> dlongley: right, but if you combine them, then you get a clash of terms
16:09:49 <dlehn> present+
16:10:31 <bigbluehat> dlongley: if you put protected on these things in the next example
16:10:41 <bigbluehat> ...you would be told that there were issues...when in fact there aren't
16:10:55 <bigbluehat> ...this is more like a bug that is revealed by `protected`
16:11:19 <bigbluehat> ...so if you had also used some other terms that you intended to be dropped, those would get picked up by `Library` terms
16:11:29 <bigbluehat> azaroth: right. without Person being in the heirarchy
16:11:34 <bigbluehat> dlongley: even if it were there
16:11:57 <bigbluehat> ...if you had them nested, and had terms you wanted dropped, if that same term is defined earlier, it remains defined
16:12:10 <bigbluehat> ...so the `Library` terms don't stay within `Library`, they bleed out
16:12:18 <bigbluehat> azaroth: well...that sounds like what I'd expect, actually
16:12:32 <bigbluehat> dlongley: so, for property scoped contexts
16:12:43 <bigbluehat> ...but for the type scoped contexts, it's more like object oriented expectations
16:13:04 <bigbluehat> ...so you don't want unrelated contexts showing up in unexpected places
16:13:10 <bigbluehat> ...property scoped terms are different
16:13:16 <bigbluehat> ...those stick around
16:13:25 <bigbluehat> ...the property scoping works as expected
16:13:42 <bigbluehat> ...but the type scoping shouldn't behave like a property scoped context
16:14:01 <bigbluehat> azaroth: so the situation we have in IIIF.io is...
16:14:06 <bigbluehat> ...we use ActivityStreams properties
16:14:12 <bigbluehat> ...which are very very broad...like `items`
16:14:18 <bigbluehat> ...it's the same JSON key and RDF property
16:14:25 <bigbluehat> ...it's just, "here's the things in this list"
16:14:40 <bigbluehat> ...but at various places in the tree, the `items` are of various types
16:14:56 <bigbluehat> ...so when you get to an Annotation, you then need to use type scoping to deal with that change
16:15:24 <bigbluehat> ...so we'd need it to re-re-redefine its terms to deal with this change
16:15:36 <bigbluehat> dlongley: you can put a property scoped context inside a typed scoped space
16:15:59 <bigbluehat> azaroth: what happens when those continue into an `@container: @list` scenario
16:16:11 <bigbluehat> ...so, for example, you can have collections, which either contains collections or things
16:16:17 <bigbluehat> ...so a tree, or leaf nodes
16:16:25 <bigbluehat> ...so trees get one context, and leafs get another
16:16:28 <bigbluehat> ...how would that not collide
16:16:36 <bigbluehat> ...I assume you'd use type scoped?
16:16:42 <bigbluehat> dlongley: it's OK to use type scopes
16:16:52 <bigbluehat> ...your concern is that using type scopes don't travel down the branch
16:17:00 <bigbluehat> azaroth: yes. specifically when there are 1.0 contexts
16:17:09 <bigbluehat> dlongley: when you use type scopes, you can choose which path is traveled down
16:17:28 <bigbluehat> ...you can say in TypeA use this context, and then within these properties use that other context
16:17:53 <azaroth> 1.1 context for IIIF - https://preview.iiif.io/api/image-prezi-rc2/api/presentation/3/context.json
16:18:21 <bigbluehat> ...one of the goals is to deal with ActivityStreams scenarios specifically using `protected` for use with non-JSON-LD processors using ActivityPub
16:19:04 <bigbluehat> azaroth: in that example, there are typed contexts which should be overridden further down
16:19:14 <bigbluehat> ...like below Annotation, there are further nodes
16:19:20 <bigbluehat> ...what is the context there?
16:19:33 <bigbluehat> dlongley: if the only thing that's bringing in the context is this type scoped context
16:19:46 <bigbluehat> ...that context will get removed if you move on to something that is not scoped to the same thing
16:19:53 <bigbluehat> ...like an ordered collection or something
16:19:59 <bigbluehat> ...they'll need to define their own
16:20:02 <bigbluehat> ...or use the earlier one
16:20:09 <bigbluehat> azaroth: that's not what 1.0 would say
16:20:21 <bigbluehat> dlongley: well, 1.0 didn't have typed scoped contexts at all
16:20:30 <bigbluehat> azaroth: there doesn't seem to be a solution for this particular case
16:20:41 <bigbluehat> dlongley: well, there is a solution, which is to say for those properties, you can
16:21:17 <bigbluehat> ...if you want every single property in an AnnotationCollection, then you'd need to use that via typed scoped contexts throughout the collection
16:21:26 <bigbluehat> azaroth: but given that most of these contexts are just the properties
16:21:38 <bigbluehat> ...you're doing an awful lot of rewriting with that approach
16:21:47 <bigbluehat> dlongley: there is a solution
16:21:50 <bigbluehat> ...which is unpleasant
16:21:58 <bigbluehat> ...but without this bug fix, there's no way to do the other approaches
16:22:18 <bigbluehat> ...you literally cannot use type scoped contexts and protected terms together in the way you'd expect
16:22:26 <bigbluehat> azaroth: is there a way to flag which of the two?
16:22:32 <bigbluehat> ...that seems like a lot of processing
16:22:41 <bigbluehat> ...it would require context import metadata...
16:22:57 <bigbluehat> ...like only this class + all that descend from it
16:23:05 <bigbluehat> dlongley: yeah, we do that with property scoped contexts
16:23:11 <bigbluehat> ...but you want to do that without redefinition
16:23:31 <bigbluehat> azaroth: right. if the Annotation context got updated, we'd then have to synchronize this context with that one.
16:23:41 <bigbluehat> ...so...maybe...if there were an Annotation 1.1 context
16:23:47 <bigbluehat> ...could it then redefine things within itself?
16:23:51 <bigbluehat> dlongley: yes. that would work
16:24:02 <bigbluehat> azaroth: so for this particular case, that would be the right solution
16:24:05 <bigbluehat> dlongley: correct
16:24:18 <bigbluehat> azaroth: so, given that context files are not versioned in the same way that specifications are
16:24:24 <bigbluehat> ...we could propose a 1.1 context
16:24:37 <azaroth> q?
16:24:45 <bigbluehat> dlongley: this would also afford the ability to use the `@protected` feature
16:24:51 <bigbluehat> ...which would help JSON processors
16:24:52 <azaroth> ack workergnome
16:25:05 <bigbluehat> ...who don't want to do JSON-LD processing
16:25:16 <bigbluehat> ...and want terms to remain identical in both ecosystems
16:25:28 <bigbluehat> workergnome: does this only protect at a certain level in the heirarchy?
16:25:37 <bigbluehat> ...or does to descend into the tree?
16:25:53 <bigbluehat> dlongley: any term definition does not continue down the tree--if you change type scope
16:26:03 <bigbluehat> workergnome: given your definition, that makes sense
16:26:09 <bigbluehat> ...but that's not what I expected
16:26:29 <bigbluehat> ...I'd thought that this covered the terms in the hierarchy under that type
16:26:43 <bigbluehat> dlongley: my opinion of that is when you're thinking of it from either OOP or graph perspectives
16:26:56 <bigbluehat> ...you move into a node, and that node has a class with certain properties
16:27:04 <azaroth> Another type scoped context: https://linked.art/ns/v1/linked-art.json
16:27:14 <bigbluehat> ...so to go into a node is to move into a new space
16:27:25 <bigbluehat> ...and if it cascaded as you describe it would be incompatible with `@protected`
16:27:37 <bigbluehat> workergnome: I think its two different contextual models of how this work
16:27:46 <bigbluehat> azaroth: yep. we just need to verify the models against the use cases
16:27:55 <bigbluehat> ...so here's another type scoped context
16:28:01 <bigbluehat> ...right at the top, there's some vanilla ones
16:28:10 <bigbluehat> ...but the 4th class is `Period`
16:28:20 <bigbluehat> ...we want to rename some of these to simpler names
16:28:24 <bigbluehat> ...there's no importing of anything
16:28:32 <bigbluehat> ...so these would not descend down
16:28:39 <bigbluehat> dlongley: yep. that should work just fine
16:29:03 <bigbluehat> azaroth: anyone have other 1.1 contexts?
16:29:06 <azaroth> q?
16:29:17 <bigbluehat> simonstey: I was also kind of confused
16:29:38 <bigbluehat> ...given that we have multiple people confused by this--or having differing expectations...maybe we should put this in the primer or something?
16:29:59 <bigbluehat> ...if we decided on the specific way to deal with this, then we should write-up the foundation of how this works
16:30:06 <bigbluehat> ...because it's not like a class hierarchy
16:30:18 <bigbluehat> ...and we want to avoid those expectations causing confusion
16:30:28 <workergnome> q+
16:30:36 <bigbluehat> azaroth: one of the reasons why I had the opposite expectations from dlongley
16:30:45 <bigbluehat> ...is that the way gkellogg has expressed in the past
16:30:50 <bigbluehat> ...was to avoid contexts inline in the JSON
16:31:13 <bigbluehat> ...if you had a top-level node with a context, then that context would extend down
16:31:21 <dlongley> q+
16:31:26 <azaroth> q?
16:31:27 <azaroth> ack workergnome
16:31:34 <bigbluehat> ...whereas if you had `@type` with a scoped context, it would be equivalent to putting that context in at that part of the tree
16:31:50 <bigbluehat> ...which would come with the expectation of cascading--as in the case of an inline context at that point in the tree
16:31:58 <bigbluehat> workergnome: so, say someone else is using our vocabulary
16:32:09 <bigbluehat> ...what would it require us to do to rewrite the linked-art context
16:32:16 <bigbluehat> ...to be sure that our terms stay scoped into our context
16:32:24 <bigbluehat> ...is it the same as what's being considered for activity streams?
16:32:32 <bigbluehat> s/activity streams/ActivityStreams
16:32:36 <azaroth> q?
16:32:37 <azaroth> ack dlongley
16:32:40 <bigbluehat> azaroth: only if they're type scoped
16:32:54 <bigbluehat> dlongley: you either define properties that can appear anywhere
16:33:05 <bigbluehat> ...or those that can be used within certain types
16:33:25 <bigbluehat> ...or those that can be used within any type
16:33:48 <bigbluehat> ...so, yes the way gkellogg had stated this as pulling context into a type
16:34:01 <bigbluehat> ...and thinking about it as pulling a context in "in place" as a context object would
16:34:12 <bigbluehat> ...that, however, doesn't work well with protected, etc.
16:34:34 <bigbluehat> ...so, the change would be that type scoped would now map singularly to that scope
16:35:00 <bigbluehat> workergnome: so, assuming that someone uses a type scoped definition
16:35:10 <bigbluehat> ...when I put this type in, it's a vocabulary concept
16:35:18 <bigbluehat> ...so where we put our contexts have names and dates
16:35:26 <bigbluehat> ...we wouldn't want to implement them at every level
16:35:43 <bigbluehat> ...we'd have to protect the linked-art context against being used as type scope context
16:36:02 <bigbluehat> azaroth: so, like IIIF includes Annotations
16:36:31 <bigbluehat> ...so when you descend from `Concept` to `name` via `identifiedBy` property
16:36:38 <bigbluehat> ...you'd no longer have an active context
16:37:00 <bigbluehat> ...the context doesn't have a notion of inheritance
16:37:08 <bigbluehat> ...so it's not really Object Oriented
16:37:11 <bigbluehat> ...if it did, then you'd be fine
16:37:26 <azaroth> q?
16:37:29 <bigbluehat> ...so we instead would have to enumerate every possible property of every possible class
16:37:46 <bigbluehat> dlongley: given that I have no knowledge of what you're talking about...
16:37:54 <bigbluehat> ...from the high level it sounds correct
16:38:02 <bigbluehat> ...if you want to scope against types, use types on everything
16:38:27 <bigbluehat> ...if you want your types to survive under all the properties, then yes...this will be verbose
16:38:35 <bigbluehat> ...there could be another simpler syntax
16:38:44 <bigbluehat> ...but I don't think the solution is to not handle this sort of inheritance
16:39:04 <bigbluehat> ...if that is indeed a need to solve that verbose syntax, then we should solve that on its own and not give up this sort of inheritance
16:39:12 <bigbluehat> workergnome: this sounds like shallow scoping vs. deep scoping
16:39:38 <bigbluehat> dlongley: to me its a difference between property scoping vs. type scoping
16:39:48 <bigbluehat> ...when you use property scoping, you're cascading into the tree
16:40:03 <bigbluehat> ...but with type scoping, you have no idea where it's going next
16:40:14 <bigbluehat> ...this gets worse with protected
16:40:36 <bigbluehat> ...because if you don't know where a type usage is going next, there's no way to correctly protect its terms
16:40:53 <bigbluehat> ...so maybe we need like an `@any` property to handle this scoping with protecting
16:41:19 <bigbluehat> workergnome: so, if you do want shallow scoped types, could you reimport the base context back via nullifying?
16:41:25 <bigbluehat> dlongley: nullifying can't do that
16:41:31 <azaroth> q+
16:41:34 <bigbluehat> workergnome: but if you knew what it was, could you bring it back in?
16:41:42 <bigbluehat> dlongley: that would be dependent on how you got that base context
16:41:45 <bigbluehat> ...which sounds very difficult
16:41:48 <azaroth> q+ to ask if putting it back after nullifying is a circular import error?
16:42:00 <bigbluehat> workergnome: so, if we have deep scoping, then shallow scoping seems hard, and vice verse
16:42:21 <bigbluehat> dlongley: there might be a cleaner way to say, in this scoped context, you can use these type scopes
16:42:22 <azaroth> ack azaroth
16:42:22 <Zakim> azaroth, you wanted to ask if putting it back after nullifying is a circular import error?
16:42:28 <bigbluehat> ...to me one seems easier to solve than the other
16:42:34 <bigbluehat> ...but it certainly seems like they do differ
16:43:02 <bigbluehat> workergnome: I think there is to do them both...and maybe syntax sugar would make things simpler
16:43:13 <bigbluehat> dlongley: think where we're at now, shallow is broken
16:43:32 <bigbluehat> ...so if we fix for shallow, we make deep harder
16:43:40 <bigbluehat> ...and that's where this syntactic sugar might help
16:43:51 <bigbluehat> azaroth: what about nullification and circular reimporting?
16:44:31 <bigbluehat> ...I fear you'd end up recursively recursing and cursing about recursion
16:44:59 <azaroth> q?
16:45:01 <bigbluehat> ...so the `@properties: use-this-context` is way less verbose than defining every single property
16:45:13 <bigbluehat> dlongley: yeah, it's effectively a way of defining a base context
16:45:18 <azaroth> q?
16:45:23 <bigbluehat> azaroth: right. `@base-context` (vs. `@base`)
16:45:28 <bigbluehat> ...it was very good to discuss this
16:45:35 <bigbluehat> ...anything else? or are we at proposal time
16:46:03 <bigbluehat> dlongley: so, we'd need to change this to default to shallow, so VCWG can use `protected`
16:46:09 <bigbluehat> ...so the VCWG testing can move forward
16:47:12 <azaroth> PROPOSAL: Type scoped contexts will be shallow and not be inherited via properties of instances of the type, and we will add a syntactic sugar for a wildcard match on properties on the type to define their context
16:47:28 <dlongley> +1
16:47:38 <bigbluehat> +1
16:47:42 <azaroth> +1
16:47:43 <workergnome> +1
16:47:47 <simonstey> +1
16:47:49 <bigbluehat> azaroth: so this solution seems better than the other options...which all seem worse
16:48:01 <jeff_mixter> +1
16:48:03 <dlehn> +1
16:48:14 <bigbluehat> ..and for the linked-art case, we simply have in the context generating script, "for each class, put in magic-ness to use self for all the properties of this thing"
16:48:19 <azaroth> RESOLVED: Type scoped contexts will be shallow and not be inherited via properties of instances of the type, and we will add a syntactic sugar for a wildcard match on properties on the type to define their context
16:48:51 <dlongley> https://github.com/w3c/json-ld-api/issues/90
16:49:14 <bigbluehat> dlongley: so this one is about reusing existing contexts
16:49:32 <bigbluehat> ...the syntax spec says that a protected term definition with `@protected: true`
16:49:37 <bigbluehat> ...it prevents it being overrident
16:49:45 <bigbluehat> ...possibly by setting context to null
16:49:57 <bigbluehat> ...what is prohibited is introducing other definitions
16:50:06 <bigbluehat> ...but what happens when new terms come in
16:50:19 <bigbluehat> ...what this change could provide is allowing using 1.0 contexts alongside protected
16:50:28 <bigbluehat> ...so, things that define aliases for id/type
16:50:37 <azaroth> +1 to this issue
16:50:46 <bigbluehat> ...you can't currently bring those in with protected, because that throws an error
16:51:02 <bigbluehat> ...because you're trying to redefine terms--even though the result would be the same
16:51:19 <bigbluehat> ...so the only caveat is reusing old contexts won't come with `@protected` set
16:51:30 <bigbluehat> ...so in that case, you just keep `@protected` flag to on
16:51:53 <azaroth> q?
16:51:57 <bigbluehat> ...so update the API to switch where we check that protected is set, not update existing terms that are identical--modulo the protected flag
16:52:19 <bigbluehat> workergnome: it does seem to make complete sense
16:52:28 <bigbluehat> ...I'd want gkellogg to weigh in
16:52:42 <bigbluehat> ...to get another implementer's input on this
16:53:03 <bigbluehat> dlongley: so, the only sticky issue is two scoped contexts, then you have to do a full comparison
16:53:12 <bigbluehat> azaroth: if they're by value rather than by reference...yeah...that would be rough
16:53:20 <bigbluehat> ...so with the caveat that the editors are OK
16:53:29 <bigbluehat> ...here's a proposal
16:54:43 <azaroth> PROPOSAL:  Assuming the update to the algorithm is not controversial, protected definitions of terms do not raise an error when the term is redefined in exactly the same way, with the potential exception of not being protected
16:54:47 <workergnome> +1
16:54:48 <jeff_mixter> +1
16:54:48 <dlongley> +1
16:54:50 <azaroth> +1
16:54:51 <simonstey> +1
16:54:59 <dlehn> +1
16:55:00 <bigbluehat> +1
16:55:09 <azaroth> SUBTOPIC: @protected algorithm change
16:55:15 <azaroth> link: https://github.com/w3c/json-ld-api/issues/90
16:56:04 <azaroth> SUBTOPIC: Compact IRIs #177
16:56:10 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/177
16:56:42 <bigbluehat> azaroth: if you define a term that's the same as a URI schem
16:56:48 <bigbluehat> ...e then you'll have problems
16:57:09 <bigbluehat> ...so there are schemes that are very likely to be used in values
16:57:25 <bigbluehat> ...like `mailto:` which could be high jacked in this scenario
16:57:38 <bigbluehat> ...we could fix this by being able to protect URI schemes that are in use
16:57:51 <bigbluehat> ...by making it possible to set certainly ones to null
16:58:08 <bigbluehat> ...so, for instance, you could also set them within certain properties--like foaf:mailbox
16:58:24 <bigbluehat> ...and then protect them to keep upstream ones from overriding `mailto:`
16:59:37 <bigbluehat> ...so this means we don't need to put all possible URI schemes in the spec
16:59:38 <azaroth> q?
16:59:54 <dlongley> not enough time to consider it :/
16:59:56 <bigbluehat> ...and context authors can limit the damage to specific spaces where it could be damaging
17:00:23 <bigbluehat> ...so, something to think about over the week
17:01:48 <azaroth> TOPIC: Adjourn
17:02:12 <azaroth> rrsagent, draft minutes
17:02:12 <RRSAgent> I have made the request to generate https://www.w3.org/2019/05/17-json-ld-minutes.html azaroth
17:03:09 <azaroth> Meeting: JSON-LD Working Group
17:03:11 <azaroth> rrsagent, draft minutes
17:03:11 <RRSAgent> I have made the request to generate https://www.w3.org/2019/05/17-json-ld-minutes.html azaroth