15:31:09 <RRSAgent> RRSAgent has joined #json-ld
15:31:09 <RRSAgent> logging to https://www.w3.org/2019/07/19-json-ld-irc
15:32:01 <azaroth> rrsagent, set log public
15:32:06 <azaroth> Meeting: JSON-LD Working Group Telco
15:32:12 <azaroth> Date: 2019-07-19
15:32:41 <azaroth> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jul/0005.html
15:32:50 <azaroth> azaroth has changed the topic to: Agenda 2019-07-19: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jul/0005.html
15:33:03 <azaroth> regrets+ ivan
15:33:07 <azaroth> regrets+ workergnome
15:33:19 <azaroth> regrets+ rubensworks
15:33:26 <azaroth> regrets+ bigbluehat
15:33:53 <azaroth> zakim, this is JSON-LD
15:33:53 <Zakim> got it, azaroth
15:34:00 <azaroth> Chair: azaroth
15:55:52 <ajs6f> ajs6f has joined #json-ld
15:57:33 <pchampin> pchampin has joined #json-ld
16:01:22 <gkellogg> gkellogg has joined #json-ld
16:01:56 <timCole> timCole has joined #json-ld
16:02:35 <gkellogg> present+
16:02:45 <ajs6f> present+
16:02:51 <pchampin> present+
16:02:51 <timCole> present+
16:03:00 <dlongley> present+
16:03:31 <dlongley> https://w3c.github.io/vc-data-model/#base-context
16:04:40 <azaroth> present+
16:04:55 <azaroth> TOPIC: Scribe Selection
16:05:18 <dlongley> scribe: dlongley
16:05:22 <dlehn> present+
16:05:29 <azaroth> TOPIC: Approve minutes of previous call
16:05:36 <azaroth> PROPOSAL: Approve the minutes: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-12-json-ld
16:05:38 <azaroth> +1
16:05:39 <gkellogg> +1
16:05:39 <dlongley> +1
16:05:42 <pchampin> +1
16:05:54 <timCole> +1
16:05:56 <azaroth> RESOLVED: Approve the minutes of the previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-12-json-ld
16:06:05 <azaroth> TOPIC: Announcements / Reminders
16:06:14 <hsolbrig> hsolbrig has joined #json-ld
16:06:27 <dlongley> azaroth: Weekly reminder to register for TPAC and book travel if you haven't already. Any other announcements or reminders?
16:06:30 <dlongley> q+
16:06:34 <azaroth> ack dlongley
16:06:39 <azaroth> scribenick: azaroth
16:06:56 <dlongley> https://w3c.github.io/vc-data-model/#base-context
16:07:02 <azaroth> dlongley: The VC model is going to PR shortly. This is short notice, but please do give feedback on it if you can
16:07:07 <azaroth> ... either today or monday please
16:07:10 <hsolbrig> present+ hsolbrig
16:07:29 <azaroth> ... send that to me, or to the WG.  Quicker to send to me (dlongley) directly :)
16:07:31 <gkellogg> q+
16:07:33 <azaroth> ack gkellogg
16:07:37 <azaroth> scribenick: dlongley
16:07:50 <jeff_mixter> jeff_mixter has joined #json-ld
16:07:55 <jeff_mixter> present+
16:07:56 <dlongley> gkellogg: Regarding that, you pointed to the appendix within the spec where you've put the context, which does limit your ability to change that later on.
16:08:21 <dlongley> gkellogg: As we've seen sometimes they do need to be changed downstream -- and the time...
16:08:28 <azaroth> q+ to note that Annos did this too
16:08:33 <azaroth> scribenick: azaroth
16:08:46 <azaroth> dlongley: We need to lock everything in due to the way that the model and implementations work
16:09:15 <azaroth> ... So any new context would require a new URL. We're looking to lock it in for v1 credentials. Most people won't actually process it, just by reading human readable spec
16:09:17 <azaroth> q?
16:09:18 <azaroth> ack azaroth
16:09:18 <Zakim> azaroth, you wanted to note that Annos did this too
16:09:46 <dlongley> azaroth: We also did that in the Annotations WG which has been a little bit counterproductive at times but we did it for exactly the same reason that we wanted to lock everything down.
16:10:13 <dlongley> azaroth: Have the same pattern in other spaces as well, only for major versions though. The context will be backwards compatible for all of those changes, if it produces exactly the same output that's fine.
16:10:18 <dlongley> azaroth: That has worked for us.
16:10:24 <azaroth> q?
16:11:08 <azaroth> TOPIC: Privacy HR
16:11:14 <azaroth> ref: https://github.com/w3c/json-ld-wg/issues/88
16:11:15 <dlongley> azaroth: We have some feedback from PING.
16:11:43 <dlongley> azaroth: Would be good to discuss now and send the answers we get back to the group.
16:11:57 <dlongley> azaroth: Q1. I don’t see a point where the described API touches the Web API. How is this intended to be used by applications running in the browser?
16:12:27 <dlongley> azaroth: To me, the answer is that it's just data and it's intended to be loaded into browser apps rather than the browser directly. Is that a reasonable response or do we need to say more?
16:12:31 <azaroth> q?
16:12:55 <dlongley> gkellogg: I'd say that's right. There is no model currently how a JSON-LD script block is intended to interact with HTML and that would seem to be the responsibility of some other spec or possibly another group.
16:13:05 <dlongley> azaroth: Q2. What privacy relevant information is sent with calls to the documentLoader end point? Cookies or similar? If so, pulled from what origin (and single or double keyed), etc? In general more explanation of how this interacts with the browser is needed.
16:13:41 <dlongley> azaroth: They'd like more information about how the document loader interacts with the browser. This follows on from the first one, applications within the browser will use XmlHttpRequest [or fetch, etc.].
16:14:01 <dlongley> azaroth: They specifically ask about the document loader. Is there anything in particular that is different for document loaders compared to anything else?
16:14:58 <dlongley> gkellogg: There's nothing sent along -- there's no cookies or anything like that, it's an HTTP GET request. There's HTTP headers, considerations for cross origin access, things like that that are outside of the scope of this. We only describe the behavior of a document loader -- that there is such a thing that is used to fetch and could provide a hook for in browser implementations to do that.
16:15:05 <dlongley> gkellogg: Most of the description of the document loader is what you do with the response.
16:15:08 <dlongley> q+
16:15:17 <azaroth> scribenick: azaroth
16:15:17 <dlongley> gkellogg: It does imply access to the returned HTTP headers, for example a link header.
16:15:37 <azaroth> ack dlongley
16:16:14 <azaroth> dlongley: I was going to add that our spec doesn't create any _new_ headers or behaviors to implement, we provide an API that you can implement however you want. Can use fetch or XHR, and all the privacy implications of those
16:16:26 <azaroth> ... it doesn't let you do anything new, beyond what those APIs already do
16:16:31 <azaroth> scribenick: dlongley
16:16:52 <dlongley> azaroth: Q3. If this is intended to be implanted in browsers, have any vendors implemented it? Generally W3C prefers at least two independent implementations of functionality before standardizing / recommending.
16:17:18 <dlongley> azaroth: It could be implemented by browsers. Chrome could have a JSON-LD specific thing...
16:17:19 <dlongley> q+
16:17:31 <azaroth> ack dlongley
16:17:35 <azaroth> scribenick: azaroth
16:17:48 <azaroth> dlongley: Agree there's no *intention* to be implemented, there's nothing to prevent it
16:18:12 <azaroth> ... Chrome has put it in lighthouse. THey're using a JSON-LD processor which ships with the browser, but not otherwise aware of native code
16:18:27 <azaroth> scribenick: dlongley
16:18:36 <dlongley> azaroth: Given that there's one browser implementation -- is that going to cause given that there isn't two?
16:18:36 <gkellogg> q+
16:18:37 <dlongley> q+
16:18:48 <azaroth> ack gkellogg
16:19:41 <dlongley> gkellogg: I think they think we're trying to do more than we are. We are just describing the format of a data block that can appear in HTML without describing its interactions or how you get that the contents of that data block. The action of a browser directly interacting with these blocks is outside the scope of our specification.
16:20:01 <dlongley> gkellogg: The fact that vendors are experimenting with it -- does not imply that we're setting a bar that requires multiple implementations of that.
16:20:17 <azaroth> scribenick: azaroth
16:20:19 <azaroth> ack dlongley
16:20:22 <dlongley> gkellogg: There might be future specifications that talk about how JSON-LD interacts with the DOM or marks it up -- we're not trying to specify that.
16:20:29 <azaroth> dlongley: I think Gregg covered it :)
16:20:33 <azaroth> scribenick: dlongley
16:20:36 <pchampin> q+
16:20:40 <azaroth> ack pchampin
16:21:09 <dlongley> pchampin: To add something -- I see the in browser implementation as a convenience as something different from an external JavaScript implementation.
16:21:29 <dlongley> pchampin: That comes back to what Gregg was saying, there's no particular value other than convenience [or speed] to having it in the browser directly.
16:21:43 <dlongley> pchampin: There are other ways to use the API.
16:21:55 <dlongley> azaroth: Q4. How does the contextUrl interact with other URL / origin specific privacy features in the browser (same origin policy, CORS, etc?)
16:22:11 <dlongley> azaroth: As above, the answer is that it's identical. The only way you get access to the context is via those already implemented and specified features in the browser.
16:22:20 <dlongley> azaroth: It interacts in exactly the same way as all other URLs.
16:22:22 <dlongley> +1
16:22:58 <dlongley> azaroth: I will take an action to type up the notes as answers and put them into the issue and send them to PING.
16:23:13 <azaroth> ACTION: azaroth to collate answers and send to PING
16:23:15 <dlongley> azaroth: And hopefully get a response that all the boxes are checked and carry on, but we'll see.
16:23:28 <azaroth> TOPIC: Issues
16:23:47 <azaroth> SUBTOPIC: Link header for HTML / JSON-LD
16:23:56 <azaroth> ref: https://github.com/w3c/json-ld-syntax/issues/204
16:23:58 <gkellogg> q+
16:24:12 <azaroth> ack gkellogg
16:24:56 <dlongley> gkellogg: This was brought up because we were anticipating possibly removing the ability of having a context embedded in HTML. And that being the case -- speaking for what Google's desires were here around content negotiation (looking for some other means).
16:25:27 <dlongley> gkellogg: The link header support for JSON came to mind but in thinking about it it's entirely different. In that case, there might be a link header with a context in our namespace that would give the location of the context file to load.
16:25:57 <dlongley> gkellogg: That's not something that helps you if you have JSON-LD that points to `http://schema.org` that points you to something else. Possibly rel-alternate might help.
16:26:36 <dlongley> gkellogg: Really maybe the solution for them is to ... I'm not sure what the solution is. In how link headers might be used to provide information to processors that are requesting context at a certain location to redirect them to another location using something other than content negotiation.
16:26:37 <azaroth> q?
16:27:02 <dlongley> q+
16:27:05 <azaroth> ack dlongley
16:27:10 <azaroth> scribenick: azaroth
16:27:29 <azaroth> dlongley: Haven't looked closely to see if there's a good way to put it in, as conneg is the mechanism designed to do this
16:27:42 <azaroth> ... there might be a way to put it in link header ... very much like a redirect without a redirect!
16:27:52 <azaroth> scribenick: dlongley
16:28:15 <dlongley> gkellogg: I suspect that there's too much inventing from whole cloth -- and without Dan Brickley being here to champion this to have it go anywhere, if they truly care about it that much they'll show up.
16:28:39 <dlongley> azaroth: One minor advantage would give us another way, via the meta head tag to put the equivalent into the HTML doc such that it could be relatively easily extracted by an HTML processor.
16:29:10 <dlongley> azaroth: If you didn't have access to do conneg or didn't like it and you needed to declare where to go then putting it in the headers might be tricky, but if you have a system that doesn't let you do that you could put it into the DOM.
16:29:18 <pchampin> q+
16:29:20 <dlongley> azaroth: That would be another minor advantage.
16:29:21 <azaroth> ack pchampin
16:30:01 <dlongley> pchampin: If I understand Dan's concern that they would like to lower the demand on the server by having static web pages. That's a way of floating the burden of conneg to the client rather than the server. I think that's a relatively straightforward and webby way to do it so why not?
16:30:04 <gkellogg> q+
16:30:08 <azaroth> ack gkellogg
16:30:39 <dlongley> gkellogg: Yeah, I think if we imagine what it would take to make something work on gh-pages... if we wanted w3c.github.io/foo to serve a context, how could we do that?
16:31:14 <dlongley> gkellogg: If we put an HTML file in there right now ... using a meta tag, I don't know that appreciably solves the problem. If your concern is needing to parse the HTML and it's easier to parse a meta tag than a script tag ... I'm not sure that passes muster.
16:31:19 <dlongley> +1 it doesn't, it's still a problem
16:31:33 <dlongley> gkellogg: I don't think there's anything short of what can be done short of looking in the HTML itself.
16:31:49 <azaroth> PROPOSAL: Invite danbri representing schema.org to a call to discuss the proposed solution, and if he agrees it would be useful, accept the issue
16:31:50 <dlongley> azaroth: How about we invite Dan to the call and if he shows up and thinks it would be useful we can accept it, otherwise we close it.
16:31:53 <gkellogg> +1
16:31:56 <azaroth> +1
16:31:59 <jeff_mixter> +1
16:32:01 <timCole> +1
16:32:14 <hsolbrig> +1
16:32:36 <pchampin> +1
16:32:44 <dlongley> +1 provided that JSON-LD processors don't have to look at HTML, only headers
16:32:48 <azaroth> RESOLVED: Invite danbri representing schema.org to a call to discuss the proposed solution, and if he agrees it would be useful, accept the issue
16:33:21 <dlongley> gkellogg: If you were attempting to retrieve a context file and you see that header that processors must use the URL that's provided in there instead of the resource that is returned, unless that resource is itself `application/ld+json` or something along those lines.
16:33:41 <dlongley> gkellogg: That doesn't solve a gh-pages scenario but it probably provides sufficient support for other static sites that can influence their HTTP headesr.
16:33:44 <dlongley> s/headesr/headers/
16:33:55 <azaroth> ACTION: azaroth to invite dan to a call
16:34:10 <azaroth> SUBTOPIC: more compact @prefix
16:34:16 <azaroth> ref: https://github.com/w3c/json-ld-api/issues/76
16:34:45 <dlongley> azaroth: We discussed this back in May/June and we didn't come back to it/
16:34:58 <dlongley> s/\//./
16:35:20 <dlehn> q+
16:35:21 <dlongley> q+
16:35:24 <gkellogg> q+
16:35:24 <azaroth> q?
16:35:28 <azaroth> ack dlongley
16:35:32 <azaroth> ack dlehn
16:35:35 <azaroth> q+ dlongley
16:35:57 <dlongley> dlehn: I had a comment in there, I don't know if I was mixing this in with this other topic -- but if we wanted as another feature of the `@prefix` to scope terms to a certain context so it doesn't escape out.
16:36:31 <dlongley> azaroth: Maybe?
16:36:38 <dlongley> dlehn: It seems like a feature that might fit in.
16:36:38 <azaroth> ack dlongley
16:36:41 <azaroth> scribenick: azaroth
16:37:14 <azaroth> dlongley: Part of what I was going to say refers to what dlehn said ... there's different ways to scope the prefix. I think we should consider that, but don't remember exactly where we were
16:37:31 <azaroth> ... it should / should not escape the context, and the inbetween state where you want to use it, but it shouldn't escape to the data
16:37:45 <azaroth> ... it feels like it fits in with the idea that when defining a prefix you say where it applies
16:37:49 <azaroth> ack gkellogg
16:37:54 <azaroth> scribenick: dlongley
16:38:31 <dlongley> gkellogg: I guess there's two different issues going on here. For what was originally described, this was syntactic sugar, it doesn't provide any new functionality. But it does provide complexity. As such, I don't think we should do this.
16:38:57 <dlongley> gkellogg: Adding complexity for important new functionality is fine, but out of some sense of simplicity that isn't really simplicity, particularly when it comes to a context file vs. the data, it doesn't hit the bar.
16:39:28 <dlongley> gkellogg: In terms of scope, certainly if you define a term with a scoped context that adds a prefix it would be used, but `@prefix: true` means is ... is that term available for use when compacting.
16:39:54 <azaroth> q?
16:39:57 <dlongley> gkellogg: If you say `@prefix: false` ... will you then not use that to expand things that look like CURIEs. Example "http". I don't know if we've decided that question or if that's wrapped up in this issue or not.
16:39:58 <dlongley> q+
16:40:01 <azaroth> ack dlongley
16:40:05 <azaroth> scribenick: azaroth
16:40:19 <azaroth> dlongley: My view is that if you say prefix: false, we had agreed that you would not use it as a curie in any way
16:40:35 <azaroth> ... the only thing that would change with a third value is for expanding in a context but not in the data
16:40:42 <azaroth> ... if you say prefix it's not a prefix. ever.
16:40:49 <azaroth> gkellogg: I don't think the spec does that now
16:41:25 <dlongley> gkellogg: The original use of this was to prevent creating CURIEs inadvertently -- the example I used `schema:sport` or something like that.
16:41:30 <azaroth> ... the original use was to prevent compacting inadvertently. e.g. schema:sportsVenue and schema:sport creates sport:sVenue
16:42:01 <dlongley> gkellogg: It was intended to control [compaction]... we didn't look at expansion. We need to implement that and I think that's a good idea.
16:42:05 <azaroth> ... so to control expansion. Don't know if we have a resolution to control for other scenarios, but it seems a good idea
16:42:12 <azaroth> scribenick: dlongley
16:42:43 <azaroth> +1 to gkellogg
16:42:48 <dlongley> gkellogg: As for controlling whether you can use that in a context but not in a body, I don't favor that as much. The place for complexity is in the context, if you don't want to use it in the data but in the context and I think that's trying to aid those that write contexts and not those that write contexts.
16:42:51 <azaroth> q?
16:42:52 <dlongley> +1
16:43:26 <azaroth> q+ to propose best practice?
16:43:29 <dlongley> dlehn: Writing contexts does get kind of awkward when you have a prefix you want to use but don't want it to leak out into your data. It becomes kind of awkward -- you have to use the expanded form everywhere.
16:43:45 <dlongley> dlehn: In practice we've been writing some contexts like that and it seems a little weird and it would be nice to have a shortcut to make it easier to write.
16:43:52 <azaroth> ack azaroth
16:43:52 <Zakim> azaroth, you wanted to propose best practice?
16:43:53 <dlongley> dlehn: It's complexity in a context, it gets unwieldy.
16:44:05 <pchampin> q+
16:44:06 <gkellogg> q+
16:44:13 <dlongley> dlehn: I don't know what the solution is -- other than to write things out long form.
16:44:19 <azaroth> ack pchampin
16:44:28 <dlongley> azaroth: Or use `__internal_prefix__` or something like that.
16:44:41 <dlongley> dlehn: Yeah, but I feel that's heading towards a bad solution.
16:45:00 <dlongley> pchampin: It would still be possible to define a prefix, use it in your contexts, and then set it to null to prevent it from being used in the data.
16:45:12 <dlongley> q+
16:45:22 <dlongley> q-
16:45:28 <dlongley> q+
16:45:33 <azaroth> ack gkellogg
16:46:25 <dlongley> gkellogg: I can see the point. We really don't want to make things use CURIEs with xsd in the data ... when you go to compact but we want to use it so much that we want to be able to use that in the context. That would be an example where you'd want to say `@prefix: @context`. The `__internal_prefix__` doesn't help. That isn't going to affect the compaction algorithm from using that term to create a CURIE.
16:46:35 <dlongley> gkellogg: Pierre-Antoine's suggestion does address that.
16:46:47 <azaroth> Right - it makes it less likely, but I agree is security by obscurity
16:46:51 <dlongley> gkellogg: That solves the problem but it seems a little ugly.
16:46:52 <azaroth> q?
16:46:53 <azaroth> ack dlongley
16:47:00 <azaroth> scribenick: azaroth
16:47:23 <azaroth> dlongley: Suggesting the arrays would run afoul of other features such as @import
16:47:31 <azaroth> ... seems a big of a hacky way to accomplish it
16:47:35 <azaroth> q?
16:48:17 <dlongley> azaroth: Let's take `xsd` as the use case. How important do we think it is to be able to express this as an in context only prefix? If we have a recommended context ... like in our best practice document.
16:48:43 <dlongley> azaroth: One of our issues is to talk about pulling in a best practice context that everyone should import into their contexts.
16:48:43 <pchampin> q+
16:48:47 <azaroth> ack pchampin
16:48:52 <dlongley> -1 to recommend everyone do that at all! :)
16:49:05 <dlongley> pchampin: Why do you want to prevent `xsd` from leaking into the data?
16:49:56 <dlongley> gkellogg: This is more Dave Longley and Dave Lehn concerned about having prefixes leak into the data. If you have a policy for no CURIEs and you depend on compaction for creating the data, if there's a `xsd` term defined as a prefix, there's nothing that would prevent it from then being used for compaction.
16:50:04 <dlongley> gkellogg: You'd violate that policy of not using CURIEs in data.
16:50:12 <dlehn> q+
16:50:23 <azaroth> q+ to ask if about the issue in reverse
16:50:48 <azaroth> ack dlehn
16:50:49 <dlongley> gkellogg: The array solution addresses that/solves it. The way we defined `@import` wouldn't help. If you undefined a term the end definition would win and it wouldn't work properly. It doesn't work with that but it can work with array contexts.
16:51:28 <dlongley> dlehn: This might be a scoping issue -- you want to use this locally but not overwrite other things. You're writing a context and you want to have lexically scoped variables like let/const in JavaScript.
16:51:29 <azaroth> q?
16:51:31 <azaroth> ack azaroth
16:51:31 <Zakim> azaroth, you wanted to ask if about the issue in reverse
16:52:41 <dlongley> azaroth: I think there's the same issue in reverse. In the data we expect that a particular field always has the full URI so that the consumer can just follow it. Doing an xhr and get that piece of data. If someone defined the beginning of that URI as a prefix and in compaction you couldn't just give that to xhr. [apologies, couldn't follow]
16:53:00 <dlongley> azaroth: For this field, never compact IRIs. If we did that, could we say which fields shouldn't be compacted?
16:53:00 <pchampin> q+
16:53:03 <azaroth> ack pchampin
16:53:35 <azaroth> eg if there's a property that should always have a full IRI, can we say that about the property, rather than about the prefix itself
16:54:39 <dlongley> pchampin: For me, `@prefix: false` for `xsd` would prevent compaction using the `xsd` prefix. Still, in the data, someone could use `xsd:foo` and that isn't resolving the scoping issue, but solving the not compacting things to CURIEs with `xsd`. I can see the need to not generate those kinds of IRIs and the current spec addresses that problem.
16:54:56 <dlongley> pchampin: Forbidding the users from using the prefix for the sake of purity ... but is it worth the added complexity?
16:54:59 <azaroth> q?
16:55:01 <dlongley> pchampin: Or am I still missing something?
16:55:24 <gkellogg> q+
16:55:27 <azaroth> ack gkellogg
16:55:36 <dlongley> gkellogg: I propose we defer this to a future version.
16:55:59 <dlongley> gkellogg: We should resolve the way that `@prefix: false` is interpreted when expanding things that might look at a CURIE though.
16:56:19 <azaroth> ACTION: gkellogg to make issue for clarifying @prefix:false
16:57:33 <azaroth> PROPOSAL: Defer compact @prefix issue until a future version, pending better understanding of value of use case versus added complexity given remaining chartered time
16:57:38 <gkellogg> +1
16:57:39 <azaroth> +1
16:57:41 <dlongley> +1
16:57:41 <ajs6f> +1
16:57:42 <timCole> +1+1
16:57:42 <pchampin> +1
16:58:06 <dlehn> +0.5, still concerned about scoping issue
16:58:10 <azaroth> RESOLVED: Defer compact @prefix issue until a future version, pending better understanding of value of use case versus added complexity given remaining chartered time
16:58:30 <dlongley> azaroth: If new information comes up we can undefer it.
16:58:41 <azaroth> q?
16:59:01 <dlongley> azaroth: Let's call it there, thank you everyone for joining, we'll see you next week.
16:59:13 <azaroth> TOPIC: Adjourn
17:00:02 <azaroth> rrsagent, publish minutes
17:00:02 <RRSAgent> I have made the request to generate https://www.w3.org/2019/07/19-json-ld-minutes.html azaroth
17:00:21 <azaroth> rrsagent, make minutes public
17:00:21 <RRSAgent> I'm logging. I don't understand 'make minutes public', azaroth.  Try /msg RRSAgent help
17:00:29 <azaroth> rrsagent, make log public
17:01:19 <azaroth> Thanks all!
17:44:38 <gkellogg> gkellogg has joined #json-ld
19:09:25 <gkellogg> gkellogg has joined #json-ld
19:15:05 <Zakim> Zakim has left #json-ld
21:34:52 <gkellogg> gkellogg has joined #json-ld
23:19:03 <gkellogg> gkellogg has joined #json-ld
23:53:48 <gkellogg> gkellogg has joined #json-ld