JSON-LD Working Group Telco — Minutes

Date: 2018-08-03

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Simon Steyskal, Gregg Kellogg, Tim Cole, David Newbury, Ivan Herman, Jeff Mixter, Harold Solbrig, Benjamin Young

Regrets: Adam Soroka, Dave Longley

Guests:

Chair: Rob Sanderson

Scribe(s): Jeff Mixter, Rob Sanderson

Content:

Rob Sanderson: dlongley - Can we assume a -1 on the @comment issue from you?

Dave Longley: azaroth: yes

Dave Longley: thanks, sorry can’t attend today

1. Approve minutes of last call

Rob Sanderson: link: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-07-27-json-ld

Rob Sanderson: Any changes to last week’s minutes?

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Simon Steyskal: +1

Tim Cole: +1

David Newbury: +1

Resolution #1: Minutes of last call are approved (https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-07-27-json-ld)

2. Issues proposed to close

2.1. Expanding ordered lists (https://github.com/w3c/json-ld-api/issues/9)

Gregg Kellogg: json-ld has syntax and the RDF algorithms process rest and nill and turn it back to quads. Issue was about JOSN-ld doc that has those URIs. Can compaction algorithm process that? Round trip through RDF?

Rob Sanderson: are there questions?

Ivan Herman: clarification please

Gregg Kellogg: you can serialize triples first without rest. Part of the transformation from RDF to JSON-ld is a process that collects list nodes and makes sure they are correct and then turns into internal rep. The request is to do that without going through RDF
… if you have a blank node ID, can the compaction algorithm can do that work.

Rob Sanderson: or RDF type

David Newbury: are we planning on using implicit knowledge in the RDF vocabulary. What we do and do not do?
… weird situation where we are in both worlds

Gregg Kellogg: different types of JSON-ld algorithms - transfer JOSN-ld to different forms of JSON-ld and ones that convert between RDF syntaxes

Rob Sanderson: +1 to gkellogg’s explanation

David Newbury: thanks for the clarification

Simon Steyskal: either we go full in or do not. I would be against bringing in RDF interpretation. We are currently in middle ground
… gregg explained it very well. for example RDF type and this is similar

Rob Sanderson: is everyone up to speed on the issue?
… does everyone understand why we propose to close it. Any objections to closing and that we will not do this?

Harold Solbrig: proposal to close and not do anything

Rob Sanderson: proposal is to close and not do anything

Gregg Kellogg: most of these issue appear to be from me but they are linked to the original proposals
… i vote to close and do nothing

Proposed resolution: Close issue https://github.com/w3c/json-ld-api/issues/9 without any change (won’t fix) (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Gregg Kellogg: +1

David Newbury: +1

Simon Steyskal: +1

Jeff Mixter: +1

Harold Solbrig: +1

Tim Cole: +1

Resolution #2: Close issue https://github.com/w3c/json-ld-api/issues/9 without any change (won’t fix)

Rob Sanderson: I will go through and actually close the issue and link to the minutes

2.2. introducing @dir (https://github.com/w3c/json-ld-syntax/issues/11)

Ivan Herman: I put in a comment last week that I favor closing it
… the problem that folks have is that of direction of the writing. There are some very confusing issue when writing for example Hebrew text with an English text in the middle with brackets. We can not properly represent that in JSON or JSON-ld. The real issue is that RDF can not represent that
… thought we might be able to add it to JSON-ld to account for this. Similar to HTML. But there were some discussions in the original comment about extending things that are not in RDF - and decided to not do that

Rob Sanderson: any questions? Do not do non-RDF stuff unless you need to

Tim Cole: sorry wrong thing in chat. Just to be clear if a community has a property in RDF that is fine to include? It just does not allow you to do that in JSON-ld

Ivan Herman: RDF does not have this facility

Tim Cole: but we have modeled it in some RDF ontologies

Ivan Herman: yes, this is only about literals

Gregg Kellogg: You can always make an HTML literal that has direction included in the HTML.

Rob Sanderson: link to annotation model, with textDirection predicate: https://www.w3.org/TR/annotation-model/#external-web-resources

Ivan Herman: by using the full power of the language tag - it may be possible to do this type of stuff
… do not do anything JSON-ld specific

Proposed resolution: Close issue https://github.com/w3c/json-ld-syntax/issues/11 without any change (won’t fix) (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Tim Cole: +1

Jeff Mixter: +1

Harold Solbrig: +1

Simon Steyskal: +1

Benjamin Young: +1

Resolution #3: Close issue https://github.com/w3c/json-ld-syntax/issues/11 without any change (won’t fix)

2.3. Allow @value, @language and @type simultaneously (https://github.com/w3c/json-ld-syntax/issues/13)

Rob Sanderson: the next one is a bit of a defensive one. So I will explain it
… it is not possible in the RDF model to have language, type and value.
… the datatype with a language is a lang string.
… if we mess with direction we can also talk about this. Given the previous proposal, I propose we close this one.
… any questions or objections?

Proposed resolution: Close issue https://github.com/w3c/json-ld-syntax/issues/13 without any change (won’t fix) (Rob Sanderson)

Rob Sanderson: +1

David Newbury: +1

Harold Solbrig: +1

Jeff Mixter: +1

Simon Steyskal: +1

Ivan Herman: +1

Tim Cole: +1

Benjamin Young: +1

Gregg Kellogg: +1

Resolution #4: Close issue https://github.com/w3c/json-ld-syntax/issues/13 without any change (won’t fix)

3. Issue from last week (#32)

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

Rob Sanderson: now larger questions that we started to discuss last week
… additional metadata in context. Not in instance data needed discussion about context and frames
… there has been good discussion in GitHub. Thanks. By my count, there are 6 -1s, 2 +0s, and 1 +1. So we should close this one
… does that makes sense

Tim Cole: makes sense but does a new issue need to be opened for human readable documentation
… might still be important but comment is an issue

Harold Solbrig: I learned a lot from the dialog. i would like to entertain the idea to open another issue. Come up with an escape character ‘@@’ for example. would like more discussion

Rob Sanderson: before we talk about more stuff
… any more comments on the comments issue?

Proposed resolution: We will not add a specific @comment (or similar) keyword for providing comments in contexts or frames (Rob Sanderson)

Gregg Kellogg: +1

Tim Cole: +1

Rob Sanderson: +1

Harold Solbrig: +1

Jeff Mixter: +1

Simon Steyskal: +1

Gregg Kellogg: will not fix but do not close

Benjamin Young: +1

Rob Sanderson: we derived ‘@comment’ from trying to understand what the initial issue creator wanted

David Newbury: this is not closing the issue on how to provide inline documentation or clarification.

Rob Sanderson: yes just not in the form of comments. escaping would allow documentation. external linking could as well

Resolution #5: We will not add a specific @comment (or similar) keyword for providing comments in contexts or frames

Gregg Kellogg: this links to a comment where poly-fills could be included. I am not an advocate of that but it is a proposal to consider

Rob Sanderson: we resolved the proposal so the broader question is do we want to allow for some mech to inject additional metadata in context?

David Newbury: +1

Rob Sanderson: meta-context to allow for documentation. Or do we want a single keyword to distinguish this

Gregg Kellogg: in many cases is when you have a term def and that term matches one in an external vocab def. there you need to follow your nose to find that def. Use linked data principles

Rob Sanderson: +1 to follow your nose for term descriptions

Harold Solbrig: allow for some mech? which is interesting. there will be situations where people do this. It is a question of whether we approve or do not approve and if we do, then do it this way.
… I am fine with a URI link but we need to say something

Harold Solbrig: +1 to workergnome’s comment

David Newbury: very common case but there are more complicated issues where magic is needed and it is not usable by anyone else. want to explain why I did that weird thing

Tim Cole: there is a balancing act. linked data principles would allow you to do that but would be harder than in-line comments.

Rob Sanderson: +1 to Tim’s observation about level of work

Jeff Mixter: +1 to Tim’s level of work also

Jeff Mixter: I acknowledge the need to do weird stuff in contexts, I do think that round-tripping is very important. If it can’t be represented elsewhere, okay, but if it’s for processing then it’s important. It’s not about the graph data, it’s about the specific JSON-LD document.
… I would support Tim’s proposal. I think we would see a bunch of weird stuff about processing the document rather htan the graph

Rob Sanderson: +1 to bigbluehat

Benjamin Young: any human focused text that we introduce will run us around of multi-language issues
… prefer to point people elsewhere for human readable stuff

Harold Solbrig: one thing that makes machine processing comments is the caveat that we clarify no round-trip-ability of comments

Harold Solbrig: … that prevents the use of machine processing comments

Rob Sanderson: to summarize - there is reasonable support to reference to external resource and only harold and david is keen on in-line

Gregg Kellogg: we are looking at using YAML/YAML-ld for this type of issue

Benjamin Young: +1 to using YAML for what YAML’s good at (and JSON isn’t)

Rob Sanderson: moving forward - would someone write up an external reference approach and one do the inline approach? we can then close 32 and discuss these new ones separately
… who will do it.

Benjamin Young: difference between http://schema.org/Person

Benjamin Young: https://www.w3.org/ns/oa#Annotation

Benjamin Young: difference between W3C Anno and Schema.org
… URL’s resolve to HTML?

Rob Sanderson: we are talking about a keyword that points to a URI that when resolved they see a human readable content.

Benjamin Young: additional term
… do not want to route away from what Schema.org does

Rob Sanderson: content-negotiation on the context URI is something we had not talked about. We could propose this

Ivan Herman: content-negotiation is hard. 80% of users can not do this. I like the concept but it is hard

Gregg Kellogg: one thing to consider - if a context resolves to an HTML document. The processor could extract embedded JSON-ld for processing

Ivan Herman: I like that

Rob Sanderson: 4 proposals
… inline
… reference in context
… content negotiation
… extract the context from the html doc that has the context
… create an issue in the syntax repo and we can compare and contrast over the week
… can not do that in the next 5 minutes
… herold is inline, tim is doing reference, benjamin is doing content and benjamin is doing extraction from html. Separate issues
… not sufficient time to look at other issues. Let us quickly try issue 36.

Proposed resolution: Close https://github.com/w3c/json-ld-syntax/issues/32 (@comment) in favor of the four coming proposals (Rob Sanderson)

Rob Sanderson: proposal to close 32

Rob Sanderson: +1

Ivan Herman: +1

Tim Cole: +1

Jeff Mixter: +1

Harold Solbrig: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Benjamin Young: +1

Resolution #6: Close https://github.com/w3c/json-ld-syntax/issues/32 (@comment) in favor of the four coming proposals

4. List of lists (https://github.com/w3c/json-ld-syntax/issues/36)

Rob Sanderson: whether or not we should support lists of lists

Rob Sanderson: regardless of how the algorithm supports it, who would support it.

Rob Sanderson: +1

Gregg Kellogg: +1

Harold Solbrig: +1

Tim Cole: +0

Jeff Mixter: +0

Benjamin Young: +1 (because GeoJSON)

Ivan Herman: +0.5

Simon Steyskal: +2 (1 on behalf of Axel)

Jeff Mixter: do not have an understanding of use case to have opinion

Tim Cole: seen use cases but has no strong opinion

Gregg Kellogg: in compact form, you would have lists of arrays.

Gregg Kellogg: there is code in the algorithm to look for this pattern. So it would be a quick win

Rob Sanderson: thanks to everyone talk to you next week. Do not forget to comment on the issues

5. Resolutions