JSON-LD Working Group Telco — Minutes

Date: 2019-01-04

See also the Agenda and the IRC Log

Attendees

Present: Pierre-Antoine Champin, Ivan Herman, Benjamin Young, David Newbury, Adam Soroka, Gregg Kellogg, Jeff Mixter, Harold Solbrig, Tim Cole, David I. Lehn

Regrets: Rob Sanderson

Guests:

Chair: Benjamin Young

Scribe(s): Adam Soroka, Benjamin Young

Content:

1. Approve minutes of previous call

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-12-14-json-ld

Adam Soroka: +1

Jeff Mixter: +1

David Newbury: +1

Harold Solbrig: +1

Resolution #1: last year’s last minutes accepted

2. 2019 Winter Face-to-Face - February 7-8 in Washington, DC

Adam Soroka: if the govt is open at the time.
… if it’s closed, these buildings will not be open
… I’m consequently on furlough at the moment
… and my time will need to go elsewhere depending on how this plays out
… however the F2F is scheduled in a government office
… so if that doesn’t change, we won’t be able to meet there

Benjamin Young: [general moans, etc]

Benjamin Young: will investigate Wiley as an alternative host

Benjamin Young: which would imply rebooking flights

Ivan Herman: that’s a problem!

Benjamin Young: yes, let’s try to meeting DC, to avoid changing tickets

Tim Cole: we might want to find a contact at UMaryland

Harold Solbrig: +1

Adam Soroka: I do know some of those folks too, and would be happy to take that on

David Newbury: Could reach out to the Folger Library

Benjamin Young: also I know some folks at the American Geophysical Union

Harold Solbrig: potentially JHU could host if needed, but sounds like we have some options closer

Benjamin Young: let’s list our potential sites in the planning Google Doc

Harold Solbrig: Shall we set a cut-off date for this?

Ivan Herman: end of the month?

Benjamin Young: Yes, 31 jan

Benjamin Young: let’s use the google Doc with the agenda to plan this as well

Benjamin Young: https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit

3. Pending Pull Request: Improve [framing] intro

Benjamin Young: https://github.com/w3c/json-ld-framing/pull/33

Benjamin Young: there’s a PR pending review, has had some feedback

Benjamin Young: dlehn offered some tweaks
… if folks could help move that forward, that would be great

Ivan Herman: this seems editorial
… can just leave this to the editor

Benjamin Young: just announcing this to make sure everyone knows what’s about tto be merged

4. Issues

4.1. HTTP parameters for specifying context or frame

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

Benjamin Young: * syntax - https://github.com/w3c/json-ld-syntax/pull/111

Benjamin Young: * framing - https://github.com/w3c/json-ld-framing/pull/34

Benjamin Young: * api - https://github.com/w3c/json-ld-api/pull/56 (work in progress)

Benjamin Young: gkellogg has the lion’s share of the work done on this

Gregg Kellogg: the first PR (syntax doc, #111) pretty much ready to go
… removed language about quotes for the value of profile params
… which is not true in general
… only if multiple URIs are used, and added some examples with different types of profile params

Ivan Herman: I had a comment on that
… content, not editorial
… a sentence says that JSON-LD processors may restrict URIs for context and frames
… which I read as saying, “If I’m a JSON-LD processor, I can refuse any context except this particular one”
… is that really what we mean

Gregg Kellogg: well, this could become an attack vector, so we allow servers to restrict the action

Gregg Kellogg: framing is potentially expensive computationally
… and people have demonstrated attacks via context
… which we think we’ve mostly fixed, but obviously we can’t rule it entirely out
… going back to the CG, there was this desire to restrict present there

Ivan Herman: i have two problems…
… this is clearly non-editorial
… have we discussed/voted on this restriction?
… shouldn’t be in an editorial PR.
… I don’t understand the problem this solves

Gregg Kellogg: this is part of the request header.

Ivan Herman: oh, the request header? (not the response)

Gregg Kellogg: this signals the server as to what the client wants
… the server must examine the profile param and if it isn’t acceptable, return a 406
… this new language just gives license to the server to do just that if the context is unacceptable
… you could also fall-back in various ways

Ivan Herman: Okay, I misunderstood what was done, so that’s okay
… but still, this is more than editorial

Gregg Kellogg: I don’t say that this is editorial
… I folded in the previous discussions on this

Ivan Herman: sorry for the interrupt, fine with this. I will put in a link to this discussion into the PR
… must be documented, now it is
… we just want to document that everyone is fine with this

Benjamin Young: I’ve got a nit
… about the quotes being optional save for multiple URIs

Gregg Kellogg: for spaces
… and I show examples of this
… we don’t mandate that single spaces must be used
… it’s just whitespace as defined by the rFC

Benjamin Young: okay, thanks

Gregg Kellogg: we have also the PR for the API doc

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

Gregg Kellogg: there is w-i-p on the API at that PR
… framing was a more minor change

Gregg Kellogg: https://github.com/w3c/json-ld-framing/pull/34

Gregg Kellogg: the controversial point bigbluehat raised is whether adding a framing URI changes the semantics enough to make it inappropriate
… as a profile param
… online discussion indicates not
… the change requires the profile param
… which changes current behavior for people requesting frames
… there might b more changes requireed for this for optinality

Gregg Kellogg: the idea was that a frame would be represented by a mimetype
… but no one implemented that
… and now we’ve moved to using a profile param for frame
… so the question is, must the profile param appear, or is it optional/advisory
… this param is for getting a doc that is a frame
… and would appear on the response as well

Benjamin Young: yes, we would want that on the response as well

Benjamin Young: https://tools.ietf.org/html/rfc6906

Gregg Kellogg: we need more discussion on that PR

Adam Soroka: https://github.com/w3c/json-ld-framing/pull/34

Gregg Kellogg: the API PR (https://github.com/w3c/json-ld-api/pull/56) is just tests for this new behavior
… I couldn’t see what language to add to the API, otherwise
… the API do is concerned with what happens once you’ve requested a doc and are processing the result
… we don’t need to specify how to use an Accept header

Benjamin Young: this would only be for requesting a single doc in various representation
… I’m glad that framed docs aren’t new mediatypes
… but it seems unlikely that one document would be all the things at once (frame, context, instance)

Gregg Kellogg: but you aren’t requesting a doc, you are requesting a resource.
… e.g. for SPARQL users

Gregg Kellogg: profile contains one or more of our URIs, as well as URLs to contexts, frames, etc.

David Newbury: a real-world example: we have resources we’d like to be able to provide either as schema.org or CIDOC-CRM
… same data, difference context/framing

Gregg Kellogg: only the non-registered URLS would be treated as dereferencable
… similar to when the mimetype is just application/json and you stick the contet in a header

Benjamin Young: this is where I get concerned about violating the RFC– the profile param shouldn’t be dereferenced

Gregg Kellogg: good point…
… my impression was that we could define this behavior, but we do need to review

Benjamin Young: in the Web Annotation we avoided triggering new representations via the profile param, only selecting from extant representations

Ivan Herman: https://tools.ietf.org/html/rfc6906

Benjamin Young: this is a supernice feature, but is this where it belongs?

Ivan Herman: what the RFC (https://tools.ietf.org/html/rfc6906#section-3) does say is:

“A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation.”

Benjamin Young: There is also https://tools.ietf.org/html/rfc4288#section-4.3

Ivan Herman: so this may indeed be a problem

Gregg Kellogg: the use of a context does not change the semantics of a representation, just the syntax

Benjamin Young: it’s the functionality concern
… if these are URLs (not merely URIs) they will be looked up and used for computation

Ivan Herman: it is an identifier; to quote further from https://tools.ietf.org/html/rfc6906#section-3:

“Profiles are identified by URI. However, as is the case with, for example, XML namespace URIs, the URI in this case only serves as an identifier,”

Ivan Herman: it is at the beginning of that section

Gregg Kellogg: rfc4288#section-4.3 is a different case of profile: that’s the header vs the mimetype

Gregg Kellogg: e.g. dc:name vs schema:name
… totally different graphs
… but for framing, it’s the same graph
… and client can reframe or re-compact or whatever
… for bigbluehat’s case, where there’s a range of possible contexts…
… two ways to interpret that: first, I want the Schema context vs the DC context
… or, I want “name” vs “schema:name” where the terms used are different

Benjamin Young: in the case of conneg, you could list several contexts
… and the sever will compute on your request and select something
… that’s not a processing instruction
… that’s a great idea, but it should go in a different box

Pierre-Antoine Champin: not fully agree with gkellogg about changing strings in the JSON for different contexts
… in both cases, the semantics are the same
… the condition for selecting different vocabularies is that the semantics of the vocabularies is the same
… in both cases, the changes are at the syntax level, just at concrete or abstract syntax

Gregg Kellogg: if we look at the test suite, what might be considered?
… one, you can take the result, expand it, and compare
… or two, turn them into RDF and compare the graphs for isomorphism
… (or in framing, a strict subgraph relationship)

Ivan Herman: +1 to gregg

David Newbury: I’m assuming that I have all the data and am just selecting from it, not doing new processing

Ivan Herman: whither shall we wander?
… what do we do if profiles are not the correct choice?
… our own request header?
… is there an extant header we can adopt?

Benjamin Young: Profile seems like the wrong vehicle for this signaling, but we cannot discard the use case

Proposed resolution: limit profile parameter use to URI’s, but continue to pursue an alternative to the profile media type parameter for client-signaled frames and contexts URLs for servers to (potentially) use when providing responses (Benjamin Young)

Gregg Kellogg: https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld

Gregg Kellogg: we might borrow from the way we handle application/json
… in a response header, we add a link header targeting the context
… we could use a Link header on the request

Ivan Herman: we would need a more detailed description

Benjamin Young: https://tools.ietf.org/html/rfc8288

Benjamin Young: you sure can use a Link header on the request
… but let’s get to a proposal
… we need to get URLs out of the profiles
… and there is clear desire in the group for this functionality
… link rel= might be a nice way to do that

Proposed resolution: limit profile parameter use to URI’s, but continue to pursue an alternative to the profile media type parameter for client-signaled frames and contexts URLs for servers to (potentially) use when providing responses (Benjamin Young)

Gregg Kellogg: +1

Benjamin Young: +1

Adam Soroka: +1

Jeff Mixter: +1

Harold Solbrig: +1

Tim Cole: +1

Ivan Herman: do we suspend all three PRs?

Gregg Kellogg: not necessarily framing, but that needs its own discussion

David Newbury: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Gregg Kellogg: if there is no actual language in the API doc, the tests that have been added there might belong in the syntax doc

Resolution #2: limit profile parameter use to URI’s, but continue to pursue an alternative to the profile media type parameter for client-signaled frames and contexts URLs for servers to (potentially) use when providing responses

Benjamin Young: let’s leave it to gkellogg as to how he’d like to manage the PRs, whether to add more commits or start afresh or whatever

4.2. Content addressable contexts & hashlink

Benjamin Young: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0000.html

Ivan Herman: it is interesting, no doubt
… (puts admin hat on)
… these are very early drafts
… Manu made this proposal in December, very early days
… we’re fine, though.
… if the technique becomes a standard form for URIs, we can use it as such
… I’m happy to have us say that we are interested
… we should try to see whether this tech really can be used to annotate links while we also pursue other avenues

Gregg Kellogg: really like the idea, could be very useful

Gregg Kellogg: but not clear that it really affects our docs at all
… what would we change?

Ivan Herman: we shouldn’t close issues just because this new thing is a new thing

Gregg Kellogg: unless we think that we can do that via a reference in the best practice docs

Adam Soroka: if hashlink solves for problems we have, then we may not want to recreate alternative features that solve the same issues

Benjamin Young: although this new hash URI tech isn’t standardized, it has been put into use

5. Resolutions