JSON-LD Working Group Telco — Minutes

Date: 2018-10-12

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Adam Soroka, Ivan Herman, Gregg Kellogg, Jeff Mixter, Tim Cole, David I. Lehn

Regrets: Simon Steyskal, David Newbury

Guests:

Chair: Rob Sanderson

Scribe(s): Jeff Mixter

Content:

1. approve minutes

Proposed resolution: approve minutes of the last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-10-05-json-ld (Rob Sanderson)

Gregg Kellogg: +1

Adam Soroka: +1

Rob Sanderson: +1

Jeff Mixter: +1

Ivan Herman: +1

Resolution #1: approve minutes of the last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-10-05-json-ld

2. Logistics

2.1. TPAC

Rob Sanderson: Draft Agenda for TPAC F2F: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#

Rob Sanderson: have a look at the draft agenda for TPAC meeting. discusses issues that we need to talk about in our face to face meeting with reasonable chunks of time and tries to not overlap with other groups
… breaks are end times are still up in the air

Adam Soroka: lunch is fixed?

Rob Sanderson: yes
… hour for lunch seems good. Half hour for breaks
… some breaks can be moved but not the ones next to joint meetings

Ivan Herman: nice park nearby to decompress…

Rob Sanderson: there are blocks of time we might want to talk about

Gregg Kellogg: 1:30 - 3:30 blocks seems like it could go long
… we have time on Friday to do follow-up on things

Rob Sanderson: friday afternoon we could compress the 1:30 - 3:30. Or push on to 5:30 and have hour and a half slot

Adam Soroka: how quickly can we get to an agreement but leave a few details for Greg and others to sort out details?

Adam Soroka: 11:00 -12:30 is that part of the joint meeting?

Rob Sanderson: yes
… issue that we have that others care about

Adam Soroka: we have common things with Web Of Things. Do we have set things to chat about or is it just a grab bag of things?

Rob Sanderson: there was a long email this morning about stuff to talk about. more to come later on that
… certain things will likely be really important like Contexts - don’t want your smart frig freaking out

2.2. Echidna update

Gregg Kellogg: as of last night we did get all 3 specs through. Sent out links to the mailing list. One of them will appear to to be published on Friday and the other 2 on Saturday. Only can publish from the master branch. It needs to publish with something that respec can render
… one suggestion was to use raw Git but it is at end of life and there are a few exploits
… respec might be able to do this. But the mime type needs to be really specific. Just make sure Master is what we want to publish and then push to the Publication branch
… update specs so the previous version is OK. Do not publish diffs from the previous version. We are encouraged to do that but requires some manual work
… feedback on that?

Ivan Herman: this will remain a manual thing. Which might be better because diffs on spelling mistakes are rather useless. If we make it auto - we will get tons of diffs on minor editorial changes

Rob Sanderson: any further thoughts/questions?

Gregg Kellogg: we started maintaining class diffs that allow us to highlight the change sections. We could simply that if we want
… whole mech could stand to be styled better

Ivan Herman: we can publish a new version at any time so we need to create a strategy on how/when to publish

Benjamin Young: make some issue for highlighting and styling
… happy to help with some of these

Jeff Mixter: .. they are really nice and helpful

Gregg Kellogg: the example buttons are another example

3. Issues

3.1. IRI Compaction wording

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/75

Rob Sanderson: first one seems like a misunderstanding about the algorithm. Greg clarified in the issue. no issue and we can close

Gregg Kellogg: maybe more descriptive overview could be helpful

Ivan Herman: the comment came in 8 days ago and the response came in 8 days ago as well. We should probably wait 1 week when we have issue from external members.

Rob Sanderson: close or make note about editorial changes?

Adam Soroka: +1 to editorial.

Gregg Kellogg: make it editorial and look to make sure the description is more robust

Ivan Herman: marked as editorial and will add reference to the notes

Rob Sanderson: we can close without further discussion

Proposed resolution: Mark #75 as editorial, for Gregg to consider whether additional text is needed to explain how to read the algorithm steps (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Jeff Mixter: +1

Ivan Herman: +1

Adam Soroka: +1

Benjamin Young: +1

Tim Cole: +1

Resolution #2: Mark #75 as editorial, for Gregg to consider whether additional text is needed to explain how to read the algorithm steps

3.2. Node types in @context

Ivan Herman: Link: https://github.com/w3c/json-ld-syntax/issues/76

Rob Sanderson: I think this falls into the out of scope category.
… close with a will not fix with other issue as precedence. kick back to community group for how this should be handled in the future

Gregg Kellogg: no need to kick it to the community group. This can be done with framing.

Rob Sanderson: the desire was to not have explicit but rather implicit defs
… i.e. adding triples via the context

Adam Soroka: note that once again this issue revolves around type of dataype and type of resource. We are not going to change this. We need to document this very clearly to help prevent this type of misunderstanding

Ivan Herman: agree with Adam and additionally framing seems more like presenting the data based on a template. But since framing can be used for transformation then it must be emphasized much more than it currently is.

Benjamin Young: ditto on Ivan
… need to better describe framing and what it is and what it can do
… this desire from the issue is not the first time we have heard this issue. We should look at them and ask if framing can do this, why are people not finding it?
… this problem will not go away

Tim Cole: tend to agree that framing is powerful for data transformation. But framing conflates a bunch of processing and slows things down in general. Might want to consider that and debate if we should pull things apart a bit

Gregg Kellogg: Add content using @default

Rob Sanderson: want to clarify that my understanding of framing is that adding data to the graph is by @reverse properties and with @default but these do not allow you to randomly move data around.
… we could be clearer about this but also be opinionated about what it should do and what we are willing to add
… adding a bunch of stuff is not ideal. Keep it simple and focused

Adam Soroka: agree with Ben and impression is that we see this so often because framing is newer and there is less uptake
… is it out of our arena to introduce a document that demonstrate how to do what Tim’s student wanted to do?

Gregg Kellogg: to the last point, we could/should add this to the framing document. We should also add some to the API document that separates transformation and points them to the framing doc
… about how far we go, we could imagine framing as more of query language. There was push back - it is for framing. Framing is not that.
… there is a upcoming W3C workshop about standardizing graph data

Rob Sanderson: do we put in a reference to framing or should we just close it?

Benjamin Young: I asked about that issue and I think we should point arrows between specs. I am planning some work and would like help with encouraging and pointing people to the right spec

Rob Sanderson: give a few days more and mark it as editorial

Proposed resolution: Mark #76 as editorial for Gregg (et al) to consider pathways between specs such as API to Framing (Rob Sanderson)

Gregg Kellogg: +1

Jeff Mixter: +1

Rob Sanderson: +1

Tim Cole: +1

Ivan Herman: +1

Adam Soroka: +2

Adam Soroka: +1

Benjamin Young: +1

Resolution #3: Mark #76 as editorial for Gregg (et al) to consider pathways between specs such as API to Framing

3.3. Empty Lists

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/18

Gregg Kellogg: couple of things. How to assert there is nothing? Sort of counter to RDF but you can create an empty list
… one issue, is rdf:null the same as an empty list?

Rob Sanderson: Similarly, rdf:type / @type are not identical

Gregg Kellogg: we do not turn rdf:nil into an empty list
… should we have something to encode this in JSON-LD?
… this can go away in compaction so the info might be lost
… there is a null keyword that could be used
… seems like a way to complicate a narrow issue. More of an editorial explanation

Ivan Herman: add one more problem - we have the situation in JSON-LD that [] as a syntax is used 2 diff ways based on context. If we introduce and use [] as valid syntax, we would create invalid graphs
… if the object is a set of objects, we might create graph with subject predicate but no object

Rob Sanderson: @container:@set vs @container:@list

Gregg Kellogg: the algorithm would not allow that

Ivan Herman: but in JSON-LD I create a valid triple or an error

Gregg Kellogg: if it is not valid, it just would not produce anything

Ivan Herman: [] present potential errors

Gregg Kellogg: the expansion algorithm removes properties whose values are null
… the RDF transform would throw out an empty array

Rob Sanderson: you would only end up in this state if it was @container : @list
… are we OK or should we talk more next week
… editorial or close

Gregg Kellogg: seems editorial but we have a lot of that now. So maybe just close

Proposed resolution: Close #18 nothing to do, as we don’t process rdf: terms separately in the syntax (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Tim Cole: +1

Gregg Kellogg: +1

Benjamin Young: +1

Jeff Mixter: +1

Adam Soroka: +0

Resolution #4: Close #18 nothing to do, as we don’t process rdf: terms separately in the syntax

4. Resolutions