JSON-LD Working Group Telco — Minutes

Date: 2018-09-07

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Adam Soroka, David Newbury, Gregg Kellogg, Benjamin Young, Jeff Mixter, Harold Solbrig, Simon Steyskal, Ivan Herman, David Lehn

Regrets: Tim Cole

Guests:

Chair: Benjamin Young

Scribe(s): Jeff Mixter

Content:

1. Approve minutes of previous call

Rob Sanderson: approve minutes of previous call

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

Rob Sanderson: +1

Gregg Kellogg: +1

Adam Soroka: +1

Jeff Mixter: +1

Benjamin Young: I+1

Benjamin Young: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-31-json-ld

2. Announcements / Reminders

Rob Sanderson: TPAC reminder
… Open call for consensus - have until next week to agree or disagree

Gregg Kellogg: the parts of the proposal sit in frozen repos - can we go ahead and merge those pull requests?

Rob Sanderson: yep we should do that and will do that

Benjamin Young: if folks are new to W3C it might be helpful to go over first working draft stuff

Jeff Mixter: yep that would be helpful

Ivan Herman: it is putting stake in the ground. Not binding but gives a general idea of where the group is going
… this case is special because we already have full-blown working draft. typically the first draft is very sparse and includes mostly section headings and what the group will do

Benjamin Young: W3C Process doc section on FPWD https://www.w3.org/2018/Process-20180201/#first-wd

Ivan Herman: hopefully things are all in order for publication next Tuesday

Rob Sanderson: first public working draft has more requirements then later drafts due to initial overhead

Ivan Herman: it will be easier than the annotation work stuff hopefully. Has sent out a green light request and then send a note to the webmaster to pick up the document and publish it. Once this is done, we can set up an automatic procedure for updating
… some groups no longer have editors draft and any change is published directly to the master. But the generation process is pretty much automatic. This works up to candidate req.

Gregg Kellogg: the barrier to continuous publication is related to the automatic configuration settings

Ivan Herman: in the initial phase things are not so strict

Ivan Herman: once we get to more formal steps we will get back to more strict ways
… just waiting for a response

3. Issues

3.1. JSON Literals

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

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/4#issuecomment-418857569

Benjamin Young: first issue is number 4. there had been an agreement in past meeting to close but it was brought back up. Further discussion on GitHub and there is now a proposal from Rob to defer. Want to open it back up for further discussion

Proposed resolution: Defer work on JSON literals until specific use cases have been described (Benjamin Young)

Gregg Kellogg: chris weber brought up issue of canonical order of the literal. there is a draft out for JSON canonicalization but it is a burden until algorithms there to do it. This issue is related to the RDF JSON canonicalization. we have this issue with HTML and XML literals.
… we are laking a compelling use case for this
… part was to support geo json but we added list of list to support that

Adam Soroka: to clarify, geo json has no use case for this current issue?

Rob Sanderson: Related to #7 – https://github.com/w3c/json-ld-syntax/issues/7

Gregg Kellogg: list of list allows us to represent geo json but some of the proponents of geo json want to see us go further

Adam Soroka: happy with the proposal and to see conversation to move forward. We owe it to geo json to see that their issues are represented in our work

Rob Sanderson: while I supported the issue, given the lack of use cases, I support the deferral.

David Newbury: I glad it is a deferral and not a close. but when you need to semanticalize and de-semanticalize json it can be a pain.

Ivan Herman: no strong opinion about literals in json but do want to make sure we do not close it for the wrong reason. understand the canonicalization issue but it is not our responsibility. should we have a more broad RDF canonicalization group.

Rob Sanderson: +1 to ivan.

Adam Soroka: +1

David I. Lehn: i’ll just note, that similar to empty terms, raw json would be very helpful for obfuscated json-ld

Benjamin Young: csvw:JSON

Benjamin Young: did more digging and there is another community that minted a json encoding type. the csv working group has this. The json is not native json but rather just a string but has way to say, this is a json string.
… need to make sure we have a compelling use case

Rob Sanderson: +1

Benjamin Young: does anyone want changes?

Proposed resolution: Defer work on JSON literals until specific use cases have been described (Benjamin Young)

David Newbury: +1

Jeff Mixter: +1

Ivan Herman: +1

Adam Soroka: +1

Benjamin Young: +1

Harold Solbrig: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Resolution #2: Defer work on JSON literals until specific use cases have been described

David I. Lehn: +1

3.2. Data Transformation

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

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

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

Benjamin Young: The GeoJSON-LD community https://github.com/geojson/geojson-ld

Benjamin Young: next topic is data transformation. two proposals in the email

Benjamin Young: PROPOSAL#1: Close, won’t fix, as JSON-LD contexts are not the right vehicle for data transformation

Benjamin Young: PROPOSAL#2: Defer until after a discussion at TPAC

Rob Sanderson: 7 came from the geo json folks. We need to address 7 but if we close it, we will not prevent geo json ld we are just not enabling geo json ld from adding stuff not in geo json
… if we go down this route there will be a snowball affect of requests
… still in favor of closing this

Ivan Herman: +10000 to azaroth

Rob Sanderson: defer to TPAC

Gregg Kellogg: to play devils advocate, the original mission statement was to allow devs to use idiomatic json and have it be interpreted as linked data
… follows this pattern and does something that RDF does not handle very well
… gets into a can of worms, could use some templating stuff to get around this
… there is also the json-ld transformation library that might do this but this working group does not have the time to take this up

Rob Sanderson: Definitely useful, no argument there!

Rob Sanderson: +1 to principle of least surprise

David Newbury: +1 to ajs6f

Gregg Kellogg: As bigbluehat noticed, it’s “JSON-LD Macros”, not Transformation. https://github.com/antoniogarrote/json-ld-macros

Adam Soroka: in support of at least deferring these this is an issue of surprise. When contexts can do this type of things, it can cause very surprising effects in the output RDF. Also to play devil’s advocate, if we close these all together, we are saying this is transformation and that you should not do it in the context but in different way
… but we have no recommendations to do that
… we need to point people who need this where to go to solve this issue

David Newbury: It’s probably worth mentioning jq (https://stedolan.github.io/jq/), which is a tool that is very good at this sort of JSON transformations

Ivan Herman: we are not doing jsonld 2.0
… this belongs in 2.0 not 1.x

Benjamin Young: jsonld is sort of a transformation layer and what we need to address is the concerns of each camp - Tree JSON folks and Graph RDF folks.
… people will do this and if we do not give them a way to express it where will they go?
… in favor of proposal 2 - defer

Rob Sanderson: the other schema.org folks are concerned about security - context being dereferenced on the fly and if the context manipulate the graph, that could introduce major issue - phishing for example
… could be pushed back to community group and brought to TPAC

Benjamin Young: +1 for incubation in the CG

David Newbury: things that are mentioning about applying types are more like inferencing but is not really the same as data manipulation done in the context.

Ivan Herman: we have 2 years to complete this work. This is a major piece of work and would proposal that we should not do it in this working group. Push it to 2.0

Ivan Herman: +1 to gkellogg

Rob Sanderson: +1 to close out of scope for 1.1 and ask the CG to work on it

Gregg Kellogg: maintaining things in defer state does not do anyone a service because it leave the option there. Makes more sense to claim out of scope and close - push it to another group or the community group. like to keep open issue list tight

Adam Soroka: this will come up again when we talk about framing. You can introduce new data when framing.

Proposed resolution: Defer for exploration to the Community Group for future consideration in JSON-LD 2.0 (or elsewhere); Close current WG issue as wontfix with reference new open issue at the CG. (Benjamin Young)

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Jeff Mixter: +1

Benjamin Young: +1

David Newbury: +1

Harold Solbrig: +1

Adam Soroka: +1

Simon Steyskal: +1

Benjamin Young: just covers issue 7

Gregg Kellogg: need a different proposal for each issue

Benjamin Young: there concerns are not lump-able?

Gregg Kellogg: other issue are subtly different

Resolution #3: Defer #7 for exploration to the Community Group for future consideration in JSON-LD 2.0 (or elsewhere); Close current WG issue #7 as wontfix with reference new open issue at the CG.

Ivan Herman: +1

Jeff Mixter: +1

Benjamin Young: +1

Harold Solbrig: +1

Adam Soroka: +1

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

Benjamin Young: Alternative support for list-like structures such as schema:ListItem

Benjamin Young: now 15, do we want this to go to the CG?

Gregg Kellogg: close and won’t fix

Ivan Herman: we can not force the CG to do anything

Benjamin Young: right just asking them to look at it and maybe talk about it

Benjamin Young: defer 15

Rob Sanderson: close this out and ask the CG to take up

Gregg Kellogg: not even go that far, they had the authority to shut the door. All we can do is close the issue.
… out of scope and you can see the minutes to explain why

Benjamin Young: Rob as Dan to follow up and comment

Proposed resolution: Close #15 as wontfix. (Benjamin Young)

Rob Sanderson: +1

Ivan Herman: +1

Gregg Kellogg: +1

Jeff Mixter: +1

Benjamin Young: +1

Harold Solbrig: +1

Adam Soroka: +!

Adam Soroka: +1

Simon Steyskal: +1

Resolution #4: Close #15 as wontfix.

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

Rob Sanderson: my proposal is to close and not fix 64

Ivan Herman: specific application areas can do this for their needs

Rob Sanderson: + all the numbers to Ivan

Ivan Herman: direct consequence of issue 7

Rob Sanderson: not in our scope to say how people should process RDF

Gregg Kellogg: this is in the transformation area

Rob Sanderson: +1

Ivan Herman: N3 could do this

Rob Sanderson: +1 to ajs6f

Proposed resolution: Close #64 as wontfix and reference the CG issue created for the transformation topic (see resolution of #7). (Benjamin Young)

Rob Sanderson: +1

Adam Soroka: +1

Gregg Kellogg: +1

Benjamin Young: +1

Ivan Herman: +1

Harold Solbrig: +1

Jeff Mixter: +1

Simon Steyskal: +1

Adam Soroka: more appropriate for others to deal with transformation

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

Resolution #5: Close #64 as wontfix and reference the CG issue created for the transformation topic (see resolution of #7).

3.3. blank nodes as predicates

Proposed resolution: Add an editorial warning to the 1.1 specification that the use of blank nodes as predicates is possible, but that it is deprecated and recommended for removal in a hypothetical JSON-LD 2.0 (Benjamin Young)

Rob Sanderson: add an editorial to spec to say you can use bnodes as predicates but please do not do so

Ivan Herman: we can look at the terms for what we use to describe it
… maybe something like deprecated
… this issue comes up if you use OWL inferencing stuff

Gregg Kellogg: this does not have to do with OWL type stuff but rather being able to transform JSON into JSON-ld without having to deal with ontologies and such

Rob Sanderson: I think it’s obsolete: https://github.com/w3c/w3process/issues/36#issuecomment-317019111

Gregg Kellogg: obsolete, deprecated and mark test cases that use this as 1.0 only
… needs to be on the road to elimination

Proposed resolution: Mark the use of blank nodes for properties as obsolete/deprecated and mark issue as “Editorial” (Benjamin Young)

Rob Sanderson: > An Obsolete Recommendation is a specification that W3C does not believe has sufficient market relevance to continue recommending that the community implement it, but does not consider that there are fundamental problems that require the Recommendation be Rescinded. It is possible for an Obsolete Recommendation to receive sufficient market uptake that W3C decides to restore it to Recommendation status. An Obsolete Recommendation has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR licenses granted under the Patent Policy.

Rob Sanderson: +1

Gregg Kellogg: +1

Adam Soroka: +1

Benjamin Young: +0

Jeff Mixter: +1

Ivan Herman: +1

Simon Steyskal: +1

Rob Sanderson: bigbluehat: If Manu has new evidence, we can change our mind

Benjamin Young: azaroth: sounds good.

Rob Sanderson: But at this stage I think some significant evidence of use is what is needed

Resolution #6: Mark the use of blank nodes for properties as obsolete/deprecated and mark issue as “Editorial”

4. Resolutions