The W3C JSON-LD Community Group

Go Back

W3C Logo


Minutes for 2024-03-06

Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Benjamin Young is scribing.

Topic: YAML-LD

Gregg Kellogg: Any announcements?
Gregg Kellogg: YAML-LD
Gregg Kellogg: YAML Media Type is now RFC 9512
... anything to add?

Topic: CBOR-LD

Gregg Kellogg: Anything to discuss about CBOR-LD?
David I. Lehn: Nothing to add here
David I. Lehn: Haven't spent much time on CBOR lately.
... we're doing some stuff, but nothing formal to discuss
Gregg Kellogg: We did move CBOR-LD v1.0 to the CG, and we need issues added to it
Gregg Kellogg: It's been moved to the json-ld org, and needs issues added.
David I. Lehn: That's on my list, to help get things started
Pierre-Antoine Champin: CBOR-LD was moved to the json-ld repo, and it identifies itself as an W3C editor's draft.
Gregg Kellogg: We talked about advertising it as a draft
Pierre-Antoine Champin: There are two types of CG reports
... We should update the document status as to a CG-DRAFT.
... it should be a draft CG report
... it currently smells like rec-track
... Currently, Editor's Draft implies rec-track ED, which is premature.
Gregg Kellogg: Agreed. it's premature
... Currently, this would imply W3C endorsement.
David I. Lehn: We need to clean that up, and there are some DB things in it as well.
Pierre-Antoine Champin: I can make a quick PR.
Gregg Kellogg: Also, pchampin should add some issues to reconcile the two drafts.

Topic: JSON-LD Issue Discussion

Subtopic: open PRs

PR json-ld-api#593
/Issues/593 -> #593
PR w3c/json-ld-api#593 -> Pull Request 593 Test protected flag retained during redefinition. (by davidlehn) [test:missing-coverage]
David I. Lehn: I don't know the status of implementations, and Ruby fails it.
Gregg Kellogg: Suggest merging.
PR w3c/json-ld-api#591 -> Pull Request 591 Add test for `@context` redefinition. (by davidlehn) [test:missing-coverage]
Niklas Lindström: Looks good, we can merge.
PR w3c/json-ld-api#158 -> MERGED Pull Request 158 Add tests to check for keyword redefinition allowing `@protected`. (by gkellogg)
PR w3c/json-ld-framing#158 -> Pull Request 158 Add test with empty frame and empty context. (by davidlehn) [test:missing-coverage]
Niklas Lindström: For the record, PR 593 looks good.
PR w3c/json-ld-api#585 -> Pull Request 585 Add graph container array tests. (by davidlehn) [test:missing-coverage]
David I. Lehn: Do we have other tests that have a property expanding to an empty array.
... It doesn't change the N-Quads output, but there may be some ambiguity on the expected results.
Gregg Kellogg: It might be a warning condition if the result contains a property with no values.
Subtopic Discuss-Call
Issue w3c/json-ld-api#586 -> Issue 586 Meaning of "ordered by" in Node Map Generation step 6.12 (by danpape) [spec:substantive] [needs discussion] [ErratumRaised]
David I. Lehn: Do we have tests for this?
Pierre-Antoine Champin: Codepoint order is the same as lexicographical order in UTF-8.
... I wanted to be sure Rust was doing the same thing.
... There may be an issue in UTF-16.
... Internally, Javascript uses UTF-16.
David I. Lehn: I think there was a test for this.
Gregg Kellogg: I think saying that "ordered by" is in Codeppoint order is consistent with the rest of the spec, and consistent with current test results.
... That would make the change editorial, not substantive.
Issue w3c/json-ld-syntax#425 -> Issue 425 how to "retype" rdf:JSON to geo:geoJSONLiteral? (by VladimirAlexiev)
Niklas Lindström: No strong feelings about this, but my reaction is that I've considered something like this and could be important to do, but not in JSON-LD.
... Whatever we might come up with could have some repercussions on how to deal with literals in RDF.
Gregg Kellogg: I think this is narrowly defined on specifying the datatype of a JSON literal.
Niklas Lindström: If properties are intrinsic in the data-space of the datatype, you could think of what it entails.
... It reminds me of the direction thing for language literals.
... My hope would be that it could serve a general purpose for RDF usage.
David I. Lehn: When I looked at this, I saw it in the RDF domain. Could it be done at the application level?
... Is it a general solution?
Pierre-Antoine Champin: What you said about the asymmetry is interesting. There are corner cases where JSON-LD fails to do proper coercion.
Pierre-Antoine Champin: "P": 3.14
... For example JSON numbers.
Pierre-Antoine Champin: "314E-2"^^xsd:decimal
... Things are not as smooth as you describe.
... The only robust way to get a literal of any type is to use strings. You get into trouble using numbers, and you could using JSON values, as well.
... Not sure it's a bug; I'd lean towards application level.
Benjamin Young: I think this is severe scope creep; if we add geoJSONliteral, it gets nuts.
... We could get data peppered with all sorts of different kinds of literals. Ultimately, if it's a string, you can parse it into JSON.
... Better stated using properties within the resulting graph, than by expecting that the content of the literal has some additional meaning.
Gregg Kellogg: TAG thinks polyglot formats are an anti-pattern.
Benjamin Young: This could lead to a proliferation of datatypes that require special knowledge to understand.
Gregg Kellogg: Propose closing.
David I. Lehn: This may beyond the scope of the group, but it feels like structured suffixes of media-types.
... Not sure how to represent that in RDF.
Pierre-Antoine Champin: Geo:geoJSONLiteral rdfs:subClassOf rdf:JSON
Ted Thibodeau Jr.: It would be a sub-property.
Gregg Kellogg: You would need to parse a string value and parse to JSON to work with it in the application layer.
Niklas Lindström: I agree with the use cases and pragmatic within the JSON-LD context, but it opens up several strange things.
... The real solution is to use RDF to describe things with properties.
Ted Thibodeau Jr.: Or probably better ... "blah"^^
... In practice we use structured values. Theory and practice often collide.
... Not convinced to close it, but can see why we might want to defer to the application layer.
Benjamin Young: It's a heavy topic that we should continue to discuss. I agree it should be in the application layer.
... The reason we did this is because of query considerations, and a query engine might be expected to introspect these values.
... From GeoSPARQL, you want to be able to find GeoJSON literals.
... This requires that the application do more work of the database.
... This requires vocabularies to describe the relationship between GeoJSON and RDF.
... What's being asked for is a way of doing magic-string labeling, which is what media-types are.
... A better solution would be to figure out how to bring in media-types and then we could leverage this.
... But, I don't just want to add new terms to do a surface solution that doesn't really solve the problem.

Topic: Open Discussion

Gregg Kellogg: Perhaps next meeting is for the WG to discuss the charter. -> Pull Request 1 add REC-track deliverables CBOR-LD and YAML-LD (by pchampin)
Pierre-Antoine Champin: The PR against the current charter is for things we want to add.
Skip next CG meeting, and April 3 will be a WG meeting.