The W3C JSON-LD Community Group

Go Back

W3C Logo

JSON-LD CG Telecon

Minutes for 2022-09-12

Present
Orie Steel, Dominik Tomaszuk, Joost van Ulden, Ivan Herman, Ted Thibodeau Jr., Phil Archer, Mahmoud Alkhraishi, Alexandre Bertails, Charles Cunningham, Benjamin Young, Mike Prorock, Kristina Yasuda, David I. Lehn, Geunhyung Kim
Chair(s)
Gregg Kellogg
Scribe(s)
Charles Cunningham, Pierre-Antoine Champin, Phil Archer, Manu Sporny, Gregg Kellogg
Agenda
https://www.w3.org/events/meetings/6b900451-f0a7-46b0-8668-3cc20e0b026c
Topics
  1. Introductions
  2. YAML-LD
  3. Issues
  4. Conformance tests
  5. Issue 63 - YAML Streams and JSON Sequences
  6. YAML-LD Datatypes
  7. YAML-LD Primer
  8. JSON-LD-star
  9. JSON-LD 1.1 API
Resolutions
  1. merge PR 78
  2. close issues 11 and 55 as "won't fix"
  3. close issue 42 as out of scope
Charles Cunningham is scribing.

Topic: Introductions

Mike Prorock: Mike Prorock, one of the co-chairs of the Credentials Community Group, working on Verifiable Credential work items, doing JSON-LD / linked data items
Phil Archer: Phil Archer, GS1, RCH WG, canonicalizing your stuff
Pierre-Antoine Champin: From W3C, co-editor with Greg on JSON-LD 1.1
Alexandre Bertails: Alex from Netflix, doing GraphQL federation
Pierre-Antoine Champin is scribing.
Charles Lehner: independant observer, DID and VC person
Charles Cunningham: Charles Lehner, independent, VCs/DIDs related
Gregg Kellogg: Greg Kellogg, co-editor of specs
Ivan Herman: Staff contact previously for this WG and for DID WG
Joost van Ulden: From Canada, cross-border work, as observer
Javad: observer
Kdeangs1: working with Phil
Mahmoud Alkhraishi: Maven Net, supply chains
Anatoly Scherbakov: Republic of Romania. Interested in YAML-LD for bringing linked data to the mainstream, for people to use semantic data in their daily lives
Benjamin Young: Co-chair of JSON-LD WG that was and is about to be again - and of community group, working for John Wiley and Sons as a principal architect
Dan Burnett: Daniel, working at Google, TypeScript, privacy
Dominik Tomaszuk: Dominik Tomaszuk, extremely interested in YAML-LD
Jeff Waters: AC Rep for DISA, just joined this last week
... I was a rep in the old days when we were members earlier on. A great fan of JSON-LD and all the work you all are doing; interested in catching up
... Interested in this being used more in our organization/agency; looking forward to advocating
David I. Lehn: David Lehn from Digital Bazaar, working on JSON-LD since it started. doing implementations in JavaScript and Python
Juuso Autiosalo: Juoso Autisado. post-doctoral researcher on digital prints
... interested in describing digital prints with JSON-LD and hopefully YAML-LD in the future
Orie Steel: Orie Steele, CTO and co-founder of Transmute; working on verifiable credentials for supply chains; IETF COSE and JOSE cryptographic representations
... YAML-LD and pieces; interested in overlap of formats here at W3C
Ted Thibodeau Jr.: Ted Thibodeau, Open Link Software, working here for ~20 years; distributed identity, RDF; you'll see me in a group
Timothée Haudebourg: Timothée Haudebourg..., working on Rust JSON-LD library, at Spruce
Kristina Yasuda: Kristina from Microsoft, co-chair Verifiable Credentials WG
Masaki: WebRTC, joining here for my curiosity
Geunhyung Kim: Geunhyung Kim, JSON-LD linked data ecosystem
Seukyoon Kang: Seukyoon Kang, from South Korea, first time at W3C, interested in many things
Gregg Kellogg: Welcome everyone, thank you for meeting with us today.
Gregg Kellogg: We have been meeting every other week on Wednesdays; WG page has more info; everyone is welcome to join
... Mostly discussing YAML-LD, but the community is for everything discussing JSON-LD
Gregg Kellogg: Arguably, JSON-LD is one of the most successful linked data formats ever, which probably surprises people working on RDF/semantic-web standards all this time...
... Over 43% of all websites have some JSON-LD
... Web Data Commons reports...
... JSON-LD is used as a native way to represent RDF, but also simply because it's JSON.
... For describing SHEX expressions, tabular data, and a number of other places.
... By and large most people interacting with JSON-LD don't realize they are interacting with a linked data format. That's by design, to make it easy for people to use it
Benjamin Young: I think a lot of that growth is attributable to schema.org, and its "rich snippets" for search engines
... But also a huge growth of publishers (e.g. John Wiley and Sons) using it...
... and for web annotations.
... Our e-reader includes Apache Annotator
... Embedded use cases...
... Over the last 5-6 years it's grown exponentially,
... and into places we didn't expect initially
Gregg Kellogg: I think much of the success of JSON-LD is largely tied to the success of schema.org - as one of the 3 recommended serializations for expressing info about schema.org

Topic: YAML-LD

Gregg Kellogg: YAMl-LD is basically a way of expressing linked data in YAML.
... It does that by basically mirroring what JSON-LD provides.
... JSON and YAML are largely interchangeable. YAML is commonly used in configuration files - more human readable.
... For example, a YAML document may have a context declaring a common vocabulary; that's used to determine all the lines that come after that.
... In this case I've used a Turtle interpretation. Usually we use literals...
... [slide 15]
... Quoted string is because many YAML interpreters interpret certain values in certain ways. For date formats though, that may be obsoleted.
... Extended YAML-LD. [slide 16]
... Basic YAML is mostly 1:1 with JSON.
... YAML has more funtionality. Effectively, data types for scalar values.
... In this example we provide a data type for our date format, that allows expressing an RDF literal.
... It's under debate...
... YAML allows the ability to tag nodes with a URI; that's used for internal formats to describe things as integers, booleans, maps, arrays.
... It's extensible by declaring a tag at the top, like a prefix in Turtle, or a term in a context in JSON-LD.
... This exists outside JSON-LD. An open issue is how to best take advantage of these capabilities.
... YAML also allows you to share nodes by putting effectively a node label, and then reference it later on.
... Microdata has a similar capability.
... This was addressed in JSON-LD. We have some ways of including references in JSON-LD but typically only to nodes rather than scalars.
... We can actually create references to scalars in YAML.
... As noted in the shortcomings, I've used a string representation for the XSD URI.
... rather than a hash. Most tools don't allow a hash, so need some escaping. %23 is equivalent to #.
... There is also a potential to use other data types for expressing things like language. In JSON-LD v1.1 we introduced a proposal for one way of representing language - in particular, text direction - in JSON-LD - and therefore in RDF.
... That is to use a URI which encodes in it a language and a text direction.
... One shortcoming of RDF is it doesn't have the ability to encode text direction, like other formats such as XML do.
... Ivan is responsible for coming up with the i18n namespaces with a semantic such that you can append information to the URI, such that you can extract both language and text direction.
... That means you can only encode language.
... e.g. en-US could be encoded using this mechanism
... JSON-LD 1.1 introduced the concept of an internal representation. Rather than operating entirely on JSON concepts, it operates on a more abstract representation of the structures that are encoded in JSON. Arrays, maps, numbers, strings, boolean values, and null.
... Here we see (slide 18) a representation in YAML on the left that might appear using these various capabilities
... At the top is a document with a tag for the specific version of YAML. It includes a mapping, encoding the scalar values for context, which represents a map, which has a scalar value @vocab, which has a value which is the namespace.
... By using YAML you can use the internal structure
... to turn into JSON-LD. Can also use anything that can represent these types, like CBOR.
... to turn not into JSON but into the internal representation used by JSON-LD API mechanisms such as expand, compact...
... Then can serialize back to YAML or JSON.
... That provides our basic interoperability between these formats.
Javad: 2/3 small questions... Is the format fixed?
Gregg Kellogg: Undergoing active development. Nothing is fixed; seeking more feedback and better ideas
Javad: Does this make the processing more expensive, since have to process the whole value?
Gregg Kellogg: Yes, this is why we separated the basic YAML-LD from the extended YAML-LD
... You should be able to implement the basic YAML-LD JSON profile... But there are more capabilities that YAML provides that are of interest to people to be able to express more JSON-LD
... The ability to use tags potentially reduces the dependency on a (JSON-LD) context.
... Right now may use a term definition for date; that has a type when used as a property; this provides a different way of doing that, that's built into YAML.
... Another important capability is to have references to nodes
Javad: From a sensor perspective, sensors could send JSON/RDF-annotated data. Every time there is a reading, they just send that part - a partial record
... Is there a way at the record level to refer to an IRI to say which document something should be a part of?
Gregg Kellogg: This is related to NDJSON. Line-delimited JSON; each line is its own JSON document
... YAML content has the concept of a stream composed of many documents. How do you relate a stream of documents to JSON which does not have a stream concept (no way of talking about multiple documents); that's a shortcoming we should consider; this might be a way to deal with sensor networks that might want to output complete information that is about a subset of a document, by line
... The way to associate it would be like in JSON-LD; an object with an identifier, properties and values
... The data model being an RDF dataset means that the effect of processing these documents is additive
... So you are building up a dataset after processing each of these
... Similar to have embedded script tags in HTML are treated
... The way JSON-LD algorithms currently treat it is that all the documents are basically serialized into an array
Mike Prorock: About i18n, lang tags... is anyone looking at training models like Common Crawl with that? I'm doing natural language processing, this comes up a lot...
... The language flag, when looking at multi-lingual models, seems like it could be helpful
... Anyone doing that, other than for display hints?
Ivan Herman: No (short answer)
... What really led to this issue - I don't think this would be easy to train - There are situations where you have a text, say in Hebrew, in which you mix latin characters. These bidirectional things are always the stumbling block. The fact that these could not be expressed in RDF came up time and time again.
... Our arms were twisted in JSON-LD by assuming we solved it
... I don't know if training models handle these edge cases
Mike Prorock: Knowing you could attach the tag is part of the factorization
Gregg Kellogg: Providing this... is likely not a primary source. You might be trying to extract truth from unknown sources... text direction...
Mike Prorock: And knowing the intent of the author. e.g. a description about something... what did you mean by that? Are there additional hints?
Manu Sporny: Question... You were talking about going from JSON to the internal JSON-LD model and back out to YAML...
... Have you looked at the way CBOR-LD skips that intermediate step? Goes straight from CBOR-LD to JSON-LD without the intermediate step
... Do you feel we have now a generalized mechanism to go through the internal representation - or you think going through another model is viable?
Gregg Kellogg: JSON is a serialization format. Algorithms can't really operate directly on the serialization; they can operate on the representation of the serialization
... We operate on numbers, not the serialization of numbers, for instance
... The internal representation was put in 1.1 as a way of being able to operate on "objects" to do programming.
... You might be pointing at an issue that is under active discussion... Is that internal representation sufficient?
... i.e. are arrays/maps/numbers/strings/booleans enough? certainly is for JSON-LD interop. For a basic profile to be able to express in YAML exactly what can be expressed in JSON.
... But there are things that can't be expressed in JSON. like a native datetime format. similar in CBOR.
... So I have a proposal for an extended representation - to be able to convey other primitive data types - specifically, RDF literals
... This date format, for instances... where we see xsd:date of "2022-09-12", you could see the RDF literal for that
... If that is native, it would be conveyed through the JSON-LD algorithms as-is.
... The algorithms where that is not true is to/from-RDF.
Manu Sporny: Is the internal representation mandatory? CBOR-LD in practice doesn't; just reads bytes and translates CBOR
... If we were to standardize CBOR-LD, would we need to define how it goes through the internal representation?
Pierre-Antoine Champin: Are you saying it goes through the CBOR-LD representation to CBOR without the internal representation?
Manu Sporny: Yes, It's a straight translation... I wonder if we need language that is is okay, or if it's not
Gregg Kellogg: I think it's okay, like the basic YAML-LD representation
... There might be some advantages of instead targetting an internal representation, if this group decides to go through some extended mechanism to make fuller use...
... This date would expand into a value object, which includes a value and a type component.
... Problem is that in a compacted format, you don't know without processing, whether the value has e.g. type "date"
... When re-serializing back to JSON, you can't serialize to string without processing the context
... By maintaining a more native representation... JSON-LD currently just passes through numbers... There might be some advantages if you want to deal with CBOR structures that are not simply expressed in the base JSON typing.
... I don't believe it's required to define mapping to/from the internal representation if you don't need to take advantage of those features
Manu Sporny: So maybe a rule of thumb is that if you don't need to do JSON-LD processing with those algorithms, you don't need to go through the internal representation
Gregg Kellogg: The APIs... may say turn into the internal representation by parsing, then the last step is implied to serialize - implied e.g. by HTTP Accept headers
... YAML-LD may have to detect application/ld+yaml to parse, then serialize back to JSON
... Presumably CBOR-LD has similar requirements
Gregg Kellogg: This goes on (slide 19) to how we might represent an extended YAML-LD profile.
... The example on the left is what a JSON representation of YAML might be.
... We have a couple scalar values there with type information. e.g. name is xsd:string, date is xsd:date
... One way of dealing with these expanded values is simply to represent them as value objects.
... That is the natural way you might do it. But in order to take advantage of the JSON-LD context... that might require reserialization, if date is defined with xsd:date, we're not doing it that way if we recompact it we now have it with a string object rather than a value object.
... Having done that I've sortof lost the ability to turn it into YAML using these node tags
... Although the advantage is that is doesn't require change to the internal representation, it introduces some disadvantages for how we manipulate the data.
... The alternative is that we carry these extended values, e.g. rather than using a value object we use a literal object, encoding things you expect from a literal (value, type, language)
... Advantags is that it goes through JSON-LD algorithms unchanged, since it only deals with expanded values (ignoring string values of other types)
... but it's no longer representable as JSON; requiring us to extend the internal representation to do that.
... There are also thoughts of doing this on IRIs and blank nodes.
... That's our introduction to what the group has done so far
... We have a number of open issues
... Want to move forward on this open pull request...
... PR adds a section on how to convert YAML into the internal representation
... Targetting a broad audience, for people to understand what YAML-LD is.
... One issue is to split out into a "YAML-LD primer"
... for people wanting to use it without getting into the algorithmic details
... YAML-LD is fundamentally YAML. Most people will interact it with it as such, rather than as a linked-data format
Phil Archer is scribing.
Gregg Kellogg: IMO, we should use the extended internal representation
Gkellogg works through draft spec
Gregg Kellogg: Turns YAML into the internal representation, which takes advantage of the YAML spec to create the internal graph
... the tools such as {} do provide entry points into this internmedia representation that provide more of the sturctured representation, no interpretation of data types
... this presumes that mechanism is available
... so process first involves creating interal representation graph then interpreate that
... so YAML does have the capability of describing multiple docs (YAML stream)
Gregg Kellogg: JSON doesn't have a way of doing that
... this is an area we need to explore further
... we have a need to describe multiple different docs
Gregg Kellogg: [Continues through doc]
Gregg Kellogg: In JSON a map is an object
... Recusive steps here, create an array composing of the constituent parts
... YAML has a mapkey that can be any other node type
... YAML-LD restricts that a string scalar. Anything else wouldn't be possible to deal with the JSON-LD algorithms, so that's a concession
... by doing this recursively, you get back to the internal mapping
... Interpreting scalars... this is where we get into some more changes from the base.
... We keep the notion of an extended YAML flag
... So processor has to be running in an extended YAML mode
Gregg Kellogg: Basic YAML types are used for tag namespace
... might be an str for a sstring etc.
... there are other primitives that YAMl provides
... Then we have some special processing.
... If in the i18n namespace then it's processed differently
... so you can interpret the "_" character
Gregg Kellogg: YAML distinguishes some number types - YAML distinguishes integer and float, JSON does not
... Could have a float that looks like an integer. Should be able to serialise back out as a float, even it's an integer
Gregg Kellogg: Code for alias nodes. Introduces potential for looping
... An alias cannot refer to a labelled node before it's been encountered, but might have a recursive set of nodes.
... YAML has a way of dealing with that so we're OK
Gregg Kellogg: Then there's the turning the extended internal rep back into YAML
Gregg Kellogg: There's an open PR here that's a month old now. So an action is whether we want to merge this PR
Gregg Kellogg: Or what do we want to do with an extended internal rep?
Gregg Kellogg: Invites opinions
Gregg Kellogg: If we elect to go ahead and merge, we can still change it.
PROPOSAL: merge PR 78
Ted Thibodeau Jr.: +1 Merge #78 and iterate with smaller changes as needed
Gregg Kellogg: +1
Pierre-Antoine Champin: Just to comment on bigbluehat's comment - yes, smaller PRs are better
Benjamin Young: +0 Still concerned about the $ prefix...but we can address that as a follow-up
Ted Thibodeau Jr.: (This would be yaml-ld #78, not json-ld.org #78)
Pierre-Antoine Champin: +1
Juuso Autiosalo: +1
Gregg Kellogg: In general yes. Each small would be smaller. I apologise for the grand PR. Apologies to TallTed as there are so many lines to review
Gregg Kellogg: What is proposed here is already implemented in my distiller
... my time is becoming more and more scarce
Dominik Tomaszuk: +1
Benjamin Young: We're for ever in your debt Gregg :-)
Gregg Kellogg: It provides a more fleshed-out spec
Ted Thibodeau Jr.: Soooooo much easier to do via github than via the old w3 wiki!
Pierre-Antoine Champin: This is will make it easier now that we have a lot of things put down for future dicusssion
Benjamin Young: It means we have more to complain about
Mahmoud Alkhraishi: +1
David I. Lehn: +1
Mike Prorock: +1
Manu Sporny: +1 To merge PR78
Timothée Haudebourg: +1
[Some discussion about who can vote in a CG]
RESOLUTION: merge PR 78

Topic: Issues

[Discussion of what to discuss]

Subtopic: https://github.com/json-ld/yaml-ld/issues/55

Gregg Kellogg: Wants to talk about @-keywords with $-keywords
Gregg Kellogg: Why not allow YAML to work with $? Was a suggestion
Ivan Herman: Why not use the € sign?
Timothée Haudebourg: €Ontext
Gregg Kellogg: People have pointed out you don't really need to do this except for context
... Benjamin went further and suggested no character was necessary
Gregg Kellogg: @ Container can only be used within a context, and within a context defn, you can't use aliases
... However, schema.org ... one way of disposing of this issue is by suggesting that by publishing this context, under json-ld, simply use this context
Benjamin Young: 1+
... You can't create a context in YAML-LD without quotes but that's a specific context
Manu Sporny: I wonder whether this is a big issue
... We talked about this in the JSON-LD WG. We started with $ but the jquery people didn't like that.
... Mist things that we're seeing are aliasing id and type
... schema.org is an exception, but even they alias id and type
... So I'm not sure who is being impacted by this
... It feels like it is not being driven by data
Manu Sporny: My suggestion is that we don't do anything about this until someone tells us we need to.
Manu Sporny: Bigbluehat is always talking about a default context - that could be a processing instruction
Gregg Kellogg: No one's talking about a default context
Manu Sporny: We should act if we have real data
Benjamin Young: I agree with Manu
Benjamin Young: I didn't want to see another prefix happen. I didn't want YAML-LD grow weird features
Benjamin Young: ... I feel like this is a nuke to kill a chicken. It's not a big problem
Benjamin Young: You can alias the main terns with or without a prefix to suit your use case - we can say that, to help avoid implementers coming up with their own ideas
[Apologies to bigbluehat I missed some of that]
Gregg Kellogg: This was proposed by members coming from YAML and were more identifying with the types of problems that YAML people face
... IS there anyine here that can represente that position?
[Crickets]
Pierre-Antoine Champin: I'm on the side of people coming from JSON-LD, but if I can play devil's advocate...
... I think the ambition is to open LD to other people who are not using it currently
Pierre-Antoine Champin: The initial idea was to have this magaic transformation from $ to keywords
... Some people prefer standard mechanisms
Pierre-Antoine Champin: From this start, we kept looking for something that was a different prefix that wasn't a prefix
... I;m all for getting rid of the $
... That works well in the data but not in the context
... Newcomers will not write context
... The people who do write contexts can handle the complexity of quoting stuff
Gregg Kellogg: I'll also point out that using YAML-LD does not mean that you're entirely in the YAML ecosystem. a YAML doc can reference a JSON-LD doc
... with the YAML extensions, it would be possible to mix and match
... take account of accept headers etc
Gregg Kellogg: I'd like to propose that we close issues 11 and 55
Manu Sporny: +1 To close issues 11 and 55
... perhaps consider them for a best practices doc
Ted Thibodeau Jr.: +1
Benjamin Young: Are we removing these items? I think the $ got merged in 78?
Gregg Kellogg: PR 78 doesn't include any $ signs
Pierre-Antoine Champin: I think there are in the examples
Benjamin Young: As long as closure means removing
Juuso Autiosalo: +1
Gregg Kellogg: It means we're going to move on
Benjamin Young: +1 To close "wontfix" (at least not now ;))
Timothée Haudebourg: +1
PROPOSAL: close issues 11 and 55 as "won't fix"
Benjamin Young: +1
Gregg Kellogg: +1
Pierre-Antoine Champin: +1
[Discussion of we're resolving]
David I. Lehn: +1
Timothée Haudebourg: +1
Juuso Autiosalo: +1
Mahmoud Alkhraishi: +1
Ted Thibodeau Jr.: +1
Anatoly Scherbakov: +1
Ivan Herman: +1
Charles Cunningham: +1
RESOLUTION: close issues 11 and 55 as "won't fix"
Gregg Kellogg: As for the convenience context we can revisit that when we come to the best practice

Topic: Conformance tests

Gregg Kellogg: We don't have any! One suggestion was to re-create the JSON-LD tests for YAMl-LD. I think that would be be overkill
Gregg Kellogg: We do need conformance tests
... Having set up a basic direction, I think we can use basic conformance tests
... And encourage more implementations
... I'd love to see json-ld.js used as a basis for YAML-LD
... So issue 20 is a call for contributions
Gregg Kellogg: I can put forward the basic infrastructure but it tends to be a lot of fiddly work creating hte inputs and outputs

Subtopic: https://github.com/json-ld/yaml-ld/issues/20

Subtopic: https://github.com/json-ld/yaml-ld/issues/42

[Apologies for mess]
Gregg Kellogg: My proposal is that we close this as being out of scope
... It's about how many spaces to leave off, etc. These are things that serialisers define for me
Ivan Herman: These are religious discussions
Gregg Kellogg: Should we have some way of representing how it might be serialised?
... YAML has more capabilities, meta tags etc.
... I don't think it's a duty of this group
Pierre-Antoine Champin: The same kind of question could be asked of JSON. Has it ever been raised?
Gregg Kellogg: Only in canonicalization
Ivan Herman: That has a clear reason, yes
Ivan Herman: But I don't remember this being discussed in the JSON-LD list
Pierre-Antoine Champin: The RFC for c14n of JSON is about JSON, not JSON-LD
Gregg Kellogg: My proposal is that we close this as being out of scope
PROPOSAL: close issue 42 as out of scope
Pierre-Antoine Champin: +1
Ted Thibodeau Jr.: +1
Gregg Kellogg: +1
Juuso Autiosalo: +1
Timothée Haudebourg: +1
Ivan Herman: +1
Benjamin Young: +1
David I. Lehn: +1
Dominik Tomaszuk: +1
RESOLUTION: close issue 42 as out of scope

Subtopic: https://github.com/json-ld/yaml-ld/issues/54

Gregg Kellogg: This involved melding JSON schema with contexts
... There has been some desire to use context as a schema [paraphrase]
Manu Sporny: Every time we've discussed this, we've decided to keep them separate
... We don't want to commit to a schema language. There are different schema languages for different serialisations
Manu Sporny: In the JSON-LD world, even though schema and context play nicely together, I worry about other shape languages and if we commit to using schema for context, we might get into trouble
... So I don't see an argument for mergig the two
Ivan Herman: I may be out of touch by now but the problem I have with JSON schema is that it's not stable. We offered those folks a W3C WG if they're ready.
... We were turned down as they were on version 7, and from one version to another they may not keep interop
... It's not a stable partner so we can't use it normatively
Orie Steel: There is also OAS, which builds on JSON Schema and defines APIs.... very useful.
Benjamin Young: I would echo the same things. It seems to be a recurring problem with YAML-LD. All these weird appendages that seems to scrape in other issues
Orie Steel: +1 To JSON Schema / OAS / YAML stuff being its own spec, not directly related to YAML-LD
... It might be cool, but it would be its own spec and not part f YAML
Orie Steel: We'll keep using JSON Schema as it is... its working for us.
Benjamin Young: There would be high hills to climb through JSON-schema's lack of stability (not for lack of interest)
Benjamin Young: It's not YAML-LD related as such
Orie Steel: +1 To embedding LD in OAS not being YAML-LD related.
Gregg Kellogg: I'd say that we should close this as being out of scope
... schemas are closely related to JSON-LD. If there were a subgroup that wanted to pursue this, OK, we can create the repos
Ivan Herman: I'd have the more fundamental proposition. It comes back to the misconception - when people look at an RDF vocab, they see it as a constraint. It's not, it's a licence to infer
... A context is a mapping from JSOn to the RDF
Orie Steel: I'm happy to continue to merge JSON Schema + JSON-LD in CG work :) ... as I said, its been working fine for what we are doing.
... That's very different than a schema language that constrains what is and isn't valid.
Manu Sporny: +1 To what Ivan is saying
Ivan Herman: So even if schema were stable, it's not the right choice as it mixes up vocabs and context. Not the same
Timothée Haudebourg: +1 Totally agree with that
Pierre-Antoine Champin: Big +1 that this has noting to do with YAML-LD
... but I must disagree with what Ivan said. There is indeed a misconception of what RDFS etc. do
... this misconception has been reduced now that we have SHACL/ShEx
... we do agree that JSON-LD contexts are not vocabs
Orie Steel: +1 To comfort defining vocabs though schemas... thats what we do.
Orie Steel: But thats not what YAML-LD is about...
Mike Prorock: +1 Orie
Orie Steel: It might be what OAS-LD would be about...
Pierre-Antoine Champin: It so happens that people are more comfortable sharing a voc as a constraint. I don't thnik there's a probem to map ...
Ivan Herman: That's not what I said. Is it possible to combine a JSON schema with SHACL? I'm not sure. Trying to combine those is likely to be difficult.
Ivan Herman: They sort of do the same thing - setting up constraints. But that's not the same as a JSON-LD context
Pierre-Antoine Champin: I agree with that
Pierre-Antoine Champin: The value I see in trying to bring together JSON schema and JSON-LD context - JSON schemas are used to define shared vocabs.
Pierre-Antoine Champin: On the WEb, those terms can have an IRI. They may not be considered an RDF voc, there's low hanging fruit there
Pierre-Antoine Champin: It could make it easier for people to adopt JSON-LD
Mike Prorock: +1
Manu Sporny: I want to agree with PA - this keeps coming up. The traceability folks have created the ability to take a schema and use that as a context
Orie Steel: Example: https://w3c-ccg.github.io/traceability-vocab/openapi/components/schemas/credentials/BillOfLadingCertificate.yml ... --> ... https://github.com/w3c-ccg/traceability-vocab/blob/gh-pages/contexts/traceability-v1.jsonld#L250
... I think we're going to keep seeing it
Manu Sporny: We are seeing a pattern where people want to create a shape along with a JSON-LD context
Manu Sporny: It's a large discussion than just YAML-LD. It's an ecosystem discussion
Manu Sporny: This is for the broader LC community
Mike Prorock: I think it is a broader ecosystem need. VCs using JSON-LD makes sense, but there's a need to constrain what the VC can contain
Phil Archer is scribing.
Phil Archer: One other thing that might come up in RCH is canonicalization against a shape
... take some data and some shape, and output a canonical form that excludes anything that's not in the shape
Gregg Kellogg: This sounds like framing
Gregg Kellogg: Maybe there's something adjacent to framing that can be used
... Might be useful for output formatting
... How do I order the properties of an object etc.
Gregg Kellogg: JSON objects are unordered
... Lots of discussions about this
Gregg Kellogg: I don't think there's any action we can take on this issue, except to point back to this conversation for future reference
Orie Steel: I feel like we have confirmed that "JSON Schema" and "OAS" are not related to YAML-LD.
Pierre-Antoine Champin: There's a comment from Orie that this is not a YAML issue specifically.
Manu Sporny is scribing.

Topic: Issue 63 - YAML Streams and JSON Sequences

Gregg Kellogg: Touched on this earlier, JSON-LD doesn't have concept of multiple documents. How did we deal w/ YAML streams? Treat each document in there as its own JSON-LD document and process accordingly.
Gregg Kellogg: JSON-LD defined as API, might need sequences API calls and recompose possibly, YAML-LD, compact things in stream, do them in sequence? Seems that this needs to bounce back up to JSON-LD. Is there an analog?
Pierre-Antoine Champin: My concern regarding that, I can see a number of use caess, sensor use case earlier.
Pierre-Antoine Champin: I'm not sure if we can come up with a unique way of dealing with those things. That might be just a lack of imagination.
Benjamin Young: Yes, would like to see this happen, not expressly YAML related... YAML's origin is out of mime documents and email containers, where you were sending a bundle that was all inerrelated. First document was foundational, other documents were attachments.
Anatoly Scherbakov: Thank you very much all, I will unfortunately have to leave. It was quite interesting to participate, thank you again!
Benjamin Young: Newline deliminated JSON and JSON -- server sent events, event notifications, JSON - what's coming next... YAML multidoc is understood as a unit together. Context documents being sent together in stream. For most newline deliminted JSON, interesting things to explore here, what's been done for Link header for example on bare JSON documents.
Pierre-Antoine Champin: YAML streams in the YAML spec: https://yaml.org/spec/1.2.2/#92-streams
Benjamin Young: For example, if you start w/ context, maybe that context applies to everything in the stream. Where should these happen, where shouldn't they happen, this isn't only about YAML.
Gregg Kellogg: There is a broader concept of LD streams, could have applications in JSON-LD, fits in nicely with YAML... but why not other formats, why not NTriple streams? One could argue that NTriples are another multidocument mechanism since all statements stand on their own.
Gregg Kellogg: There might be a notion of stream documents, each element of stream could have its own format. Does each have its own location? Even though this issue isn't about YAML streams, it begs for additional work for LD Streams and until that happens, with regard to this issue... there are two ways forward, 1) YAML-LD is only defined for streams in a single document, or 2) YAML-LD streams are treated the way multiple script elements are treated,
That algorithm creates an array, merges content to it, that's the only way you can really do this until something bigger/better happens.
Phil Archer: Linked Data fragments was similar.
Gregg Kellogg: Yes, it was, had more to do with SPARQL querying...
Gregg Kellogg: There was work done on JSON-LD streaming, but specifically took into consideration open pipe on which you were continuously interpreting.
Gregg Kellogg: These are all references that should be considered.
Gregg Kellogg: We can leave this for a future meeting noting this discussion.
Benjamin Young: JSON-LD Streaming note was about parsing a *single* JSON documents as it was streamed into the parser (which is very different than a stream of individual JSON-LD docs)--just to clarify relationships.

Topic: YAML-LD Datatypes

Gregg Kellogg: We were running against issues w/ existing YAML-LD tool set. Notion of having IRI tags, might be dealt with term within YAML namespace, interpret item as IRI, scalars treated as literals.
Gregg Kellogg: This is of less use given short syntax to create node reference, doesn't buy us much more than that.
Gregg Kellogg: We might be able to define a regex to refer to values, first time validation ... value interpreting as IRI.

Topic: YAML-LD Primer

Gregg Kellogg: There seems to be a desire to not over burden the specification with extra language, desire for Primer -- We will create a yamlld-primer, and yamlld-bp for best practices, We can then focus on each one.
Ivan Herman: We are fighting in another group to try and figure out a way to do multi-publilcation, let's not bring that here.
Gregg Kellogg: Does anyone have anything specific they'd like to have in a primer?
Gregg Kellogg: Convenience contexts?
Gregg Kellogg is scribing.
Manu Sporny: I'd argue against a Primer. I'm not sure if we have data on how much they're read.
Gregg Kellogg is scribing.
... If people want to know about it, they typically look at the spec, or Best Practices.
Manu Sporny: I don't know how often people read primers
... I'm not sure we have enough data to validate the effort needed to do this work. Instead, keep it in the spec.
... That content might be more useful at the begining of the document
... If you can't explain it in three n pages, then you probably haven't done a good enough job.
Ivan Herman: The OWL Primer was well received, but it was difficult work to boil those concepts down. There are cases where it works.
Ivan Herman: We are heading for a case where VCs will be several specifications, that might be a place where a Primer might work well. OWN is complex because there are 2-3 core specifications plus a bunch of additional things.
Ivan Herman: In this case, maybe it's not the case, YAML-LD might only need to be one specification. Then it becomes a matter of personal style.
Mike Prorock: Something inbetween, what is the audience, there is normal webdev folks, the other side is broader linked data developer... when you're coming in from normal enterprise stuff and they come into this, we've gota figure out how to bridge this concepts back here... there is not another resource to introduce people to this.
Mike Prorock: Who is the Primer for? Normal webdev folks for HTML end user facing content... vs. low level developers using this stuff.
Phil Archer: The first W3C spec I read was the RDF primer, which help me understood RDF... suggestion might be, with YAML-LD, could add to RDF 1.1 primer, there is a whole ecosystem here, LD always needs primers... why would you do this? Why is it better?
Mike Prorock: Yes, especially for people that were not around in the beginning, dealing with a new breed of developers learning Python/Java... they don't have the context, they don't even know what IRC is.
Ivan Herman: One thing I like in the OWL primer, how has the nice feature for 5 serializations of same concept, not all of them are RDF specific, but what they did is same trick as VC spec, you can choose which syntax you want to see... having Linked Data primer which puts together YAML/JSON-LD for example, can choose and compare like in the VC spec.
Ivan Herman: I think that's very helpful, not to do a YAML primer, but a Linked Data for the masses primer, that would make a lot of sense.
Gregg Kellogg: We need to come back to json-ld.org, its easy to add resources to there, the playground is invaluable, thank you Dave Lehn for keeping this thing going.
Gregg Kellogg: The efforts are appreciated.
Gregg Kellogg: Should we have yaml-ld.org domain? Could have it's own fork of JSON-LD Playground... some of upcoming work on playground might make it more suitable to do that... basic profile of YAML, to get that into something that works w/ jsonld.js -- given there's only so much developer time, having online resources might be better use of our time.
Pierre-Antoine Champin: Reconsider if we can put the thig in the front of the spec, unless there is a large amount of specs... we should consider the audience. It was pointed out how JSON-LD was deliberately made easy for end users even if it's more complex for developers. There are different parts of the spec, more for end user, JSON-LD API is more for end developers... that's one thing we should consider, Primer could address different audnece thatn spec itself.
Gregg Kellogg: These things are solved by people that step forward to do the work.
Gregg Kellogg is scribing.

Topic: JSON-LD-star

Pierre-Antoine Champin: RDF-star is an extention of RDF
... An RDF-star working group has been created; goal to integrate changes into the RDF specification
... A CG report has been published by the RDF-dev CG
... In order to support this, Greg and I have started working on JSON-LD-STAR
... Embedded nodes: a special node object representing a quoted triple
... You could state a triple whose subject or object is another triple
... Important to understand is that the statement is not "endorsed" by the subject
... In JSON, we allow the value for @id to be an object
... The rest is JSON-LD as usual
... The object of belief is this node object [looking at example]
... Triple-STAR... want to be able to both assert a triple in your graph, and also quote it as a subject of another triple
... Example: "Alice is working for ACME" ["Annotation syntax" slide]
... I want to say something about that fact
... that it's true since 2019, and the role is seniorManager
... In Turtle-STAR we could represent this with three triples in a row... This syntax here is more convenient
... New @annotation keyword - we decided to put in the object of the annotated triple
... Up to this point "@id": "#acme"... it's JSON-LD as usual. Then "@annotation": {... - this is a quoted triple generated from above
... It could be called metadata
... Property Graph model...
... Given the appropriate content, NGSI could be interpreted as RDF-STAR
Phil Archer: If I have another triple, i.e. working for ACME, does the annotation apply to both?
Pierre-Antoine Champin: No, only to one
Phil Archer: But I could make another?
Pierre-Antoine Champin: You would put it in another block
... If you want to annotate triples for the same thing, it has to be repeated. We kept that for RDF-STAR
... RDF-STAR is about talking about individual triples
... Arguably if you have the same annotation for multiple triples, what you are trying to do is annotate a graph, which is not in scope
... Some say RDF should be able to annotate whole graphs rather than individual triples
Gregg Kellogg: That's more what Notation 3 does
Pierre-Antoine Champin: Yes
Gregg Kellogg: Key is you have annotations applying to a relationship
... You can have as many things as you want in that annotation
... You can have other things in the object, but they are not related to that particular annotation
... You could say working for ACME Corporation - that would be fine - but the annotation only applies to that relationship
Kdeangs1: annotation applies to the predicate of workingFor... although you could join them together to make a complete statement, the ACME as a subsidiary is separate
Mahmoud Alkhraishi: Are there limits on what you can put on an annotation?
Pierre-Antoine Champin: Yes... the only thing you can't do here is to put an id
... The subject is the quoted triple.
... Except for that, we don't put any limit on it
Gregg Kellogg: Yes, in fact annotations can have annotations.
Pierre-Antoine Champin: Annotations on annotations, like in Turtle-STARR
Ivan Herman: More an RDF-STAR question than JSON-LD-STAR: In this case, are all the statements there valid RDF statements?
... Previously you said "Bob is a genius" - this is not asserted; in this case, everything is asserted?
Pierre-Antoine Champin: Right. Annotations are useful when a quoted triple in the subject position is also asserted
... Basically you don't want to repeat it; since you write it once to assert it, it seems natural to add those annotations after that, without having to repeat that statement in double-brackets
Gregg Kellogg: It's only when the quoted triple is in...
Pierre-Antoine Champin: Subject position.
Gregg Kellogg: If this was to be expanded out... You could have a quoted triple in the subject or in the object. In Turtle it only works in the object...? Is it symmetric in turtle-star?
... The triple has to be asserted, and has to be in the appropriate position?
Pierre-Antoine Champin: Yes, same as in Turtle
... "Alice is working for ACME" ... "since 2019"
Ted Thibodeau Jr.: This will almost certainly be more easily comprehended by explaining via Turtle-star notation, and then presenting comparable JSON-LD-star.
Ivan Herman: We began to discuss this yesterday. If the whole thing there is part of a named graph, that means that all the asserted triples, and the annotation triples, are all part of a named graph
Pierre-Antoine Champin: Right
Ivan Herman: Is it possible to make annotation of a triple part of a node graph, where the annotations themselves are not part of the named graph?
Pierre-Antoine Champin: To segregate them, no... then you would have to use the embedded node representation
... in Trig-Star, the annotations only work within a given node graph
... Maybe there is a way in JSON-LD-STAR, i don't know
Ivan Herman: I ask because in VCs, people wanted to put additional metadata into a VC structure
... A problem is that we have a strict separation of a graph that gets hashed and signed, and annotations that may or may not be part of the graph
... We want to use them as metadata that should not influence the signature
... That is the case we have here, to put annotations on the graph without them being in the graph (and therefore interfering with the security)
... Worth keeping an eye on
Pierre-Antoine Champin: Very interesting use case; please submit an issue!
Timothée Haudebourg: I don't understand why you can't put an id on an annotation. Is it something to do with circular statements?
Gregg Kellogg: The subject of an annotation is the triple. If you put an id on there, it would no longer be an annotation on that triple, it would be on that particular id; that is why it's not alloewd
Timothée Haudebourg: I would understand it as an id for the triple itself
... If you could put an id on the triple, you could talk aobut statements...
Ted Thibodeau Jr.: You can do that, but not using RDF-STAR. This is a new thing; shortcuts for a few things that does not necessarily replace the things we've already been using for 10-15 years now
... A few things, fairly confusing to people... 1 is that JSON, no matter how you use it, is a tangled syntax, difficult to read straight off-the-bad
... Also using RDF-STAR makes it more complicated
... I suggest first present it as Turtle-STAR.
... Then the comparable JSON-LD-STAR could be presented
... [points out error in slide about seniorManager/seniorDeveloper]
Pierre-Antoine Champin: Thanks
Manu Sporny: I'm concerned about the syntax in general, but specifically around verifiable credentials
... The graph annotation has been a touchy subject around VCs. difficult to get the group to understand the most basic graph annotation
... This could throw a bomb into people's understanding of verifiable credentials
... I understand this could get us there faster, just not sure about choosing to use it
... If we're concerned about lone developers understanding it.
... Trying to keep to a simpler syntax.
... We may want to see if we could use this in a VC; get feedback from that group, to see if it makes things easier to reason about
Gregg Kellogg: This could be data that could be signed by a credential. Can a credential sign an RDF-STAR graph?
... Would there be some use in using JSON-LD-STAR/RDF-STAR in the credential itself, like in an annotation?
... Typically I think in VCs you have an object where something's value is a graph, and the other statements are about that graph. That's not an RDF distinction, although JSON-LD makes it conveniently happen.
... Is there a way to use this to clean that up? I don't think so, because this is about triples, not graphs.
... But I think that would be a useful thing to explore, in some group, maybe it would be in RDF-STAR's mandate to consider that, as already out there in the wild
Ted Thibodeau Jr.: "Unnamed Named Graphs" a/k/a "Blank Graphs"
Ivan Herman: Problem we might have process-wise; by the time we need a normative reference to these things, it might not be there yet
... So we have a problem in the sync of the work. We have a schedule on the RCH WG
... I'm a little worried as a staff contact about bringing in RDF-STAR and JSON-LD-STAR into the picture with normative references, that becomes a bit difficult
Manu Sporny: Certainly we don't want to do that for VC 2.0
... But a use case to consider; if something blows up, it's a clear sign something is not right
... A VC has effectively 3 graphs: the graph of the credential subject, of the credential itself, and of the proof.
... You could argue that some of them are annotations... A proof block could be viewed as an annotation of the main graph. That's a complex enough use case, with broad use, that could show if on the right path
... All the complexity is hidden
Ivan Herman: That may be a problem
Phil Archer: Trying to understand having an annotation on a credential
... A credential says "this thing is true"...
... You can't stop people from writing gibberish. I could see a case that credentials would say "no annotations"
Manu Sporny: Yes, it would just confuse people
Ivan Herman: We had issues raising that
Gregg Kellogg: Canonical example: Louis Clark believes Superman can fly. Is that something you could sign if expressed in RDF-STAR?
Manu Sporny: You could express it today as a verifiable credential
Gregg Kellogg: But can't claim fact...
Manu Sporny: VCs are just statements
Gregg Kellogg: That's the issue...
Ted Thibodeau Jr.: We know that stuff said in a quoted triple... It's a black box; even though it looks like RDF, not really. Until it's asserted. Then it becomes something you can reason over. Makes sense?
Manu Sporny: No
Ted Thibodeau Jr.: Trying again. Triple "Alice is working for ACME"
... Annotation syntax: first we assert it, then annotate with info about the role and year
... If we use the quoted syntax instead... We have a triple that says "Bob is a genius". That is a quotation, not a statement
... Alice believes Bob is a Genius. We don't know if that is true... Just that Alice believes something
Pierre-Antoine Champin: We know it, because those are the terms in the triple, but we don't really care. It's just a triple, that has those things
Ted Thibodeau Jr.: If you treat that as a subject-predicat-object triple, it fits into the data model
... You can use named graphs to get around this in some ways
Pierre-Antoine Champin: I see your point
Gregg Kellogg: We have a whole working group for RDF-STAR; I encourage participation in that.
... This topic was allocated 15 minutes; we've spent 35
Pierre-Antoine Champin: Use cases such as the VC one... Issues could be opened.
Ivan Herman: I didn't realize, I thought JSON-LD-STAR was on the charter of the JSON-LD WG
Gregg Kellogg: JSON-LD was an ongoing WG...
Ivan Herman: We could put it in the charter...?
Ted Thibodeau Jr.: Here be dragons!
Pierre-Antoine Champin: That could work
Phil Archer: I think thinking will be clearer if you have a non-subjective triple
... "This box is red"
Pierre-Antoine Champin: Alice's belief that the box is red
Gregg Kellogg: The ramifications of JSON-LD 1.1 being out there... One concern which goes back to the core WG work...
Ted Thibodeau Jr.: Sure. `Alice said, "Bob is a genius."` or `Alice said, "Bob has a 250 IQ."`
... The cost and signalling that happens, in this case... Potentially every access to something which uses JSON-LD, going to fetch the context, even though we have many descriptions about caching and reducing that, we did not put anything in overtly to limit that other than suggestions of how to overcome that
(Aside, what I tried to say is that it's the 'believes' predicate that's the problem, not the annotation)
... An ongoing issue that may need some resolution
... [JSON-LD 1.1 slide]
... Hash links could help
Ted Thibodeau Jr.: (Re aside -- Yes. Hence my changing from "believes" to "stated." Which is actually the formulation I used months ago, coining this quotation example.)
Benjamin Young: About danbri, this was a conversation Greg, Dan, I and others were having
... Mid-stream, it's parcel and part about what JSON-LD should care about
... He shares a Google Doc ^
... of the situation and his perspective on it
... Many folks commented on it, pointing out different options. Dan's scratch pad of working through it
... tldr is to just do vocab, and context statements as needed
... Interesting comments, pointing out the flaw that Dan is trying to highlight. There is one where Rob says that there is some degree of trust needed, that contexts referencing other contexts is just going to work.
Pierre-Antoine Champin: TallTed +1, "believes" also a can of worm.... I made those slides to quickly :-/
... Don't think that is going to fly. There has to be some higher level of stability or digitized trust that can be leaned on when doing context resolution
... I don't think we can ignore those; or it will be built for us.
Gregg Kellogg: Ongoing issue. I think the issue of retrieval of resources on the web is general, it hits everything. Even Turtle, by referencing other vocabularies, is implicitly requiring that those vocabularies be dereferenced for reasoning... subclass relationships... Not typically done...
... Typically people take JSON-LD, that requires retrieving
Ivan Herman: I think there is a difference. In Turtle, if you have the URLs, then the only reason to dereference is if you perform any kind of inference.
... As part of the inference process, yes, you fetch those URLs
... In JSON-LD, in theory, you have to dereference them every time...
Gregg Kellogg: Every time you use one of the APIs that require it... Expansion...
... It may be more common in some regimes... SPARQL entailment...
Manu Sporny: I know this doesn't fix or change anything; but I don't understand how it's just a JSON-LD problem. Every browser fetches things, affecting how pages render, run JavaScript... Seems like a strange complaint
... On an airplane I couldn't work on ReSpec because no WiFi. People don't get upset about that, but about JSON-LD contexts?
... Just cache forever.
... Even if you use hash-links, you still have to fetch content and cache it.
Manu Sporny: Just tell people to cache it?
Gregg Kellogg: I suggest if you do some severe rate-limitting, that could solve the problem.
Manu Sporny: E.g. reject every 4th request.
Gregg Kellogg: E.g. exponential delay
Manu Sporny: Need to decide where to do this. W3C, IETF...
... If we need to push this forward (hash-link spec)...
... On the other side, we'll still get these complaints
Gregg Kellogg: Basic problem of caching things on the web.
... Hash links doesn't solve it in and of itself.
Manu Sporny: Still will have bad implementations going to the Web every time
Mahmoud Alkhraishi: Hash links still useful
Mention of rate limiting reminds me of work going on right now in the IETF HTTP API WG on this https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers
Pierre-Antoine Champin: Yes, caching and hash-links provide solutions (to respective problems)
Gregg Kellogg: JSON-LD WG started/ended on August 31st
Gregg Kellogg: YAML-LD work and JSON-LD-STAR work needs the WG
... Backlog of issues is on the table for the WG.
Philippe Le Hégaret: Publishing, I'll get fixed after TPAC. We need a new charter for the upcoming 2 years. My understanding is we keep doing what we're doing. I've prepared a draft charter, sent a link earlier today to it.
Philippe Le Hégaret: Shouldn't be controversial at all
Philippe Le Hégaret: Benjamin still chair, ok?
Benjamin Young: Fine
Philippe Le Hégaret: Copied some stuff from Wikipedia
... Some text to be helpful if never heard of JSON-LD
... Added sentence about Community Group
... Out of scope didn't change; list of deliverables didn't change
... Updated wording; I don't know if in practice it makes any change at all.
Gregg Kellogg: Other deliver about YAML-LD note?
Philippe Le Hégaret: It's a "such as" - not meant to be restrictive; just as examples.
... Coordination section did not change.
... Repeating sentence about JSON for Linking Data CG
... May want to add sentence about RDF-STAR WG?
Gregg Kellogg: RCH?
Pierre-Antoine Champin: Couldn't hurt
Philippe Le Hégaret: If you want to be reminded to check with a group, it should be listed here.
... If not, don't expect to be asked about it
... Other sections unchanged.
Ivan Herman: Would list RDF-STAR and RCH?
Philippe Le Hégaret: Alright, I'll add those two.
Philippe Le Hégaret: If you want to work on JSON-LD-STAR in the WG... this is pretty vague; I don't think anything here would restrict you from doing so.
Gregg Kellogg: It is pretty mature; developed in the JSON-LD CG
Ivan Herman: Would JSON-LD-STAR become a recommendation or a note?
Philippe Le Hégaret: As a new version of JSON-LD?
Pierre-Antoine Champin: RDF-STAR WG will be publishing RDF 1.2 which would include STAR features. That's a new version
... Logically it would be JSON-LD 1.2; that's maintenance
Philippe Le Hégaret: I don't want to prejudice you from making that decision down the line
Gregg Kellogg: The group may want to decide...
Philippe Le Hégaret: Nothing here would prevent that
Philippe Le Hégaret: I will start the review of it, crank the wheel. Eventually you'll get a new WG.
Gregg Kellogg: Fortunately the chair doesn't expire
Ivan Herman: Started the extension?
Philippe Le Hégaret: I will start it
... Just cannot publish TR right now
Pierre-Antoine Champin: Out of scope section?
Ivan Herman: It just says don't do what another WG is doing
Philippe Le Hégaret: OK, will remove it
Gregg Kellogg: We have all sorts of leftover stuff

Topic: JSON-LD 1.1 API

Gregg Kellogg: Erratum on syntax
... [moving through slides 33+]
... Most urgent is the erratum. How are they supposed to be addressed?
... Pierre-Antoine and I have been working on them, presumably in a vacuum
... These are things to be developed in the community group when there is sufficient interest
Ivan Herman: For erratum, you can do the same thing as the VC WG did in maintenance, publish an update
Gregg Kellogg: I think we should continue to update the erratum document and the editor's draft
Ivan Herman: There is a process now to republish the recomendation if it's only a certain category of changes
Manu Sporny: These are greater changes?
Ivan Herman: These are all erratum
Gregg Kellogg: One of them is substantive; most are editorial
Manu Sporny: Be very careful with the new process; it caught me by surprise that there was an enormous amount of documentation...
Gregg Kellogg: Using the process you went through
Ivan Herman: As long as editorial, no problem. If you have substantive changes that need to go through AC approval, then there is something very heavily editorial to do...
... Produce a document showing the previous and new; not just a diff... Manually create a diff on the parts with substantive changes.
Manu Sporny: Have to manually create the diff...
Ivan Herman: Now there are some tools to make it easier
Gregg Kellogg: API has one substantial issue
Ivan Herman: Then leave that (open)
... Put together all the editorial changes, and get rid of the erratum. It give you a cosy feeling!
Gregg Kellogg: Thank you everyone!
... I encourage your continued participation
... Slides will be up; any corrections please send and we'll make them manually