JSON-LD Working Group Telco — Minutes

Date: 2019-08-16

See also the Agenda and the IRC Log

Attendees

Present: rob sanderson, Gregg Kellogg, Ivan Herman, Benjamin Young, Ruben Taelman, Dave Longley, David I. Lehn

Regrets: Ivan Herman

Guests:

Chair: Benjamin Young

Scribe(s): Ruben Taelman

Content:

1. Approve minutes of previous call

Benjamin Young: Previous call’s minutes

Proposed resolution: approve last week’s minutes (Benjamin Young)

Gregg Kellogg: +1

Ivan Herman: +1

Ruben Taelman: +1

Rob Sanderson: +0 (not present)

Dave Longley: +1

Benjamin Young: +1

Rob Sanderson: +0 (not present)

Dave Longley: +1

Resolution #1: approve last week’s minutes

2. Announcements / Reminders

2.1. Standing TPAC reminder

Benjamin Young: TPAC is coming. Only five of us confirmed, is that correct?
… On September 1st, the registration price goes up.

Ivan Herman: Correct, five of us are registered at the moment.

Rob Sanderson: I will register today.

Ivan Herman: JSON-LD is on thursday~friday.

Gregg Kellogg: Normative things will be resolved, so we can focus on tutorials etc.

3. Horizontal Review Updates

Benjamin Young: See Horizonal review issues

Rob Sanderson: I’ve sent an email for the privacy review.
… I think privacy is in good shape. Is a formal sign-off needed?

Ivan Herman: It would be good if they put a comment on our issue saying “yes, you are done”.
… Or we can explicitly ask them for such a comment, by saying we consider it is done.

Action #1: request an okay from PING on https://github.com/w3c/json-ld-wg/issues/88 (Rob Sanderson)

Ivan Herman: Just like I did for #93.

Rob Sanderson: #77 had a questionaire, which I did. #93 also had such a questionnaire, which has been done.

Ivan Herman: See Security/Privacy questionnaire

Rob Sanderson: 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.
… On June 19th, I emailed them, saying that we will be going to CR before TPAC, so they would have to check before then.

Ivan Herman: If you’ve sent it, and followed the steps, but if they don’t answer, we are fine.

Rob Sanderson: I will send a new mail for privacy asking for them to check.

Action #2: put https://w3ctag.github.io/security-questionnaire/ into https://github.com/w3c/json-ld-wg/issues/89 and request comments from security (Rob Sanderson)

Ivan Herman: 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.
… Not a lot of response. Only person who reacted was Andy.
… In september, we will have to put a plug on this. So issue will still be unresolved.
… It should not affect JSON-LD 1.1, but on long term in may.
… Andy said that it may be simpler to introduce terms in RDF namespace to create reified objects with value and direction.

Benjamin Young: See RDF Direction Literal repository

Gregg Kellogg: rdf:value is underutilized, and may be the way to go.

Benjamin Young: Are there actions for this group to take?

Ivan Herman: Not really, I’ve sent multiple mails to semweb mailing list.
… The rdf:value option may be the only way to go if there comes no further feedback.

4. Issues

4.1. Framing and @container:@set for scoped contexts

Benjamin Young: See Framing issue #64

Rob Sanderson: 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.
… Also in Python implementation.

Gregg Kellogg: This is because there’s a step to handle @preserve values post-compaction.
… This is because there are cases where there are null values that are replaced during compaction.
… My suggested fix would emit empty array instead of null. But this does not preserve null in output anymore.

Dave Longley: JSON devs expect null there, so it must be preserved. They want to see the null there.

Gregg Kellogg: Except if null is part of an array.

Dave Longley: Indeed. That’s another case.
… I wonder if we can do something during compaction to indicate preserve:null.
… Can we leave a note during compaction for this?

Gregg Kellogg: 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.
… There’s no easy way to handle this. But handling null after compaction may be the best way.

Dave Longley: Not great, but may be a good solution.

Gregg Kellogg: Not needed to discuss this further during this call. There is a way to fix this. But this is implementation work.

4.2. Link header for HTML and JSON-LD #204

Benjamin Young: Link header: preemptive conneg.

Benjamin Young: See Syntax issue #204

Benjamin Young: See API PR #134

Benjamin Young: See Syntax PR #212

Benjamin Young: 2 PRs are ready to go, right?

Gregg Kellogg: Yes. Open question for base during redirect.
… If you retrieve something non-json. Doc loader will detect rel-alternative links, and redirect to that resource.
… I think the original requested document should be preserved as base URL.
… Just like 303 redirect semantics. In 302, this would not be the case.

Rob Sanderson: JS will silently follow redirects and give you the results. So you don’t know which redirects got you there.

Gregg Kellogg: JS should correctly implement redirect semantics.

Dave Longley: +1 to using 303 semantics, so on, +1 to gregg’s position.

Gregg Kellogg: You have processing state to keep track on this.

Proposed resolution: merge api#134 and syntax#212, and close syntax#204 (Ivan Herman)

Rob Sanderson: +1

Dave Longley: +1

Benjamin Young: +1

Rob Sanderson: :shipit:

Ivan Herman: +1

Gregg Kellogg: +1

Ruben Taelman: +0.5

Resolution #2: merge api#134 and syntax#212, and close syntax#204

4.3. JSON-LD Context processing in HTML Documents #172

Benjamin Young: See Syntax issue #172

Benjamin Young: This issue is very related. Originally, extracting JSON-LD from HTML. This can now be done with a simple link header.
… schema.org for example does not want to use conneg, so this is good for this. Proposed closing based on the last PRs.

Gregg Kellogg: The behavior is slightly modified if you request context. Document loader will not add text/html from request. The API is not affected too much.
… 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.

Dave Longley: Everything is untangled, and is cleaner now.

Ivan Herman: Users should be warned that they don’t define context as part of an HTML file.

Gregg Kellogg: We don’t have text saying that it can’t be done. We just removed the text saying that it can be done.

Ivan Herman: Because it can be done in theory?

Gregg Kellogg: Syntax doesn’t say anything about it. API doc explicitly excludes HTML.

Proposed resolution: close #172 as addressed by #204 (Benjamin Young)

Rob Sanderson: +1

Dave Longley: +1

Benjamin Young: +1

Ruben Taelman: +1

Ivan Herman: +1

Gregg Kellogg: +1

Resolution #3: close #172 as addressed by #204

4.4. Reconsider Processing Levels #213

Benjamin Young: See Syntax issue #213

Benjamin Young: This issue discusses multiple processing levels.
… 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.

Ivan Herman: If I remember well (we’re talking about schema.org), JSON-LD in HTML 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.
… 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?
… The only way at the moment is to put it in a different file.
… Also, the reason why they did it back then is because that’s the easiest way to produce JSON-LD data.

Rob Sanderson: 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.
… I’m fine with putting it in the docloader spec.
… Main question is: can we have a conforming processor that can not handle HTML?

Benjamin Young: 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.
… (part around data blocks in HTML5 spec)
… 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.

Benjamin Young: See HTML data blocks

Dave Longley: I feel like talking about HTML in a JSON-LD processor is conflating formats. We need a cleaner separation of concerns.
… HTML is not the only format in which JSON-LD can be included.

Benjamin Young: +1

Dave Longley: 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.

Gregg Kellogg: 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?

Rob Sanderson: +1 to gkellogg

Gregg Kellogg: We have to define these things normatively.
… JSON-LD is not just about getting LD from JSON, it is more. We also tackle issues regarding link headers etc.

Ivan Herman: +1 to gkellogg

Dave Longley: “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.

Benjamin Young: supports clarifying multiple blocks, data sets, etc.

Benjamin Young: +1 to dlongley

Ivan Herman: +1 to gkellogg

Dave Longley: +1 that we should specify how to do it – but we need a cleaner architecture and repeatable extension pattern

Rob Sanderson: If we have normative recs about JSON-LD in HTML, and have two processor classes, then we need different processor levels.

Dave Longley: -1 to making this about processor classes

Rob Sanderson: dlongley - the issue is explicitly about processor classes?

Dave Longley: 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

Dave Longley: azaroth: it’s about processor classes and the architecture.

Benjamin Young: The point isn’t that we shouldn’t normatively describe this. I would like a spec on graphs in HTML.
… We should however not put the extraction concern of extracting JSON-LD from HTML in this spec.
… There should be a separate thing in front of this.

Dave Longley: +1 to benjamin, this does not scale and is a bad architecture choice.

Ivan Herman: If I am a user, I put data into HTML as JSON-LD. How do I make sure that it is understood?
… Do I have to write a separate processor? I have to know how, otherwise it is useless.
… 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.

Dave Longley: Processor classes won’t solve ivan’s problem.
… 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.

Benjamin Young: +1 to dlongley’s summation

Gregg Kellogg: Concern people have is that to be a full processors, you have to process HTML. Defining these as capabilities may be better.
… I would support extracting HTML bits from our current spec to something else.

Dave Longley: we don’t have to split this up now

Dave Longley: let’s make sure we CAN split it up later.

Dave Longley: we can have the right architecture now and split later.

Rob Sanderson: I agree with dlongley and gkellogg.

Benjamin Young: +1

Rob Sanderson: 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.

Dave Longley: we’re not talking about a ton of changes.

Ivan Herman: If we do this, we won’t adhere to our timetable.

Dave Longley: no, no no… not saying that.

Dave Longley: ok, next call :)

Benjamin Young: Let’s take this to next call, as we will need it.

5. Resolutions

6. Action Items