JSON-LD Working Group Telco — Minutes

Date: 14 Sep 2018

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Benjamin Young, David Newbury, Adam Soroka, Gregg Kellogg, Tim Cole, Jeff Mixter, Simon Steyskal, David Lehn

Regrets: Ivan Herman

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Tim Cole

Content:

1. Approve minutes

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

Proposed resolution: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-07-json-ld (Rob Sanderson)

Rob Sanderson: +1

Jeff Mixter: +1

Benjamin Young: Any objections to minutes from last call?

Gregg Kellogg: +1

Tim Cole: +1

David Newbury: =1

David Newbury: +1

Resolution #1: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-07-json-ld

Simon Steyskal: +1

2. Announcements / Reminders

Benjamin Young: now at fpwd stage!
… we now have 3 URLs
… also had a blog post go up

Benjamin Young: https://www.w3.org/blog/news/archives/7270

Benjamin Young: 1.1 specs are available for people to review and provide feedback
… by doing this, we are seeing some people taking a fresh look at json-ld and that is beneficial

Rob Sanderson: e.g. https://github.com/w3c/json-ld-framing/issues/13 and https://github.com/w3c/json-ld-framing/issues/14

Gregg Kellogg: next thing to discuss is policy and mechanism for regular working drafts

Benjamin Young: so, what cadence

Gregg Kellogg: yes, and we should have a relatively low bar when we update
… does anyone have experience keeping link checker happy?

Benjamin Young: do we want an issue about these matters?

Gregg Kellogg: will do.

Action #1: Gregg Kellogg to add issues related to continuous publication of working drafts

3. TPAC

Benjamin Young: getting close. Scheduled for Thurs and Fri of TPAC
… may also have an informal WG dinner earlier in week
… we have also put a doc up for discussing our agenda.

Benjamin Young: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#

Benjamin Young: includes rsvp for TPAC WG meeting and for those wanting to call in

Rob Sanderson: https://github.com/orgs/w3c/projects/4

Rob Sanderson: in the project we have a column for discuss face-to-face
… so people should add / move to make sure this column has all the items we want to cover in f2f
… as time allows we will then work our way through other issues

Simon Steyskal: will there be remote access?

Benjamin Young: we are planning on it - you can rsvp for that in planning doc

Jeff Mixter: +1 to remote access

Rob Sanderson: minor note - in the doc there is a list to TPAC reg list, includes people requesting observer status
… as of last week I told observers who had registered were welcome
… looks like a good group of observers

Benjamin Young: encourage others as appropriate
… any other announcements or agenda items for today?
… hearing none, we will proceed

4. Issues

4.1. IRI vs URL - https://github.com/w3c/json-ld-syntax/issues/25

Rob Sanderson: discussions a little quiet this week, but IRI vs. URL has gotten some discussion
… issue - should we adopt URL or should we stick with IRI
… for example, HTML has a note about why that spec uses URL, but Web annotation has a note from member from Sony about differences between URL and IRI
… on the table is idea to defer until it becomes more clear

Gregg Kellogg: microdata spec uses URL and includes some RDF, possibly providing a model for using URL in context of RDF

Benjamin Young: current Working Draft of the Microdata spec https://www.w3.org/TR/microdata/

Gregg Kellogg: issues lurking about impact on SPARQL, etc.
… probably this means we need a wider scope than just json-ld

Rob Sanderson: one of the editors of microdata is Dan Bri who is in this WG, another is Charles
… so lets grab them at TPAC and get a better sense of their feelings

Proposed resolution: Defer any change until the extent to which technical differences between URL and IRI can be determined, especially any difference between web browser and other stacks. (Benjamin Young)

Adam Soroka: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

Simon Steyskal: +1

Tim Cole: +1

David I. Lehn: +1

David Newbury: +1

Jeff Mixter: +1

Gregg Kellogg: another factor is whether json-ld use of IRI makes some people see json-ld as not web browser friendly

Resolution #2: Defer any change until the extent to which technical differences between URL and IRI can be determined, especially any difference between web browser and other stacks.

4.2. Inverse of @container:@set

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

Rob Sanderson: next is issue #17
… this came from a discussion with Dan that is broader than just schema.org
… so with @container @set, we can say if this resource is present then its always an array, even if a single item
… the issue in terms of expressing json-ld we don’t have the opposite
… we can’t say I would like it compacted to a single value rather than an array
… e.g., for reciepe use case was to show value for single step reciepe as a string rather than array
… so this would mean some changes to compacting

Gregg Kellogg: this impacts first, compaction

Rob Sanderson: +1 to gkellogg

Gregg Kellogg: but second how does a processor when expanding interpret a string value when defined that it could be array
… this latter seems to impact schema.org users and instruction to them especially
… I explained this in my last comment on the issue thread
… I personally don’t think the compaction issue is on its own a big deal, given that trend is encouragement to always use arrays when allowed as value for key

Benjamin Young: +1

Benjamin Young: the actual listing issue on allreciepes is microdata related because microdata can’t do lists
… so if run that use case through current microdata processor you get RDF that looks a little different

Gregg Kellogg: to beat a deadhorse - decision was made to not overcomplicate things, but when microdata is dumb, we shouldn’t want to dumb json-ld down to match

Benjamin Young: +1 to gkellogg yet again

Rob Sanderson: any other thoughts?
… to clarify expansion part of issue, what happens now if you have a single string value for a key that is defined to be an array

Gregg Kellogg: it gets turned into array

Rob Sanderson: so close, won’t fix, no compelling use cases

Gregg Kellogg: we could include note in primer

Proposed resolution: Close #17 won’t fix, as no use cases for compaction, and expansion already works as expected (Rob Sanderson)

Rob Sanderson: +1

Benjamin Young: +1

Jeff Mixter: +1

Gregg Kellogg: +1

Tim Cole: +1

David Newbury: +1

David I. Lehn: +1

Simon Steyskal: +1

Adam Soroka: +1

Resolution #3: Close #17 won’t fix, as no use cases for compaction, and expansion already works as expected

4.3. Recursion and @reverse - https://github.com/w3c/json-ld-framing/issues/5

Gregg Kellogg: issue #5 is about how framing for reverse properties, but not adequate support
… if you have a reverse property expressed in a frame, that property may have its own reverse properties, currently framing does not handle this
… so seems a good idea to improve, but devil is in the details
… this could be turned into an editors action, assuming we can get some support from other implementers

David Newbury: support this approach, we anticipate running into this issue at the Getty

Rob Sanderson: agree
… principle of least surprise
… so how does the WG feel about how we should continue to track and make sure it gets addressed?
… not ready to go into detailed solution on this call, but do need other implementers to work with gkellog

Gregg Kellogg: that sounds right - its partly a bandwidth issue of having a single editor

Proposed resolution: Accept framing#5 but seek additional support in terms of implementation experience (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Benjamin Young: +1

Tim Cole: +1

Simon Steyskal: +1

Adam Soroka: +1

David Newbury: +1

David I. Lehn: +1

Jeff Mixter: +1

Resolution #4: Accept framing#5 but seek additional support in terms of implementation experience

4.4. Indexing with a predicate

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

Rob Sanderson: issue #19 came up at Getty and IIIF over the past year
… it’s hard at API level to determine where you would find a repeated description of a resource
… e.g., there’s a bunch of items in a list with various properties
… if you building an application consuming descriptions as json (rather than RDF), it would be nice to be able to find these descriptions
… looking for a json surface level construct that makes it easier to find relevant descriptions further down
… there has been promising development, but relies on a new keyword
… so, do people support the feature? and then if yes, we can talk about solutions.

Gregg Kellogg: we can certainly come up with solutions, but is this semantic overhead we want to add to json-ld just because it’s available in other approaches
… framing may help with this, but would result in repetition of statements
… consistent with RDF which is happy with repetition of statements, although that is not a natural json approach
… question is whether framing/repetition approach is sufficient

Jeff Mixter: agree with usefulness of this, would be super-convenient
… but I do have concerns about adding a keyword to do this
… and I do think like @gkellog that there may be ways to do this without a new keyword

Benjamin Young: my concerns echo Jeff’s. We should look at how close we can get to this without existing json-ld mecahnisms
… and not move forward with introducing something new until we’ve exhausted existing options

David Newbury: when we started on this we tried 3 ways
… the size of the document you have to send over the wire gets large, really verbose

Gregg Kellogg: of course it is compressed when sent over the wire

David Newbury: 3rd way we’ve done this is with reverse properties
… saying this concept is inside this container, etc.

Rob Sanderson: http://iiif.io/api/auth/1.0/#example-description-resource-with-authentication-services

Rob Sanderson: to give a sense of repeated data (see link above)
… in IIIF we have idea of authentication service, which needs to be repeated for each resource

David Newbury: http://aat-web-services-staging.getty.edu/aat/300390918.json

Rob Sanderson: so service block in example linked above is actually about the shortest

David Newbury: is the example of where we’re doing it, with the seeAlso predicate

Rob Sanderson: and if you repeat it 500 times in the same document, the memory usage gets rediculous
… may not be significant for modern browsers, but does become problem in mobile environment

Gregg Kellogg: wondering how much this comes down to a data modelling issue?
… can you model it by indirect reference approach?
… this is more like what the framing would support

Jeff Mixter: +1 to the reference to a separate node for the iiif service issue

Gregg Kellogg: you end up with references rather than having to include
… we’re looking for another way to avoid repeating all properties up at node level

David Newbury: in most consuming applications we’ve been using, the practice they recommend is shallow references as opposed to deeply nested structures
… so we end up building a flatter structure
… having a pattern that allows expressing in flatter structure would be good

Jeff Mixter: i agree with David’s comments
… want to differentiate between graph-based use cases and IIIF use cases that want to cache and focus on json, not the RDF

Gregg Kellogg: I’m wondering, should we explore a new framing mechanism as a way to address this?
… something indirection mechanism in the framing
… might not end up with round tripping solution
… or do we need to keep in the existing expansion / compression options

Adam Soroka: you’re talking about a way to add to document when framed

Gregg Kellogg: yes, for example if framing could allow you to pull info from references into the object being framed
… don’t have full solution yet, but trying to explore solution space

David Newbury: I think this goes beyond framing, more about how we structure the data
… the rdf should be the same however we do it
… could end up with data section and included section

Adam Soroka: some of the same concerns come up when we talk about using context to add new data
… always a little worried about solutions that draw beyond the source, you end up with multiple sources

Gregg Kellogg: We might reconsider @default, then

Rob Sanderson: noting it is top of the hour, first agree with Adam, also agree this is a framing (rather than compaction) issue

Adam Soroka: gkellogg: yes, and I admit that I don’t have clear thinking about that

Rob Sanderson: let’s have a bit homework on this one.
… please find examples and add to the issue, and look at framing rather than compaction
… and add use cases
… not ready to resolve, but this discussion was promising. Revisit next week.
… Adjourn

Adam Soroka: bye y’all

5. Resolutions

6. Action Items