The W3C JSON-LD Community Group

Go Back


W3C Logo

JSON-LD CG

Minutes for 2022-09-28

Vladimir Alexiev is scribing.
Vladimir Alexiev: Presents himself
Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Vladimir Alexiev: I work at Ontotext, and have seen activity around this which I find quite interesting.
... YAML is easier to read and write than JSON, and can be as pretty or prettier than Turtle.
... Yet, YAML is a superset of JSON and if we leverage these features, we can get further prettiness

Topic: Approve Minutes

Vladimir Alexiev: Interesting discussion on datatypes and YAML-LD-star.

Topic: YAML-LD

Subtopic: Face-to-Face Q&A

Gregg Kellogg: If people want to discuss YAML-LD, now's a good time
Niklas Lindström: +1 For "ndjson-ld" (we're using lots of that internally)
Vladimir Alexiev: I think streams there are two concepts being confused.
... This relates to how you can use anchors, they can occur in different documents within a stream
... On the other hand, a stream might remain open.
... Also notes rubenwork's work on streaming JSON.
... These are different things. It makes sense that YAML streams could be the chunks.
Gregg Kellogg: Talks about YAML streams, and maybe a more general concept of "LD streams" that can be instantiated for YAML and JSON
Niklas Lindström: Let's not forget to standardize MIME types. We implemented ndjson-ld in rdf4j, but made up some custom MIME type
Niklas Lindström: Ndjson is a simple pragmatic way to do streaming. consider it as "one page of a note" or a data unit that's quite independent
Vladimir Alexiev: And so then, can't we map YAML streams to NDJSON: one piece per line?
Vladimir Alexiev: Maybe we can just map YAML streams to NDJSON.
Gregg Kellogg: There's a general feeling that streaming is important, so let's take up to standardize it
ACTION: gkellogg to create a repo for NDJSON-LD
Created https://github.com/json-ld/json-ld.org/issues/796 -> action 796 create a repo for NDJSON-LD (on ) due 5 Oct 2022

Subtopic: YAML-LD datatypes (and tags for datatypes) yaml-ld#17

https://github.com/json-ld/yaml-ld/issues/17 -> Issue 17 YAML-LD datatypes (and tags for datatypes) (VladimirAlexiev) UCR, spec
Pierre-Antoine Champin: The devil is in the details, and in the bnodes :-D
Vladimir Alexiev: I think we should use YAML tags in the form that datatypes are used for RDF.
... JSON-LD is more verbose, and the YAML syntax is more concise.
... In many case the context will relieve you of this need, but there are cases where the graph is heterogeneus
... May be a problem with parsers.
... This also relates to YAML schemas, and how to attach types.
... YAML had a schema including dates, but have backed up.
... My proposal would be that the WG will declare a %TAG |xsd| ...
... But, implementers will need to use a better parser that supports tags.
... This is also important for numbers.
... We had trouble in xxx group, where the number would be mis-interpreted.
... Then we need to look at a YAML parsers matrix to determine how widely available it is.
Gregg Kellogg: The current "spec" refers to a basic profile, which doesn't include tags but only basic YAML values
... and an Extended profile that includes XSD datatypes, and tags for URLs (is it absolute, or relative...)
... Gregg has an implementation that uses the YAML parse tree.
... Also in JSON-LD (discussion between Gregg and Antoine at TPAC), there is a movement towards handling more datatypes, and not mangling literals with default treatment of numbers
Vladimir Alexiev: What about URLs?
... In a heterogeneous dataset, the same field could contain either a string or a resource.
... can we have a single tag !id or !uri that would handle absolute, relative and CURIEs?
Gregg Kellogg: We want to explore some more use cases of URLs before deciding
Vladimir Alexiev: Can we decide this issue?
... let's not forget custom datatypes, eg geo:wktLiteral, geo:gmlLiteral, 5-10 more in GeoSPARQL 1.1, and the tentative rdf:JSON and rdf:YAML
Gregg Kellogg: Questions of quoting: is !xsd!integer '123' the same as !xsd!integer 123 and same as 123, or different?
Niklas Lindström: Author: someone!tag-key => as if author was defined in the context with "@type": <tag-key>; then if e.g. someone!uri was encountered, *and* uri is defined as an alias of "@id", this is short for {"@id": "someone"}
... the tag comes before the value, eg !tag-key someone
Gregg Kellogg: Tags should be declared in %TAG not in context, else we'll go against the grain of YAML

Subtopic: test suite

Vladimir Alexiev: I'll try to contribute to this. I grok the yamlld tests, but not how they are linked into the spec

Subtopic: Serializing JSON or YAML literal in YAML-LD yaml-ld#36

https://github.com/json-ld/yaml-ld/issues/36 -> Issue 36 Serializing JSON or YAML literal in YAML-LD (gkellogg) spec
Vladimir Alexiev: I gave an example from Elastic Search. This connector can be used in indexing.
... Fields have types and other attributes.
... Currently, we implement this in JSON. There's a SPARQL INSERT involved.
... We've wanted to turn that into a better notation, as you can't use prefixes.
... We're thinking of converting it to proper RDF; the question is how to write it.
... If we allow JSON and YAML literals, it would help with the interpretation of that data.
... If JSON was done because it was popular, it makes sense that you be able to store YAML as a literal.
... A good example is GeoJSON. In JSON-LD 1.1, it can be interpreted.
... But, it comes out as a nested list of lists.
... There are textual formats for GeoJSON.
... I think we should have a YAML literal.
Gregg Kellogg: There's the JCS spec to canonize a JSON literal. We don't have such a thing for YAML
... the value of canonization is that then you can compare literals for equality, so that value equality will coincide with lexical equality
Vladimir Alexiev: Ok, I see but 1. RDF doesn't even canonize simple things like xsd:boolean, numbers (123 vs 0123), and even URLs
... 2. We could tackle YAML canonization, in fact I'd like to have that (and standardize pretty-printing parameters, and the ability to capture them in YAML-LD)
Gregg Kellogg: Sorry, out of time for today. We can contniue on next call. Please send in discussion topics for next meeting agenda.
Created https://github.com/json-ld/json-ld.org/issues/797 -> action 797 create a repo for NDJSON-LD [1] (on ) due 5 Oct 2022