15:44:03 <RRSAgent> RRSAgent has joined #json-ld
15:44:03 <RRSAgent> logging to https://www.w3.org/2019/08/16-json-ld-irc
15:44:04 <ivan> rrsagent, set log public
15:44:04 <ivan> Meeting: JSON-LD Working Group Telco
15:44:04 <ivan> Date: 2019-08-16
15:44:04 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Aug/0010.html
15:44:04 <ivan> ivan has changed the topic to: Meeting Agenda 2019-08-16: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Aug/0010.html
15:44:05 <ivan> Regrets+
15:44:05 <ivan> Chair: bigbluehat
15:49:23 <azaroth> azaroth has joined #json-ld
15:58:08 <azaroth> present+ Rob_Sanderson
15:58:36 <gkellogg> gkellogg has joined #json-ld
15:59:13 <gkellogg> present+
15:59:20 <ivan> present+
15:59:47 <bigbluehat> present+
16:00:42 <rubensworks> present+
16:02:14 <azaroth> scribenick: rubensworks
16:02:41 <dlongley> present+
16:02:59 <bigbluehat> Topic: Approve minutes of previous call
16:03:05 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-08-09-json-ld%3Chttps://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-26-json-ld
16:03:06 <gkellogg> +1
16:03:17 <ivan> +1
16:03:19 <rubensworks> +1
16:03:23 <azaroth> +0 (not present)
16:03:24 <dlongley> +1
16:03:24 <bigbluehat> PROPOSAL: approve last week's minutes
16:03:25 <bigbluehat> +1
16:03:26 <azaroth> +0 (not present)
16:03:26 <dlongley> +1
16:03:33 <bigbluehat> RESOLVED: approve last week's minutes
16:03:43 <bigbluehat> Topic: Announcements / Reminders
16:03:48 <bigbluehat> Subtopic: Standing TPAC reminder
16:04:18 <rubensworks> bigbluehat: TPAC is coming. Only five of us confirmed, is that correct?
16:04:30 <bigbluehat> Subtopic: Others?
16:04:38 <rubensworks> bigbluehat: On September 1st, the registration price goes up.
16:04:48 <rubensworks> ivan: Correct, five of us are registered at the moment.
16:04:59 <rubensworks> azaroth: I will register today.
16:06:58 <rubensworks> ivan: JSON-LD is on thursday~friday.
16:07:20 <rubensworks> gkellogg: Normative things will be resolved, so we can focus on tutorials etc.
16:08:11 <bigbluehat> Topic: Horizontal Review Updates
16:08:19 <bigbluehat> https://github.com/w3c/json-ld-wg/issues?q=is%3Aissue+is%3Aopen+label%3Ahorizontal-review
16:08:52 <rubensworks> azaroth: I've sent an email for the privacy review.
16:09:07 <rubensworks> ... I think privacy is in good shape. Is a formal sign-off needed?
16:09:26 <rubensworks> ivan: It would be good if they put a comment on our issue saying "yes, you are done".
16:09:55 <rubensworks> ... Or we can explicitly ask them for such a comment, by saying we consider it is done.
16:09:57 <azaroth> ACTION: azaroth to request an okay from PING on https://github.com/w3c/json-ld-wg/issues/88
16:10:18 <rubensworks> ... Just like I did for #93.
16:11:38 <rubensworks> azaroth: #77 had a questionaire, which I did. #93 also had such a questionaire, which has been done.
16:12:13 <ivan> https://w3ctag.github.io/security-questionnaire/
16:12:19 <rubensworks> azaroth: Process doc says that for privacy, you have to email them, and they come to you. But for I18N, you email them, and you come to them.
16:13:20 <rubensworks> ... On June 19th, I emailed them, saying that we will be going to CR before TPAC, so they would have to check before then.
16:13:57 <rubensworks> ivan: If you've sent it, and followed the steps, but if they don't answer, we are fine.
16:14:16 <rubensworks> azaroth: I will send a new mail for privacy asking for them to check.
16:14:31 <azaroth> ACTION: azaroth to put https://w3ctag.github.io/security-questionnaire/ into https://github.com/w3c/json-ld-wg/issues/89 and request comments from security
16:14:32 <ivan> q+
16:14:36 <bigbluehat> ack ivan
16:15:25 <rubensworks> ivan: For I18N, we have the issue of base direction. There has been an action in June where we tried to start a WG to fix it in RDF. If it fixed there, it will be fixed everywhere else.
16:15:41 <rubensworks> ... Not a lot of response. Only person who reacted was Andy.
16:15:58 <rubensworks> ... In september, we will have to put a plug on this. So issue will still be unresolved.
16:16:12 <rubensworks> ... It should not affect JSON-LD 1.1, but on long term in may.
16:16:12 <bigbluehat> q+
16:17:03 <rubensworks> ... Andy said that it may be simpler to introduce terms in RDF namespace to create reified objects with value and direction.
16:17:22 <bigbluehat> https://github.com/w3c/rdf-dir-literal
16:17:50 <bigbluehat> ack bigbluehat
16:18:09 <rubensworks> gkellogg: rdf:value is underutilized, and may be the way to go.
16:18:21 <rubensworks> bigbluehat: Are there actions for this group to take?
16:18:53 <rubensworks> ivan: Not yet, I've sent multiple mails to semweb mailing list.
16:19:43 <rubensworks> ... The rdf:value option may be the only way to go if there comes no further feedback.
16:19:51 <bigbluehat> Topic: Issues
16:19:59 <bigbluehat> Subtopic: Framing and @container:@set for scoped contexts
16:20:06 <bigbluehat> https://github.com/w3c/json-ld-framing/issues/64
16:21:26 <rubensworks> azaroth: In framing context, I had a container:set. I did various things in playground, and discovered that in framing, container:set does not get handled properly. It does work fine in compaction.
16:21:39 <rubensworks> ... Also in Python implementation.
16:22:02 <rubensworks> gkellogg: This is because there's a step to handle `@preserve` values post-compaction.
16:22:09 <dlehn> present+
16:22:32 <rubensworks> ... This is because there are cases where there are null values that are replaced during compaction.
16:22:55 <dlongley> q+
16:23:13 <bigbluehat> ack dlongley
16:23:17 <rubensworks> ... My suggested fix would emit empty array instead of null. But this does not preserve null in output anymore.
16:23:52 <azaroth> q+ to ask about expections of @container:@set /and/ null
16:23:54 <rubensworks> dlongley: JSON devs expect null there, so it must be preserved. They want to see the null there.
16:24:04 <rubensworks> gkellogg: Except if null is part of an array.
16:24:12 <rubensworks> dlongley: Indeed. That's another case.
16:24:42 <rubensworks> ... I wonder if we can do something during compaction to indicate preserve:null.
16:25:05 <rubensworks> ... Can we leave a note during compaction for this?
16:25:56 <rubensworks> gkellogg: One way would be to separate processing of preserve:null, and do preserve before compaction. Once it has been compacted, there may be values with null. If in array, would be removed, if not, it would be preserved.
16:26:31 <rubensworks> ... There's no easy way to handle this. But handling null after compaction may be the best way.
16:26:44 <rubensworks> dlongley: Not great, but may be a good solution.
16:27:07 <bigbluehat> Subtopic: Link header for HTML and JSON-LD #204
16:27:10 <rubensworks> gkellogg: Not needed to discuss this further during this call. There is a way to fix this. But this is implementation work.
16:27:13 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/204
16:27:43 <rubensworks> bigbluehat: Link header: preemptive conneg.
16:27:45 <bigbluehat> API PR https://github.com/w3c/json-ld-api/pull/134
16:27:55 <bigbluehat> Syntax PR https://github.com/w3c/json-ld-syntax/pull/212
16:27:58 <rubensworks> bigbluehat: 2 PRs are ready to go, right?
16:28:15 <rubensworks> gkellogg: Yes. Open question for base during redirect.
16:28:53 <rubensworks> gkellogg: If you retrieve something non-json. Doc loader will detect rel-alternative links, and redirect to that resource.
16:29:19 <rubensworks> ... I think the original requested document should be preserved as base URL.
16:29:58 <bigbluehat> q+
16:29:58 <azaroth> q+ to ask about javascript and redirects
16:30:01 <bigbluehat> ack azaroth
16:30:01 <Zakim> azaroth, you wanted to ask about expections of @container:@set /and/ null and to ask about javascript and redirects
16:30:05 <rubensworks> ... Just like 303 redirect semantics. In 302, this would not be the case.
16:30:45 <rubensworks> azaroth: JS will silently follow redirects and give you the results. So you don't know which redirects got you there.
16:30:54 <rubensworks> gkellogg: JS should correctly implement redirect semantics.
16:31:02 <dlongley> +1 to using 303 semantics, so on, +1 to gregg's position.
16:31:12 <rubensworks> ... You have processing state to keep track on this.
16:32:01 <bigbluehat> ack bigbluehat
16:32:15 <ivan> Proposed: merge api#134 and syntax#212, and close syntax#204
16:32:22 <azaroth> +1
16:32:23 <dlongley> +1
16:32:25 <bigbluehat> +1
16:32:27 <azaroth> :shipit:
16:32:29 <ivan> +1
16:32:34 <gkellogg> +1
16:32:35 <rubensworks> +0.5
16:33:57 <ivan> resolved: merge api#134 and syntax#212, and close syntax#204
16:34:13 <bigbluehat> Subtopic: JSON-LD Context processing in HTML Documents #172
16:34:18 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/172
16:35:02 <rubensworks> bigbluehat: This issue is very related. Originally, extracting JSON-LD from HTML. This can now be done with a simple link header.
16:35:43 <rubensworks> ... schema.org for example does not want to use conneg, so this is good for this. Proposed closing based on the last PRs.
16:37:00 <rubensworks> gkellogg: The behaviour is slightly modified if you request context. Document loader will not add text/html from request. The API is not affected too much.
16:37:52 <rubensworks> ... If you will deal with HTML, like schema.org, then you can achieve a compatibility level with processing JSON-LD in HTML, instead of doing it mid-processing.
16:38:02 <rubensworks> dlongley: Everything is untangled, and is cleaner now.
16:38:16 <rubensworks> ivan: Users should be warned that they don't define context as part of an HTML file.
16:39:11 <rubensworks> gkellogg: We don't have text saying that it can't be done. We just removed the text saying that it can be done.
16:39:12 <bigbluehat> q+
16:39:19 <rubensworks> ivan: Because it can be done in theory?
16:39:37 <rubensworks> gkellogg: Syntax doesn't say anything about it. API doc explicitly excludes HTML.
16:39:40 <bigbluehat> ack bigbluehat
16:39:41 <bigbluehat> PROPOSAL: close #172 as addressed by #204
16:39:46 <azaroth> +1
16:39:46 <dlongley> +1
16:39:48 <bigbluehat> +1
16:39:50 <rubensworks> +1
16:39:52 <ivan> +1
16:40:09 <gkellogg> +1
16:40:58 <bigbluehat> RESOLVED: close #172 as addressed by #204
16:44:33 <bigbluehat> Subtopic: Reconsider Processing Levels #213
16:44:40 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/213
16:45:12 <rubensworks> bigbluehat: This issue discusses multiple processing levels.
16:45:56 <ivan> q+
16:46:00 <bigbluehat> ack ivan
16:46:02 <rubensworks> ... If the link header approach solves the use case for linking to a JSON-LD context in HTML, then we probably don't need a full processor level for HTML processing.
16:46:05 <azaroth> q+ to argue that we need them still
16:47:06 <rubensworks> ivan: If I remember well (we're talking about schema.org), this came up with a discussion that website producers had difficulties producing microdata/rdfa when they had different data in databases, and wanted an easier way to dump data from their databases in JSON.
16:47:47 <rubensworks> ... If we don't say anything about JSON-LD in HTML, then how can we trust any JSON-LD processor out there that this JSON-LD in HTML will be used?
16:47:59 <rubensworks> ... The only way at the moment is to put it in a different file.
16:48:21 <bigbluehat> q+ to clarify who should be doing extraction and when
16:48:27 <rubensworks> ... Also, the reason why they did it back then is because that's the easiest way to produce JSON-LD data.
16:48:32 <bigbluehat> ack azaroth
16:48:32 <Zakim> azaroth, you wanted to argue that we need them still
16:49:42 <rubensworks> azaroth: I agree. We have normatively defined how JSON-LD is expressed in HTML. So we've opened the door to this. This requires all processors to handle HTML. These levels allow only some processors to not handle HTML.
16:49:46 <dlongley> q+ to ask if we can define this only according to the document loader being used by the processor rather than as the processor being "full" or not?
16:50:02 <rubensworks> ... I'm fine with putting it in the docloader spec.
16:50:15 <bigbluehat> ack bigbluehat
16:50:15 <Zakim> bigbluehat, you wanted to clarify who should be doing extraction and when
16:50:23 <rubensworks> ... Main question is: can we have a conforming processor that can not handle HTML?
16:51:03 <rubensworks> bigbluehat: These data blocks have been used for a long time before JSON-LD. Anything can be placed in there. This is part of the HTML spec.
16:51:15 <rubensworks> ... (part around data blocks in HTML5 spec)
16:51:20 <gkellogg> q+
16:52:04 <rubensworks> ... A piece of software that exist now that extracts data from data blocks, and forwards it to any processor can also be used to handle extracting JSON-LD from HTML.
16:52:21 <bigbluehat> ack dlongley
16:52:21 <Zakim> dlongley, you wanted to ask if we can define this only according to the document loader being used by the processor rather than as the processor being "full" or not?
16:52:40 <azaroth> q+ to argue that Benjamin's approach is an argument against normative JSON-LD in HTML
16:52:56 <bigbluehat> HTML data blocks https://html.spec.whatwg.org/multipage/scripting.html#data-block
16:52:57 <rubensworks> dlongley: I feel like talking about HTML in a JSON-LD processor is conflating formats. We need a cleaner separation of concerns.
16:53:08 <rubensworks> ... HTML is not the only format in which JSON-LD can be included.
16:53:38 <bigbluehat> +1
16:53:42 <bigbluehat> ack gkellogg
16:53:49 <bigbluehat> q+ to mention email https://developers.google.com/gmail/markup/reference/rsvp-action
16:53:50 <rubensworks> ... It is a mistake to define these different levels. Instead, we should see it as plugging in a JSON-LD processor in another piece of software.
16:53:52 <ivan> q+
16:54:23 <rubensworks> gkellogg: There is not standard way to handle these data blocks. What happens when you have a doc with multiple JSON-LD docs? And combined with RDFa?
16:54:40 <azaroth> +1 to gkellogg
16:54:44 <rubensworks> ... We have to define these things normatively.
16:54:49 <ivan> +1 to gkellogg
16:54:57 <dlongley> "JSON-LD in HTML" almost feels like a separate spec to me ... and we have a mechanism to hook this up to a JSON-LD processor -- a document loader; we could define other extensions this way ... it provides a clear pattern.
16:55:09 <bigbluehat> supports clarifying multiple blocks, data sets, etc.
16:55:21 <bigbluehat> +1 to dlongley
16:55:23 <rubensworks> ... JSON-LD is not just about getting LD from JSON, it is more. We also tackle issues regarding link headers etc.
16:56:03 <dlongley> q+
16:56:05 <bigbluehat> ack azaroth
16:56:05 <Zakim> azaroth, you wanted to argue that Benjamin's approach is an argument against normative JSON-LD in HTML
16:56:05 <ivan> +1 to gkellogg
16:56:31 <dlongley> +1 that we should specify how to do it -- but we need a cleaner architecture and repeatable extension pattern
16:56:57 <rubensworks> azaroth: If we have normative reqs about JSON-LD in HTML, and have two processor classes, then we need different processor levels.
16:56:58 <bigbluehat> ack bigbluehat
16:56:58 <Zakim> bigbluehat, you wanted to mention email https://developers.google.com/gmail/markup/reference/rsvp-action
16:57:00 <gkellogg> q+
16:57:02 <dlongley> -1 to making this about processor classes
16:57:25 <azaroth> dlongley - the issue is explicitly about processor classes?
16:58:03 <rubensworks> bigbluehat: The point isn't that we shouldn't normatively describe this. I would like a spec on graphs in HTML.
16:58:06 <dlongley> azaroth: yes, it is ... and i think people are confused about my position/benjamin's ... we aren't arguing against defininig how to do JSON-LD in HTML
16:58:16 <dlongley> azaroth: it's about processor classes and the architecture.
16:58:27 <rubensworks> ... We should however not put the extraction concern of extracting JSON-LD from HTML in this spec.
16:58:32 <dlongley> +1 to benjamin, this does not scale and is a bad architecture choice.
16:58:39 <rubensworks> .. There should be a separate thing in front of this.
16:58:41 <azaroth> q+ to note that /this/ argument argues against document loaders and http?
16:58:56 <bigbluehat> ack ivan
16:59:26 <rubensworks> ivan: If I am a user, I put data into HTML as JSON-LD. How do I make sure that it is understood?
16:59:46 <rubensworks> ... Do I have to write a separate processor? I have to know how, otherwise it is useless.
16:59:46 <dlongley> q+ to say you don't get that guarantee with processor classes anyway
17:00:37 <dlongley> q+ to say, if you want to put JSON-LD in HTML, use the HTML in JSON-LD spec (which is currently embedded in our spec) ... and if you want to consume it do the same and implement the document loader according to the spec.
17:01:17 <rubensworks> ... For example, RDFa processors do a basic entailment, based on flags. Processors can only do things based on these flags. If I know that someone's processor supports flags, then I can use a specific processor based on these capabilities. We need something like this, otherwise this is useless to users.
17:01:17 <bigbluehat> ack dlongley
17:01:17 <Zakim> dlongley, you wanted to say you don't get that guarantee with processor classes anyway and to say, if you want to put JSON-LD in HTML, use the HTML in JSON-LD spec (which is
17:01:20 <Zakim> ... currently embedded in our spec) ... and if you want to consume it do the same and implement the document loader according to the spec.
17:01:39 <rubensworks> dlongley: Processor classes won't guarantee ivan's problem.
17:01:53 <rubensworks> s/guarantee/solve/
17:02:50 <bigbluehat> ack gkellogg
17:02:57 <bigbluehat> +1 to dlongley's summation
17:03:04 <rubensworks> dlongley: If you want to process JSON-LD from HTML, you have to look at that separate spec. Different document loaders can support these things. This is a better architecture, regarding separation of concerns.
17:03:38 <rubensworks> gkellogg: Concern people have is that to be a full processors, you have to process HTML. Defining these as capabilities may be better.
17:03:58 <azaroth> q?
17:04:00 <bigbluehat> ack azaroth
17:04:00 <Zakim> azaroth, you wanted to note that /this/ argument argues against document loaders and http?
17:04:01 <rubensworks> ... I would support extracting HTML bits from our current spec to something else.
17:04:09 <rubensworks> azaroth: I agree with dlongley and gkellogg.
17:04:13 <dlongley> we don't have to split this up now
17:04:18 <dlongley> let's make sure we CAN split it up later.
17:04:25 <bigbluehat> +1
17:04:31 <dlongley> we can have the right architecture now and split later.
17:04:33 <rubensworks> ... It would be cleaner in a different spec. But we don't have time to split into a different spec. Maybe something for JSON-LD 2.0.
17:04:41 <dlongley> we're not talking about a ton of changes.
17:04:45 <rubensworks> ivan: If we do this, we won't adhere to our timetable.
17:04:46 <dlongley> no, no no... not saying that.
17:04:54 <dlongley> ok, next call :)
17:05:06 <rubensworks> bigbluehat: Let's take this to next call, as we will need it.
17:05:53 <ivan> rrsagent, draft minutes
17:05:53 <RRSAgent> I have made the request to generate https://www.w3.org/2019/08/16-json-ld-minutes.html ivan
17:05:53 <ivan> zakim, bye
17:05:53 <ivan> rrsagent, bye
17:05:53 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2019/08/16-json-ld-actions.rdf :
17:05:53 <RRSAgent> ACTION: azaroth to request an okay from PING on https://github.com/w3c/json-ld-wg/issues/88 [1]
17:05:53 <RRSAgent>   recorded in https://www.w3.org/2019/08/16-json-ld-irc#T16-09-57
17:05:53 <RRSAgent> ACTION: azaroth to put https://w3ctag.github.io/security-questionnaire/ into https://github.com/w3c/json-ld-wg/issues/89 and request comments from security [2]
17:05:53 <RRSAgent>   recorded in https://www.w3.org/2019/08/16-json-ld-irc#T16-14-31
17:05:53 <Zakim> leaving.  As of this point the attendees have been Rob_Sanderson, gkellogg, ivan, bigbluehat, rubensworks, dlongley, dlehn
17:05:53 <Zakim> Zakim has left #json-ld
17:06:03 <dlongley> ivan: i didn't mean make a new spec *now* ... shortness of time made that unclear, will discuss next week :)