JSON-LD Working Group Telco — Minutes

Date: 2019-05-03

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Ivan Herman, Ruben Taelman, Benjamin Young, Dave Longley, David I. Lehn, Pierre-Antoine Champin, Adam Soroka, Jeff Mixter, tim cole, Rob Sanderson

Regrets:

Guests:

Chair: Benjamin Young

Scribe(s): Pierre-Antoine Champin, Dave Longley, Ruben Taelman

Content:

1. Approve minutes of previous call:

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-26-json-ld

Benjamin Young: +1

Ruben Taelman: +1

Dave Longley: +1

David I. Lehn: +1

Pierre-Antoine Champin: +1

Resolution #1: last week’s minutes accepted

2. Announcements / Reminders

Benjamin Young: Ivan and I will be at the Publishing WG next week
… The call on the 17th is during The Web Conference. Should we cancel?

3. Issues

3.1. Indexing without a predicate

Benjamin Young: link: https://github.com/w3c/json-ld-syntax/issues/19

Gregg Kellogg: Related https://github.com/w3c/json-ld-wg/issues/52

Benjamin Young: this is issue is also known as @included
… proposed by azaroth
… there is a related proposal by gkellogg

Gregg Kellogg: there are several ways of doing something like id-ref
… one of them would be to combine @nest and @container:@id
… Rob’s proposal would better be handled in expansion (this is where syntactic sugar is removed).
… Properties declared as e.g. @container:@include would look into a special @include container.
… Problem with compaction, which can not easily reverse this kind of extension.
… More appropriate in Framing.
… Seems quite complex and convoluted, with a lot of corner cases.

Ivan Herman: azaroth asks to defer that topic until he can join

3.2. More compact @prefix

Benjamin Young: link: https://github.com/w3c/json-ld-api/issues/76

Gregg Kellogg: related: https://github.com/w3c/json-ld-api/pull/77

Benjamin Young: proposal from rubenworks, to make it simpler to declare @prefix terms

Ruben Taelman: a similar thing is already possible with @reverse, so it should not be too hard to add in implementations

Dave Longley: is this an error?
… what do we do when @id and @prefix are both strings and they disagree? is that an error?
… my understanding is that the proposal is that "@prefix": `` is just syntactic magic for `"@id": ``, "@prefix": true` … not a replacement

Gregg Kellogg: it is with @reverse, so it should be an error, yes
… there is a point in the issue about terms which are not appropriate as prefixes
… there are two aspects in the PR: 1/ use @prefix where the value is an IRI, while the current practice is to use @id with an IRI, and @prefix is a boolean. Should we obsolete the current practice?
… 2/ what if the value of @prefix is a pname?

Ruben Taelman: [answers to gkellogg]

Gregg Kellogg: we must keep in mind the JSON 1.0 behavior

Ruben Taelman: I see this as an alternate representation

Ivan Herman: does the combination of @id and @prefix:false come up in practice?

Gregg Kellogg: there are reasons to use it. I don’t know if it is used in the wild?

Ivan Herman: that would be a reason to keep the current practice, and consider the new version as a shorthand
… and I wouldn’t be shocked if the new notation @prefix:IRI was roundtripped to @id+@prefix:true

Gregg Kellogg: we don’t roundtrip contexts anyway

Benjamin Young: there seems to be a consensus on considering the proposal as a shorthand for the current syntax

Benjamin Young: https://w3c.github.io/json-ld-syntax/#compact-iris (for current text)

Gregg Kellogg: there are some implications; must be some working on the implications of combinations of @id and @prefix
… you probably would not use the prefix term as a property

Dave Longley: perhaps if @prefix is a string, then also including @id is an error … and then process @prefix as a string first and do the transformation to @id: `, @prefix: true`

Benjamin Young: https://w3c.github.io/json-ld-syntax/#example-32-using-explicit-prefix-declaration-to-create-compact-iris

Benjamin Young: @id+@prefix:true feels a lot like using @vocab

Gregg Kellogg: it works a little differently in the compactIRI algo
… we are going contrary the trend of moving compact IRIs away
… the reason it is there is that, in 1.0, many terms were used to build compact IRIs, but were not intended to do that
… eg: Sport := schema:Sport, then using Sport:Event
… @prefix was a way of capturing the intention of the creator of the term

Dave Longley: lots of unwanted CURIEs being greedily generated in 1.0

Benjamin Young: strange compact IRIs can be used maliciously, to misdirect users to an unexpected endpoint URL

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/155

Dave Longley: I like the syntax, makes it more obvious that the term is intended to be used as a prefix
… even though I don’t like CURIEs in general
… in JSON-LD
… It was a mistake in 1.0 to allow any term to be used as a prefix

Benjamin Young: curie spec https://www.w3.org/TR/curie/

Benjamin Young: I agree with that

Pierre-Antoine Champin: Proposal is not to make @prefix:false the default?

Dave Longley: No

Gregg Kellogg: we did change 1.0 behavior by limiting the terms that can be used as prefixes
… only IRIs ending with gen-delims can be used as prefixes

Dave Longley: instead of just “property”

Benjamin Young: gendelim https://tools.ietf.org/html/rfc3986#section-2.2

Ivan Herman: what does @prefix:false means?

Ivan Herman: for the records: https://tinyurl.com/yxw7qv98 (example)

Gregg Kellogg: it means that we do not want this term to be used by compaction to generate a compact IRI

Gregg Kellogg: https://w3c.github.io/json-ld-syntax/#example-32-using-explicit-prefix-declaration-to-create-compact-iris

Gregg Kellogg: for expansion, it does not matter whether @prefix is true or false

Dave Longley: if you click on compact in the link above
… by copying the context to the right and changing the value of @prefix
… you can see the difference
… but you can’t make a term only a prefix, this is a 1.0 problem, we can’t go back

Gregg Kellogg: but we could define @prefix:IRI to mean exactly that
… but we still mean @prefix:false

Dave Longley: yes, but that would differ from what we said earlier. This is not syntactic sugar anymore

Pierre-Antoine Champin: another way would be add 3 values for @prefix

Rob Sanderson: +1 to PA

Pierre-Antoine Champin: @default would say you can use this prefix as a term
… false as you can not use this as prefix
… true, the proposed new meaning that gregg proposed about @prefix IRI
… this way we can keep backwards compatibility with 1.0

Proposed resolution: dlongley and pchampin to craft alternate proposal to #76 with @prefix having 3 values (Benjamin Young)

Gregg Kellogg: +1

Adam Soroka: +1

Benjamin Young: +1

Ruben Taelman: +1

Ivan Herman: +1

Dave Longley: +1 sure

David I. Lehn: +1

Dave Longley: the third value would be an IRI, and we’re back to what gkellogg just proposed

Rob Sanderson: +1

Resolution #2: dlongley and pchampin to craft alternate proposal to #76 with @prefix having 3 values

4. spec release cadence

Gregg Kellogg: we are processing issues slowly
… we have not released a draft in a while

Benjamin Young: discussing this column: https://github.com/orgs/w3c/projects/4#column-3279307

Gregg Kellogg: some issues in the management console are editorial work
… [enumerates which issues should be addressed after or before the next working draft]
… I would like to segment the issues for discussion,
… between those who are standing in the way of releasing a WD,
… and those that can be discussed afterwards

Gregg Kellogg: … https://w3c.github.io/json-ld-syntax/#inheriting-base-iri-from-html-s-base-element

Dave Longley: +1 to consolidating all the HTML stuff under document loader

Ivan Herman: we can close the issue about HTML base; there is a text in the document

Gregg Kellogg: another editorial issue is pushing forward the documentLoader,
… so that we can move all the HTML processing into the documentLoader
… problem: this changes the interface of the documentLoader,
… so might be consider as a backward compatibility issue

Rob Sanderson: +1 as well

Rob Sanderson: working drafts are just… working draft
… we can release one now, as long as the editors are not embarrassed by what’s in there
… it is still to be considered as work in progress anyway

Ivan Herman: +1 to azaroth

Rob Sanderson: we don’t need to finish anything before releasing it

Gregg Kellogg: given how long it’s been since the last WD, the next one is going to be quite consequential
… if we decide to defer the discussion on documentLoader, I can release a WD this afternoon
… We still should address bigbluehat’s discussion about contexts being IRIs (identifiers) or URLs (dereferenceable)

Dave Longley: I’m surprised that the spec says that documentLoader returns a string;
… any other text in the spec is written as if it returned a document
… so the returning a string is a spec error

Gregg Kellogg: I agree. This could be fixed easily.
… The error may have been introduced after 1.0, with the migration to the next ReSpec version.

Benjamin Young: regarding my remarks on contexts IRI vs. URL,
… the abstracting behind documentLoader would solve that problem.
… Putting this change in a WD, very early after we have discussed it,
… would be new for this WG. We have to be aware of that.

Dave Longley: I checked: the problem with the definition of documentLoader was not in 1.0; it has been introduced by 1.1.

Proposed resolution: gkellogg should publish a new WD containing the proposed documentLoader changes https://github.com/w3c/json-ld-api/issues/85 which will be discussed at a future time. (Benjamin Young)

Dave Longley: so we can safely fix it back.

Gregg Kellogg: +1

Dave Longley: +1

Ruben Taelman: +1

Benjamin Young: +1

Rob Sanderson: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

Tim Cole: +

David I. Lehn: +1

Tim Cole: +1

Resolution #3: gkelloggg should publish a new WD containing the proposed documentLoader changes https://github.com/w3c/json-ld-api/issues/85 which will be discussed at a future time.

5. Resolutions