The W3C JSON-LD Community Group
Go Back
JSON-LD CG
Minutes for 2022-08-17
- Present
- Gregg Kellogg, Juuso Autiosalo, Ted Thibodeau Jr., Pierre-Antoine Champin, Benjamin Young, David I. Lehn
- Chair(s)
- Gregg Kellogg
- Scribe(s)
- Niklas Lindström
- Agenda
- https://www.w3.org/events/meetings/37dfdfbe-ffa4-4fff-9589-0bdc12401128/20220817T160000#agenda
- Topics
- Resolutions
Niklas Lindström is scribing.
Topic: Announcements and Introductions
Juuso Autiosalo: FYI, just added new issue on adding "How to read this document" section: https://github.com/json-ld/yaml-ld/issues/73
Announcements: Pierre-Antoine set up our official (w3c) repos to ensure that commits are properly checked.
Gregg Kellogg: You need to associated your account names with your github id; sent these to Pierre-Antoine.
Topic: Approve Minutes
Gregg Kellogg: https://json-ld.org/minutes/2022-08-03/
Juuso Autiosalo: Introduce yaml-ld#73 [scribe assist by Gregg Kellogg]
https://github.com/json-ld/yaml-ld/issues/73 -> Issue 73 Add section: How to read this document (juusoautiosalo)
Topic: YAML-LD
Juuso suggests to add issue 173 to agenda if there is time.
Gregg Kellogg: To complete work on the spec we need to go through certain steps:
... Define limitations on use of YAML Alias Nodes, for profiles (basic? extended?).
Gregg Kellogg: JSON profile: PR yaml-ld#12
https://github.com/json-ld/yaml-ld/issues/12 -> Issue 12 Convert JSON-LD to YAML-LD using standard YAML libraries (pchampin) UCR
Pierre-Antoine Champin: +1 To keep that out of the base profile
Gregg Kellogg: My feeling is to keep it out of the most basic profile. The more specific yaml-ld profile can go beyond this.
... What is undefined is what a processor should do if it operates under a basic profile and sees features it cannot handle.
... Either best effort or throw error.
Gregg Kellogg: In my implementation a basic profile works well and ignore unknown tags. Aliases need to be specified by an option.
Anatoly Scherbakov: It is not entirely clear how to implement the distinction of a profile. In my view we were going from yaml to json, then process that as json-ld. If we go beyond that basic profile, do we need to go beyond regular processors because we need to support special tags and to handle anchors/references.
Pierre-Antoine Champin: My two cents: other profiles would not need dedicated yaml processors; specific yaml constructs would need to be intricately processed, e.g. a string with a specific tag would be translated into a specific value object with a specific datatype.
Gregg Kellogg: In JSON-LD 1.1 we specifically created an internal representation in order to support e.g. a YAML processor. A YAML-LD processor would create this internal representation, not a JSON structure.
... A YAML processor could create, natively other datatyped values.
... You would not need to quote those types of things. YAML tags allows to define other datatypes, and an extended profile would define how to interpret that as an internal JSON-LD representation.
... Almost all non-RDF algorithms should work to create general RDF literals. That doesn't affect any of the algorithms until serialization time.
... A use-native-types option tells a processor to allow these and support more native values beyond what is available in JSON.
Anatoly Scherbakov: So a piece of software needs to be forked or extended to parse more specific YAML features?
Gregg Kellogg: Yes to do an extended profile we might do so, but another way to do so, as suggested by Pierre-Antoine, it may be done by putting the burden on the YAML-LD to emit JSON-LD expanded form for specific tagged values in the YAML source.
... So the tagged values would produce value objects. The reason I shyed off from that was that it wouldn't support clean round-tripping.
... So you would need that in the context instead of in the, by the YAML-LD work, extended internal representation.
Anatoly Scherbakov: So the extended profile promises more. So if the internal representation knows more about how the data looked, we can in certain cases reproduce the particular YAML constructs. Probably this excludes the possibility to roundtrip anchors though.
.... So the extended representation gives us more for the extended profile to be roundtrippable.
Gregg Kellogg: Yes, you could expand an internal YAML-LD and compact it and get back the same. No, aliases can probably not be maintained.
... Only if you serialize the exact same memory object, if it detects that the same object is being serialized in two places.
... Round-tripping those structures is outside our scope.
Anatoly Scherbakov: Sounds logical. Same situation in Python.
Gregg Kellogg: If we use these as parameters, we have a way to extend the document to describe these things.
... We need to spell out e.g. using the I18N namespace, so go beyond XSD to allow for more native datatypes.
... Whether the document itself has a processing instruction for YAML-LD we can discuss further.
Gregg Kellogg: Also, the points of defining extension points to JSON-LD API and a full test suite needs to be addressed.
... It would be great to see some contributions here.
Anatoly Scherbakov: Is there any work plan written down anywhere?
Gregg Kellogg: I could create a proposal to adopt a work plan, and determine how we want to use github to address these steps, doing PRS, and/or using milestones.
PROPOSAL: adopt the work plan as laid out in the agenda
Gregg Kellogg: +1
Ted Thibodeau Jr.: +1
Anatoly Scherbakov: +1
Pierre-Antoine Champin: +1
Niklas Lindström: +1
Benjamin Young: +1
David I. Lehn: +1
RESOLUTION: adopt the work plan as laid out in the agenda
Gregg Kellogg: We'll use this as a basis for our time at TPAC.
... We have 4 hours. We could spend the first 2 hours for YAML-LD.
Anatoly Scherbakov: Regarding using Github issues and projects; I usually like small completable issues.
... To easier organize your time for participation. Something that takes more than a day might get postponed since it cannot be planned into a working day.
Gregg Kellogg: Milestones are a good way to keep things linear over time.
Anatoly Scherbakov: With github I've only used issues, but I assume there are kanban-like means for organization as well.
Gregg Kellogg: For organizing if we create a meta-issue for it, we can attach tags and sub-issues to keep track of things.
... I'm open to other ways to manage this work too.
Benjamin Young: We used issues mainly, in a fairly loose setup, to organize testing and recording what needed doing and assigning issues.
... I'm for using projects. Anyone who've worked with W3C groups knows that deadlines will probably move, since this is often [work beyond regular work days].
... Its up to us to call for participation and let people manage their time.
Anatoly Scherbakov: Regarding the TPAC, could you explain more about what is is and for regarding the regular W3C process.
Gregg Kellogg: W3C has a technical plenary (TPAC). It is held 12 september in Vancouver Canada. We have a 4 hour group slot for YAML-LD.
... This is an opportunity for W3C groups to meet and work together. Since we're still in a pandemic, it will be a hybrid meeting to allow for remote participation. There is a doodle poll linked from the agenda (it had to be recreated so please fill in again).
... Other W3C groups can join too so we can work in a wider context. For instance the payment group relying on JSON-LD.
... This is a timeslot for us to get a lot of work done, and possibly meet face to face. It is an opportunity to get a lot of progress both for YAML-LD and JSON-LD-star. (RDF-star will also participate at TPAC.)
Anatoly Scherbakov: Thank you! I hope to join virtually, and on site in future time. Is there a link for the TPAC agenda?
Gregg Kellogg: [Pasted agenda link].
... People can present things as well.
... opportunity to present the current work and create liaisons with other groups.
Gregg Kellogg: Not so much papers but for slides about a topic you could work on during the TPAC [correct?]
Gregg Kellogg: Tapic: issue yaml-ld#73
https://github.com/json-ld/yaml-ld/issues/73 -> Issue 73 Add section: How to read this document (juusoautiosalo)
Juuso Autiosalo: A section on how to read this document would be beneficial to set up the rest of the document. For instance the audience, and the prerequisites for understanding the specification. What we require readers to know before reading the YAML-LD (just as JSON-LD requires familiarity with JSON). Do we require familiarity with YAML and JSON-LD?
... As reference, the JSON-LD does not require knowledge of RDF.
... Is this a conscious choice? We need to be clear if knowledge of JSON-LD is needed.
Anatoly Scherbakov: A very valid point. In my POV YAML-LD is an effort to democratize linked data. Thus it would be inhumane to require readers (students, doctors etc) to read the intricasies of JSON-LD syntax.
... Some people believe the JSON-LD spec is too complicated. I do not wholly agree; it is a honking great idea. But certain parts are difficult. It would be an obstacle for YAML-LD.
Gregg Kellogg: Parts of the spec should not require any deep understanding of JSON-LD. In a similar way not all who use JSON-LD knows all details of the spec. For instance a primer should be produced for this purpose. But the full spec, with profiles etc. would be impossible to understand without the JSON-LD syntax and API spec.
... Compare to how many use HTML who have not read the full HTML spec.
... So a YAML-LD Primer would be good.
... A "how to read this document" section would be great to see a PR for.
[Juuho and Anatoly both are interested in writing that section.]
Anatoly Scherbakov: As a separate document?
Gregg Kellogg: First include this as section of this spec. We might let the CG take up this work at some point to take the reports towards a recommendation. A rec trac could split out a Primer, API and profiles documents. But for now lets keep them in a single document for now.
Anatoly Scherbakov: Agreed. It eases management.
Benjamin Young: I love the intent that YAML-LD would increase the use of LD. A Primer would be great.
... I've been worried about a far more complex situation if advanced profiles. But having this point of view to ease adoption is good.
... Lets keep promoting this tech as simple and obvious. And address what is perceived as complex.
Gregg Kellogg: Agree. Something for the use case document.
Topic: TPAC
Gregg Kellogg: Call for presentations at September 12 TPAC meeting
Pierre-Antoine Champin: I can definitely prepare something about RDF-star
Gregg Kellogg: Participation poll: https://doodle.com/meeting/organize/id/aMj3LPBb
Gregg Kellogg: Please indicate your interest (whether local or remote).
Topic: Next call
Ted Thibodeau Jr.: Next call is Aug 31, can't be Sept 31 (as that doesn't exist)
Gregg Kellogg: Next call on August 31