15:05:46 <RRSAgent> RRSAgent has joined #json-ld
15:05:46 <RRSAgent> logging to https://www.w3.org/2018/07/27-json-ld-irc
15:05:47 <ivan> rrsagent, set log public
15:05:47 <ivan> Meeting: JSON-LD Working Group Telco
15:05:47 <ivan> Chair: azaroth42
15:05:47 <ivan> Date: 2018-07-27
15:05:47 <ivan> Regrets+ bigbluehat
15:05:47 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0017.html
15:05:48 <ivan> ivan has changed the topic to: Meeting Agenda 2018-07-27: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0017.html
15:24:05 <azaroth> azaroth has joined #json-ld
15:24:20 <azaroth> present+
15:51:25 <simonstey> simonstey has joined #json-ld
15:52:17 <ajs6f> ajs6f has joined #json-ld
15:55:05 <workergnome> workergnome has joined #json-ld
15:57:07 <jeff_mixtter> jeff_mixtter has joined #json-ld
15:59:14 <jeff_mixter> present+
16:00:33 <dlongley> present+
16:00:41 <ivan> present+
16:00:43 <workergnome> present+
16:01:11 <simonstey> present+
16:01:46 <dlongley> scribe: dlongley
16:01:51 <azaroth> scribenick: dlongley
16:02:01 <gkellogg> present+
16:02:29 <azaroth> minutes link: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-07-20-json-ld
16:02:37 <ajs6f> present+
16:02:53 <dlongley> azaroth: Any objections to the minutes?
16:02:56 <dlongley> +1 to the minutes
16:02:58 <simonstey> +1
16:03:00 <azaroth> Proposal: Approve the minutes from last week
16:03:02 <azaroth> +1
16:03:08 <jeff_mixter> +1
16:03:12 <workergnome> +1
16:03:18 <gkellogg> +1
16:03:28 <dlongley> Resolved: Minutes Accepted
16:03:33 <azaroth> TOPIC: Announcements / Reminders
16:04:15 <ajs6f> q+
16:04:17 <dlongley> azaroth: This is the last call before the early bird rate runs out for TPAC. If you haven't registered and are intending to come please register urgently. I'm happy to answer questions about TPAC if you have any.
16:04:19 <azaroth> ack ajs6f
16:04:35 <dlongley> ajs6f: Do you know off the top of your head what the story is with hotel arrangements?
16:04:36 <dlehn> present+
16:04:51 <dlongley> azaroth: First come, first serve basis. I don't know what the status is.
16:05:00 <dlongley> ajs6f: Oh, can't know without calling the hotel.
16:05:10 <dlongley> azaroth: Yes. It's quite likely that there are still rooms.
16:05:25 <dlongley> azaroth: Any other questions/comments about TPAC?
16:05:29 <dlongley> q+
16:05:33 <azaroth> ack dlongley
16:06:25 <dlongley> dlongley: Verifiable Claims WG meeting at the same time as JSON-LD WG, so members might miss one or the other meeting or have to pop in/out.
16:07:03 <dlongley> Topic: Issues proposed to be closed
16:07:16 <dlongley> azaroth: https://github.com/w3c/json-ld-syntax/issues?q=is%3Aissue+
16:07:16 <dlongley> is%3Aopen+label%3A%22propose+closing%22
16:07:30 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22
16:07:51 <dlongley> azaroth: I propose working down from the topic. First issue is #31.
16:07:56 <dlongley> https://github.com/w3c/json-ld-syntax/issues/31
16:08:46 <dlongley> gkellogg: Ivan has suggested that the term type coercion might be confusing. And he has been confused by what it meant by it in JSON-LD. The commenter who raised the issue is of the opinion that because we can specify the datatype of a value in a @context that we should be able to add @type for a node (a class type).
16:09:18 <workergnome> q+
16:09:25 <dlongley> gkellogg: That's not currently the case. The purpose of @type in the context [in a term definition] is to either say that the @type is an ID/URL or a literal value of some datatype. To distinguish strings from other values.
16:09:38 <azaroth> ack workergnome
16:09:39 <dlongley> gkellogg: We have proposed closing this; I think there may be some call to change the language.
16:10:31 <dlongley> workergnome: Having run into this issue back in the early days with playing with JSON-LD. When I was trying to take existing APIs and convert them into JSON-LD, this was the most difficult thing to wrap my head around and to do. Adding in a type is an important part of RDF but no existing APIs I'd worked with included that data. There was no obvious place to put this.
16:10:46 <dlongley> workergnome: That being said, I'm not saying we should necessarily increase scope for JSON-LD, just bringing up what the problem was.
16:11:04 <timCole> timCole has joined #json-ld
16:11:17 <timCole> present+ Tim_Cole
16:11:32 <dlongley> azaroth: We made this exact same mistake in early implementations and adding @type and having compaction fail using filtering, etc. and it failed. I'm +1 for closing this one because adding additional RDF triples via a @context is a terrible idea because those triples will disappear again.
16:11:48 <gkellogg> q+
16:11:50 <dlongley> azaroth: I'm a +1 on the editorial issue. To be clearer that this is exclusively for setting datatypes not for classes.
16:11:51 <azaroth> ack gkellogg
16:12:09 <azaroth> q?
16:12:29 <dlongley> gkellogg: I'd suggest then that we ... we've seen this before where the purpose of the issue morphed through discussion ... this is an example where rather than trying to keep this issue open to describe an editorial issue, we should close this and open a new one.
16:12:34 <dlongley> +1
16:13:02 <azaroth> PROPOSAL:  Close #31 wontfix, and create a new editorial issue to change the language around type coercion
16:13:06 <simonstey> +1
16:13:07 <dlongley> +1
16:13:07 <ivan> +1
16:13:07 <ajs6f> +1
16:13:07 <azaroth> +1
16:13:12 <gkellogg> +1
16:13:14 <timCole> +1
16:13:25 <gkellogg> q+
16:13:27 <azaroth> ack gkellogg
16:13:31 <workergnome> +1
16:13:33 <dlongley> workergnome: Do we feel that adding data via @context is out of scope for JSON-LD 1.1?
16:13:39 <jeff_mixter> +1
16:14:07 <dlongley> gkellogg: We looked at a more comprehensive mechanism in the CG for adding boilerplate content via, I think @content, and the body of that value could be added to something. Then you could add @type in there and add type to the thing. That went down in flames.
16:14:21 <simonstey> +q
16:14:22 <ajs6f> q+
16:14:24 <dlongley> gkellogg: People were misconstruing the purpose of @context -- it is to provide context to the data, not supplemental data.
16:15:10 <azaroth> ack simonstey
16:15:18 <dlongley> gkellogg: Ivan brought up in a comment that this is the role of RDFS/OWL reasoning and we're sort of overstepping ... if we were to add something to say explicitly add the type of an object we'd be repurposing something you'd do through reasoning instead and it would complicated things from an RDF perspective.
16:15:50 <azaroth> q+ to note discussion with danbri re overstepping
16:16:10 <dlongley> simonstey: I was wondering if you'd add this RDF range information in the @context and it's giving context... one could argue it's adding context that you have to interpret the property this way, not adding the property. If someone was using reasoning they could use this context information. One could argue that adding RDFS range is adding context not data.
16:17:11 <azaroth> ack ajs6f
16:17:13 <dlongley> gkellogg: The practice I use when creating @context documents is to include the RDFS data in the [context] document. I've created vocabularies that have done that in WGs. Where do we stop? Are we turning the @context into an alternative way to specify RDFS ... maybe there should be more called out ways to achieve these types of goals and best practices for publishing the RDFS definition along with the @context.
16:18:27 <azaroth> +1 to ajs6f
16:18:33 <azaroth> q?
16:18:36 <dlongley> ajs6f: I'm very much in agreement with Ivan and Gregg's general sense. I wanted to offer one concrete, pragmatic point, someone like me who are assembling systems where RDF is the meta model between components and JSON-LD is just a serialization. The possibility that using JSON-LD in another context would introduce more triples is horrifying. From one point of view inside a message triples could just appear and that's really surprising.
16:18:49 <azaroth> ack azaroth
16:18:49 <Zakim> azaroth, you wanted to note discussion with danbri re overstepping
16:18:57 <dlongley> ajs6f: That's not something that should happen in that way, the reasoning/inference, any new kind of triple coming into the world should be carefully distinguished from what we do with contexts.
16:19:11 <dlongley> azaroth: We're in agreement.
16:20:21 <dlongley> azaroth: Before the charter was approved this was one of Google's concerns. The level of new functionality in 1.1 should be as tightly scoped as possible and not do things like introduce new triples. For the reason Adam said, if you try and interpret a @context you found on the Web, like schema.org's... and then it starts to add in additional data that's not in the document without very strong versioning on the @contexts so you could reproduce where
16:20:21 <dlongley> those triples came from, when you interpret the same data in your cache you get different triples.
16:20:42 <azaroth> q?
16:20:44 <dlongley> azaroth: I am also quite firmly of the opinion that this is out of scope for @contexts, it might not be about of scope for the WG, but it doesn't go in a @context.
16:20:54 <dlongley> +1 from the peanut gallery
16:21:30 <dlongley> Resolved: Close #31
16:21:42 <dlongley> RESOLVED:  Close #31 wontfix, and create a new editorial issue to change the language around type coercion
16:22:16 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/14
16:22:53 <ivan> Subtopic: Lax IRIs
16:23:51 <dlongley> gkellogg: This came about as an effort to quash something where someone has a poor understanding of JSON-LD and was trying to recreate it ... and had this notion that creating IRIs is difficult. Creating any sort of string as an identifier is not a good idea. There has been some discussion of using URLs as a replacement for IRIs which does except a broader syntax and that has been common in a number of different groups.
16:24:24 <dlongley> azaroth: Does anyone want to speak up to allow more lax IDs?
16:24:42 <azaroth> Proposal: Close wontfix.
16:24:46 <ajs6f> +1
16:24:47 <dlongley> +1
16:24:47 <ivan> +1
16:24:48 <gkellogg> +1
16:24:51 <dlehn> +1
16:24:52 <workergnome> +1
16:24:52 <simonstey> +1
16:24:53 <jeff_mixter> +1
16:24:54 <timCole> +1
16:24:54 <azaroth> +1
16:24:59 <timCole> q+
16:25:01 <dlongley> Resolved: Close wontfix.
16:25:14 <azaroth> ack timCole
16:26:05 <dlongley> timCole: I do think that putting an issue in about URLs rather than IRIs might be worthwhile. Sometimes the objection to IRIs means you can't use an URL even though the URL would qualify as an IRI. People who are not RDF-inclined sometimes think that IRIs are more complicated than they are used to.
16:26:41 <dlongley> azaroth: That's a very good point, one we ran into Annotation WG/CG as well. The complication of using Japanese characters in IRIs/URLs.
16:27:13 <dlongley> s/Proposal: Close wontfix/Proposal: Close #14. wontfix/
16:27:18 <dlongley> s/Resolved: Close wontfix/Resolved: Close #14. wontfix/
16:27:21 <ivan> issue on IRI vs URL: https://github.com/w3c/json-ld-syntax/issues/25
16:27:25 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/10
16:27:42 <ivan> topic: 2.0 v. 1.1
16:27:54 <ivan> s/topic/subtopic/
16:28:09 <dlongley> azaroth: There was some discussion last year at TPAC that adding any new feature would cause 1.0 processors to break and we should go to 2.0 not 1.1.
16:28:28 <ivan> q+
16:28:54 <dlongley> azaroth: The charter is pretty explicit after dealing with objections and resolutions to those, that we aren't going to introduce incompatibilities. A JSON-LD 1.0 processor should know not to process a 1.1 document. We're not forward compatible but backwards.
16:29:08 <azaroth> ack ivan
16:29:09 <dlongley> azaroth: I feel like this issue has been decided by the charter and we can close.
16:30:05 <dlongley> ivan: I agree with the resolution, just one more thing to make clear. One thing that came up during chaptering. You referred to this in your discussion with Dan Brickley. We should try to minimize the changes vs. 1.0. The naming has a psychological effect (2.0 vs. 1.1). 2.0 suggests radical changes, 1.1. doesn't mean that. It's not just bug fixes but keeping changes to a minimum. Messaging also justifies keeping it 1.1.
16:30:06 <dlongley> +1
16:30:14 <azaroth> Proposal: Close #10, wontfix. Not going to introduce breaking changes, per charter.
16:30:16 <gkellogg> +1
16:30:16 <ivan> +1
16:30:18 <azaroth> +1
16:30:19 <ajs6f> +1
16:30:20 <jeff_mixter> +1
16:30:23 <dlongley> =1
16:30:23 <timCole> +1
16:30:25 <dlongley> +1
16:30:26 <dlehn> +1
16:30:30 <simonstey> +1
16:30:32 <workergnome> +1
16:30:35 <gkellogg> +1 to dlongley
16:30:49 <dlongley> Resolved: Close #10, wontfix. Not going to introduce breaking changes, per charter.
16:30:51 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/6
16:31:06 <ivan> topic: new `@label` keyword
16:31:51 <dlongley> gkellogg: Someone wanted to add some extra syntactic sugar that you might use when describing node definitions that would replace schema label or presumably something like that. Just syntactic sugar and the @context can be purposed to do that type of thing. I think we forbid using things like keywords. We may want to revisit that.
16:32:01 <workergnome> q+
16:32:05 <dlongley> azaroth: I think there's an issue about raising an error or warning about that.
16:32:15 <azaroth> ack workergnome
16:32:18 <ivan> q+
16:32:24 <dlongley> workergnome: Do we want to open a separate issue about things like @contexts in frames/
16:32:31 <dlongley> s/\/?/
16:33:02 <dlongley> workergnome: If there's not something about a desire for comments within JSON-LD in @contexts that's worth talking about
16:33:20 <azaroth> ack ivan
16:33:22 <dlongley> azaroth: Someone wanting to assert the unit of a height in a comment... I forget whether that was in the CG or WG.
16:34:05 <dlongley> ivan: The problem I have ... using something like that as syntactic sugar is syntactic sugar for what? We won't have our own vocab. Maybe someone wants to use rdfs:label, there is no end to such discussions. I don't see the reason for that.
16:34:29 <azaroth> PROPOSAL: Close #6 wontfix, no need to add syntactic sugar
16:34:30 <workergnome> +1
16:34:31 <azaroth> +1
16:34:32 <jeff_mixter> +1
16:34:33 <ivan> +1
16:34:33 <ajs6f> +1
16:34:33 <gkellogg> +1
16:34:36 <simonstey> +1
16:34:36 <dlongley> +1
16:34:39 <timCole> +1
16:34:39 <dlehn> +1
16:34:44 <dlongley> RESOLVED: Close #6 wontfix, no need to add syntactic sugar
16:34:57 <azaroth> Issue for adding comments to contexts/frames: https://github.com/w3c/json-ld-syntax/issues/32
16:35:12 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/5
16:35:37 <dlongley> azaroth: Adding @language at the object level as a shorthand for doing it in @context.
16:35:43 <ivan> subtopic: object-level `@language`
16:35:54 <dlongley> azaroth: This just introduces more complexities and @language would have to be recognized within the data instead of within the @context.
16:36:18 <dlongley> azaroth: Gregg do you recall if there was significant rationale other than cutting down the number of characters?
16:36:37 <dlongley> gkellogg: I think it perhaps hadn't occurred to the issue proposer that you could add a per-object @context that did exactly this.
16:36:38 <azaroth> q?
16:37:00 <azaroth> PROPOSAL:  Close #5 wontfix, unnecessary syntactic sugar
16:37:02 <workergnome> +1
16:37:02 <dlongley> +1
16:37:03 <gkellogg> +1
16:37:03 <ivan> +1
16:37:04 <azaroth> +1
16:37:04 <jeff_mixter> +1
16:37:05 <ajs6f> +1
16:37:09 <simonstey> +1
16:37:11 <timCole> +1
16:37:14 <dlehn> +1
16:37:16 <dlongley> RESOLVED: Close #5 wontfix, unnecessary syntactic sugar
16:37:25 <ivan> subtopic: Pick a better keyword for `@nest`
16:37:29 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/3
16:37:46 <dlongley> azaroth: Can you refresh us on what @nest refers to?
16:38:50 <dlongley> gkellogg: One of the major features introduced by the CG in 1.1 is the concept of nesting where you can include the properties of an object underneath another one. So "nested" properties. We did bikeshedding. There were a number of different proposals on a vote and @nest won, but not universally loved. At TPAC there was continued lack of love, but this is bikeshedding and no better proposals. Let's just move on is the proposal.
16:39:03 <dlongley> ivan: Or organize a meeting in Lyon. :)
16:39:07 <azaroth> q?
16:39:18 <dlongley> azaroth: Any questions/discussion?
16:39:40 <dlongley> obscurity means you won't get it confused with anything else!
16:40:10 <azaroth> PROPOSAL:  Close #3 wontfix, unnecessary painting of bikesheds
16:40:12 <gkellogg> +1
16:40:13 <dlongley> +1
16:40:14 <jeff_mixter> +1
16:40:14 <ajs6f> +1
16:40:15 <azaroth> +1
16:40:15 <timCole> +1
16:40:16 <dlehn> +0
16:40:21 <simonstey> +1
16:40:24 <ivan> +1
16:40:39 <workergnome> +1
16:40:42 <dlongley> RESOLVED: Close #3 wontfix, unnecessary painting of bikesheds
16:41:40 <ivan> Topic: discuss non-substantive issues
16:41:58 <dlongley> azaroth: We hope we can get consensus around these fairly easily.
16:42:12 <dlongley> azaroth: Will need to be some discussion around the implementation and the wording and so forth, but not ones that would require a lot of changing.
16:42:24 <azaroth> link to issues: https://github.com/w3c/json-ld-syntax/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22propose+closing%22+-label%3Aspec%3Aeditorial+-label%3Aspec%3Asubstantive
16:42:55 <dlongley> azaroth: Start at the top or should we do some easier ones first, Gregg?
16:43:11 <dlongley> gkellogg: Issue #32 is something that we broached already... the ability to define additional metadata in the @context.
16:43:24 <dlongley> gkellogg: Most RDF syntaxes do provide some mechanism for a syntax level comment.
16:43:28 <dlongley> https://github.com/w3c/json-ld-syntax/issues/32
16:43:45 <ivan> subtopic: Is there a way to define additional metadata in JSON-LD `@context`?
16:44:38 <dlongley> gkellogg: JSON-LD being based on JSON does not have a syntax-level comment capability. So one of the thoughts is to create a keyword @comment that is basically syntax level and you ignore the value. The value space for that comment would a legal JSON value and it wouldn't survive compaction/expansion/etc and it would be a way to insert comment definition within a JSON document.
16:44:48 <azaroth> q+
16:44:52 <workergnome> +q
16:44:52 <ajs6f> q+
16:44:59 <azaroth> ack azaroth
16:45:01 <dlongley> gkellogg: That would allow comment like structures within term definitions, etc. Or we could allow it arbitrarily any place else in the whole JSON-LD document.
16:45:29 <workergnome> q-
16:45:29 <dlongley> azaroth: Should we separate adding comments in contexts and frame documents from adding comments in instance documents (actual data)?
16:45:42 <dlongley> azaroth: I see different levels of agreement being possible between those two.
16:45:48 <azaroth> ack ajs6f
16:46:36 <dlongley> ajs6f: I wanted folks to see that link, I don't think it should change the way we end up going on this. That's from Douglas Crockford and I saw people were using them to hold parsing directives and that would destroy interop.
16:46:38 <ivan> Douglas' note on comments: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr
16:46:47 <dlongley> ajs6f: Let's remember that.
16:47:05 <workergnome> +q
16:47:15 <ivan> q+
16:47:20 <azaroth> ack workergnome
16:47:28 <dlongley> ajs6f: I suggest that it's immediately higher complexity. Having separate ways for putting separate data in documents and contexts/frames. I don't know if there are additional problems with using this in keywords, etc. Initially my reaction is please don't make me memorize more keywords to do the same thing.
16:48:10 <azaroth> q?
16:48:12 <azaroth> ack ivan
16:48:13 <dlongley> workergnome: If we're going to do it we should use the same keyword in both places, but the question is really, within @contexts we could add comments, but more thinking required in other JSON-LD documents. I think we should do it in our processing documents is an obvious choice, elsewhere I'd like to think more.
16:48:18 <ajs6f> +1 to workergnome
16:48:26 <gkellogg> q+
16:49:03 <dlongley> ivan: I am a bit torn on this, on the one hand ... everybody using JSON and not being able to comment is painful because I do that a lot. On the other hand not expanding the underlying data model with adding new triples ... I have a similar feeling and we have chosen to use JSON and we're tweaking JSON in some ways. And it looks a little bit dirty to me.
16:49:35 <azaroth> q+ to propose the pattern I just put into IRC
16:49:41 <azaroth> ack gkellogg
16:49:42 <dlongley> ivan: I can't fully explain why I feel uneasy about it. Let's not do that. We have, in a more general sense, we have decided that whatever we do in our model that we should apply to other syntaxes like YAML. Maybe the JSON syntax will add this in the future.
16:49:43 <dlongley> +1
16:49:47 <dlongley> q+
16:49:58 <dlongley> gkellogg: I'll just note that any previous discussion q-
16:50:00 <dlongley> q-
16:50:07 <dlongley> s/q-//
16:50:26 <azaroth> +1 to gkellogg
16:50:39 <dlongley> gkellogg: A JSON-LD 1.0 processor that saw @comment within a @context or within a document would currently ignore it.
16:50:42 <azaroth> q?
16:50:43 <dlongley> q+
16:50:45 <azaroth> ack azaroth
16:50:45 <Zakim> azaroth, you wanted to propose the pattern I just put into IRC
16:50:56 <workergnome> +q
16:51:43 <dlongley> azaroth: If someone mapped rdfs:comment to @comment you'd want to not discard it and it could get slightly confusing.
16:52:10 <azaroth> q?
16:52:12 <azaroth> ack dlongley
16:53:43 <ivan> +1 to dlongley
16:53:47 <azaroth> ack workergnome
16:53:54 <timCole> q+
16:54:45 <azaroth> ack timCole
16:54:48 <dlongley> workergnome: I would be perfectly happy ... I notice me doing workarounds every time I do this, or putting my comments into the data which is then roundtripped ... introducing a keyword that would always be ignored and let me get around this problem I would like that.
16:54:52 <dlongley> workergnome: It's a problem that's real.
16:55:42 <dlongley> timCole: While I agree with Ivan about not polluting JSON with data and the @context and the frame are ours. I think some way of adding meta data to that is important. I don't think it would get superceded if there's a more general comment method in the JSON data. I think it's reasonable for us to consider doing. It will open up some complications I'm sure, but I'd like to see that.
16:55:53 <azaroth> q?
16:56:16 <dlongley> I'm less against putting something in @context than in the data, I'm a -1 on in the data.
16:56:37 <dlongley> azaroth: Let's figure out where we do have consensus.
16:57:01 <dlongley> azaroth: Is it fair to say that people agree that we should not have comments in data? Leaving @contexts/frames alone for now.
16:57:27 <dlongley> azaroth: Is anyone strongly in favor of putting comments to be ignored into the data as opposed into @contexts/frames.
16:57:28 <ajs6f> +!
16:57:33 <gkellogg> +0.1
16:57:50 <azaroth> PROPOSAL: We will not add comments to instance level JSON in a special keyword
16:57:52 <workergnome> +0
16:57:53 <ivan> +1
16:57:55 <azaroth> +1
16:57:55 <ajs6f> +1
16:57:57 <gkellogg> +0.1
16:57:58 <dlongley> +1
16:57:59 <jeff_mixter> +1
16:58:03 <timCole> +1
16:58:08 <simonstey> +1 (as it's similar to the @language issue)
16:58:20 <dlehn> +1
16:58:21 <dlongley> RESOLVED: We will not add comments to instance level JSON in a special keyword
16:59:14 <azaroth> ------
16:59:35 <timCole> +0.5
16:59:35 <azaroth> +1
16:59:40 <ivan> -0.5
16:59:41 <workergnome> +1
16:59:41 <simonstey> +0
16:59:42 <ajs6f> +0
16:59:44 <gkellogg> +1
16:59:47 <dlongley> +0
16:59:53 <dlehn> +0
16:59:55 <jeff_mixter> -0.5
17:00:36 <dlongley> azaroth: Let's just get some feelings on adding something like @comment to @context/frames... not a proposal.
17:00:50 <dlongley> azaroth: Let's take it to the github issue.
17:01:23 <dlongley> azaroth: If you get a chance to think about how you feel on this one please add your arguments in favor/against in #32.
17:01:33 <simonstey> https://github.com/w3c/json-ld-syntax/issues/32
17:01:43 <azaroth> ACTION: Everyone to add thoughts on comments in contexts/frames to issue #32
17:02:25 <ajs6f> bye all!
17:02:28 <azaroth> TOPIC: Adjourn
17:02:30 <ivan> rrsagent, draft minutes
17:02:30 <RRSAgent> I have made the request to generate https://www.w3.org/2018/07/27-json-ld-minutes.html ivan