Meeting minutes
Announcements and Introductions
YAML-LD PR check-in
<bigbluehat> https://
Pull Request 180 [#103]: Anchor names do not convey semantic information (by anatoly-scherbakov)
anatoly-scherbakov: this is a simple change.
… it confirms that anchor names in YAML-LD have no bearing in the output
… this PR also adds a note to the spec demonstrating the usefulness of anchors in the JSON-LD context
TallTed: just to confirm that I understand; anchor names are basically equivalent to fragment ids?
anatoly-scherbakov: you can fetch fragment IDs, I don't think that you can fetch anchors
TallTed: you actually don't fetch a fragment; you fetch the whole document, and then find the fragment ID in it
… I don't understand what an anchor name is, where it is defined.
bigbluehat: it is a YAML thing.
bigbluehat demonstrates anchors in transform.tools
pchampin: there are two sides to TallTed's question
… maybe they work like fragment IDs...I don't know
… we'd have to check
… because it may be possible to use an anchor name as a fragment identifier in a URL
… but how it's being used in this example is from the "macro" case
… where the named content is copied into other locations
<niklasl> +1 It's a part of the data structure, not it's.. ehrm... "semantics" (afaict)
pchampin: and since the JSON-LD processing happens after the macros
TallTed: "anchor" is a bad name, then, but we can not change it so...
bigbluehat: anatoly-scherbakov maybe we should add some clarifying text to the PR
anatoly-scherbakov: I like the analogy with macros
bigbluehat: and we should avoid the "fragment ID" discussion
anatoly-scherbakov: I will make a seperate PR for the clarification
bigbluehat: we said earlier that contexts should be published in JSON-LD, so examples of contexts in YAML-LD should also make it clear that not all JSON-LD processors are expected to understand those contexts "as is"
Pull Request 182 [#181]: YAML-LD requires YAML ⩾ 1.2 (by anatoly-scherbakov)
<ajs6f> Did we not invent Unicode?
anatoly-scherbakov: I looked into the changelog of YAML. The most changes appeared between YAML 1.1 and 1.2. The changes in 1.2.1 and 1.2.2 are cosmetic
pchampin: I raised w3c/
<gb> Issue 181 should YAML-LD require YAML ≥ 1.2 ? (by pchampin)
pchampin: and many mentions of the "Norway problem"
… which disappeared 15 years ago or so with the advent of YAML v1.2
… but many libraries are still only doing YAML v1.1
… so clarifying that this is v1.2 based should avoid the "Norway problem" and many other things
… requiring v1.2 in YAML-LD should provide a clearer foundation
ivan: my question is: how big is the problem?
… if I take a YAML parser, are they 1.2 these days?
… it is important to be precise, but is it a practical problem?
anatoly-scherbakov: someone pointed out that PyYAML is 1.1, and suffers from the "Norway problem"
… but a 1.2 library is available
… it is important to point out to developers that their library might be outdated
… also we already test that 'no' is interpreted correctly
ivan: my question was about users rather than implementers
… when I create a YAML file, I have to be sure that I don't dammage it on the way
<niklasl> +1 to @ivan (to be fair, "on" and "no" are safe afaics)
ivan: Could we provide guidance to users about how to stay away from problems?
bigbluehat: there is more in the YAML-LD spec than "convert your YAML to JSON and hope for the best"
… the spec should help authors navigate that space
… as pchampin mentioned, a lot of people reacted negatively to the announce of YAML-LD because of YAML's bad reputation
… we need to explain "when we say YAML, we mean this particular subset"
anatoly-scherbakov: the spec says that you need to use YAML 1.2; that you can only use string as keys (YAML allows other types)
… you must not use infinite and NaN numbers
… you can use YAML anchors (with restrictions) and tags, but its is up to the parser to interpret tags
… some parsers will interpret things that look like dates into the native date datatype of the language: this also is not supported
bigbluehat: we might want to make the point that users need a proper YAML-LD parser, rather than any tool able to convert YAML to JSON
<ivan> /me I do not agree; a YAML-LD parser does not necessarily generate a JSON-LD...
bigbluehat: anatoly-scherbakov, feel free to merge the PRS if they get enough approval
CBOR-LD issues
Pull Request 62 Update tag processing algorithms. (by wes-smith)
wes-smith: the current spec does not match the current state of the register
… there was some back-and-forth with IANA
… this PR updates the algorithm to match the current state of the tag system
… as you can see, this is mostly a simplification
bigbluehat: each CBOR tag would normally have to be registered with IANA, but there is now a range usable by W3C, right?
wes-smith: IANA were not in favor of that, there is now a single CBOR-tag, with an array of 2 elements
… the first one contains a registry ID, the second one contains the payload
<wes-smith> +1 ivan
ivan: in principle, this PR must be merged, as it is the agreement with IETF
Pull Request 61 Update top-level encoding/decoding algorithms to support uncompressed use cases. (by wes-smith)
wes-smith: the specification and the registry says you can use CBOR-LD either with or without semantic compression
… CBOR-LD is a syntax for encoding linked data in JSON; the semantic compression is a specific feature, but it is not a requirement
… registry entry 0 means "no compression", but the algorithm currently assume semantic compression
… this PR fixes that
wes-smith describes the "Person" example in CBOR-LD in the next playground,
wes-smith: it would be nice to have, in the playground, a way to change the registry entry for CBOR-LD
… by default it uses registry entry 1, which is generic semantic compression
pchampin: registry entry 1 is generic semantic compression
… is the compression based on schema.org? or some other process in the playground example?
wes-smith: the compression is done by what context is provided in the registry when you do the compression
… we take all the terms in the provided contexts in the document
… we do a term to an integer map
… doing that well and correctly is what almost all of the algorithmic text is about
wes-smith: for each registry entry, people can chose whether it uses semantic compression or not, whether it includes features specific to their own context...
… registry entry 100 (Verifiable Credential) is interesting, because it addresses compressing keys but also *values*
https://
… this entry defines compressed value for contexts and for cryptosuite
registry entry https://
ivan: how does it relate to the email discussion we had with Leonard Rosenthol. What does he wants us to do?
wes-smith: ther are two things; one is to decouple semantic compression from the basics of CBOR-LD, that's what this PR is doing
… the other question is: is there some CBOR linked data that does not serialize to JSON-LD?
… We need to further discuss this with the WG
ivan: I'm not sure I understand this question. My understanding is that C2PA want to use VCs, but that boils down to JSON-LD
bigbluehat: my understanding of what Leonard is asking for is, first, registry entry 0 (although I'm not sure that what he needs); and he wants to stay in CBOR land when processing the data, without going into JSON land
… we will meet him to clarify
wes-smith: +1 to what you said
… in addition to that, he also wants some CBORD-LD that didn't start from JSON-LD
pchampin: about processing without going into JSON-LD land is not a problem
… because you can stay within the processing environment
ivan: that's what I responded :)
<ajs6f> bye all!