The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG

Minutes for 2024-07-24

Present
Gregg Kellogg, Ted Thibodeau Jr., Benjamin Young, Anatoly Scherbakov, Niklas Lindström, David I. Lehn
Chair(s)
Gregg Kellogg
Scribe(s)
Gregg Kellogg, Benjamin Young
Agenda
https://www.w3.org/events/meetings/08563546-30fd-497a-ac16-77f96e96e8c0/20240724T120000/
Topics
  1. Announcements and Introductions
  2. Who's coming to TPAC?
  3. YAML-LD
  4. CBOR-LD
  5. JSON-LD Issue Discussion
Action Items
  1. gkellogg to propose text on describing "flexible" use of the API by implementors.
Gregg Kellogg is scribing.

Topic: Announcements and Introductions

Benjamin Young is scribing.

Topic: Who's coming to TPAC?

Gregg Kellogg: I'll be there
Benjamin Young: Likewise
Ted Thibodeau Jr.: I'll be remote
Anatoly Scherbakov: I'll also be remote
Gregg Kellogg: PA should be there in person
Gregg Kellogg: Monday we meet with the Spatial Data on the Web.
... Tuesday with RDF-star
... Thursday we may give up our 9 am slot to not conflict with RDF-star
... then we have our standalone JSON-LD spot at 2 pm
... then a joint meeting with Web of Things
Gregg Kellogg: One of the topics that will come up with Web of Things is CBOR
... it has some compression advantages over the Digital Bazaar approach

Topic: YAML-LD

Anatoly Scherbakov: Not much to report.
... except I have made a release of my library which is a wrapper around PyLD
Anatoly Scherbakov: Just today, pushed a PR against JSON-LD API about the JSON Representation. Published https://python-yaml-ld.iolanta.tech — Python implementation with JSON-LD functions working with YAML-LD documents, plus a command line interface to expand/compact/flatten/etc such documents from the Web & local filesystem.
... it also includes a command line interface
Anatoly Scherbakov: I'm not sure what else is needed for YAML-LD
Gregg Kellogg: YAML-LD is an official report
Benjamin Young: We should start working on charter issues.
Benjamin Young: So we wait on the updated JSON-LD WG?
Gregg Kellogg: Correct. that seems best

Topic: CBOR-LD

Benjamin Young: DB has a growing need to get moving on the CBOR-LD spec. We have several more implementors working on OpenCred as well as verifiable bar codes.
Benjamin Young: Is the Web of Things approach covered in the CBL paper? https://arxiv.org/abs/2407.04398
Gregg Kellogg: Yes
Gregg Kellogg: CBOR doesn't need to be tree based.
... we should sync with them about the details
Anatoly Scherbakov: Is DigitalBazaar planning to implement CBOR-LD within `pyld` library at any capacity?
Anatoly Scherbakov: Is DB planning on implementing CBOR-LD within PyLd?
Benjamin Young: We don't currently have a need to do that.

Topic: JSON-LD Issue Discussion

Subtopic: w3c/json-ld-api#606

https://github.com/w3c/json-ld-api/pull/606 -> Pull Request 606 The default for extractAllScripts in toRdf() should be true. (by gkellogg) [spec:enhancement]
Gregg Kellogg: We've discussed this. it seems ready to go. it needs one more editor approval.
... we should poke PA
Gregg Kellogg: Need's pchampin's approval.

Subtopic: w3c/json-ld-api#608

https://github.com/w3c/json-ld-api/pull/608 -> Pull Request 608 JSON Serialization → Object Representation (by anatoly-scherbakov) [spec:substantive] [ErratumRaised]
Anatoly Scherbakov: I just made a couple of more comments on this.
https://github.com/w3c/json-ld-api/issues/605 -> Issue 605 It is not clear enough what "JSON Serialization" is (by anatoly-scherbakov) [spec:editorial] [ErratumRaised]
Gregg Kellogg: Needs something to describe serizliing to JSON based on the Accept header.
Anatoly Scherbakov: If we call expand against a vocabulary and use Accept. It could provide problems with interacting services.
... The input type and output type may be different.
Gregg Kellogg: Potentially, one could send up RDF/XML and have that transformed on the server and then returns the result as compacted JSON-LD
Anatoly Scherbakov: I may not be following
... the interface of the JSON-LD Processor API refers to how we call it's functions
... if we pass `Accept` header to those functions would be what they will ask of a remote server
... but in the JSON-LD API, I don't see a way to respond with a native representation vs. a string
... the point of my PR was to return whatever it is natively in the language/implementation vs. always returning a JSON string
Gregg Kellogg: So that's the point of the Accept header
... we do describe those headers in the syntax document
... that sort of thing wraps those API methods
... my Distiller implementation receives a string representation, turns it into an RDF Dataset, and then sends it back in the requested format
... so maybe the only thing needed is a note about adding back in a description of how the internal format is turned into JSON
Anatoly Scherbakov: I will think about adding such a note
... it is subjective, but the term "internal representation" is confusing
... it sounds like JSON-LD implementations use, but that never leave the software...and developers will never see
... but it's actually just the JSON-LD document has when represented within the programming language
Gregg Kellogg: I think we've established the "internal representation" in other specs years ago...we can't really change that
... and it's essentially what you're describing
... so that was an abstraction for working with multiple formats
... what's missing is a description of how to turn the "internal representation" into a string
... similarly we need something for the output as well
... to say it's an "object representation" is not quite correct, since objects tend to refer to maps
... the API can also return arrays of objects
... we don't return smaller representations
... we should update the API to make sure that text is accurate
Niklas Lindström: Isn't the issue that the API IDL is at odds with the algorithm text? The IDL specifies the return types of compact and flatten to be a Promise of JsonLdRecord, and a sequence thereof for expand and fromRrdf (JsonLdRecord "is the definition of a map used to contain arbitrary map entries which are the result of parsing a JSON Object").
Niklas Lindström: I've only glanced at this, but it seems to point to a problem that the API definitions seem to be at odds with the actual function definitions
... it's a bit weird that it says "resolve" as well
Gregg Kellogg: Right. that's what's being addressed here
Niklas Lindström: K. we should not say JSON serialization, but maybe "JSON-LD record"
Gregg Kellogg: The promise is resolved with the record
... but maybe we need to revisit that wording
... what's needed is the bridge that says, for this middleware layer to actually serialize that, it needs to know what it's changing it into
Anatoly Scherbakov: There is a section about resolving...if a string is provided that it is a URL that it's trying to resolve
... I may add a note there about converting it to a form specific to the implementation
... and not to the API specification
... I do have another question: it says `.expand()` will return a Promise that will have to be responded
... that's very specific to JavaScript
... in Python, `.expand()` returns an expanded document itself
... so, the question, if an implementation doesn't return a Promise, is that implementation non-compliant?
Gregg Kellogg: Promises are defined in WebIDL which is what we're using to define the API
... which is meant to be cross-language
... do they have to use Promises? no. My Ruby implementation doesn't
... how that's interpreted--given the results are self reported--it's up to the implementer
... we don't make implementations pass a WebIDL test suite, for instance
... we mostly use that for describing the interface--regardless of language
... we have faced a lot of pushback since browser vendor folks want to narrow it to just their software
... the W3M said it was fine for us to use it
... but really, how the implementation does the implementation is informed by the WebIDL, but will be implemented as makes sense in that language
Anatoly Scherbakov: Can an implementation change the function signature? `expand(input_, options: JsonLDOptions)` vs `expand(input_, expand_all_scripts: bool, expand_context: JsonLDContext | None, …)`
Anatoly Scherbakov: Thank you. I didn't know Promises were a WebIDL thing
... one more question.
... expand takes a second parameter `options`
... but in Python, it would be more idiomatic to use named arguments
... this would be more customary for Python devs which would make it closer to their experience
... I haven't because I thought I would not be compliant
Gregg Kellogg: No. there's no police here
... ES6 does have support for keyword arguments, as does Ruby
... my own implementation uses a combination of these things
... as long as the calling sequences are consistent, then I think you're fine
... if you're building on PyLD, I'd continue that pattern
Anatoly Scherbakov: That's what I've done
Gregg Kellogg: The WebIDL is meant to remove ambiguity
Niklas Lindström: I'd like to comment that it would be nice about what you just said gkellogg
... in case this comes up again
... if I recall correctly, the interface was originally non-normative?
Gregg Kellogg: It's normative
Niklas Lindström: Maybe a note about idiomatic implementations still being complaint even if they deviate from some WebIDL specifics would be helpful?
ACTION: gkellogg to propose text on describing "flexible" use of the API by implementors.
Sorry, I don't know what repository to use.
Niklas Lindström: I recall that the API was intentionally non-normative in 1.0.
Niklas Lindström: I do recall a conversation around this before Python had async/await, etc.

Subtopic: w3c/json-ld-api#607

https://github.com/w3c/json-ld-api/pull/607 -> Pull Request 607 Fix test output for html/f004 for default extractAllScripts to false. (by gkellogg) [test:missing-coverage]
Gregg Kellogg: This goes along with the previous one about `extractAllScripts` is meant to work
Gregg Kellogg: This PR needs approvals.
... this is about fixing wording about `extractAllScripts`
... the tests assumed one thing, the text said another
... so this is about making the tests match the text
Ted Thibodeau Jr.: Maybe we can change the PR title to make it clearer?

Subtopic: w3c/json-ld-api#559

https://github.com/w3c/json-ld-api/pull/559 -> Pull Request 559 Add JSON literal tests. (by davidlehn) [test:missing-coverage]
David I. Lehn: Still an issue, but We're going to have to start our brains thinking about it again.

Subtopic: w3c/json-ld-api#585

https://github.com/w3c/json-ld-api/pull/585 -> Pull Request 585 Add graph container array tests. (by davidlehn) [test:missing-coverage]
David I. Lehn: Did I need to do this?
Gregg Kellogg: I can pick this up and move it forward.

Subtopic: w3c/json-ld-api#418

https://github.com/w3c/json-ld-api/pull/418 -> MERGED Pull Request 418 Add term scoping test for toRdf (by rubensworks)
Gregg Kellogg: This updates things to RDFv1.2
... did we have a WG statement about this?
... we're not in a good position about this if we're blocked by this work
... maybe let's talk about it on the next WG meeting
... we just more eyes on it again
Gregg Kellogg: Needs pchampin's eyes on this.
Niklas Lindström: +1 There's always a risk, but I think it's better to bet JSON-LD 1.2 being based on RDF 1.2...
Ted Thibodeau Jr.: For (near) future AOB/AMA -- How can compaction API be used to transform a JSON-LD document with unrecognized `@profile` value(s) to use recognized `@profile` value(s) (arose in Data Integrity)? Perhaps best to add this to JSON-LD docs?
Ted Thibodeau Jr.: It says you can use the API to transform a document and drop unrecognized values.
Gregg Kellogg: If `@prefix` was used, then we'd be falling into the prefix algorithm
Ted Thibodeau Jr.: This is not for `@foo` this is about `foo`
... when you encounter `foo` and go looking for the map for that term
... I think this is an expansion + compaction
... but I couldn't find how to do that
Gregg Kellogg: In the case you're describing: a term during expansion
... there should be some wording about that
... the RDF content remains constant. It's OK to loose that profile string
... and then the transformed document only retains profile strings
Gregg Kellogg: Sorry...could you raise an issue on this?
Ted Thibodeau Jr.: Yeah. I can do that.
Gregg Kellogg: K. we're out of time, so we'll take a look more next time