JSON-LD CG

Minutes for 2024-03-06

Present

Benjamin Young, Gregg Kellogg, Pierre-Antoine Champin, David I. Lehn, Niklas Lindström, Anatoly Scherbakov, Ted Thibodeau Jr.

Chair(s)

Gregg Kellogg

Scribe(s)

Gregg Kellogg, Benjamin Young

Agenda

https://www.w3.org/events/meetings/398465c7-3787-40df-856a-434a438d9f05/20240306T120000/

Topics

Announcements and Introductions
YAML-LD
CBOR-LD
JSON-LD Issue Discussion
Open Discussion

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 https://www.rfc-editor.org/rfc/rfc9512.html

... 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: https://json-ld.github.io/cbor-ld-spec/

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 ✪

David I. Lehn: I don't know the status of implementations, and Ruby fails it.

Gregg Kellogg: Suggest merging.

Niklas Lindström: Looks good, we can merge.

Niklas Lindström: For the record, PR 593 looks good.

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.

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.

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.

Ted Thibodeau Jr.: "Blah"^^https://www.w3.org/ns/iana/media-types/application/geo+json

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"^^https://www.iana.org/assignments/media-types/application/geo+json

... 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.

Pierre-Antoine Champin: https://github.com/json-ld/json-ld-wg-charter/pull/1

Pierre-Antoine Champin: The PR against the current charter is for things we want to add.

The W3C JSON-LD Community Group

Go Back