14:04:00 RRSAgent has joined #json-ld 14:04:00 logging to https://www.w3.org/2019/02/07-json-ld-irc 14:04:01 rrsagent, set log public 14:04:01 Meeting: JSON-LD Working Group F2F meeting — First day 14:04:01 Chair: azeroth 14:04:01 Date: 2019-02-07 14:04:01 Agenda: https://tinyurl.com/ycc3cyts 14:04:01 ivan has changed the topic to: Meeting Agenda 2019-02-07: https://tinyurl.com/ycc3cyts 14:04:09 Chair: azaroth 14:04:24 gkellogg has joined #json-ld 14:06:02 present+ 14:06:09 hsolbrig has joined #json-ld 14:06:10 present+ 14:06:25 present+ hsolbrig 14:08:13 pretty handy 14:08:17 s/pretty handy// 14:08:22 present+ Gregg_Kellogg 14:08:25 azaroth has joined #json-ld 14:08:33 present+ Benjamin_Young 14:08:37 present+ Rob_Sanderson 14:08:45 zakim, who is here? 14:08:45 Present: ivan, simonstey, hsolbrig, Gregg_Kellogg, Benjamin_Young, Rob_Sanderson 14:08:48 On IRC I see azaroth, hsolbrig, gkellogg, RRSAgent, Zakim, ivan, pchampin, simonstey, ChristopherA, bigbluehat, fr33domlover, dlehn, dlongley 14:09:32 workergnome has joined #json-ld 14:09:32 preset+ David_Lehn 14:09:40 present+ workdergnome 14:09:45 jeff_mixter has joined #json-ld 14:09:54 present+ 14:09:57 present+ 14:10:00 present- workdergnome 14:10:24 present+ 14:10:33 zakim, who's here? 14:10:33 Present: ivan, simonstey, hsolbrig, Gregg_Kellogg, Benjamin_Young, Rob_Sanderson, jeff_mixter, workergnome, dlehn 14:10:35 On IRC I see jeff_mixter, workergnome, azaroth, hsolbrig, gkellogg, RRSAgent, Zakim, ivan, pchampin, simonstey, ChristopherA, bigbluehat, fr33domlover, dlehn, dlongley 14:11:00 scribenick: hsolbrig 14:15:19 hsolbrig2 has joined #json-ld 14:16:33 https://docs.google.com/document/d/1FcbySJzY5QyBW6HcCtO0LCUmppgIJqQzv565BqC5bOU/edit?pli=1 14:20:09 ajs6f has joined #json-ld 14:20:13 present+ 14:20:16 (example of sealed document posted on google docs - Test se03) 14:24:37 azaroth: first CR end of August, then time for implementations to be written/updated 14:24:52 ... targeting full PR by next June 14:25:48 azaroth: still have primer to do, to discuss later... 14:25:55 .. possible other documents as well 14:26:47 ... still need to deal with security and privacy. Comments from Microsoft, Google and ? 14:27:22 ... concerns about lightbulbs looking up people's habits via context. Any network access gives information 14:27:32 ... i18n -- may or may not be an issue 14:28:09 ... hopefully we will push to a future RDF working group 14:28:44 ... TR - at least 1 candidate recommendation that can be implemented. By end of CR, 2 independent implementations of every feature 14:29:08 ... correction: two implementations for every feature. 14:29:12 +q 14:30:02 ... then to PR w/ AC approval. PR has to be at least 6 weeks 14:30:43 ivan: when PR is published, documents are frozen beyond spelling and grammatical errors 14:31:01 ... if some feature doesn't get enough implementation, must be removed from PR 14:31:21 ... we have to close technical issues by time of PR 14:32:33 ... a new process may come out in 2020 that makes it easier to update recommendations. 14:33:07 q? 14:33:10 ack simonstey 14:33:11 ... may consider keeping group alive to take advantage of this. Defer may not mean freeze for 5 years 14:33:35 simonstey: do we also have to check 1.0 features as well or just new features? 14:34:32 ivan: we could concentrate on new, but have to prove that no impact on old, so checking all might be easier 14:34:59 ... we should have enough implementations, emerging from 1.0 continuance 14:35:45 ... would propose testing the whole thing as is 14:36:25 q? 14:36:41 q+ 14:37:02 ack jeff_mixter 14:37:22 jeff_mixter: how permanent does implementation have to be? Research projects? 14:37:50 ivan: W3C requirement is that we know it can be implemented. Research is fine... 14:39:17 azaroth: need to focus on the technical issues and either solve or toss... 14:39:48 ... can't add or remove remove features in CR, so be "judicious but brutal"... 14:40:04 ... if too complicated, defer. 14:40:18 q? 14:40:51 ivan: If we can't get to a clear model and agreement on sealing today, I propose we defer it. 14:41:19 ajs6f: If we happen to do that, what do we say to verifiable claims, etc? 14:42:11 azaroth: (reads guiding principles) 14:42:24 https://www.w3.org/2018/json-ld-wg/WorkMode/guiding_principles 14:45:15 q? 14:46:14 azaroth: sealed contexts - goal is to solve by end of day 14:46:21 Topic: Sealed Context 14:47:55 ivan: one thing from last week's discussions - sealing seems to be a very dangerous thing to do... 14:48:20 ... if Google decides to put a seal on schema.org, community will be unhappy ... 14:48:59 gkellogg: we need to understand who we're serving. Not there for schema.org, rather verifiable claims 14:49:29 q+ 14:50:04 ... specs sucin spech as verifiable claims have a shared vocabulary, with some domains wide open, but people can't change semantics 14:50:18 ... in spec, intentionally or otherwise 14:50:26 ack bigbluehat 14:51:05 bigbbluehat: chief aim of proposal is that json and json-ld world co-exist. Term sealing is to guarantee that ... 14:51:23 ... json and json-ld authors work on exact same shape 14:51:25 q+ 14:51:44 q+ re shape 14:51:47 q+ 14:51:48 ... maybe take a step back from sealing and see what other options there may be 14:52:03 ack pchampin 14:52:15 ... notion of foundational shape surviving framing 14:52:30 We don't hear you PA 14:52:48 q+ pchampin 14:52:56 ack ivan 14:53:44 ivan: what I understand from ver. claim. is that they have a wrapper w/ properties whose value is an object... 14:54:23 ... want to give total freedom for another vocabulary to leave locally. How about a syntax that says this is an extension point... 14:54:39 q+ 14:55:16 q+ 14:55:20 ... @context null + specific situation that is sealing + @context null 14:55:49 ... concentrate on this use case and try not to generalize 14:56:05 ack azaroth 14:56:05 azaroth, you wanted to discuss shape 14:56:16 q+ 14:57:01 azaroth: sealing doesn't solve actual shapes - just relationship between key and class. Not producing necessary structure 14:57:33 q+ to ask re schema languages 14:57:35 ack pchampin 14:57:38 ... it is intersection of RDF semantic layer and JSON keys. Not shape thing as an API. Mapping not API 14:58:24 pchampin: goal of sealing is not to guarantee LD has same shape as plain JSON, but JSON LD that has the same shape... 14:58:31 ... has the same semantics. 14:59:15 ... agree with ivan -- sealed is sealed from point to rest of subtree and not try to address unsealed point. 14:59:17 ack workergnome 14:59:54 wokergnome: Use case for unsealing is to insert user specified documents into structure. Unstructured JSON into LD... 15:00:15 ivan: may try to pick up json literal again 15:01:00 ivan: some examples don't want literal, but piece of RDF graph but based on another vocabulary on its own 15:01:23 workergnome: do we need ability to interpret unsealed part in context of whole document? 15:01:32 gkellogg: yes 15:02:45 q? 15:03:06 workergnome: do we have use cases where sealed and unsealed need to be interpreted? 15:03:15 azaroth: I think so 15:03:15 ack gkellogg 15:03:50 Note - if we can't solve by the end of the day, revisit the fallback position of JSON literals 15:04:11 gkellogg: We're making this too hard. A sealed context is a collection of sealed terms -- maintains original interpretation 15:04:26 q+ 15:04:48 ... an extension point is where you use a term that is not sealed... 15:05:36 ... say there is a named term in VC that has a given meaning, but want to be able to add other properties that aren't sealed... 15:06:15 ... also need a "this is a place for you to put stuff" -- creating a scoped context where properties can be re-intepreted. 15:06:38 ack dlehn 15:06:43 ... sealed terms have fixed meaning when you use them. 15:06:43 a term may be sealed (i.e. its meaning, esp. its IRI, can not be overridden) and an extension point (allow sealed terms to be overridden in its subtree) 15:07:55 ack ajs6f 15:07:55 ajs6f, you wanted to ask re schema languages 15:07:56 q? 15:08:03 dlehn: common use will be use an example, preserving semantics and adding on... 15:09:18 ajs6f: we have ways to control shapes of json and RDF, but now we're talking about a third way... controlling semantics 15:09:45 ack pchampin 15:10:41 pchampin: gregg says extension points are properties that aren't sealed -- sealed means one cannot override 15:11:29 gkellogg: one approach is sealed context that allows context underneath to be unsealed... 15:11:31 q+ 15:12:19 ack azaroth 15:12:37 scribenick: ajs6f 15:12:40 scribenick: ajs6f 15:13:05 thanks @gkellogg, that's clearer :) 15:13:27 ivan: i would like to hear a description of the exact sealing proposal 15:13:38 gkellogg: that would be pchampin's PR 15:14:07 ivan: if we cannot explain where we are, we have a problem 15:14:32 pchampin: I agree with first 2 parts of the PR, the 3rd one is related to extension points 15:14:56 ... we don't have the same model for unsealing 15:15:24 ... especially when it happens automatically 15:15:57 ... I think the sealed definitions in a context cannot be overwritten by anything in that context 15:16:22 ivan: if you seal a context, then the only way the terms can be overriden is in a scoped context within the sealed context? 15:16:31 pchampiin: I _thikn_ so 15:17:55 gkellogg: explicates example on whiteboard Test so03 15:18:21 reference: https://docs.google.com/document/d/1FcbySJzY5QyBW6HcCtO0LCUmppgIJqQzv565BqC5bOU/edit?pli=1#heading=h.sup6uw56yj6j 15:19:17 dlehn: there are problems with this example because the inner context has no effect 15:19:23 q+ 15:19:32 ivan: we often use such examples, which I find a little unnatural 15:19:39 hsolvig: That confuses me 15:19:48 q+ 15:19:59 ivan: [disusses example] 15:20:47 gkellogg: ivan: azaroth: [edit and discuss example] 15:22:05 ivan: sealing seems to mean that the terms are cast in concrete 15:22:17 ivan: it is very difficult to explain exception 15:22:41 dlehn: Not sure why it's unnatural? 15:22:52 q? 15:22:56 ivan: if the context says "Sealed" that would seem to me to mean that everything is cast in concrete 15:23:06 ... but that doesn't seem to be the case 15:23:21 ... we can change things with scoped contexts etc 15:23:35 gkellogg: this comes out of discussion of multiple sealed contexts 15:24:14 hsolvig: by changing this one term to add a type, I can open up everything I thought I was sealing 15:24:21 s/type/typo 15:25:22 workergnome: I would have assumed that by sealing a term, it would remain sealed 15:25:47 gkellogg: so once sealed, always sealed 15:26:25 gkellogg: that didn't work for Verifiable Claims because they don't want to intro a constraint on the JSON-LD within the wrapper 15:26:58 ack jeff_mixter 15:27:50 jeff_mixer: can I constrain the type of value used with a term this way? 15:28:58 all: no, JSON-LD has no way to constrain the types of values 15:29:35 scribenick: azaroth 15:29:47 q? 15:29:47 ajs6f: Agree comppletely. The wrapper compresses the protocol into the document 15:29:49 q+ 15:30:17 ... It pulls us toward sealing other things beyond just the mapping, but into complex chains 15:30:23 ack pchampin 15:30:32 hsolvig: preventing people from accidentally overwriting contexts seems within our scope, but not all the futher ramifications 15:30:33 scribenick: ajs6f 15:30:55 pchampin: re: when terms become unsealed 15:31:05 ... it is genuinely hard to explain 15:31:31 ... I would say that a sealed term is sealed anywhere, except when the sealed context opens it 15:32:00 ... there are two situations in which one can redefine a sealed term 15:32:20 ... plain JSON users don't expect the semantics to be sealed any more 15:32:38 ack ivan 15:32:55 ... we should leave the decision of when to unseal terms to the authors of the sealed context 15:34:08 ivan: an extension point means a combination of "context now" and "I cannot touch what is on the upper level" 15:34:31 gkellogg: {discusses Ivan's example] 15:35:06 ivan: how about a keyword "extension" that means you cannot redefine anything you inherit? 15:35:25 gkellogg: not quite @context: null. 15:35:46 q? 15:35:59 q+ 15:37:13 ack workergnome 15:37:47 workergnome: if we have a context that defines 'name' within a sealed context, [points to examples] 15:38:21 gkellogg: [discusses examples] 15:40:28 gkellogg: it may be simpler in the end to say that sealed terms are always sealed except for @context:null 15:41:08 gkellogg: but subtleties arise when two sealed contexts interact 15:41:15 azaroth: can we do that example? 15:41:24 q+ 15:42:20 ivan: the only place where @context:null would have a nuclear option would be in the context that is sealed 15:42:28 q? 15:43:09 [discussion of various examples] 15:43:24 gkellogg: [refers to examples] 15:43:43 workergnome: ditto 15:43:59 q? 15:44:18 pchampin: [example of two contexts conflicting] 15:44:50 q? 15:44:54 q+ 15:46:04 ack hsolbrig 15:46:32 workergnome: the confusion caused by accounting for the complex interactions outweighs the utility 15:46:57 hsolvig: what if we turned the pattern inside out and let contexts signify that they don't intend to override? 15:47:45 ... if you want to enforce that, you do it on a vocabulry-specific basis 15:47:53 ... with rules for that particular context 15:48:35 gkellogg: so if a context lacked that flag, it would be harder to reuse it 15:48:57 hsolvig: depends on how much you care about this relationship between the contexts 15:49:12 q? 15:49:14 ack ajs6f 15:52:09 q+ 15:54:00 q+ 15:54:15 [discussion of what is or is not in scope for the use case and interoperability concern] 15:55:34 ack ivan 15:55:40 gkellogg: not clear how to specify that 15:55:48 ivan: going back to workergnome's example 15:56:18 ivan: [discusses example] 15:56:57 azaroth: [discsses example] 15:57:29 gkellogg: @context: null has a specific mean 15:57:36 ...ing and we are altering t 15:57:57 q+ 15:58:06 q+ 15:58:08 ivan: if we go down the road of "sealing", then @context:null is going to conflict in some way and we will have to resolve it 15:58:47 hsolvig: that's why I went for an extension-based approach 15:59:08 ack gkellogg 15:59:55 gkellogg: we have until noon! 16:00:07 ack workergnome 16:00:09 hsolvig: can we get the use case in a more concrete form? 16:00:12 gkellogg_ has joined #json-ld 16:00:36 workergnome: I'm incerasingly fond of hsolvig's idea to put in an "extension" property that errors if something with it overrides a term 16:00:50 q+ to have scoped extension 16:00:55 ack pchampin 16:00:57 q+ 16:01:10 ... this allows me to write extensions that will work, but it may not be what VC need 16:02:03 pchampin: I have to think about that idea (hsolvig's idea). gkellogg convinced me to try to explain again how a context becomes ineffective. 16:02:37 ... I'm in favor of saying that whenver I traverse a term that is not part of a sealed context, it's not sealed anymore 16:02:59 ... after which a term could have been redefnined: no guarantees about the semantics! 16:03:39 ... as for @context:null-- maybe the "extension" idea is a better way to make extension points; it makes the unsealing specific 16:04:14 ... to make @context:null work one goes through both extension properties 16:04:43 gkellogg: let's for the moment let's put off the table any terms from a non-sealed context 16:04:55 ... the behavior I heard dlongley describe 16:05:06 ... is that history is wiped out and we start from scratch 16:05:29 ivan: I'm good so far 16:06:19 gkellogg: but if you do want to allow a mixture of sealed and unsealed terms, we get into the case that pchampin discussed 16:07:15 ... two ways to have an extension point: 1) an unsealed term, under which anythign goes, 2) a sealed term that is defined as an extension point 16:07:48 ... and 2) doesn't satisfy the use case 16:08:12 q+ 16:08:56 ivan: let's say I have a claim, and I put into the context a @context:null to make an extension point. 16:09:26 ... the danger is that I will redefine a term from VC, accidentally or maliciously 16:09:48 ... IIUC VC, it's a bit like Annotation 16:10:19 ... outsiders are expected to use their own vocabularies with these guys, without having to understand VC or Annotation 16:10:45 gkellogg: one case is that everything is wiped out, but the other is that you intermingle the use of properties 16:10:53 ivan: so I can add my own context 16:11:02 gkellogg: but not redefine terms 16:11:30 ... we would end up with semantics that differ between JSON and JSON-LD 16:11:39 https://www.w3.org/TR/activitystreams-core/#jsonld 16:12:30 dlehn: the way that Activity Streams does this is to say "You must not override or change contexts" as a normative piece 16:12:40 q+ 16:12:42 azaroth: people do this now by ordering the contexts 16:12:47 q- 16:13:07 ack azaroth 16:13:07 azaroth, you wanted to have scoped extension 16:13:24 azaroth: [returns to examples} 16:16:02 q? 16:16:07 scribenick: jeff_mixter 16:17:24 azaroth: you can say that a sealed context can have an extension 16:18:26 ... having sealed on the context is confusing and makes more sense at the term level 16:19:10 ivan: what is the difference between sealed and extension 16:19:51 q+ 16:20:17 ... if extension was not true then there would be a warning 16:20:33 scribenick:ajs6f 16:20:48 ivan: why not just say extension:true-- it's not setting a context? 16:20:51 q- 16:21:04 azaroth: to distinguish from the case of this term being an extension 16:21:39 gkellogg: two different keywords that act on the context are unclear 16:22:01 q+ 16:22:17 azaroth: the change is that the default condition is "sealed" 16:22:41 q? 16:22:46 i'm on another call and can't join, so i apologize... but was reading what's here and thought i'd throw this in here... if there is a fear that schema.org (or contexts like it) might get sealed ... we could allow `{"@context": [{"@contextref": "http://schema.org", "@sealed": false}, ...]}` and the reason that would be ok for the sealed case we care about in VC community and so on, is because JSON processors would reject that ... the context MUST be 16:22:46 specified as a simple string, that's what JSON-only processors would be looking for: `{"@context": ["https://w3id.org/credentials/v1", ...]}` 16:22:57 q+ 16:22:58 ack workergnome 16:23:35 workergnome: I thought we were talking about three use cases, one of which is ability to delete context, which is @context:null 16:24:08 ... are we trying to prevent people from overriding accidetnally or maliciously? 16:24:22 gkellogg: we can't prevent malice 16:24:37 ivan: it's a clean slate... but not 16:24:45 q? 16:24:53 hsolvig: @context:null is often too much 16:25:05 gkellogg and ivan: [thrash more examples] 16:26:30 azaroth: we fundamentally don't want the semantics to slip between JSON and JSON-lD 16:26:39 q+ 16:26:40 azaroth: [more examples] 16:28:36 q? 16:29:01 azaroth:gkellogg: "extension" unseals everything, which is not @context:null 16:29:43 q? 16:31:01 [discusion of @context:null and whether it is a problem for the original use case] 16:32:10 gkellogg: if there's anothe context with sealed terms and extension points 16:33:06 azaroth: regardless of which context has the sealing, extension overrides it. 16:33:12 q- 16:33:13 gkellogg: that's the simplest way 16:33:16 ack bigbluehat 16:33:21 q- 16:33:32 https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-442896360 16:33:47 bigbluehat: dlongley and I discuss term ordering and inheritence 16:34:06 ... there is a problematic example there 16:34:37 ... [discusses vocabulary] 16:34:41 https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-454485321 16:34:59 ... this example shows how to avoid that by being verbose 16:36:04 ... [discusses problems that concern @type usage and inheritance] 16:36:19 q? 16:36:21 ack workergnome 16:36:48 workergnome: if I have two sealed contexts that define the same term, who wins? 16:36:53 gkellogg: last one in 16:38:30 else, they wouldn't really have one 16:38:37 s/else, they wouldn't really have one// 16:58:55 rrsagent, draft minutes 16:58:55 I have made the request to generate https://www.w3.org/2019/02/07-json-ld-minutes.html ivan 16:59:06 About to restart 17:01:58 scribenick: workergnome 17:02:35 azaroth: Reviewing the rules that we think we're talking about. 17:03:13 jeff_mixter has joined #json-ld 17:03:19 present+ 17:03:41 ajs6f: the use case is to avoid semantic slippage around terms when interpreted as JSON. 17:04:38 azaroth: If @extension:true is encountered in scoped context definition, then attempts to redefine terms from the active context will succeed. 17:04:51 hsolbrig has joined #json-ld 17:05:12 ivan: If this is the rule, in the embedded context, I can also change the ID of that term? 17:05:18 azaroth: yes. You can redefine anything. 17:05:50 ivan: so if i extension : {}, the extension of the original key remains. 17:06:09 gkellogg: the effect of extensions: true is to update the active context and remove the sealed status of all terms within that context 17:06:24 ... allowing those terms to be renamed within the value of the extension property 17:06:36 ivan: so inside, something may be different than outside? 17:06:41 q+ 17:06:55 gkellogg: yes. It only makes sense within a scoped context, and only makes sense on a sealed term. 17:07:14 q+ to ask if we can apply this to dlongley's example here http://tinyurl.com/ycrgkeyy 17:07:24 ... if you extend an unsealed property... 17:07:56 gkellogg: within an extension property, we can only define additional properties within that context. 17:08:59 azaroth: this is an error: 17:09:00 [ {"extension": { @id: extension_property, @sealed:true, @context: {@extension:true}} } }, { "extension": {@id: extension_propery} ] 17:09:28 q? 17:09:29 azeroth: extending unsealed terms is dumb, but not an error. 17:09:30 ack pchampin 17:10:17 pchampin: I'm fine with this...in practice, this would mean that the plain JSON interpretation can only trust terms from the sealed context in the subtrees I defined. 17:10:39 ... because when there is a term from another context, theydon't know anything about that term. 17:11:31 ... if we're happy with this, we're happy, but it seems like a lot of work to get to the same point. 17:11:36 gkellogg: I don't think we're at the same point. 17:11:50 ... it's only when we transition to a property when it's exentsion: true that we transition 17:12:17 pchampin: the assumption that JSON-only is the same--it's only trustworthy when looking at sealed terms. 17:12:23 gkellogg: that's consistent with the spec. 17:12:31 pchampin: right. that's why I'm OK with this. 17:12:52 azaroth: the thing we're not able to deal with is nulling out terms and then redermining them. So it works. 17:13:09 ... so for VC, the context for the claim can start with null, which wipes out their context. 17:13:26 ... so I don't think that VC will use extension: true. 17:13:34 gkellogg: do we have a use case for this? 17:14:58 ivan: I thought that they want to avoid that anyone includes in the claim things that redefine things within verifiable claims 17:15:09 gkellogg: I think that applies to the envelope 17:15:37 ... within the envelope, naive applications may not need to understand them. 17:15:44 ... for example, annotation properties 17:15:50 ... they come from another context 17:16:20 ... so if you introduce another term in the envelope, those envelope extenions won't override the VC 17:16:29 azaroth: don't mess with our stuff 17:17:29 ... vs:issuer should not be overrided, but if an extension defines ex:date, that's fine. but the extension should not be able to override vs:issuer. 17:18:28 gkellogg: ...explaining his example... 17:19:00 ... since we have both a sealed context and schema, name remains it's context. within the extension, something could set the scoped context to null. 17:19:07 ... it could add a new context, and it could be anything. 17:19:17 ... thus, VC does not need extension 17:19:23 ivan: why are we doing this? 17:19:52 ... if this can be met with sealed and nullification, what is the use case for extension? 17:20:27 ... this is the simplest thing that can work. That's what we should do. 17:20:41 ... do we need extension at any point? 17:20:50 gkellogg: I agree. 17:21:06 q? 17:21:08 ajs6f: so there's no need for nullification 17:21:19 ...(i mean extension) 17:21:48 gkellogg: what we determined is that we're not going to restrict context: null. In that case, we don't need the exceptions. 17:21:54 ... you can always do context: null 17:21:59 ... thus, you can do it in a scoped context 17:22:02 ack bigbluehat 17:22:02 bigbluehat, you wanted to ask if we can apply this to dlongley's example here http://tinyurl.com/ycrgkeyy 17:22:05 ... meeting VC's use case 17:22:55 bigbluehat: this VC is something that we haven't discussed 17:23:04 ... We don't have anything that addresses it . 17:23:15 ... since it's type term usage, not property-term usage 17:23:22 ... can we describe it as a use-case? 17:23:35 ... term inheritance works...they don't need sealing... 17:23:47 ... but the scoped context around @type breaks things 17:24:04