The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG

Minutes for 2023-10-18

Present
Gregg Kellogg, Anatoly Scherbakov, Niklas Lindström, Pierre-Antoine Champin
Chair(s)
Gregg Kellogg
Scribe(s)
Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/1ab7df94-bb06-440e-a6b9-bc9022018c57/20231018T120000/
Topics
  1. Announcements and Introductions
  2. YAML-LD
  3. JSON-LD Issue Discussion
Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Topic: YAML-LD

Anatoly Scherbakov: The only change I've managed is to remove the %YAML 1.2 from some files and tests.
... There was some discussion on this issue.
Gregg Kellogg: Using YAML 1.2 was a problem for Linux tests.
Anatoly Scherbakov: I agree that we should allow implementations that are based on libraries not yet supporting YAML 1.2.
... We could either revert the change, or change the test runner implement.
Gregg Kellogg: Test runners are per implementation.
... I don't think we have tests that depend on any specific YAML 1.2 information.
Anatoly Scherbakov: My concern is that an explicit %YAML 1.2 header would be perceived by users as an indication that such a header is required for YAML-LD files when they look at the spec and the test suite for inspiration.
Ted Thibodeau Jr.: My concern that the spec says it's based on 1.2.2, but it doesn't say what specifically it depends upon.
... Either the header declaration is necessary, or its not. If it's necessary to run on 1.2, the header should remain, otherewise, it should be removed.
Niklas Lindström: So in YAML 1.1: x: yes becomes {"x": true}?
Niklas Lindström: But in 1.2 it becomes {"x": "yes"}?
Ted Thibodeau Jr.: Did the issue arise due to GitHub CI processing?
Gregg Kellogg: For my implementation, yes.
Ted Thibodeau Jr.: I'd suggest that we raise an issue against GitHub CI that indicates that the version of LibYAML used is out of date.
... Secondly, we should note that if implementations run into issues, they should let us know.
... For now, remove the declarations, because we don't need it. We can put it back if we need it in the future.
... Roberto may be able to shed some light on these things.
Ted Thibodeau Jr.: I think we used 1.2.2 because it was the current spec.
Gregg Kellogg: Situation is similar to RDF/XML on XML 1.0 vs 1.1.
Niklas Lindström: The JSON-LD internal model is called the "Internal Representation".
... We might just want to put in a note about YAML version dependencies on limitations/features of YAML 1.2.
... There are implementations that use older libraries, and may have some issues.
... RDF/XML was only recently updated to be based on XML 1.1.
... The "yes" behavior in YAML is odd.
... It makes sense to base on the stable version of YAML, but note specific dependencies, if any, informatively.
Anatoly Scherbakov: 1) We can try installing a particular version of libyaml on Github CI via apt-get; 2) also, the PR has been already merged when Gregg had approved it; 3) YAML 1.1 accepts "y" as boolean True, which is probably not a good thing. 1.2 doesn't do that. So I'd prefer 1.2.
... It's the subset of processed YAML which is the relationship to the JSON-LD internal representation.
Pierre-Antoine Champin: Arriving
Anatoly Scherbakov: I prefer YAML 1.2 because of obscurities.
... I'd like to have some time to talk with dlehn about PyLd.

Topic: JSON-LD Issue Discussion

Subtopic: Continued discussion on RDF-star proposals for graph terms, and the implication to JSON-LD

Niklas Lindström: The current proposals for JSON-LD-star use an object for the value of at-id.
... But, code that I've written that uses JSON-LD as just JSON will trip up on that variation.
... That does relate to the use of graph terms vs triple terms.
... This also gets into type/token issues.
Anatoly Scherbakov: Is the JSON literal opaque? Thus, fields of the JSON object cannot express semantic information, is that correct?
Anatoly Scherbakov: I thought that the ability to have named graph a subject of a triple already existed. So isn't the graph-based syntax already in use today?
Anatoly Scherbakov: @Pchampin I think there is severe echo at your mic
Niklas Lindström: The description of the type/token use of graph terms seems right.
... From JSON-LD, we need to look at where we are with JSON-LD now.
... Given that we have named graphs, and blank graphs. And naming with a blank graph can't change between a token and a type.
... Everywhere an at-graph occurs, it's an occurrence.
... Whatever we come up with for graph terms in JSON-LD is the answer.
... Perhaps at-graph with at-type would distinguish between type/token.
Niklas Lindström: "X": {"@graph": {...}}
Niklas Lindström: "X": {"@type": "@graph", "@graph": {...}}
Pierre-Antoine Champin: "X": {"@id": "@graph", "@graph": {...}}
Pierre-Antoine Champin: Niklasl's proposal is interesting, but ...
... This might be a way to mark that the id isn't a blank node, but something else.
... I urge us to wait until the RDF-star WG comes to a conclusion before we go too far here.
... There are different forces at play, and there are constraints on what we can do.
... But, I agree that if quoted triples are to be replaced by terms, recycling @graph seems like a good idea.
Anatoly Scherbakov: What is the difference between a graph term and a named graph?
... Do we overload a keyword, or do something new.
Anatoly Scherbakov: What's the difference between a graph term and named graph?
... I feel that in current RDF I can do this, I can talk about properties of statements.
Niklas Lindström: The problem with named graphs when talking about triples is that when I don't use JSON-LD, I prefer to have shorthands, which don't exist.
... Named graphs are flat, so you can't have one inside another.
... I can't annotate an annotation.
... RDF-star is useful for doing these things.
... We need to devise a way to correlate the named graph with these annotations.
... They're similar to appendices.
... In practice, the Union graph in quad stores creates a restriction.
Anatoly Scherbakov: So can it be said that named graphs' problem is OWL/reasoning problem?
... We might need to fall back to reification. No way to make an assertion that isn't in a union graph.
Pierre-Antoine Champin: Not much to add.
Anatoly Scherbakov: Is it correct that the main problem is the logical consistency of the world we're modeling, and contradictions are a problem.
Niklas Lindström: Named graphs don't "kill" anything, as there is no semantics defined.
Ted Thibodeau Jr.: There's no formal semantics defined, but in practice there is; people are using it.
... Named graphs contradicting each other isn't a problem, it's the merged graph that's a problem.
Pierre-Antoine Champin: I should have said "there is no standard formal semantics for named graphs"
... When you introduce named graphs, you can say "graph a came from George, whom we trust".
... Another statement we might say we don't trust.
... This is the challenge of the way RDF was defined originally, as RDF statements are considered to be true for all time.
... That's the impetus behind RDF-star.
Pierre-Antoine Champin: TallTed except that saying "graph A comes from George", the standard semantics sees "A comes from George"... It does not relate A to the triples that are stored in your named graph.
Gregg Kellogg: Merge graphs don't actually have a formally defined semantics.
Anatoly Scherbakov: Yes it was very clear, thanks @TallTed. In SPARQL, even if we're querying against the merge graph (like in rdflib), we can use `GRAPH {…}` clause to choose named graph to query from.
Ted Thibodeau Jr.: Same for the "default graph".
Pierre-Antoine Champin: Gb, names off
Pchampin, OK.
Niklas Lindström: I agree with what TallTed said.