– DRAFT –
JSON-LD WG

Announcements and Introductions

<TallTed> bigbluehat -- For next time, you can `agendabot, find agenda`. See https://w3c.github.io/AgendaBot/manual.html for more tricks.

bigbluehat: Netflix are using RDF and CBOR-LD

bigbluehat: would like to invite them to talk

<anatoly-scherbakov> +1

bigbluehat: will schedule them

YAML-LD Issue curation (20 minutes)

<bigbluehat> https://github.com/w3c/yaml-ld/pulls

bigbluehat: looking at YAML-LD PRs

Pull Request 166 Specify editors, authors, and contributors (by anatoly-scherbakov)

bigbluehat: affiliations were added

bigbluehat: merging

Pull Request 168 #20 Reference exact test suite versions (by anatoly-scherbakov)

bigbluehat: merging

bigbluehat: editorial PRs can be merged directly without discussion

<Zakim> ivan, you wanted to meta issue

ivan: we should not work on CG document anymore

ivan: respec header must be changed to WG document

ivan: CG-DRAFT to ED

bigbluehat: can handle this in my PR

<TallTed> "editorial PRs can be merged directly without discussion" but should exist for at least a few days before they get merged, to allow for me and others to catch errors of whatever flavor.

<TallTed> It's a much lower lift to suggest changes to a PR than to create another PR.

<TallTed> Near-immediate merges obviate most of the point of working through PRs instead of direct commits.

Makes sense TallTed

Issue 163 IPR Commitments (by BigBlueHat)

bigbluehat: this is done, can resurface if more IP

bigbluehat: ...IPR commitments needed

dlehn: what's about rack dependencies?

bigbluehat: after Gregg passing, Ruby code is decaying

bigbluehat: we need support for Ruby or a rewrite

dlehn: so should we just upgrade these minor versions?

bigbluehat: we can, and see what happens

<anatoly-scherbakov> +1

bigbluehat: ultimately, when a spec has an editor then maintenance of Ruby code will be their responsibility

bigbluehat: there is probably no risk, so this is not a high priority

anatoly-scherbakov: I haven't looked into these issues in a bit

https://github.com/w3c/yaml-ld/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22test%3Aneeds%20tests%22

anatoly-scherbakov: the plan was to write tests for each of these
… to confirm that YAML-LD implementations could do these
… especially when contexts and frames are in YAML-LD
… the need is still there
… I can look into it
… I wanted to mention that I've created milestones
… the idea is to free us from looking at the issues that cannot or are not addressable
… for example, the triples as subjects one is related to RDF1.2
… and the extended profile idea was from Gregg for using more of YAML

bigbluehat: YAML-LD could use defer-future-version label

bigbluehat: adding it

bigbluehat: we'll do calls with editors to do such stuff

bigbluehat: moving json literal support to future work

bigbluehat: -00 milestone is unclear

bigbluehat: now, we can filter issues excluding future versions

Issue 143 Should output type of `expand()` be `dict` or `str`? (by anatoly-scherbakov)

anatoly-scherbakov: I wrote this one as a question
… mostly about the proper typing of the expand function
… I would likely re-request this in JSON-LD API spec

bigbluehat: keeping this for now

Issue 118 Write test manifests in YAML-LD instead of JSON-LD (by anatoly-scherbakov) [test:needs implementation]

Issue 103 Test: anchor names do not convey semantic information (by anatoly-scherbakov) [test:missing-coverage] [test:needs implementation]

anatoly-scherbakov: in a YAML document you can create an anchor to assign a name to a piece of the document
… and then refer to it from within the document essentially duplicating it into the place where the anchor is referenced
… and in YAML-LD the anchors are being resolved via YAML parsing
… and when you look at it in Linked Data the anchors are gone
… so there is not semantic meaning
… and this issue is about writing a test for this
… it could be possible to maintain the anchors, but it would be for future work

bigbluehat: so this issues is just for writing a test
… does this need a test? because the anchors are gone after YAML.parse() aren't they?

anatoly-scherbakov: yes, but there were ideas for the future to possibly give the anchors semantic meaning
… and theoretically one could keep those around, but it would reduce compatibility with JSON-LD and others

<niklasl> I'd probably be a -1 on that (as it sounds like it reduces interoperability?)

bigbluehat: this issue might be beyond scope

pchampin: I'm +1 on writing this kind of test

pchampin: agree with adding such a test even if being non-compliant requires lots of work

pchampin: because the idea existed

pchampin: YAML has several data model levels

pchampin: one of these keeps comments

pchampin: some parsers give you the choice of the level

pchampin: I guess some parsers give you access to anchors if you want

pchampin: also important to distinguish anchors in context vs data

pchampin: anchors in context might be very useful

pchampin: for instance, for the same scope context in different places

<pchampin> https://w3c.github.io/yaml-ld/spec/#example-with-anchors

bigbluehat: making the test makes sense, spec has an anchors example, maybe we could explain a bit further how to use anchors in context

anatoly-scherbakov: we can close this

bigbluehat: what is FHIR?

Issue 98 investigate FHIR Shorthand (FSH) (by VladimirAlexiev) [out-of-scope]

bigbluehat: might be up for discussion elsewhere, marking as out of scope

Issue 84 Downgrading from Extended Internal Representation should use value objects (by gkellogg) [enhancement] [spec]

bigbluehat: deferring to future version

Issue 83 use regular expressions to resolve literals; URIs, CURIEs (by VladimirAlexiev) [UCR]

bigbluehat: let's come back to this one later

<anatoly-scherbakov> +1

bigbluehat: let's close the Work Plan issue

bigbluehat: let's do further cleanup

bigbluehat: we'll probably do CBOR-LD next week and we are looking to meet Netflix

we also need to talk about bringing the other minutes site/space back up to snuff