JSON-LD Working Group F2F in Fukuoka — Second day — Minutes

Date: 2019-09-20

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Ivan Herman, Rob Sanderson, David I. Lehn, Pierre-Antoine Champin, Benjamin Young, Manu Sporny, Dan Brickley, Simon Steyskal

Regrets:

Guests: Ralph Swick, Duy-Tung Luu, Elika Etemad

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Rob Sanderson, Benjamin Young, Gregg Kellogg, Manu Sporny

Content:

1. Discussions with Ralph

1.1. Version announcement to version detection

Benjamin Young: yesterday’s minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-19-json-ld

Rob Sanderson: [Various non json-ld issues about w3c irc infrastructure]

Benjamin Young: New feature to be added. Previously had rejected @direction for language, as expected to be solved in RDF
… came back in the weds breakout session, that without the RDF momentum, that JSON-LD should fix it for ourselves plus specs dependent on us
… WG is fine with doing this. Brings up the issue of versioning. Adding @version will intentionally make processors choke
… want to make some features that don’t make incompatible changes available

Ralph Swick: What happens now?

Gregg Kellogg: With a default vocab, it gets treated as a relative URI to the vocab. So it gets used, but not in the way anyone would expect

Rob Sanderson: [disagreement about when things fail]

Gregg Kellogg: if you use @direction when it’s mapped, then it won’t work in a value object but will work elsewhere
… if you use it when it isn’t mapped, then it is ignored
… in the schema.org case, they set @vocab and would only use @direction in a value object, thinking that processors will do feature detection
… it would fail without the processor, due to @vocab

Benjamin Young: ActivityPub also would benefit from this and use @vocab
… postel’s law discussions about how to get there with as much as possible
… concerns about whether this would actually get to where we want to

Gregg Kellogg: We’ve identified where in the API it has effects
… the feature detection mode, the processor would start off in 1.0 mode. It would see 1.1 at some point and switch to 1.1 mode
… to use a 1.1 feature, you MUST have @version 1.1 in the context, today. Doesn’t have to be the first context, just one of them
… the proposal is to facilitate the use of 1.1 features is it reasonable to not do that
… to switch to 1.1 when you’re using something that you detect as being part of 1.1. A lazy evaluation
… a 1.1 processor will be fine
… the issue is for 1.0 processors. We didn’t lock down things in 1.0, so it might ignore things in the context that would change the interpretation of the data
… one of the things is an id map, keys are ids values are objects for the uris.
… a 1.0 processor would just think it was another object with strange properties
… could get very very different interpretation of the same document
… if a publisher of a context is concerned about that, then use @version announcement
… but might have some reasons to not do that, if you don’t worry too much about the interpretation

Pierre-Antoine Champin: One idea - we have an extensive test suite. Could try to run the 1.1 tests on a 1.0 processor and see which ones fail or not

Benjamin Young: +1

Pierre-Antoine Champin: could compare the graphs and thus identify the features that really break things or not
… then discuss in best practices document
… as to which features should really have @version

Ralph Swick: Good to know what “break” means

Pierre-Antoine Champin: +1

Ralph Swick: if you get an object you can’t interpret, but all the other things are fine, that’s less risky than if you interpret something wrong but don’t know

Gregg Kellogg: There’d be no legit 1.0 data that tried to use lists of lists
… it would be useful to see what a 1.0 processor would do
… we have the tests, we can have versions of the tests that don’t announce 1.1 and see what happens

Ralph Swick: @version says you must not interpret this using 1.0 rules

David I. Lehn: list of lists had explicit error in 1.0 jsonld.js

Benjamin Young: I think there’s consensus to do this moving forward

Gregg Kellogg: blanket statement that publishers use version announcement, with warnings for features of what happens if you don’t do announcements

Ralph Swick: two cases, different results but new objects aren’t understood.

Gregg Kellogg: set of okay results and others that are crazy

Ivan Herman: During transition phase we have a problem. Until schema.org processors upgrade, any json-ld data for schema.org that uses direction will fail

Duy-Tung Luu: incompatibility not necessarily a feature, could be a logical error between interaction of features
… hard to anticipate all the tests needed

Manu Sporny: +1 I’m also concerned about combinatorial issues w/ feature detection

Pierre-Antoine Champin: For proposal for warnings in the spec when dangerous features are used without @version, sounds like a good idea but also the bnode @vocab warning for activitystreams
… should be cautious about things

Gregg Kellogg: that was when we deprecated behavior that we didn’t think was used
… not because of the spec, just the way my implementation interpreted it

Benjamin Young: One thing that came up yesterday was that the processors aren’t mostly json-ld processors anyway
… they won’t care
… only people that we’re hurting are json-ld processors
… hard time making the case
… it’s no issue for non json-ld processors of the data
… it’s now in lighthouse, which is a json-ld processor for real though

Rob Sanderson: [SDTT]

Gregg Kellogg: SDTT isn’t a validator

Ivan Herman: True but it reflects as much as is known about what schema.org processors do
… this construct which is valid JSON-LD isn’t processed correctly, for value objects

Benjamin Young: We heard danbri say that they would be happy to promote it, but that’s all that they can do

Pierre-Antoine Champin: Shouldn’t break things that currently work … including things that don’t work

Rob Sanderson: [laughter]

Gregg Kellogg: SDTT isn’t a metric for judging brokenness
… people complain about why SDTT complains about stuff that the linter is fine with

Ivan Herman: schema.org is already broken for value objects regardless of what we do here

Benjamin Young: Website owners just want it to show up in the search index

Gregg Kellogg: that it doesn’t work in SDTT doesn’t mean it won’t work in the index

Ralph Swick: Still the closest we have. On the principle of making sdtt doing something worse isn’t wise, we shouldn’t do it, but it already doesn’t do it so it’s no worse

Rob Sanderson: [playing with sdtt]

Ivan Herman: one thing for presence of director was a question came up. That version is not required would be put into CR as “at risk”
… during implementation if we find feature detection to be too hard, …

Ralph Swick: or a lot of documents would be broken

Ivan Herman: yes, then changing behavior in CR would be acceptable

Benjamin Young: danbri said SEO bots don’t look at the context
… they don’t process it

Rob Sanderson: is it OK to mark something as “at risk” to note that something has changed–and not that it’s something we want to have taken out
… for example, if it turns out that some things are possible and some other things are really hard
… then we might change how the warnings/errors work for those

Ralph Swick: so your proposal is that there will be feature detection
… and what’s at risk is that you may require @version

Gregg Kellogg: Possible middle ground too.
… your proposal is to make @versionpossible, and you’re marking the requirement of it as at risk

Ralph Swick: Can clarify in the document that things are at risk as to being available without @version
… two categories of features … ones that are turned on without @version which is at risk, and those that require @version

1.2. direction Part 3 … RDF

Ivan Herman: what we agreed yesterday is the syntax. We will have direction in json-ld. Within json-ld world it just works
… however, the question is if we generate RDF, what do we do?

Ralph Swick: can we be more precise about “generate RDF”?

Ivan Herman: Produce an RDF graph with a literal with a direction
… then one approach is that the processor has two api run-time options. One option is to say forget it. It would just disappear and generate a traditional language literal
… the other is to define new RDF terms for language and direction, where instead of a literal it’s a blank node
… a kind of skos-xl like structure for literals
… the positive aspect of the structure is that it round trips through the graph
… the information isn’t lost
… the negative aspect is if RDF data goes this way, we create a parallel universe for language+direction literals
… json-ld users can pick which way they want
… but what’s the default
… don’t have an answer, perhaps via a coin flip
… that’s where we are
… there are other possibilities for how to reflect into RDF
… could also be a new datatype
… there’s always a parallel universe

Rob Sanderson: [looks at rdf literals and base direction doc]

Ivan Herman: question is whether there’s a problem to define two new terms in rdf: namespace

Ralph Swick: are you already comfortable with the processor option?

Gregg Kellogg: there are options for other things, though most people use default
… Not acceptable to not round trip. Should do something that preserves it.
… lots of discussion. Future group would be expected to replace or endorse the structure. A processor option would let the future processor adapt
… can’t keep it entirely in the JSON-LD domain

Rob Sanderson: I generally agree. two comments, though
… for CR, if we mark it at risk, and it turns out that….

Ivan Herman: mark what?

Rob Sanderson: well…whatever we define here
… and at implementation phase it turns out there’s push back against the structured approach
… because it results in an “always punning” scenario
… and if, like us, you don’t have punning as an option
… then the language tag approach would be preferred
… which would be my personal preference
… because it puts things in an expected place
… the SPARQL queries already have to search for “en-*”
… there are of course other cons
… but if it turns out that during implementation that the structured approach is not the best default
… do we have to go back through CR in order to change that default?

Gregg Kellogg: the i18n seemed to strongly object to the use (well…“hacking”) of the language tag

Ivan Herman: I’d even expect them to formally object to that solution
… at this point I don’t think it’s a choice

Rob Sanderson: Addison did say he’d rather have it in the language string than to not keep it at all

Manu Sporny: I don’t think the structure solves things. We haven’t had this for a long time.

Ralph Swick: And getting objections as a result

Manu Sporny: Yes. We should be careful to do this right. It’s a half way solution that introduces problems. We should do the thing that we think is the final solution

Rob Sanderson: .. we can be a forcing function. By default it’s dropped, it doesn’t impact them if you don’t want it

Manu Sporny: so opt in
… what it looks like in RDF - I agree that the i18n folks dont’ want it in the tag - but there could be a ^direction
… of the options I’ve seen that looks the cleanest
… don’t have to upgrade infrastructure now until it’s implemented
… BCP47 doesn’t have a caret in any language
… so a clean token to split the string on
… if that’s the final option, then we should force it in that direction

Ivan Herman: Am fine with opt in
… but opt in should mean generate something in RDF which is valid today
… generating invalid RDF is unusable anyway
… no idea what the community will come to a solution, if ever, but something that no processor will accept today is useless
… caret means we create another syntax
… could have created something with a string and lots of carets bla bla :)
… won’t have it today, might not ever
… so generating it is pointless. Only one that’s valid is the structure

Pierre-Antoine Champin: If we go the way of an option, we should consider the equivalent for rdf to json-ld
… that might be none trivial for an intermediate node solution

Gregg Kellogg: to manu’s point, the algorithms to make a dataset rather than nquads serialization, adding a direction is something a dataset would need to store
… we have uris bnodes and literals
… only if language tagged can they have a language
… literal would have a direction and a language … you’ve added a column in a store
… an rdf WG might decide to do that
… deafening silence was the reaction from the community

Ralph Swick: strong +1 to opt in
… default should be to break the fewest tools
… option to do something better is most useful if the better is something that tools can work with
… suggests some choices
… don’t know how it works now but could have non binary option, and in 1.2 could then have a 3 or 4 value option with different syntaxes
… urge to do something useful to existing tools

Manu Sporny: What goes along with the option could be a function to decide what to output
… e.g. RDF in some format
… if you want new triples then great. BUt it lets the community to decide how to output it so they can integrate with different toolsets
… no clear solution that meets all the requirements
… if the solution is new triples, we have no interest in implementing it
… don’t have a strong requirement to do that, so would just wait until the problem has a final solution
… also to note that the argument of existing ecosystem not doing this is invoked a lot. Invoked in 1.0 but we defined various things and they were pulled into 1.1
… arguing this is not the state of the world today can be valid, but can’t push the ecosystem forward

Ralph Swick: [so if Manu has no strong requirement at the moment, having infinite extensibility with a function call-out seems way overblown]

Manu Sporny: concerned by implementation complexity. People saying they can’t implement a 1.1 processor
… every time they look at the spec they see a massive set of features
… looks like it will cost a lot of money so they pick and choose a small set and pay attention to the things they think are important

Proposed resolution: do not, by default, handle @direction expression in toRDF (or fromRDF) (Benjamin Young)

Manu Sporny: every new feature makes it worse – too many options and we make it very difficult.

Manu Sporny: +1

Rob Sanderson: Clarification - the default option for toRDF is to drop it

Benjamin Young: +1

Ivan Herman: +1

Manu Sporny: a future proposal will add in more options

Pierre-Antoine Champin: +0.5

Rob Sanderson: +1

Gregg Kellogg: +0.1

Resolution #1: do not, by default, handle @direction expression in toRDF (or fromRDF)

Rob Sanderson: from before – data type is also a valid option that solves the objectproperty / dataproperty distinction in OWL

2. Future of JSON-LD WG in proposed new process

Elika Etemad: Any questions about the process?

Gregg Kellogg: About CR, if we drop out of CR we can publish WG drafts, but we can also iterate in CR?

Elika Etemad: CSS iterates within CR, it just takes longer. Right now CSS has the drafts we post to TR, and editors drafts
… publishing to the TR page takes some process, up to 4 weeks, has gotten better but got as far as 3 months in the past
… still can’t publish every week
… editors draft is up to date, TR gets published every 6+ months
… meaning people look at the drafts not TR, which is supposed to be a scratch space
… allow publication on the site … it’s not regressing, not adding brand new features, just fixing the issues that are being reported
… it will be part of the next CR. So publish to the TR/ URL, and make a distinction between WG updates and the snapshot CR that have had directors’ approval and trigger patent exclusion

Ivan Herman: How to decide which to choose?

Elika Etemad: Lawyers don’t like looking at things too often
… 6-24 months should be publishing a snapshot
… up to the WG as to exactly when
… some CRs don’t get a lot of changes.
… 6-24 from any substantive change

Ivan Herman: when will it come into effect?

Elika Etemad: will take effect Q2 of 2020, or so

Ralph Swick: the question you just asked Elika is “when will there be process 2020?”, and elika guesses Q2

Ivan Herman: we’re chartered until June

Elika Etemad: If you don’t get to TR and get an extension…
… we get rechartered every two years as well
… for what changes, nothing unless you want to update more frequently

Ivan Herman: for us, what is interesting, our current charter goes until june. We’ll have no problem getting to REC (apart from @direction) by then
… the question is what to do after that
… the recommendation we might suppose we have 1 or 2 more features that the community wants to add . Not to redo the whole thing
… we thought everything was good until yesterday until @direction came along
… in a year from now we have a rec published, but there’s a new feature … today we have to recharter from A-Z
… is that easier? And if so how?

Elika Etemad: Proposal to allow non-feature addition changes. Annotate the errata inline. Call for review. Don’t have to drag the whole thing through CR
… good to have recs spawn other recs without the whole dance, just start at CR
… shortcut around a lot of the process for the feature addition
… to publish a .1 release or whatever
… that’s the feedback at tpac
… don’t have a clear answer as to which option to do that. Could use errata system for feature additions, or could make it easier to republish with a new feature with a shorter process
… still need to recharter
… as need a WG

Ivan Herman: How to recharter then? If we recharter in a year?
… if there’s nothing else happening, then is it a valid charter?

Elika Etemad: Don’t think anything defines what is a valid charter
… if that’s the kind of charter we want to have, we can discuss that
… could wait until there are feature requests coming in

Ivan Herman: charters take 3 or 4 months today.
… have to announce to AC, give them a month, then we do the charter, then to vote which is 6 weeks … so minimum of 2.5 months
… we want to add one feature, say direction, so 3 months for administration of a very short wg
… would the AC accept a maintenance WG that sat around for a long time. I think the XML group did that, and the AC said no close them
… now with this process we bring back dormant WGs

Benjamin Young: With JSON-LD we have parallel CG / WGs. The CG will reboot to take up work that we don’t do. If the process is easier to get from CG to WG for maintenance, that could more easily get a charter, they could prep the errata and have the shorter charter
… here’s our errata from the last year, boot up the WG, get the official okay and then shut down again
… prefer the maintenance WG thing as lots of administration
… sends the wrong signals … news goes out that XML is closed at the w3c
… other WGs like annotation. Shipped and people came up and said “is everything okay? the WG closed?!”

Elika Etemad: “concluded” rather than “closed” in the press release?
… satisfied the charter

Ivan Herman: Maintenance issue stands

Benjamin Young: undulating CG /WG thing would get old fast for administration

Gregg Kellogg: a better relationship for the sine wave

Ralph Swick: Ivan made a good point. Pendulum has swung back and forth
… now we realize we need CSS WG for ever

Manu Sporny: VC WG in discussion about maintenance mode
… credentials CG, and VC WG. WG has declared success, going into maintenance mode. Continuation of the IPR policy
… new features in CG won’t have IPR
… so talking about VCWG defers all decision making to the CCG. they continue to iterate and discuss. Once it’s ready they feed the features back to the WG
… staff contact goes down to 0.05 or whatever
… only thing is that chairs can veto things that come in
… but did not want members with lots of additions to be able to short circuit it
… don’t want to say closed, but also doesn’t take up resources
… helps the community keep the spec current
… bugs and errata could be fixed, new features with the new process would be good
… would that model work for JSON-LD ?
… concern is addition of new features to the point where only a few people can ever implement it

Elika Etemad: not a question for my time on the AB
… working on streamlining the process for WGs
… putting errata in is a lot of work
… but chartering hasn’t come up, but seems like a problem
… some kind of maintenance status charter is appropriate
… minor feature is interesting one. How to decide if something is minor
… a maintenance WG process?

Ralph Swick: Lowercase p process issue
… CSS is constant, other groups don’t know when the next big thing is coming

Elika Etemad: Charter to do maintenance rather than adding new features without a recharter / amendment
… if new features come in that are good ideas you amend the charter for specific features

Ralph Swick: have the machinery but not necessarily the will to do this

Elika Etemad: Either about Process or just communication. Not charter maintenance groups to do new work, without amendment and review
… that might be acceptable

Gregg Kellogg: an issue we dealt with, the DID wg did. Work starts in the CG, WG elects to take it as input. Lots of technical aspects. COmmit history, open issues to transfer etc
… policies and tooling would be good
… to the CG, JSON-LD was at a point where we gathered a backlog of features but no way to get to WG without the CG writing a big spec
… makes the 1.1 update feel like a BIG update
… if CSS was only updated every 5 years, it would overwhelm the community too
… an official relationship between CG and WG for that purpose
… of new features
… Registries. They’re a different process … they live in TR?

Elika Etemad: yes

Gregg Kellogg: Similar to namespace documents. rdf ontology lives in ns/
… groups keep documents there. Should we start using something else for namespaces?

Elika Etemad: Had a number of groups asking for registries
… they have some normative status
… they work around it by going through the whole REC track process but then updates are very painful
… in a lot of cases if there’s no IPR, then some go to notes
… then we update when we want
… others don’t know, so just put it in a wiki
… in terms of groups that need IPR, then it needs the rec process.
… making it easier to edit will make it faster, but at least 70 days for anything for exclusions and ip review
… so 2-3 months at least
… for things that need more frequent updates, no restriction on notes at all. Registry needs a little bit more official
… can’t change the process, can’t change the columns, can only add new entries in the table
… sometimes just collision management
… other times it needs to be validated
… e.g. to detect duplicates
… Process is that you can edit what you want, so long as it follows the process defined in the registry

Gregg Kellogg: implementation reports are there to get CR
… other people want to be part of the report later

Benjamin Young: good for community

Gregg Kellogg: linked from the spec

Elika Etemad: not really a registry?

Gregg Kellogg: test suite fixes

Ralph Swick: incentive to implement in CR too
… new TR class called registry is bikeshedding. The feature this new class of docs has is that it must come with a maintenance policy for how to add things
… a WG note can come with an update policy
… this is the registry of names for this thing. Lost that battle, because people add semantics to Note that it’s a low class thing
… people wanted another name for it

Elika Etemad: there’s a bit more process on it
… can only be updated by the WG. WG doesn’t necessarily want o maintain the registry
… separate process in order to delegate the maintenance to a CG or the team or something else
… as long as they follow the rules, it gets updated on TR without a WG

Ralph Swick: argued that if the WG stops, the team gets to update notes, which they could delegate to someone else
… CG transitions. Good to have best practices. JSON-LD started as a WG, then CG, then a WG.
… annotation didn’t start with a WG.
… write down what worked and what didn’t as you’ve been through it twice
… don’t understand it well enough to do it in Process

Elika Etemad: send it to the process list

Benjamin Young: happy about the registry process

Ralph Swick: asked tag to write design templates a while ago. They punted to process CG.

Elika Etemad: https://lists.w3.org/Archives/Public/public-w3process/

3. Direction … Part 4

Rob Sanderson: We agreed in the AM that we want a processor option, which defaults to drop the direction.

Ivan Herman: The datatype version familiy of language datatypes is also a viable option.
… 2.1.2.1.2 creates an ugly but valid datatype to describe language and direction #XX_YY.
… This wouldn’t be used in JSON-LD, but in the resulting quad.
… I now think this should be one option, and the other comound literal

Benjamin Young: This is adding switching in from/to RDF algorithms. 1.0 did not actually have API entrypoints for this.
… We could lower the bar for implementations by moving them into a separate interrace.

Pierre-Antoine Champin: I advocate the datatype solution over the compound node.
… The opt-in/out options would be different, but they would still be literals.
… In SPARQL, STR(literal) still gives you the expected results.
… Detecting these in the to/from algorithm would be easier and fewer corner-cases.
… On the semantics side, I think the DT solution makes it easy to define semantic interopration with existing language tags (intersecting value spaces).
… You could make interaction with existing lang-tagged strings smoother than as considering them as two different spieces of literals.

Ivan Herman: To be very precise, we’re talking about 2.1.2.1.2 in the document

Pierre-Antoine Champin: https://w3c.github.io/rdf-dir-literal/#datatype-family

Rob Sanderson: I wanted to disuss 2.1.1.2.
… I think we could subclass rdf:langString to create rtl/ltr versions of that sub-type.
… Hm, Guess not, given RDF spec.

Pierre-Antoine Champin: I agree with gkellogg that the option in fromRdf might sound strange, but the message might not be clear. If there’s no option, we bake in the processing, and close the door for other possible options.

Benjamin Young: section references come from https://w3c.github.io/rdf-dir-literal/#compound-literal

Proposed resolution: Add a parameter option to the API function toRDF, with three possible values: null or absent (do not process, the default), datatype (reflect to a datatype per 2.1.2.1.2) and bnode (reflect to a bnode structure per 2.1.4) (Rob Sanderson)

Rob Sanderson: +1

Benjamin Young: +1

Gregg Kellogg: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Resolution #2: Add a parameter option to the API function toRDF, with three possible values: null or absent (do not process, the default), datatype (reflect to a datatype per 2.1.2.1.2) and bnode (reflect to a bnode structure per 2.1.4)

Benjamin Young: What if you have both bnodes and datatypes in an input? Could we convert them?

Proposed resolution: Add a value to the options parameter to the API function fromRDF, with the above three options plus “any” which will convert either datatype or bnode as discovered in the data (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Benjamin Young: +1

Gregg Kellogg: +1

Gregg Kellogg: For example `preserveDirection: enum(null, dt, combo, any)

Proposed resolution: Add a value to the options parameter to the API function fromRDF, with the above three options plus “any” which will convert via any conversion function available as discovered in the data (Rob Sanderson)

Pierre-Antoine Champin: I see this as an extension point, some may have more than two.

Ivan Herman: +1

Benjamin Young: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Resolution #3: Add a value to the options parameter to the API function fromRDF, with the above three options plus “any” which will convert via any conversion function available as discovered in the data

4. fromRDF/toRDF status

Benjamin Young: These are different types of things which may be a barrior to implementation.

Pierre-Antoine Champin: posts comic about HTTP range-14 being a challenging issue.

Benjamin Young: We may loose because of RDF, and may gain market share because we insist on RDF
… The context fetching is also a controversial requirement.

Rob Sanderson: I’m a -1; I understand the intent, but the audience is not those that will actually read the spec.

Benjamin Young: This revision makes more claims of RDF than 1.0 did, and people are comenting that this is a shift.

Rob Sanderson: People said they liked to see the addition that RDF is not needed.

Ivan Herman: To be process oriented, we declared feature freeze and are close to CR raising an issue that is inappropriate. If we go done this line, it resets us by some amount of time, and are going against our charter.
… direction was already an issue, so was within the feature set.
… Unless this is purely editorial, I’m against it.

Ralph Swick: I don’t know if it’s editorial, but if you considered that it didn’t violate it, other groups have said things like “conformling level 1, 2, etc proessors”.
… This allows people to subset better.
… The partition excercise might be instrucive.

Pierre-Antoine Champin: It reminded me of manu’s comments before the break about the spec being quite complex and frightening. gkellogg said that some implementations might not flatten or frame. Maybe what you should say you need at the core is Compaction and Expasion, and the rest could be skipped.
… This might make it less frightening.

Benjamin Young: That’s the core of what I’d like to say; i’d like to reduce the core of what people need to do
… I’d like to do something with some core stuff, no fetching, HTML parsing, etc.

Ivan Herman: It’s not normative or non-normative, they must be implemented in that way.

Rob Sanderson: We already discussed proessor levels, we put them in, they were hated, we took them out.
… I’m in support of adding introductory prose to say that you don’t need to implement everything. If you implement something, you must do it this way.

Manu Sporny: We’re having a discussion with an implementer who thought they needed to implement everything.
… In the C++ implementation, they only need to implement expansion/toRdf (and c14n). THose two aren’t hard, but trying to do the whole spec was daunting.
… I agree with gkellogg that it might be difficult to break out into layers.
… The counter argument is that it would be nice to know if you have afullly conformant 1.1 processor.

Benjamin Young: This is marketing, there is a way that this can be accomplished, and encourage people to get into JSON-LD piece by piece.

Ivan Herman: we have a conformance section.

Rob Sanderson: There is text in the document about processor classes already (conformance). It would be months of work to do anything else.

Benjamin Young: We signal that it’s hard because you must have something that gets and retrieves stuff.

5. Issue handling

5.1. Issue #153, @prefix and keyword aliases

Ivan Herman: See API #153

Rob Sanderson: time to summarize for the minutes
… we accept that issue 153 is an issue

Gregg Kellogg: a bug

Rob Sanderson: true. a bug
… it should not in fact generate @idfoo

Gregg Kellogg: it should treat id:foo as an IRI
… so the result of expanding should be id:foo

Proposed resolution: When encountering a term in the form of a compact IRI for which the prefix would expand to a keyword, do not expand the term (Rob Sanderson)

Rob Sanderson: so if there was an @vocab it would expand to that value + id:foo?

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: it won’t be expanded as a relative URI because of the colon

Gregg Kellogg: +1

Benjamin Young: +1

Simon Steyskal: +1

Resolution #4: When encountering a term in the form of a compact IRI for which the prefix would expand to a keyword, do not expand the term

Gregg Kellogg: if there is an id term that’s legit, and I see @prefix: false
… it won’t expand that because prefix is false

Action #1: determine if @prefix: false will prevent the term from being used in expanding IRIs, and file an issue if it does (Gregg Kellogg)

Gregg Kellogg: there’s another issue about changing SHOULD’s to MUST’s for things that look like keywords

5.2. json-ld-syntax #260 – Can terms start with an @

Ivan Herman: See Issue Syntax#260

Gregg Kellogg: what we’re most worried about is other specs using @ and we want them to be compatible with us
… but at this point hopefully everyone’s aware of our use of @

Manu Sporny: what does changing it to MUST NOT buy us?

Gregg Kellogg: it means that if we add things like @direction in the future, the processors would choke on the new term but they also wouldn’t try to turn it into a URI

Ralph Swick: so, could you just say SHOULD NOT?

Rob Sanderson: it does

Ralph Swick: ah, so you are leaving this open for future compatibility

Gregg Kellogg: and I think @direction is an example of why we want this

Rob Sanderson: there was an earlier issue which we closed about this
… and it was mentioned that if we found new info we might reopen it
… this seems like new infromation

Gregg Kellogg: so, some future @direction type thing could be setup to just disappear

Rob Sanderson: or attempt to turn into a crazy relative IRI

Benjamin Young: so, as long as we just ignore the new values when processing–and don’t choke–that should leave the door open to the future without tripping up old clients

Gregg Kellogg: authors should not use these keywords, but processors must ignore them
… but with a warning

Proposed resolution: Reopen w3c/json-ld-syntax#16 and require processors to ignore terms beginning with @ that are not defined keywords (Rob Sanderson)

Ivan Herman: See Issue syntax#16

Gregg Kellogg: +1

Manu Sporny: +1

Rob Sanderson: +1

Benjamin Young: +1

Simon Steyskal: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #5: Reopen w3c/json-ld-syntax#16 and require processors to ignore terms beginning with @ that are not defined keywords

Rob Sanderson: Have we made this clear, it’s resolved?

Gregg Kellogg: Yes, the editors need to do their thing now.

Rob Sanderson: so we’ll close #260 in favor of opening #16.

5.3. w3c/json-ld-syntax#259 - @vocab and keywords

Ivan Herman: See Issue syntax#259

Rob Sanderson: propose that we can close #259, is this errata to JSON-LD 1.0?

Gregg Kellogg: it’s not

Rob Sanderson: Ok, this will remain a bug with 1.0 processors, they should update and do the 1.1 process for this particular feature.

Proposed resolution: Close w3c/json-ld-syntax#259 as we can’t fix 1.0, and 1.1 will be solved by newly reopened #16 (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Manu Sporny: +1

Pierre-Antoine Champin: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Benjamin Young: +1

Resolution #6: Close w3c/json-ld-syntax#259 as we can’t fix 1.0, and 1.1 will be solved by newly reopened #16

5.4. w3c/json-ld-syntax#257 typed values

Rob Sanderson: Moving on to #257…

Ivan Herman: See issue syntax#257

Benjamin Young: It’s probably reducible to an editorial thing in a best practices document.
… People are going to get confused when they do type coercion and they’re getting booleans that are typed as xsd:datetime… I’d love to see, when we recharter to fix bugs, I don’t expect this is a JSON-LD proper problem… I’d like an extra spec that goes and checks these things.

Gregg Kellogg: If you run it through a linter…

Benjamin Young: This is an acceptable way to do it via our specs, it looks wrong, but validation is not JSON-LD’s problem, but we didn’t take that on.

Ivan Herman: RDF doesn’t do those things either, you can have values w/ datatypes, which is wrong.

Benjamin Young: so, you can say it’s best practices stuff
… The CG could address this, these are the kinds of things that we need to address w/ the community

Gregg Kellogg: A different example, instead of a string it’s an xsd:datetime, that’s valid -

Benjamin Young: When people have an expectation of JSON-LD, and it’s one thing, and it turns out to not be that one thing… we need to build bridges towards validation.

Rob Sanderson: If you push this through to RDF, you’ll get the right thing back out.

Gregg Kellogg: well, if it’s xsd:string, you will get that, but if it’s “boolean” you will.
… another thing that could happen, is when you expand, ignored if it’s an array or object… it could be ignored for numbers… you don’t know, could be decimal/double.

Pierre-Antoine Champin: JSON-LD has support for more datatypes than RDF… it’s better, the fact that it doesn’t support other datatypes can be argued by the fact that it’s open… xsd:datatypes…

Rob Sanderson: We should transfer this issue to best practices…

Benjamin Young: my confusion is about expanded form vs. compact
… if name had ex: in front of it, it wouldn’t show up…

Gregg Kellogg: no, it would show up, it’s an IRI

Proposed resolution: Transfer w3c/json-ld-syntax#257 to best practices document (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

Simon Steyskal: +1

Manu Sporny: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Resolution #7: Transfer w3c/json-ld-syntax#257 to best practices document

Benjamin Young: if if if if if

Benjamin Young: {"name": true}

Benjamin Young: That doesn’t survive

Gregg Kellogg: The later one isn’t absolute IRI… the previous is
… This might be why manu keeps saying compact IRIs were a mistake

Benjamin Young: It means you have a bit of a rosetta stone w/ @context.

Rob Sanderson: That’s all of the open issues, except for the loads of editorial issues.
… The framing stuff has no more issues either.

5.5. w3c/json-ld-syntax#108

Ivan Herman: See issue syntax#108

Manu Sporny: this is an awareness opportunity

Rob Sanderson: so from our side, we’ve pointed to DocumentLoader as the thing that makes the loading stuff work
… whatever the format, type, etc of the IRI
… this is deferred to a future version because we don’t know if more data will be needed at the JSON-LD document level to express this
… What we said is that document loaders should do whatever they can … hashlink or ipfs or something else that enables content integrity. We added @import for future version, if there is interest in putting data into instance graphs/contexts… this particular thing needs a particular SRI value or other, we have a slot that we can provide stuff in @import so you can add something.
… The use cases fulfilled by document loader process, if there is need to support this in the future, we want to have support and have support.

Manu Sporny: the thing I don’t know is anyone circling a solution?
… we’re strongly pushing the hashlink spec as an option for DID and VCWG stuff
… for VC’s bad things happen if your context changes
… and in our specs, we make the promise that this context will never change
… so you download it and put it into your code
… but that doesn’t address extensions
… which need something like hashlink
… all you can do with SRI is to find out you got something you didn’t want
… and it requires infrastructure to be setup, etc.
… there are two parts of this
… in the future we’d like to settle on hashlink as the primary way–in our communities
… [demoing hashlink]

Dan Brickley: manu, is there a github repo for the conversation you mentioned with J Yasskin?

6. Attributions

group: [discussing how best to give credit where due in the specs]

Gregg Kellogg: I think we should add dlongley
… to all the 1.1 specs

Gregg Kellogg: https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords

Gregg Kellogg: we should add him in position 3 on Syntax after pchampin
… to both v1.0 and v1.1
… in both versions of the API spec, we’d add dlongley in position 2
… and in Framing, dlongley would be in position 1
… and he’d be removed as a “former editor” section
… and we should look back through commit amounts to consider afresh our list of additional editors
… and maybe we should add pchampin to the API spec

Pierre-Antoine Champin: yeah, I did add the folding, but I’d be happy to complete it since we recently decided to do it
… and the ordering on API sounds fine

7. Misc

Gregg Kellogg: and we should remove editors from acknowledgements and remix that as needed

Benjamin Young: we could also move some of this note work into the CG
… just so we don’t over promise or underdeliver

Manu Sporny: we do have folks interested in CBOR-LD
… and we’ve been digging into how to minimize it/simplify the storage
… and we’ve gotten URIs into single byte storage
… it’s fantastically efficient when you do that
… so you can get the document way smaller than even with gzip, etc.

Dan Brickley: so, we could do this with schema.org’s context file?

Manu Sporny: yeah, it would work great for that
… the other amazing thing with CBOR-LD, if you do data normalization
… you can do a binary comparison
… via templates

Dan Brickley: on schema.org size, “The core vocabulary currently consists of 614 Types, 905 Properties, and 114 Enumeration values.” –https://schema.org/docs/schemas.html (plus a few more in https://pending.schema.org )

Gregg Kellogg: as long as you avoid blank nodes?

Manu Sporny: …yes…and if you do this well, it’s way more compact than any linked data representation currently in use
… and it doesn’t need to be base64’d
… and you don’t need JSON Schema on it
… and you can sign it
… there’s some really interesting stuff there
… people processing an enormous amount of data can benefit
… and super tiny stuff benefits as well

Pierre-Antoine Champin: I did contact a few people in the WoT WG
… and they sent me to someone else in the JSON-LD WG who’s also in a WoT project that we are starting
… and he’s OK to contribute to a Note

Rob Sanderson: Victor Charpenay

Pierre-Antoine Champin: some of this work he’s shown in the W3C is very similar to what manu mentioned
… much of it around compact IRI’s in CBOR
… so I have a call setup with him next monday

Rob Sanderson: Are we done w/ agenda setting? CR status timeline…. when do we finish the work, what do we do after, what happens in june if we do rechartering

Benjamin Young: is there anything you want to discuss, danbri?

Dan Brickley: It would be nice if JSON-LD has a document format … we wanted lots of documents and the format… not to implement a processor.

Benjamin Young: Are there any explicit asks for us to build that bridge?

Manu Sporny: so, the VC WG and DID WG’s have basically said, you don’t need to do JSON-LD processing
… all you need to do is JSON processing focused on a few keys/things mentioned in the spec

Dan Brickley: can you say that some but not all profiles
… and there’s some history with the CSV WG

Gregg Kellogg: there is a range of groups attempting to solve for this though
… you can require the context URL…or a specific context file
… schema.org’s a bit more elaborate than most of these though
… but the solution’s the same or similar
… you state the place in the @context space where it must go

Dan Brickley: we want to be full fruited JSON-LD or whatever
… and we’ve done this a bit with Wiki Data for instance
… so you start with a schema:Person…and then describe more
… the point being that any use of the JSON-LD context implies…

Gregg Kellogg: you just require the @context include schema.org
… but if you don’t actually use the context, then you miss out on the extensibility points
… but you still wouldn’t depend on processing the context
… I’m agreeing with manu that what schema.org wants to do is very much like all the other groups wants to do
… and what we really need is some best practices for JSON-LD in “pure” JSON processing contexts

Dan Brickley: it’s tricky because we want to be able to be mixed with other vocabs

Manu Sporny: yeah, you get that with this approach
… you just have to be sure the schema.org is in there somewhere

Ivan Herman: loads of groups are doing this
… and in publishing’s case we’re using schema.org explicitly
… and we also describe if the only thing you want to do is push it into schema.org, then we make sure you know where that edge is
… if you want to do more complex stuff, then you might make it harder to process
… but the basics usually get picked up

Rob Sanderson: the IIIF docs: https://iiif.io/api/presentation/3.0/#46-linked-data-context-and-extensions

Ivan Herman: we call it a fixed shape
… tnx to bigbluehat
… but you are right that it is not documented
… and it’s on us to do that

Dan Brickley: that would be very helpful

Manu Sporny: I’m wondering if it’s a different conformance class

Dan Brickley: that would be nice

Gregg Kellogg: or at least a way to describe that there is additional restrictions

Ivan Herman: what happens if you want a specific shape of JSON
… that can be used for JSON-LD
… for the LD fans

Pierre-Antoine Champin: we already have a little of that in the @protected section

Pierre-Antoine Champin: but this could do with more details

Dan Brickley: many of these won’t ever got get contexts from anywhere

Manu Sporny: this approach allows exactly that

Gregg Kellogg: so one thing I might suggest is that now that we’ve added this HTML => JSON-LD linkage via rel=”alternate” in the HTTP header
… then you could call that requirement out lots of places

Dan Brickley: so it would just be a free form chunk of text explaining it

Gregg Kellogg: so best practices might spell out how you could do all that
… this application requires a specific shape
… so no further contexts would be processed

Dan Brickley: possibly nearby: https://www.w3.org/2017/dxwg/wiki/Main_Page#Profiles

Gregg Kellogg: but you’d still get the date from the one you want– and require it matches the shape

8. CR

Rob Sanderson: CR prereqs

Rob Sanderson: Privacy and I18n are good

Rob Sanderson: Not heard from a11y or security at all, but have pinged several times

Rob Sanderson: question about IANA registration of profiles as to when they are required

Rob Sanderson: have asked PLH about Process details

Rob Sanderson: No formal objections

Benjamin Young: a11y review request URL https://lists.w3.org/Archives/Public/public-apa/2019Sep/0025.html

Rob Sanderson: features at risk

Rob Sanderson: defined one today

Rob Sanderson: currently?

Rob Sanderson: tried to use it incorrectly

Gregg Kellogg: Framing has one

Ivan Herman: will need a list
… patent disclosures - no problem

Gregg Kellogg: json canonicalization scheme – should keep it

Ivan Herman: implementation information
… document exactly what our exit criteria are
… what do we expect and how to document it
… do we have that?

Rob Sanderson: no

Ivan Herman: a good time to define that
… clearly described, in a separate document
… should discuss it
… have example for evaluation form etc. from gregg
… dates are up to us

Rob Sanderson: baseline

Ivan Herman: What was official exit criteria for VCWG?

Rob Sanderson: is there any advantage to having a higher barrier to exit CR than the minimum

Manu Sporny: two independent implementations of each feature, where each feature is defined by a unit test.

Ivan Herman: What do we test?

Gregg Kellogg: Every feature, essentially.
… Many tests will test the same feature
… for example, testing framing also tests expansion.

Ivan Herman: The reason I’m saying this is because I can’t put this together myself… I need all this text.
… We will have a proper description on 1.0 vs 1.1 in the testing.

Gregg Kellogg: We mark every 1.1 test as 1.1

Ivan Herman: I need a clear description of all of this.

Gregg Kellogg: My report to you will have that in there.

Pierre-Antoine Champin: I don’t remember how we find the conformance criteria for RDF 1.1, but in the meantime a CG has maintained that test suite… my question is - what if the test suite continues evolving and new tests fails for implementations that did conform at some time?

Gregg Kellogg: once we’ve created a recommendation, something may fail that doesn’t take the relevant spec out of rec… that’s history.
… if the intent of adding those tests after the fact is to support the community in curating the spec and their own implementations… if there are issues that they reveal, it’s an errata.
… Errata can be marked inline now… well, soon… 2020 process update.
… By the time we need to add errata, it’ll be ready

Ivan Herman: No advantage in terms of process, but obviously if we go beyond what’s minimally required… can we say that we need 3 implementations for each feature?
… Or, we’ll need 2 impls for each feature and at least 1 complete implementation.

Gregg Kellogg: Why do we want to impose those requirements?

Ivan Herman: because we are HARDCORE!!!! throws chair across room

Pierre-Antoine Champin: that would send the wrong signal, wrt what we discussed this morning: it is ok to be only partially compliant

Gregg Kellogg: We know we can meet that bar, by why set it higher than necessary?

Ivan Herman: If we say, look - this has been implemented by 3-4 independent implementations…

Gregg Kellogg: I’m not sure we want to say that..

Ivan Herman: If we say that to the outside world… 15 implementations, all complete.. it makes the case way stronger.
… Only two… that’s the other end of the spectrum.

Gregg Kellogg: If we can get the Go, Java, and C++ folks… maybe Rust…

Ivan Herman: pchampin might do that

Pierre-Antoine Champin: uuuummmmmmmm…

Ivan Herman: Internally, we do try to get the bar higher, don’t want to state that officially….
… When we get two, we can say we are done… we go to PR, we’re done…
… On the other hand, we can say – we know we’ll pass, we’ll leave CR open, work on CBOR conversion (or whatever) and go to Director when we have 4-5

Gregg Kellogg: If we can see progress in more implementations, we should wait for them to appear.
… Yes, I’m doing Ruby, Python, and Javascript… we have to have Java, and we really should have C… and hopefully Go.

Ivan Herman: For wide review, do we have a list or feeling wrt. comments that came from outside of the group?

Gregg Kellogg: We can get that from issue list… have issues come in via email?

Rob Sanderson: Where would email have come into? I guess public, maybe we can check there.

Ivan Herman: Dependencies?

Gregg Kellogg: VCWG and schema.org

Rob Sanderson: We haven’t interacted w/ schema.org, but have talked w/ danbri repeatedly…

Gregg Kellogg: We said we’d coordinate, we should reach out for comments.

Ivan Herman: We should send a note considering that we’re feature freeze…

Action #2: send email to schema.org CG when final WD pre CR is available for review (Rob Sanderson)

Gregg Kellogg: What about VCWG

Manu Sporny: Charter ends at the end of this month, REC in early Oct.
… Might want to reach out to DID WG as well

Ivan Herman: Yes, can do that, reach out to those that exist…

Rob Sanderson: Also to reference TAG issues

Ivan Herman: When do we need to send these communications out?

Gregg Kellogg: several weeks, editorial work should be done by then.

Ivan Herman: Would help to have all material together 2nd half of October.

Action #3: send email to schema earlier (Rob Sanderson)

Action #4: set up empty wiki page with template for transition request to collect information (Ivan Herman)

Ivan Herman: Maybe what I could do, if you put an action on me, is a semi empty page on github wiki with headline that can fill in what I know and what is easy to do, as things come in, you put it there, we can send TR by refering to the wiki page.
… I will do that some time week.
… I think we’re…

Benjamin Young: say it… SAAAAY IT….

Ivan Herman: DONE!

Gregg Kellogg: we need some feature detection stuff… testing for that.

Rob Sanderson: we should wait to exit CR, then PR, then process train takes it down the track.

Ivan Herman: When we get from CR to PR, we need to repeat many of these things… update them, we’ll have to prove that implementations are done… from that point on, we have to be careful once the document goes to PR, then the only change to document between PR to REC are spelling mistakes.
… for those that may not be old timers… from the moment the CR is pubished on… there can be no technical changes on the document.

Rob Sanderson: if we have a REC in march, we don’t want to close the group because we still have other things we want to work on.

Ivan Herman: No harm in leaving document in CR… maybe something will come up.

9. Other Work

Ivan Herman: What about the Primer, CBOR, YAML, Best Practice?

Rob Sanderson: What are the priorities?

Gregg Kellogg: Best Practices, we have to have that.
… Primer is… we should have that.
… The others are nice to haves.
… There is a non-overlapping set of people working on those things…

Ivan Herman: Who may publish it as a CG document.

Benjamin Young: Can we transition them into a CG?
… if we don’t publish in time?

Ivan Herman: If the CG picks up a document that’s a NOTE, and puts it outside, no problem.

Gregg Kellogg: What if we do a maintenance WG?

Ivan Herman: We maintain the WG, we may copy certain notes… it’s all possible.
… We want to concentrate on best practices…

Rob Sanderson: Adam signed up to work on the Best Practices / Primer …

Benjamin Young: I signed up for it, but neither Adam nor I have been able to do anything on it.
… Depends on if Adam and myself should push this forward, or leave it in CG and push it up…

Gregg Kellogg: Have the WG publish it, at the same time.

Benjamin Young: The plan has, and still is, bring over everything in Best Practices document.

Rob Sanderson: So, we’ll try to move Best Practices forward to a NOTE.
… We’ll do this when we’re in CR.

Benjamin Young: There were conversations about combining JSON Schema and JSON-LD? Are we going to say something in Best Practices?

Gregg Kellogg: If we’re going to talk about Profiles, then that’s where it’s appropriate.

Rob Sanderson: Who is the intended audience for the Best Practices document?

Gregg Kellogg: Publishers…

Rob Sanderson: So it should be Publishing Best Practices…

Benjamin Young: Let’s do one document, different sections for Publishers, and Developers.
… Should rename to JSON-LD Best Practices
… We should have sections for authoring, consuming, publishing…

Rob Sanderson: Given our velocity, if we were to get through best practices… I expect it will be impossible for us to get to CBOR and YAML.

Gregg Kellogg: pchampin said he might have someone focused on CBOR…

Ivan Herman: We’d still have to go through the whole TR process….
… CBOR is interesting…

Benjamin Young: If any of manu’s claims are tenable… we might want to recharter to do that.

Manu Sporny: manu denies being a trustworthy source for rechartering criteria.

Ivan Herman: What we would have to do as a REC, it’s not 2 years work…

Benjamin Young: for the NOTE, it’s important that we have a note that we say that are opportunities…
… when we come to charter the JSON-LD thing, we can point to the NOTE.

Ivan Herman: We just discussed this w/ fantasai, depends on what she and Ralph and the others think about that.
… Let’s be optimistic, by the time we get to rechartering, Process 2020 may be in place…

Gregg Kellogg: We’re not limited to the REC we issue, we could decide to … as extension/maintenance… that and other closely related tech would remain in scope.

Rob Sanderson: I’m not convinced that NOTE is more powerful than CG document.

Benjamin Young: if BP should be a note, CBOR thing should be a note.
… It’s a signalling opportunity
… I’m saying, don’t let it drift down to a CG… keep it in the WG>

Ivan Herman: We’re all wildly in agreement, if possible, the CBOR stuff should happen.
… When should we think about rechartering?

Gregg Kellogg: Other than the CBOR stuff?
… Oh, you mean beside the rechartering for maintenance…

Benjamin Young: We should do before end of year

Ivan Herman: In this case, a bit different, we need 6 weeks for voting period, if we started in Feb… had 3 months, we would have to have some preliminary discussion, put it into voting bin…

Rob Sanderson: Into AC by …

Ivan Herman: mid-April
… On other hand, if there is a charter renewal going on… if we run out of Charter, W3M will extend.

Manu Sporny: \o/ VICTORY

10. Resolutions

11. Action Items