– DRAFT –
JSON-LD WG

Announcements and Introductions

bigbluehat: Anyone have anything to share re: announcements and intros?
… I have reached out to a couple implementers of JSON-LD and/or CBOR-LD libraries about them joining as invited experts.
… I'm hoping that we can get through the formalities of that prior to the JSON-LD spec work that is on the horizon.
… If anyone knows of other people that would be a good fit for talking about these specs, let us know.
… ivan and PA can help with the invited expert process.
… they are not from companies large enough to join W3C and mostly work on these implementations as side projects.

YAML-LD check-in

<anatoly-scherbakov> w3c/yaml-ld#190

<gb> https://github.com/w3c/yaml-ld/pull/190

anatoly-scherbakov: I have found a bug in the tests, there is a PR to fix it.
… There is a property being lost during an expansion process.

https://w3c.github.io/yaml-ld/#extended-profile

anatoly-scherbakov: The current version of YAML-LD, in addition to the basic YAML-LD profile normatively specified, describes an extended profile that leverages tags as semantic information. This is now a substantial part of the document, but is still informative - I want to keep that for potential use in the next version of YAML-LD, but want to know what the

group thinks about moving that section into a separate document to keep the current YAML-LD spec minimal.
… This section in the current document could cause confusion, especially with the normative/informative breakdown of the spec currently.

<niklasl> +1 to move this (it's not JSON-LD-isomorphic)

ivan: +1

bigbluehat: +1

<TallTed> NOTE is fine. Appendix on main doc might also be sufficient separation.

TallTed: It's sometimes better to minimize number of documents

BigBlueHat: In this case it's too large w.r.t the main document, it's confusing
… PR 190 is confusing - what was broken and what is now working?

anatoly-scherbakov: It is an expansion test. I should have mentioned the inputs.

<anatoly-scherbakov> w3c/yaml-ld#191 issue created

<gb> Issue 191 Move Extended Profile into a separate NOTE document (by anatoly-scherbakov)

bigbluehat: What is the switch that is determining whether you are getting one or more "documents", or list items?

anatoly-scherbakov: These are two documents separated by the three dashes, this is YAML terminology for a stream that consists of 1 or more YAML documents.
… In order to control how we parse this, we are reusing an API flag - extract all scripts.
… This is mimicking the behavior of the JSON-LD API when processing an HTML page.
… This will return only the first document, and alternatively if extract-all-scripts is true we will return an array with documents as items in the array.

anatoly-scherbakov: The name property was missing due to an oversight, and I noticed it while running the tests.
… The input file has the context, we should resolve the name property.

ivan: in JSON-LD when I use the array tool, AFAIK I have to repeat the context in every element of the array.

anatoly-scherbakov: It is done here as well.

ivan: but in the result it doesn't do that.

<niklasl> There is no context in an expanded result.

<niklasl> There is another problem here though.

The group discusses the details of the input/output of the test in question.

<niklasl> Look at the context - there is no vocab.

BigBlueHat: the bug is that some lines were missing, is it due to the @base value that should be @vocab?

anatoly-scherbakov: the test worked after this change, perhaps I noticed after I upgraded pyld
… I will try again and the group can discuss further.

<niklasl> Same behaviour on the playground with: {"@context": {"@base": "https://schema.org/"}, "@id": "https://www.w3.org/TR/json-ld11/", "@type": "WebContent", "name": "JSON-LD"}

niklasl: I think this is unrelated to YAML-LD, if you try the example I shared on the playground.
… There is unintuitive @type behavior in the expansion.

BigBlueHat: I think this is a series of accidents
… the test data is overly confusing.

niklasl: It's not wrong, just very confusing.

BigBlueHat: I suggest not merging this and instead cleaning up the JSON.

niklasl: I'm not sure if the test suite caches external contexts.

CBOR-LD PRs & Issues

wes-smith: we have one item of business first
… we want to publish and FPWD
… but haven't because of PR 63
… and we wanted that in first

w3c/cbor-ld#63
… this PR improved the prose around the algorithms
… and I think we're now ready to move to FPWD

ivan: PA was on vacation and I have a backlog of other documents
… so we'll have to wait on PA
… the additional practical problem is an upcoming AC meeting
… which will block FPWD
… at least the formal publication
… but that means we also don't have to be in a rush
… there's a bunch of transition requests, though
… there are boring admin steps, basically, best done by PA
… if I didn't have VCWG work to do, I would do it...

wes-smith: all good. later this month it is!
… now on to open PRs
… is this a bot?

ivan: this is a person who uses a bot

<TallTed> s|https://github.com/w3c/cbor-ld/pulls/63|... https://github.com/w3c/cbor-ld/pulls/63|

wes-smith: not sure what the discussion became

ivan: it should not be merged at this point
… he was fixing the JSON-LD refs
… but he did it mechanically probably via a bot
… but however it was done, it was done incorrectly
… so, for example, the first one is in a non-normative section, so the reference to JSON-LD is marked as non-normative...which is incorrect
… that was one problem
… but there are others
… a more general thing: if I do a reference to `json-ld` as a short name, then I get `1.0`...but that should not be the case
… PA or bigbluehat should fix that to go to the latest
… which is 1.1
… this surfaced here because he had to make an explicit `1.1` reference
… but then CBOR-LD will not "upgrade" to `1.2` when we get that done--which might be prior to publishing CBOR-LD
… in the meantime, we could do it this way, but it would be better to fix the ref

ivan: not sure if you want to take this over
… but we should close this and do the work elsewhere

TallTed: I think we should leave this open
… yes, the redirect should be fixed
… but it often takes years to get this stuff fixed
… and it's nearly ever setup correctly
… each of these things should become issues
… I don't think we should throw that work out just because it was with a bot
… it's not completely out of bounds to do this

wes-smith: I can certainly appreciate this perspective
… but in this case, rescuing this PR would essentially reverse this work anyhow

ivan: ish. however it's done it should mainly fix the informative vs. non-normative

TallTed: we should file issues that explain the problem

wes-smith: there is an issue about this

bigbluehat: I don't think it's worth the lift to protect this PR. It's wrong. We can redo it quickly. But we should fix the issue details.
… if they come back, they can do it better based on new content on the issue.

wes-smith: who can add those details?

bigbluehat: I will.

wes-smith: I will go over PR 73
… and bring in grammar and layout fixes requested in the earlier PR
… please review this one and leave feedback
… hopefully this adds clarifications

ivan: I am curious how my request will be solved
… there's a discrepancy between the description of the registry here and the registry itself

<ajs6f> bye all!