15:40:30 <RRSAgent> RRSAgent has joined #json-ld
15:40:30 <RRSAgent> logging to https://www.w3.org/2019/03/29-json-ld-irc
15:40:31 <ivan> rrsagent, set log public
15:40:31 <ivan> Meeting: JSON-LD Working Group Telco
15:40:31 <ivan> Chair: azaroth
15:40:31 <ivan> Date: 2019-03-29
15:40:31 <ivan> Agenda: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0039.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0036.html)
15:40:32 <ivan> ivan has changed the topic to: Meeting Agenda 2019-03-29: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0039.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0036.html)
15:40:33 <ivan> Regrets+ bigbluehat
15:40:42 <azaroth> regrets+ Jeff_Mixter
15:40:48 <azaroth> Present+ Rob_Sanderson
15:41:42 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0039.html
15:46:06 <gkellogg> present+
15:47:03 <rubensworks> rubensworks has joined #json-ld
15:53:01 <pchampin> pchampin has joined #json-ld
16:00:17 <ajs6f> ajs6f has joined #json-ld
16:00:47 <ivan> ivan has changed the topic to: meeting agenda 2019-03-29: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0039.html
16:00:58 <ajs6f> present+
16:01:08 <pchampin> present+
16:01:18 <rubensworks> present+
16:01:38 <dlehn> present+
16:01:58 <dlongley> present+
16:03:26 <workergnome> workergnome has joined #json-ld
16:03:44 <azaroth> scribenick: pchampin
16:03:59 <azaroth> TOPIC: Approve Minutes of Previous Call
16:04:10 <azaroth> PROPOSAL: Approve Minutes of Previous Call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-22-json-ld
16:04:12 <azaroth> +1
16:04:12 <workergnome> +1
16:04:13 <ivan> +1
16:04:13 <dlongley> +1
16:04:13 <gkellogg> +1
16:04:21 <rubensworks> +1
16:04:22 <pchampin> +1
16:04:24 <dlehn> +1
16:04:24 <ivan> present+ workergnome
16:04:34 <azaroth> RESOLVED: Approve Minutes of Previous Call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-22-json-ld
16:04:36 <timCole> timCole has joined #json-ld
16:04:45 <azaroth> TOPIC: Introductions
16:04:59 <ivan> zakim, who is here?
16:04:59 <Zakim> Present: Rob_Sanderson, gkellogg, ajs6f, pchampin, rubensworks, dlehn, dlongley, workergnome
16:05:02 <Zakim> On IRC I see timCole, workergnome, ajs6f, pchampin, rubensworks, RRSAgent, Zakim, azaroth, gkellogg, ivan, dlongley, dlehn, ChristopherA, bigbluehat
16:05:41 <ivan> present+ timCole
16:05:42 <pchampin> azaroth: we have delayed Ruben's introduction
16:06:20 <ivan> present+
16:06:41 <timCole> present+ Tim Cole
16:07:12 <pchampin> azaroth: working on the usability of linked data, including with JSON-LD
16:07:17 <ivan> zakim, who is here?
16:07:17 <Zakim> Present: Rob_Sanderson, gkellogg, ajs6f, pchampin, rubensworks, dlehn, dlongley, workergnome, timCole, ivan, Cole
16:07:20 <Zakim> On IRC I see timCole, workergnome, ajs6f, pchampin, rubensworks, RRSAgent, Zakim, azaroth, gkellogg, ivan, dlongley, dlehn, ChristopherA, bigbluehat
16:07:48 <pchampin> gkellogg: presently with Specops; involved with JSON-LD since the beginning
16:08:14 <pchampin> ajs6f: Apache Software Foundation
16:08:20 <azaroth> scribenick: azaroth
16:08:49 <azaroth> pchampin: Pierre Antoine, Associate Prof at University of Lyon, Research includes sem web, lod, and interest in JSON-LD joined after last TPAC in Lyon
16:08:52 <azaroth> scribenick: pchampin
16:09:13 <pchampin> rubenworks: from Genth University; research on publishing and querying LD on the Web
16:09:24 <azaroth> s/Genth/Ghent/
16:09:45 <pchampin> ... I implement a streaming JSON-LD processor
16:10:10 <pchampin> dlehn: from Digital Bazaar; long involved with JSON-LD
16:10:37 <pchampin> dlongley: also Digital Bazaar; one of the co-creators of JSON-LD, and implementor
16:11:08 <azaroth> present- Cole
16:11:35 <pchampin> timCole: XX library; worked with JSON-LD in the Annotation WG, and increasingly using it
16:11:50 <azaroth> s/XX/UIUC/
16:12:03 <pchampin> ivan: W3C staff contact, former lead of the Semantic Web activity
16:12:23 <azaroth> TOPIC: Announcements/ Reminders
16:12:53 <pchampin> azaroth: we have reserved Thursday/Friday for our meeting at TPAC in September
16:13:25 <pchampin> ... we can cancel it if it turns out that too few people can join (possibly because we will be advanced enough)
16:13:46 <pchampin> ivan: we should set a date to make that decision
16:14:03 <pchampin> ... probably around 1st of July
16:14:18 <azaroth> ACTION: azaroth42 to facilitate decision by July 1 for TPAC
16:15:03 <pchampin> gkellogg: we should see if we want to liaise with other groups during TPAC
16:15:54 <azaroth> TOPIC: Issues
16:15:56 <pchampin> azaroth: next week, EU/UK will have switched to DST, so the teleconf will be back to the usual time
16:16:04 <azaroth> SUBTOPIC: Defining term without @id
16:16:12 <azaroth> Link: https://github.com/w3c/json-ld-syntax/issues/129
16:16:40 <pchampin> azaroth: we discussed this in the F2F in Washington DC
16:17:17 <pchampin> ... as part of 116 (allow redefinition of terms), but reducing it
16:18:20 <pchampin> gkellogg: the original issue was about redefining a term without `@id` in the term definition
16:18:51 <ivan> q+
16:18:55 <azaroth> ack ivan
16:19:00 <pchampin> ... I did a few experiment; this should be fairly straightforward
16:19:17 <pchampin> ivan: this would radically change the behaviour compared to 1.0,
16:19:20 <dlongley> q+
16:19:24 <dlongley> q-
16:19:25 <pchampin> ... which we are not allowed to be done.
16:19:55 <pchampin> gkellogg: no, it fails in 1.0, so this is not backward incompatible per se
16:20:20 <dlongley> +1 to mark as editorial for gregg to markup (also, thanks gregg!)
16:20:26 <pchampin> azaroth: is it just editorial, or do we need to discuss how it works?
16:20:27 <pchampin> q+
16:21:03 <pchampin> gkellogg: it should be mostly editorial
16:21:19 <azaroth> ack pchampin
16:27:28 <pchampin> pchampin: if I set "foaf:knows" to an exoctic URI, then redefine "foaf:knows" without an `@id`, does the new definition inherit the exotic URI, or is it back to what "foaf:knows" resolves to?
16:27:36 <pchampin> ... ex: [{"foaf:knows": {"@id": "http://hahaha.org/foo"}, {"foaf:knows": {"@type": "@id"}]
16:27:53 <azaroth> q?
16:28:02 <pchampin> gkellogg: this kind of redefinition is an anti-pattern, possibly even an attack
16:28:18 <pchampin> ... so may be we should consider it as a bug in 1.0 and publish an errata to fix it
16:28:32 <pchampin> dlongley: I'm in favour of fixing security issues
16:28:41 <azaroth> ACTION gkellogg to make an issue for security issue on IRI as term definition
16:28:47 <azaroth> ACTION: gkellogg to make an issue for security issue on IRI as term definition
16:30:24 <pchampin> gkellogg: I even think there's some special logic when the term is an absolute IRI, which we can possibly remove
16:30:38 <azaroth> SUBTOPIC: Sealing and Order  (propose close, no issue)
16:30:47 <azaroth> Link:  https://github.com/w3c/json-ld-syntax/issues/153
16:31:54 <pchampin> rubenworks: I was reading the new 1.1 features, including sealing (now renamed protected)
16:32:21 <pchampin> ... the example shows a property defined as sealed, then a second definition fails to override it
16:32:41 <pchampin> ... but it was not entirely clear to me whether this worked when reversing the order of the definition
16:32:47 <pchampin> s/definition/definitions/
16:33:02 <pchampin> ... but pchampin pointed out that the spec reads "prevent *further* redefinitions"
16:33:16 <pchampin> ... may be it would still be good to add an example to make it clearer
16:33:18 <azaroth> q?
16:33:19 <dlongley> +1 editorial, we're in agreement
16:33:47 <pchampin> azaroth: it is mostly editorial
16:34:13 <ivan> q+
16:34:20 <pchampin> gkellogg: I think there are already many examples
16:34:23 <azaroth> ack ivan
16:34:26 <pchampin> ... maybe a test case would be better here
16:34:44 <pchampin> ivan: this could be mentioned in the Best Practices document
16:35:07 <pchampin> ... I'm always the guy who asks for more examples, but in this case I agree with gkellogg
16:35:24 <azaroth> PROPOSAL: Close #153, no issue, no editorial change needed in the spec.
16:35:27 <azaroth> +1
16:35:29 <rubensworks> +1
16:35:31 <pchampin> +1
16:35:32 <gkellogg> +1
16:35:33 <dlongley> +1
16:35:33 <timCole> +1
16:35:34 <dlehn> +1
16:35:41 <workergnome> +1
16:35:42 <ivan> +1
16:35:44 <azaroth> RESOLVED: Close #153, no issue, no editorial change needed in the spec.
16:36:03 <azaroth> SUBTOPIC: @container [@id, @set]
16:36:13 <azaroth> Link:  https://github.com/w3c/json-ld-syntax/issues/140
16:36:58 <pchampin> azaroth: this issue questions the relevance of `@container` [`@id`, `@set`]
16:38:04 <pchampin> ... many people have answered, in the line of "it's a feature, not a bug"
16:38:19 <azaroth> PROPOSAL: Close #140 as a feature not a bug - no need to use it if you don't want it, and gives consistency
16:38:23 <azaroth> +1
16:38:23 <gkellogg> +1
16:38:26 <dlongley> +1
16:38:28 <timCole> +1
16:38:28 <workergnome> +1
16:38:32 <pchampin> gkellogg: it is about consistency and orthogonality, despite the lack of use case
16:38:33 <pchampin> +1
16:38:33 <rubensworks> +1
16:38:34 <ajs6f> +1
16:38:36 <ivan> +1
16:38:40 <azaroth> RESOLVED: Close #140 as a feature not a bug - no need to use it if you don't want it, and gives consistency
16:38:44 <dlehn> +1
16:39:59 <azaroth> Link: https://github.com/w3c/json-ld-framing/issues/46
16:40:36 <azaroth> SUBTOPIC: Keywords / Flags
16:40:45 <ivan> link: https://github.com/w3c/json-ld-framing/issues/37
16:40:51 <pchampin> gkellogg: I already closed issues 41 and 46 (framing) which I raised myself
16:41:31 <pchampin> azaroth: whould we have complete parity between keywords and flags?
16:42:25 <azaroth> PROPOSAL: Close #37, only edgey edge cases when there is disparity
16:42:28 <azaroth> +1
16:42:30 <pchampin> ivan: we have the parity for most of them;
16:42:32 <ivan> +1
16:42:33 <dlongley> +1
16:42:33 <rubensworks> +1
16:42:36 <gkellogg> +1
16:42:37 <timCole> +1
16:42:40 <pchampin> ... those were we don't are edge cases, so I'm fine with closing it
16:42:41 <pchampin> +1
16:42:44 <workergnome> +1
16:42:50 <dlehn> +1
16:42:51 <azaroth> RESOLVED: Close #37, only edgey edge cases when there is disparity
16:42:54 <ajs6f> +1
16:43:09 <azaroth> SUBTOPIC: Indexing without a predicate
16:43:10 <ivan> https://github.com/w3c/json-ld-syntax/issues/19
16:43:16 <azaroth> Link:  https://github.com/w3c/json-ld-syntax/issues/19
16:43:49 <pchampin> azaroth: we discussed at the F2F
16:44:24 <pchampin> ... there was an action of gkellogg and pchampin to work on it
16:44:35 <pchampin> s/work on/look into/
16:45:00 <pchampin> gkellogg: I didn't have time to look into it yet
16:45:11 <pchampin> pchampin: me neither
16:45:53 <pchampin> azaroth: when an item appears randomly in multiple places in the document,
16:46:21 <pchampin> ... it would be nice to put this item in a kind of "bucket" where its full description is stored,
16:46:41 <pchampin> ... rather than to have to browse the full document to find the random place where the full description is included
16:46:52 <ivan> q+
16:47:12 <azaroth> ack ivan
16:47:50 <pchampin> ivan: this is essentially the 'itermref' feature of microdata
16:48:09 <pchampin> s/itermref/itemref/
16:48:12 <dlongley> q+ to say sounds like a framing issue ... similar to "@anywhere" but with a special key to drop the results in?
16:48:27 <gkellogg> q+
16:48:33 <azaroth> ack dlongley
16:48:33 <Zakim> dlongley, you wanted to say sounds like a framing issue ... similar to "@anywhere" but with a special key to drop the results in?
16:48:40 <pchampin> ... copying that mechanism in JSON-LD seems complicated, but maybe not impossible
16:49:20 <pchampin> dlongley: sounds like a framing issue, similar to "@anywhere"
16:49:41 <pchampin> azaroth: this is not only related to framing, you need something in the context as well
16:49:54 <azaroth> q?
16:49:57 <azaroth> ack gkellogg
16:50:35 <pchampin> gkellogg: this is indeed very much like 'itemref'
16:51:04 <pchampin> ... my concern is that it will be complicated if we want to ensure round-trip (compaction/expansion)
16:51:14 <pchampin> ... like we do for other features
16:51:19 <workergnome> +q
16:51:30 <dlongley> we do have special keywords in the framing compaction algorithm that are treated differently to avoid dropping undefined terms, etc.
16:51:33 <pchampin> ... that could be done using default and framing, but seems like a very complex solution
16:52:01 <ivan> q+
16:52:02 <azaroth> ack workergnome
16:52:48 <pchampin> workergnome: is there a way to handle this as a post-processing step?
16:53:25 <pchampin> gkellogg: the RDFa reference mechanism involves looking in the graph, adding triples and remove triples that were part of the pattern
16:55:07 <azaroth> ack ivan
16:56:02 <pchampin> ivan: if we do that (reproduce the RDFa ref mechanism?) people will run away screaming
16:56:20 <pchampin> ... what we are trying to do is some sort of internal references, essentially relative URIs
16:56:21 <dlongley> q+ to ask if @link would solve the use case
16:56:38 <azaroth> ack dlongley
16:56:38 <Zakim> dlongley, you wanted to ask if @link would solve the use case
16:56:42 <pchampin> ... it would still require to define a bush and not a tree, which forces us to use `@graph`,
16:56:48 <pchampin> ... but it might work
16:58:01 <pchampin> dlongley: if we consider working in memory, consider `@link` which is implemented in the Javascript processor
16:58:10 <pchampin> ... to ensure that an object is stored only in one place
16:58:31 <pchampin> gkellogg: the problem is that you would typically create cycles internally
16:59:47 <pchampin> ... I'm not sure relative URIs can be used without introducing a level of indirection
16:59:58 <gkellogg> q+ to mention issues with streaming profiles
17:00:31 <azaroth> ACTION: azaroth and workergnome to propose a concrete solution, considering link and nest
17:00:34 <azaroth> ack gkellogg
17:00:34 <Zakim> gkellogg, you wanted to mention issues with streaming profiles
17:01:32 <pchampin> gkellogg: if we are moving towards better support for streaming profiles;
17:01:50 <pchampin> ... we can't rely on in-memory storage only
17:01:55 <pchampin> s/profiles;/profiles,/
17:02:49 <pchampin> ... You would need a lot of bookkeeping to handle this.
17:03:49 <pchampin> azaroth: next week, we will talk about the Primer / Best Practices document
17:03:51 <azaroth> TOPIC: Adjourn
17:04:01 <ivan> rrsagent, draft minutes
17:04:01 <RRSAgent> I have made the request to generate https://www.w3.org/2019/03/29-json-ld-minutes.html ivan