13:50:23 RRSAgent has joined #json-ld 13:50:23 logging to https://www.w3.org/2019/02/08-json-ld-irc 13:50:24 rrsagent, set log public 13:50:24 Meeting: JSON-LD Working Group F2F meeting — Second day 13:50:24 Chair: azaroth 13:50:24 Date: 2019-02-08 13:50:24 Agenda: https://tinyurl.com/ycsvtmu9 13:50:24 ivan has changed the topic to: Meeting Agenda 2019-02-08: https://tinyurl.com/ycsvtmu9 13:50:27 gkellogg has joined #json-ld 13:50:28 present+ workergnome 13:50:31 present+ 13:50:34 present+ Rob_Sanderson 13:51:39 present+ 13:58:51 TOPIC: Sealing ... again 13:58:55 Topic: Sealing again... 13:59:00 scribenick: jeff_mixter 13:59:12 jeff_mixter has joined #json-ld 13:59:13 zakim, who is here? 13:59:13 Present: workergnome, ivan, Rob_Sanderson, simonstey 13:59:15 On IRC I see jeff_mixter, gkellogg, RRSAgent, Zakim, azaroth, workergnome, ivan, pchampin, simonstey, ChristopherA, bigbluehat, fr33domlover, dlehn, dlongley 13:59:15 present+ 13:59:20 present+ pchampin 13:59:23 present+ 13:59:28 scribenick: jeff_mixter 13:59:53 dlehn: Can you make it today? 13:59:57 bigbluehat: Ditto? 14:00:43 s/dlehn: Can you make it today?// 14:00:47 s/bigbluehat: Ditto?// 14:00:55 hsolbrig has joined #json-ld 14:02:12 pchampin: not ok with the decision with context null being able to wipe everything. it is brittle and using a nested context that could have null. It is not necessary to seal terms 14:02:28 ... we are overwriting context null 14:03:19 ... solution is to separate the functions and create a new keyword that can be used to unseal all of the current sealed terms. @unseal no would unseal all terms for example 14:03:31 ... sealed terms would not be touched 14:04:18 q+ 14:04:18 ... a third benefit would make it easier to deal with the situation where you import a sealed context 14:04:38 ack ivan 14:04:47 present+ 14:04:58 ivan: what this means is that a context null wipes out everything except what is sealed 14:05:27 pchampin: no opinion on how this would function but sealed terms would not be affected 14:06:12 workergnome: for the use case where you have an area in the document we would need to use unsealed and context null 14:06:35 q+ 14:06:36 azaroth: you could unseal everything and adding null to blow everything away 14:07:17 q+ to note the asymetry of `@unseal` 14:08:05 present+ 14:08:20 whiteboard link https://docs.google.com/document/d/1FcbySJzY5QyBW6HcCtO0LCUmppgIJqQzv565BqC5bOU/edit?pli=1#heading=h.vjeyyuqsyju9 14:09:15 gkellogg: is you see the @seal today it would have problems 14:09:51 ivan: this is very similar to the extension conversation we had yesterday 14:10:19 pchampin: this is a separation of concerns to unseal terms and/or wipe the context 14:10:35 ajs6f has joined #json-ld 14:10:41 present+ 14:10:53 ivan: yesterday we came to this a realized that we do not have a real use case for this 14:11:14 q? 14:11:18 ack ivan 14:12:00 ack gkellogg 14:12:00 gkellogg, you wanted to note the asymetry of `@unseal` 14:12:01 ivan: if you look at the examples at the end we decided to seal individual terms so in the current proposal we should rather look being able to unseal individual terms 14:12:09 q+ 14:13:27 gkellogg: there is the asymetry of unseal and seal - unseal unseals everything. this need does not seem to exist in the wild. 14:13:39 ack pchampin 14:13:44 ... not in favor of doing this 14:14:41 q+ 14:15:00 pchampin: agrees that the syntax is a bit odd but regarding the use cases from yesterday we were looking for a way to unseal the entire context. the use case here is when you encounter random sealed contexts in the wild 14:15:22 q+ 14:15:35 ack gkellogg 14:16:15 gkellogg: if we allow you to fix wild sealed contexts we lower the need/concern to get the use of seal correct 14:16:40 ... better option is to have the community decide what should be sealed 14:16:49 ack workergnome 14:17:27 workergnome: if we provide a mechanism to unseal sealed context that defeats the original point of this issue 14:17:35 q+ 14:18:25 ajs6f: thought is was more of a strong suggestion to not unseal not a restriction to unseal 14:18:36 ack pchampin 14:19:21 q+ 14:19:44 pchampin: my concern about context null we are defeating the reason for seal but in a more sneaky way. this proposal clearly defines what we are doing and can imply why we are doing it 14:24:12 gkellogg: wanted to note that we can not expect sanctity around contexts sealed, unsealed, null, etc 14:24:32 q+ 14:24:34 ack gkellogg 14:24:51 ... more comfortable with context null 14:24:56 ack azaroth 14:25:40 azaroth: also prefer context null because it raises the stakes for the user as opposed to just unsealing the terms. with null, you need to start all over 14:26:58 q? 14:27:08 ajs6f: if you want to unseal the context terms, you need to know all of the terms to unseal but if you can unseal at the context level 14:27:18 ... it is not a huge problem 14:27:31 q+ 14:27:36 ack bigbluehat 14:28:21 ivan: we should put in a proposal and move on 14:28:47 azaroth: sounds like we prefer the decision from yesterday 14:29:23 PROPOSAL: After discussion, we agree on no change to sealed contexts from yesterday 14:29:25 +1 14:29:28 +1 14:29:30 +1 14:29:35 +1 14:29:35 +1 14:29:35 +1 14:29:43 +1 14:29:43 +1 14:29:57 RESOLVED: After discussion, we agree on no change to sealed contexts from yesterday 14:30:25 Topic: issue 108, adding metadata to contexts 14:31:04 github: https://github.com/w3c/json-ld-syntax/issues/108 14:32:28 azaroth: from the discussion around sealing 14:32:51 ... beyond being able to seal we want to check if a context has changed 14:32:56 q+ 14:33:27 ... you should be able to annotate the context to know its version or a checksum to test it 14:33:50 ... there is a spec that already does this SRI 14:34:20 ... a 1.1 processor could use this to see if a context has changed and if so do something 14:35:16 q+ 14:35:20 ack ivan 14:35:58 link to SRI https://www.w3.org/TR/SRI/ 14:36:24 ivan: originally this type of feature was based on the desire to create a helping hand for implementations that want to use caching for contexts 14:37:33 ... this is what SRI is used with in HTML 14:38:12 -> https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-460201634 another syntax 14:38:52 q? 14:39:43 q+ to mention that hashlink encodes all that in a single URL (not just URI or IRI) -- see https://github.com/w3c/json-ld-syntax/issues/9#issuecomment-451245308 14:39:54 ... as an alternative we could have data that points to the nearest stored version of the context similar to how CSS works 14:40:50 ack workergnome 14:40:54 ... extra metadata for the context could be added and might be useful 14:40:55 q+ 14:41:00 q+ 14:41:11 workergnome: how is this related to hash links? 14:41:21 ivan: SRI is around and tested 14:41:36 ack bigbluehat 14:41:36 bigbluehat, you wanted to mention that hashlink encodes all that in a single URL (not just URI or IRI) -- see https://github.com/w3c/json-ld-syntax/issues/9#issuecomment-451245308 14:42:10 ... for SRI it is an existing implementation feature in HTML so all we have to so is refer to the SRI documentation 14:43:49 bigbluehat: question the value of encoding this in the context 14:45:23 ... concerned about adding all of the metadata for contexts into the context 14:45:41 q? 14:45:50 ack gkellogg 14:45:53 spec: https://tools.ietf.org/html/draft-sporny-hashlink-02 14:46:11 q+ to be -1 on hashlink too 14:46:26 msporny's write up of hashlink's value to JSON-LD (and friends) https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0000.html 14:46:30 gkellogg: this seems like we are in the HTML domain based on the use cases 14:47:11 q+ to be -1 on hashlink and html only 14:48:15 ... like the idea of pathing but feel like we should not bake that into the standard 14:48:23 ack hsolbrig 14:48:26 +1 to gkellogg's thoughts 14:48:28 q? 14:48:44 q+ to ask about kicking it up 14:48:44 hsolbrig: this seems like a general problem not specific to JSON-ld 14:49:31 q? 14:49:33 ack azaroth 14:49:33 azaroth, you wanted to be -1 on hashlink too and to be -1 on hashlink and html only 14:50:55 azaroth: against hashlinks because it is not normative. this is not prohibited but we do not need to explicitly say so. Do not want to focus just an a HTML approach 14:51:23 q+ 14:51:32 ack ajs6f 14:51:32 ajs6f, you wanted to ask about kicking it up 14:51:54 ajs6f: maybe we could offer best practices 14:51:56 +1 to best practice note 14:52:03 q> 14:52:05 q? 14:52:14 s/q>// 14:52:55 q+ 14:53:02 ... should we kick this issue up for the broader community to discuss 14:53:15 ack ivan 14:54:13 ivan: do not see the relation to HTML as relevant. for SRI all we need is a clear definition of what the hash value we are using is referring to 14:54:51 q? 14:54:58 q+ 14:55:47 ajs6f: do we need to specify what to do with the hash value 14:55:53 ivan: no 14:57:19 ajs6f: is this a protocal level question? 14:57:59 ack dlehn 14:58:29 q+ 14:59:02 dlehn: the readability could be a concern 14:59:14 q+ 14:59:22 ack azaroth 15:01:56 q+ 15:03:29 azaroth: reliance on the http headers seems not feasible. since a document can load in multiple contexts where should that information be stored and acted upon. 15:03:50 gkellogg: if the integrity checking is not done on the processor than it will not work 15:04:02 ack hsolbrig 15:04:59 hsolbrig: this is another feature we are adding to JSON-ld 15:05:33 ... what do we gain for adding this into the spec? 15:06:52 ivan: if you want to help folks that are on a bad network connection - this could solve that problem. 15:07:27 ack workergnome 15:07:29 hsolbrig: what about support for current integrity versioning approaches that work and are used? 15:08:07 workergnome: to implement this we will need to add a third way to reference contexts 15:08:34 ivan: we could defer this because it opens a lot of questions that we would need to address 15:09:02 ivan: what do say to the folks that have this problem now 15:11:30 q? 15:11:51 q+ 15:12:50 ... we do not have anything in our spec to address this use case concern 15:13:11 ack gkellogg 15:13:36 gkellogg: this is a resource caching issue and there is ways to solve this currently 15:13:44 q? 15:13:48 q+ 15:15:56 ack workergnome 15:16:06 q+ 15:17:00 workergnome: is we allow metadata in context - we could also rethink adding documentation in the context 15:17:12 ack ajs6f 15:17:29 ack ivan 15:17:36 ajs6f: is integrity also part of the concern? 15:17:39 q+ to talk about integrity 15:18:40 ivan: there are a few reference implementations. they should try to implement the best possible caching control and see how it work and document how to do it 15:19:06 q+ 15:19:22 ack azaroth 15:19:22 azaroth, you wanted to talk about integrity 15:21:57 ivan: all of these implementations should serve as examples on how to solve this problem 15:22:41 current CG "best practice" for caching https://json-ld.org/spec/latest/json-ld-api-best-practices/#cache-context 15:24:08 azaroth: the issue of integrity is related to versioning - want to ensure that the contexts that are being loaded are not mutable 15:26:57 hsolbrig: this is sort of what http expire headers are used for 15:26:58 q? 15:27:01 ack hsolbrig 15:27:32 hsolbrig: if we did SRI we would need to explain how it works and what to do with it 15:29:36 q+ 15:29:55 q+ 15:30:28 ack azaroth 15:31:50 ack ivan 15:32:27 azaroth: we should propose that this is an issue but we are not the folks to deal with it 15:33:18 ivan: agreed but we might want to also say that we will be more rigorous about documenting how implementors do this 15:33:25 PROPOSAL: Defer the integrity/context metadata related issues, and request early horizontal review from security, privacy and TAG. 15:33:35 +1 15:33:35 +1 15:33:36 +1 15:33:36 +1 15:33:37 +1 15:33:37 +1 15:33:38 +1 15:34:09 RESOLVED: Defer the integrity/context metadata related issues, and request early horizontal review from security, privacy and TAG. 15:34:51 +1 15:54:16 hsolbrig has joined #json-ld 15:54:22 scribenick: hsolbrig 15:54:35 asaroth: Issue 19 15:54:38 Topic: "itemref", issue 19 15:54:55 scribenick: hsolbrig 15:55:29 q+ 15:56:02 azaroth: issue occurs when resource occurs multiple times in the graph. What would be nice that if you knew that terms got used repeatedly... 15:56:05 q+ 15:56:38 https://jsonapi.org/format/1.1/#document-top-level 15:56:53 ... would be nice if you had references from the inclusion to included. JSON API calls it "included" 15:57:39 ... JSON Schema has $ref. 15:57:45 an example of it in the JSON-API spec is here: https://jsonapi.org/format/1.1/#document-compound-documents 15:58:20 ... useful in graph context so you can use references rather than values 15:59:08 ... is this a frame issue or syntax? We decided both - could go into framing to know that "included" is not a predicate, it is the inclusion 15:59:30 ... references block rather than included. 15:59:55 q+ 16:00:12 gkellogg_ has joined #json-ld 16:00:17 gkellogg: did you consider the RDFa approach, where there is a way to output triples where after parsing there is a reasoning step? 16:00:28 ivan: I thought that was more directly done... 16:00:52 q? 16:01:08 gkellogg: ... that was microdata. RDFa is more directly -- reasoner takes triples and outputs w/ different subject. 16:01:08 ack workergnome 16:01:26 jeff_mixter: is there a way to solve this with @graph? 16:01:39 q+ to ask if a combination of @nest and @container could not do the trick? 16:01:59 ... I have a first block of JSON which is object outside of a graph and addl subgraphs with aliased keyword 16:02:21 ivan: this is mixing levels -- syntax is similar but this is not a graph 16:02:42 gkellogg: inverse properties? Included have reverse relationships to items that are included 16:02:51 q+ to ask for review (against use case at hand) of this @graph-based example http://tinyurl.com/y7hg7b9u 16:03:39 ... is_classificaton_of is at term that is an @reverse -- achieves separation of concerns but also includes expanding, compacting and framing for round trip 16:04:07 azaroth: would still need an @nest property. 16:04:20 q? 16:04:22 q- 16:04:22 ack ivan 16:04:43 ivan: there are two ways to look at this: 16:05:22 ... 1) enum:c6 is an internal reference that we could handle with fragment id in graph, but I have an extra triple in the graph ... 16:05:29 ... you get extra links 16:05:53 ... 2) conceptually expect value of enum:c6 to be physically replicated and put back into the node 16:06:19 ... itemref (the only good feature in microdata) did the replication option 16:06:46 ... JSON Schema creates a fragment identifier, but is this what you are looking for? 16:06:51 q- 16:07:00 workergnome: our use case is the latter case 16:07:26 ... because in a JSON only environment, knowing where to go is difficult. 16:07:59 ivan: Option 2) requires duplication and massaging in graph... 16:09:26 azaroth: gregg's proposal w/ included : {"@container": "@id"} (sort of) works 16:09:55 ivan: included should be a nest 16:10:51 workergnome: how do I get option 2) (included under classification)? 16:11:24 q? 16:11:43 gkellogg: we'd still need an inverse thing. If I have an id map but want to say it is sort of transparent... 16:12:11 ivan: if a term is defined to be @nest, does @id still work or do you ignore that once and for all? 16:12:51 gkellogg: @nest allows me to use an intermediate property to hold things which are pushed up. We want subtree to be somewhere else 16:14:01 ivan: if included is @nest, is @container: @id still valid? 16:14:11 gkellogg: round tripping is an issue as well. 16:14:12 ack bigbluehat 16:14:12 bigbluehat, you wanted to ask for review (against use case at hand) of this @graph-based example http://tinyurl.com/y7hg7b9u 16:14:31 q+ 16:15:16 bigbluehat: posted playground example above that uses "embedded". Seems to do what you want. Note that "included" is an array in 16:15:27 q+ 16:15:45 ... json API not an object. Also introducing a non-JSON reference mechanism 16:16:03 ivan: what you do is define a graph, not the content of the graph 16:16:42 azaroth: there is a blank node _:b0 which has a name and a type 16:17:19 gkellogg: use a preprocessing tool or do it the way RDFa does it? 16:17:40 workergnome: I could do this but it wouldn't be valid JSON-LD ... 16:17:55 gkellogg: It would be, but it wouldn't be the graph you are looking for 16:20:25 (discussion about examples on FTF document... w/ @nest and rather than containing , references object...) 16:20:48 q? 16:20:58 q- 16:21:30 ack pchampin 16:21:35 q? 16:21:37 workergnome: in practice we use @id in our main document and use a placholder in data, but requires an addition piece of semantic ata 16:22:12 pchampin: 2 questions. 1) Do we agree that the enum term should be defined as well? (a: yes) 16:22:51 ... 2) is "@type": "@nest" the way it would be written? (a: no) 16:22:54 nest: https://www.w3.org/TR/json-ld11/#ex-65-defining-property-nesting 16:23:38 gkellogg: could handle it with n3 reasoning? 16:23:57 ... it seems like we are trying to do things at a totall different level. 16:24:22 q? 16:24:45 ajs6f: one other wrinkle ... this would play oddly with a streaming processor. 16:25:01 gkellogg: this is the reason we did rdfa the way we did 16:25:49 ivan: in rdfa we define terms and additional semantic rules, which is what we do here. 16:26:02 gkellogg: it has already been done, we could just reference it. 16:26:28 http://localhost:8001/TR/html-rdfa/#property-copying 16:26:59 https://www.w3.org/TR/html-rdfa/#property-copying 16:27:28 ivan: done through RDF, but way too complicated... 16:27:52 reminds me of the very first version of RDF 16:28:34 rdf:aboutEach 16:29:20 http://tinyurl.com/ydgfcgl4 16:30:33 (azaroth using playground example between jane and john...) 16:33:13 q? 16:34:03 ivan: copying vs. referencing. We can say that copying stuff is outside json-ld. 16:34:51 ... reference, however, might be doable. What do we need to make the example on the screen (enum:c6, ... in issue #19) work 16:35:02 q+ to ask about JSON API compatibility 16:35:24 .... included is there because of bookkeeping. The approach feels natural 16:36:49 ... if included is nested, you take it out of the equation alltogether... 16:38:07 azaroth: needs to be a new syntax ("@id": "@nest"?) 16:38:39 simonstey: works as expected on playground but @id: @nest doesn't work 16:42:16 ack bigbluehat 16:42:16 bigbluehat, you wanted to ask about JSON API compatibility 16:42:31 https://json-ld.org/playground-dev/#startTab=tab-nquads&json-ld=%7B%22%40context%22%3A%5B%22http%3A%2F%2Fschema.org%2F%22%2C%7B%22labels%22%3A%7B%22%40id%22%3A%22%40nest%22%7D%7D%5D%2C%22%40type%22%3A%22Person%22%2C%22labels%22%3A%5B%7B%22familyName%22%3A%22Doe%22%7D%2C%7B%22givenName%22%3A%22Jane%22%7D%5D%7D 16:44:27 gkellogg: is there a way through @nest to subsume @graph while defining a bush 16:44:51 gkellogg: today, nesting requires the object 16:47:17 gkellogg: There's obviously work to be done... 16:47:21 q+ 16:47:27 azaroth: how much? 16:48:55 gkellogg: (waffles and ponders...) involves extending id of nesting... there a lot of angles to this, man. 16:49:05 ack workergnome 16:49:32 workergnome: to clarify, we're not addressing framing right now, correct? 16:51:32 ivan: @workergnome -- is this approach still ok? Does it accomplish what you want? 16:53:05 PROPOSAL: Continue to explore @nest with additional features, such as @container:@id, as a solution to issue #19 16:53:09 +1 16:53:10 +1 16:53:10 +1 16:53:11 +1 16:53:12 +1 16:53:13 +1 16:53:14 +1 16:53:15 +1 16:53:15 +1 16:53:17 +1 16:53:26 RESOLVED: Continue to explore @nest with additional features, such as @container:@id, as a solution to issue #19 16:53:57 +1 16:54:26 ACTION gkellogg and pchampin to explore effect of @nest+@container:@id on compaction and expansion 16:54:34 ACTION: gkellogg and pchampin to explore effect of @nest+@container:@id on compaction and expansion 18:08:40 azaroth__ has joined #json-ld 18:33:57 workergnome has joined #json-ld 18:37:13 ivan has joined #json-ld 18:39:14 hsolbrig has joined #json-ld 18:40:51 scribenick: ajs6f 18:41:17 ajs6f has joined #json-ld 18:41:37 TOPIC: YAML? CBOR? 18:41:46 charter https://www.w3.org/2018/03/jsonld-wg-charter.html 18:41:55 jeff_mixter has joined #json-ld 18:42:06 present+ 18:42:09 azaroth: [quotes from charter] 18:42:11 present+ 18:42:21 ivan: I have no idea how that got there 18:42:29 ... i.e. who wanted that there 18:42:37 gkellogg: there was some yaml-ls out there 18:42:48 s/yaml-ls/yaml-ld 18:42:58 ... but CBOR is more interesting 18:42:58 CBOR: http://cbor.io/ 18:43:26 q+ 18:43:40 ivan: we should ignore the complexites of CBOR 18:43:46 ... that go beyond JSON 18:43:56 YAML: https://yaml.org/ 18:44:05 q? 18:44:26 ack bigbluehat 18:44:32 gkellogg: support for native types in CBOR would be useful if we do CBOR 18:45:09 bigbluehat: the CBOR idea is more compicated, but more valuable 18:45:38 ... the broader question is whether someone intends to process this kind of stuff w/o conversion to JSON first 18:46:00 q+ 18:46:09 ack ivan 18:46:31 ivan: tbc, we cannot publich a recomendation on this, but we can publish a note 18:46:55 q+ 18:47:03 ack dlehn 18:47:05 bigbluehat: CBOR is important in the space of crypto, signing, etc. 18:47:24 dlehn: YAML has a lot of advanced features, e.g. linking, a type system 18:47:34 ... that's all interesting, but it doesn't match JSON-LD at all 18:47:42 ... that feels like a different spec 18:47:46 q+ 18:48:20 gkellogg: we could offer spec text such that the native types could be extended 18:48:36 ... we might be bale to provide an extension model for that 18:49:11 ack ivan 18:49:24 ivan: we are a small group 18:49:33 ... anything we have here requires ownership from someone 18:49:56 ... if I have to choose, the one that has a market is CBOR 18:50:11 ... much as I like YAML, it has a small usage 18:50:27 dlehn: YAML is used a lot for configuration 18:50:48 ivan: just trying to be realistic 18:51:12 hsolbrig: bioinformatics and biology used the heck out of YAML, not so much JSON 18:51:29 ivan: do we have someone who will own this? 18:51:46 azaroth_ has joined #json-ld 18:52:31 azaroth: Is anyone willing to own a document that describes the relationships between these languages 18:52:42 q? 18:52:54 hsolbrig: there may be interest from my group, let me check into it 18:53:12 ivan: if we can do one, we should do CBOR! It's binary. 18:53:26 ... we would get a binary format for free 18:54:30 ivan: has anyone tried conversion to see what the gain is? 18:54:59 [discussion of potential space gains] 18:55:04 http://cbor.me 18:55:36 [discussion of CBOR] 18:56:08 gkellogg has joined #json-ld 18:56:54 azaroth: we can put some priorities into the various notes documents we've discussed 18:57:12 ... the comunity would benefit much more from the primer than anything about YAML 18:57:17 [general agreement] 18:57:46