Meeting minutes
Announcements and Introductions
wes-smith: what's the FPWD status for CBOR-LD?
ivan: I don't know where it stands
… but the AC meeting in China this week maybe delayed things
wes-smith: ah. good to know
ivan: they usually approve on Friday's
… so maybe by next week?
bigbluehat: I'll check with PA about it
YAML-LD check-in
ivan: looking at the issue list for the transition request, it was created last week.
anatoly-scherbakov: we have a big pull request re: extended profiles that separates that into a new document.
<gb> https://github.com/w3c/yaml-ld/pull/193
anatoly-scherbakov: I have created more tickets from the discussion of that PR.
… I also had a thought - there is an ontology for JSON-LD and a namespace for that ontology, and it defines a number of terms.
… It also defines profiles of JSON-LD documents. However, I don't know what use cases for which this ontology was created.
… I wonder if a version of that ontology tailored to YAML-LD would be useful.
ivan: I have not seen any usage of that ontology.
JSON-LD ontology https://
ivan: Implementers may have done something.
bigbluehat: The intention was that JSON-LD contexts are a unique JSON format, as I understand the ontology provides a way to turn contexts into RDF.
… Did you have something in mind to use it for?
commit history of the ontology https://
anatoly-scherbakov: I was hoping to describe YAML-LD behavior into an ontology.
… I like things to be machine readable.
… I created an issue but we might decide to defer to another version.
Issue 192 Create a YAML-LD namespace ontology (similar to https://www.w3.org/ns/json-ld) (by anatoly-scherbakov)
niklasl: agree to defer it, it is academic at the moment.
bigbluehat: there is value here for working with JSON-LD contexts. will be good to revisit this if we explore it further.
ivan: I raised an issue on the YAML spec, #195
<gb> MERGED Pull Request 195 Describe that type-scoped contexts are only in affect on the node objects in which they're used (by gkellogg)
Issue 195 Move anchors & aliases to Extended Profile? (by anatoly-scherbakov) [needs discussion]
ivan: my goal is to make things as simple as possible and make YAML-LD human friendly. The current structure, with anchors/aliases, is the only thing in the spec that is not a JSON feature.
… I was wondering if we want to do that.
<niklasl> +1 from me (same motivation)
anatoly-scherbakov: I agree that this feature is unusual compared to JSON but I would be hesitant to forbid it because it is useful in contexts. If we forbid these, YAML parsers might break.
… Usually parsers have extension points/customizability, but I'm not sure how standard it is to disable a YAML feature.
… Currently anchors and aliases are transparent from the spec's POV - we rely upon the yaml parser to do so.
… Currently we do not assign semantic meaning to YAML tags - we say this is up to the parser.
… The parser will fail if it encounters an unknown tag.
bigbluehat: The advantage is not repeating yourself, the disadvantage is text-based parsing.
… I'll put an example up.
niklasl: I agree with anatoly-scherbakov, I wouldn't want the spec to advise altering parsers.
… YAML is also allowed to have cycles, which we need to restrict.
ivan: clearly we cannot just say "it's forbidden", so maybe what we can do is say "if you use this feature you get something that is different from the JSON-LD equivalent".
<niklasl> +1 to ivan to call this out
bigbluehat: in my head I've had it positioned between YAML and JSON - run YAML parse with some settings to constrain the schema - so that it's constrained YAML parsing, then do other errors/warnings based on that internal representation.
anatoly-scherbakov: That's what we suggest doing, parse YAML with certain settings/version, we specifically say that cycles are not allowed, and we say that some documents are not round trappable.
bigbluehat: wouldn't that mean the YAML is invalid?
anatoly-scherbakov: If the YAML document contains a cycle it is not YAML-LD. Cycles are forbidden. Anchors/aliases without cycles are valid YAML-LD but are not roundtrippable.
bigbluehat: did we ever want YAML-LD w/anchors => JSON-LD to "round trip" back to YAML-LD w/anchors?
ivan: I'd certainly want to use anchors in a complicated context file
… I know I need to generate a JSON-LD context that was fully "hydrated"
bigbluehat: you'll loose anchors only, correct
<anatoly-scherbakov> bigbluehat: json-ld ecosystem should only carry around json-ld contexts
<anatoly-scherbakov> bigbluehat: json-ld is in the middle and other formats circle around it
<anatoly-scherbakov> bigbluehat: yaml-ld contexts referenced from CBOR-LD registry mean we have a combinatorial explosion
<anatoly-scherbakov> bigbluehat: getting back from a JSON-LD doc to something with anchors might be a stylistic choice
bigbluehat: I feel like it's a feature unrelated to the practical use of JSON-LD.
<anatoly-scherbakov> * thanks Wes!
bigbluehat: You could use any number of other scripts, that's not the responsibility of the JSON-LD layer.
… the "rehydrated" document with anchors in it is a side quest that is unrelated to the JSON-LD ecosystem, but there is nothing that I've heard that says we shouldn't allow it. I do have an ambient fear about cycles.
anatoly-scherbakov: I wanted to mention that anchors/aliases are not the only thing that prevents roundtrippability etc - another is comments.
… there are also YAML streams where you can put multiple documents in a single file.
… We would have to create an ontology to describe those minutia.
… There are also formatting differences, like per-line list items.
… byte-to-byte roundtrips are difficult and messy.
ivan: We all agree that there should be a callout in the spec telling users to be careful with features that are not in JSON-LD.
bigbluehat: Historically YAML processing has been a hot topic within W3C.
… The takeaway as I understand it is not that it should move to the extended profile, but that we need to say "you can do this but be careful".
… We should not implicitly or accidentally suggest that JSON-LD is going to carry the water for any part of the YAML-LD processing model.
CBOR-LD PRs & Issues
https://github.com/w3c/cbor-ld/pull/75
bigbluehat: yeah...I still need to finish that one
Issue 71 Discrepancy between the spec and the current registry? (by iherman)
wes-smith: ivan noted a discrepency
… with which I agree
… things are still under discussion
… so once some of that is settled, we can make the text(s) match
… not sure this needs discussion so much as time
… so I will tag this as editorial
… probably class 2 since it doesn't change the function of the document
ivan: are there definitions changing?
wes-smith: yes, they do change
bigbluehat: don't bother with picking classes.
… just pick "editorial"
wes-smith: I think other issues will make this one happen tangentially
… so, yes, this is an issue, but likely to be addressed by other PRs indirectly
Issue 67 Example needed to demonstrate the difference between forms of compression (by wes-smith)
wes-smith: this one is about different approaches to compression
… we need an example that takes the same JSON-LD document
… and runs it through different compression approaches
… and shows the compression difference based on which algorithm(s) were active
… marking this one as editorial
Issue 66 Algorithms should use <var> instead of <code> (by pchampin) [editorial:class 1]
wes-smith: this is just an editorial change in HTML tags
… help welcome!
Issue 65 The spec lacks a "terminology" section (by pchampin) [substantive:class 3]
wes-smith: this one is tagged as substantive
… am I understanding that these just need to be made linkable?
ivan: yes, they need clear definitions for the terms
… it's also editorial
… it's done in all/most W3C specs
wes-smith: good to note
Issue 64 Codecs: discussion, algorithms, registry example. (by wes-smith) [needs discussion]
wes-smith: this one surrounds codecs
… it's about compressing typed values
… we need to add the codecs that will be part of the base processing model
… and clarify what the base processing model is fully
… as well as how to define other codecs in the registry
… any questions?
… k. removing the "needs discussion" label
… and adding "substantive" and "Priority 1"
… as this needs to happen as it's a core feature
Issue 29 Ensure "processing model" is included as a registry entry option (by dlongley) [editorial]
wes-smith: this is another "collateral damage" issue
ivan: collateral, but not damage!
bigbluehat: "collateral benefit"?
wes-smith: collaterally closable
… many of the rest of the issues fall into this category
Issue 46 Define registration process (by dlongley)
wes-smith: removing the "needs discussion" label since we talked about this one
… adding a "substantive" label instead
… well...
ivan: definitely "substantive" since we can't move ahead without this
bigbluehat: the spec depends on it
wes-smith: thank you for the help
… still getting good at labels
… I think that's it for today, then
… bigbluehat we that links PR
Open Discussion
bigbluehat: short bit on PyLD from anatoly-scherbakov ?
anatoly-scherbakov: thanks, was thinking about modular document loaders
… allowing one to install them together
… so YAML-LD would be a plugin to PyLD
… and then other systems could do the same or something similar
… I'll write an issue about it
bigbluehat: the idea being that the document loaders would do the document transformation?
anatoly-scherbakov: yes, via separate packages/plugins
<dlehn> might want to write up the ideas before coding too much. finding a good pattern for that sort of design might be tricky.
bigbluehat: ...there be dragons
ivan: the only thing I'm asking is that this doesn't have much to do with this spec
bigbluehat: yeah, it effects the specs in when/how contexts are dereferenced and what we should/can expect them to be
… we're past time...thanks everyone