JSON-LD Working Group Telco — Minutes

Date: 2019-12-06

See also the Agenda and the IRC Log

Attendees

Present: Pierre-Antoine Champin, Ivan Herman, Ruben Taelman, Gregg Kellogg, Benjamin Young, Rob Sanderson, Dave Longley, David I. Lehn, Harold Solbrig

Regrets:

Guests:

Chair: Benjamin Young

Scribe(s): Rob Sanderson, Benjamin Young

Content:

1. Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-11-22-json-ld

Benjamin Young: Approve the minutes

Benjamin Young: +1

Gregg Kellogg: +0

Ruben Taelman: +1

Rob Sanderson: +1

Dave Longley: +1

Ivan Herman: +1

Resolution #1: minutes approved

Rob Sanderson: y

2. Announcements / Reminders?

Ivan Herman: Practical thing – mainly for Greg and PA – I was wrong, we cannot publish CR via echidna. Will come back to this, but we need to go the pedestrian way and go through the webmaster
… turns out that the transition requests that have more than one document, then it doesn’t work
… learnt with the Publishing WG

Gregg Kellogg: So it’s a technical issue, not policy

Ivan Herman: Yes, most WGs have published only one doc at a time

Gregg Kellogg: I will prepare snapshots

Ivan Herman: Thank you

Benjamin Young: Thank you all for the clerical work!
… anything else?

3. Call for Consensus for Candidate Recommendation Status Report

Benjamin Young: okay, CfC status…
… waiting on the director. Any other nuances to add?
… some feedback from Ralph

Gregg Kellogg: Ralph was suggesting that in the abstract we add a note about compatibility between 1.0 and 1.1
… I proposed some wording for syntax. API is a different audience and doesn’t quite apply. Is an opportunity to discuss how the algorithm is compatible, but they’re substantially different in practice

Benjamin Young: See Ralph’s request

Gregg Kellogg: there wasn’t a 1.0 spec for framing, but there was the community work as a de facto standard. Worth noting the relationship with that
… If people are happy with the wording in the issue, I’ll make PRs

Benjamin Young: Any other thoughts?

Gregg Kellogg: Process for this?

Benjamin Young: Can we just do it via the PR?

Ivan Herman: Yes it’s just editorial

Proposed resolution: add 1.0 to 1.1 relationship text to the API and Syntax specs; gkellogg to submit PR and to be approved via GitHub by chairs (Benjamin Young)

Gregg Kellogg: If Ivan and one of the chairs can +1, that seems fine

Dave Longley: +1

Gregg Kellogg: +1

Benjamin Young: +1

Rob Sanderson: +1

Harold Solbrig: +1

David I. Lehn: +1

Ruben Taelman: +1

Ivan Herman: +1

Resolution #2: add 1.0 to 1.1 relationship text to the API and Syntax specs; gkellogg to submit PR and to be approved via GitHub by chairs

Ivan Herman: I got in contact with Ralph, and he said that unless something comes up, he should give an answer later today. I may not see it today, but it will come.
… we should be confident the answer is yes, and decide on next steps so we can move quickly
… I propose to set the publication date to next Thursday, Dec 12
… in the webmaster involved case, we can only publish on Tuesday and Thursday … so can’t go to him before afternoon on Monday, so Tuesday is too soon
… if the snapshots are done by the weekend, that should be okay
… I can take care of the work to get it on the site and issue a request for publication for the 12th
… if we’re fine with that

Gregg Kellogg: Modulo the issues on the call, yes

Ivan Herman: Yes

Benjamin Young: Awesome. Moving on to issues …

4. Issues

4.1. The propagate option to Create Term Definition is unused.

Benjamin Young: https://github.com/w3c/json-ld-api/issues/233

Benjamin Young: first issue is this one …
… Propagate option is unused in the create term definition.

Gregg Kellogg: At one time, we passed propagate from context parsing to create term definition. Subsequently we reverted that, so now if you look at the API document, in create term definition, if you click that argument, you’ll see it’s not anywhere in the algorithm
… I noticed this in the jsonld.js algorithm. Verified in my own implementation
… so we can simplify it by taking this argument out

Dave Longley: +1 to remove it and simplify (it doesn’t actually change anything!)

Gregg Kellogg: question is … is that a normative change?
… no processing has changed, just the requirements for calling
… sure that we’ll face other similar things after publication

Ivan Herman: That means I think that the algorithm doesn’t change, it just has an unnecessary parameter

Gregg Kellogg: Yes, you’re passing an argument that is never used

Ivan Herman: So if I remove it, then no change … but it’s definitely borderline

Dave Longley: in no way would the output of the algorithm change, which is what is normatively defined

Gregg Kellogg: Yes, that would also speak to making changes to the algorithms in the future … the results can’t change

Dave Longley: I think this would be a useful precedent to set

Gregg Kellogg: Sense of the WG is that minor changes to the text in algorithms that do not affect the results, as specified, may be considered editorial changes

Proposed resolution: Any changes to algorithm text that do not affect the result of the algorithm may be considered non-normative changes. (Dave Longley)

Rob Sanderson: +1

Gregg Kellogg: +1

Dave Longley: +1

Ivan Herman: +1

Ruben Taelman: +1

Benjamin Young: +1

Tim Cole: +1

Harold Solbrig: +1

David I. Lehn: +1

Gregg Kellogg: +1

Resolution #3: Any changes to algorithm text that do not affect the result of the algorithm may be considered non-normative changes.

4.2. @context as relative IRI

Benjamin Young: Next three issues are all marked as editorial

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

Benjamin Young: don’t need much more than an overview of the issues
… this one was from Harold …

Harold Solbrig: This started out as a question, as it wasn’t clear to me in the docs, where context can be a relative URI as to what it’s resolution base is
… Eric Prud’hommeaux has code that resolves against an outer context
… we hope that it remains that way – that the inner context is done in terms of the outer context – as we’re building a bunch of fragmentary contexts, and don’t want to have to put in absolute URIs as that’s painful to maintain

Gregg Kellogg: I recalled that we settled in 1.0 but didn’t find a test for it
… Eric submitted one, I tweaked and it found a bug
… you shouldn’t regard @base as a logical not a physical location. If you load from a document, it should be from that physical location
… or from a URI it would be from where it was retrieved from
… writing the test found issues … we need to clarify the processing in t he syntax document, not the API doc
… as that’s where authors writing contexts will be looking

Benjamin Young: Is there some question here that needs to be resolved?

Ivan Herman: Change to the doc, or just the tests?

Gregg Kellogg: syntax doc isn’t explicit enough about how they’re resolved
… informative text in any case, that describes how this happens

Rob Sanderson: the normative text is in the algorithm in API and is already correct?

Gregg Kellogg: Yes, if the context is a relative IRI, then it is resolved with respect to the location of the containing document, rather than the base

Harold Solbrig: if I understand eric’s example, the context is resolved against the outer one.

Gregg Kellogg: Yes, the same thing. If you resolve a relative IRI context, it’s resolved relative to the document that contains the reference
… so embedded in a context or in a document, it/s the same

Harold Solbrig: This would be nice to know without reading the API, so good to have in the syntax doc

4.3. Flagging an action for CR https://github.com/w3c/json-ld-syntax/issues/263

Benjamin Young: Ivan do you want to explain this one?

Gregg Kellogg: We need to update the ontology for adding rdf:JSON
… also the terms for direction

Ivan Herman: This is when CR is done, gkellogg and I can do this

Benjamin Young: there’s no issue with us adding to rdf namespace

Ivan Herman: no additional process
… the only thing that’s a question is whether to do it now, or at PR

Dave Longley: I argue for doing it now … we’re using it now

Gregg Kellogg: I think it would be useful to do. If it went away from the spec, it wouldn’t really ever change
… the other two terms are properties … an i18n datatype that we’ve added

Ivan Herman: It’s in i18n not rdf
… we’ll need to create a separate file

Gregg Kellogg: the other ones in the blank node have been eliminated

Ivan Herman: We’ll have to look at it
… the i18n one … what URL do we use?

Gregg Kellogg: namespace is ns/i18n#
… which serves as base for adding fragments that specify the direction and language

Ivan Herman: okay the ns is fine, just need to create the file

Gregg Kellogg: the namespace doesn’t already exist … a new ns document

Ivan Herman: when we get the decision there might be a comment … don’t know. Will find out if there’s process about adding a new /ns file but i don’t think so

Gregg Kellogg: We still have 10.4 … for rdf namespace.

Ivan Herman: Yes, that’s not a problem

Benjamin Young: That’s weird that we can add to other people’s namespace?

Ivan Herman: It’s controlled by w3c

Benjamin Young: I expected more process

Rob Sanderson: just to note that in the annotation WG and in the social WG
… we added non-binding notes to explain how to add to the namespace
… by requiring that there should be discussion with the existing CG for those groups
… they’re meant to be polite requests
… not enforcement steps
… we did that because of this more flexible process

Gregg Kellogg: We’ve done this for the relevant groups
… we sent out about proposals for direction and with i18n wg

Ivan Herman: As you already have that, can you make a short list of the things we have to add
… and email so I can forward to Ralph so we have clarity, and if he sees any issues
… after the call, please

Benjamin Young: That’s helpful :)

Gregg Kellogg: Some NS docs are multiple, it’s not always apparent when you look at the ns that there’s multiple documents. Need to update all the relevant things

Ivan Herman: rdf ns doc is only one
… for i18n I’ll do turtle, rdf/xml and set up the usual conneg tricks

Benjamin Young: Thanks for all that!

4.4. Better example for included blocks

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

Benjamin Young: this one’s by azaroth, can you explain?

Rob Sanderson: in trying to explain how @included work to my engineers, they said it sucks…
… and it’s my example…and I agreed
… so this is on me to come up with a better example
… but I’ve not yet done it

Benjamin Young: and this won’t delay CR, so…good :)

Ivan Herman: I hope this is correct, but I think we can use echidna for any cr update that’s editorial

Gregg Kellogg: it updates the CR, not a wd

Ivan Herman: Yes. If we get to that, then don’t do it before asking me, but I believe so yes
… if it’s substantial, then we need to go back to the director
… but for this, it’s not substantial

Benjamin Young: Some of these should be done sooner rather than later …

Gregg Kellogg: 263 doesn’t hold up CR
… but we should do it sooner rather than later
… and will email Ivan with the NS entries

Benjamin Young: Do we need any thing formal?

Gregg Kellogg: Proposal where we authorize ourselves to update the namespaces?

Ivan Herman: I will put this into the issue for CR request
… for i18n, can you give me a pointer for what should go into the document?

Ivan Herman: See comment added to the transition request

Gregg Kellogg: It doesn’t define anything, only a namespace … so some text in a comment
… it’s a URI prefix to which we append fragments for indicating language and direction

Gregg Kellogg: i18n:ar-EG_rtl

Gregg Kellogg: for instance ^^^

Gregg Kellogg: @prefix i18n: <https://www.w3.org/ns/i18n#> .

Ivan Herman: one of the alternatives that we use
… a pointer in one of our docs where we describe that?

Gregg Kellogg: https://www.w3.org/TR/json-ld11/#the-i18n-namespace

Gregg Kellogg: The content of the document is probably HTML and contains something extracted from this section

Pierre-Antoine Champin: For the fragments, we make it hard to comply with linked data principles to make them dereferencable
… don’t want to list them all in a document … so if we used / we could do some smart service that served relevant data for the IRIs
… if someone felt like that would be a good idea

Gregg Kellogg: I see where you’re going
… something that responded to the location and could give you info about combinations of language tags and directions

Pierre-Antoine Champin: Yes, with / instead of #, then we leave the door open
… wouldn’t fight for it

Benjamin Young: Sounds like the IANA pages for media types

Benjamin Young: https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded

Gregg Kellogg: Would be a delay
… impacts tests and etc
… not that it’s not a good idea, and now /would/ be the time to do it … or rather a couple of months ago

Pierre-Antoine Champin: Well, it happens!

Gregg Kellogg: It might be useful. Another media type for the document that could better describe the fragment identifier space
… but no practical purpose

Rob Sanderson: wanted to agree with everybody
… it would’ve been good to do this earlier
… but let’s do remember that this is all for a workaround until RDF sorts out it’s i18n issues
… this should not be a long term thing
… by the time any of these services to do this dereferences got built, hopefully the real problem would be fixed
… so I don’t think we should delay

Gregg Kellogg: Both the sections and tests are non normative

Proposed resolution: gkellogg to add explanation to the syntax document around resolving relative IRIs for @context values (Benjamin Young)

Gregg Kellogg: +1

Rob Sanderson: +1

Harold Solbrig: +1

Benjamin Young: +1

Ruben Taelman: +1

Ivan Herman: +1

Tim Cole: +1

David I. Lehn: +1

Resolution #4: gkellogg to add explanation to the syntax document around resolving relative IRIs for @context values

5. Best Practice issues/topic review

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

Benjamin Young: there is a growing list of issues in the best practice repo
… that are actionable by people. We could go through these and confirm that they’re worth doing
… we could just see if people do PRs for them
… would be helpful to know which ones would be needed for which would make the document valuable
… the doc has been around for a long time but we’ve done some reorganization of it
… feedback about what is missing would be good
… any thoughts about process?

Rob Sanderson: I like your suggestion of going through the one’s we have, and trying to prioritize them
… knowing which ones would have the most impact should help us
… and which ones might be easy
… like mapping @none to none is an easy one
… so maybe we can label them as easy, useful
… and that combo is most valuable

Gregg Kellogg: Can assign people to write different ones

Harold Solbrig: Embarrassed to say that i wasn’t aware of the document until now
… would be good to get into it. Can we advertise it somewhere?

Benjamin Young: I like that suggestion
… it has lived in the specs menu for jsonld.org

Gregg Kellogg: but still points to the old version

Harold Solbrig: is there a stackexchange

Benjamin Young: yes, stackexchange :D
… there is a jsonld tag there

Gregg Kellogg: there’s stuff posted there almost every day

David I. Lehn: Stack Overflow

David I. Lehn: -> https://stackoverflow.com/questions/tagged/json-ld

Benjamin Young: That looks like a good source of evidence to mine for what should go in the BP doc
… can ask questions in that space to have others answer them and then make it more visible
… can email the CG and let people there know that they should be able to add to it
… PRs from anyone anywhere are welcome
… lets go through the issues…
… okay …

Dave Longley: I think it’s a good idea to promote idiomatic json
… people don’t use : in keynames so avoid using CURIEs in json
… doesn’t mean you can’t but looks better if you don’t

Rob Sanderson: +1 to t his

Dave Longley: If I took this one I have no idea when I would get to it

Benjamin Young: Hopefully anyone could write this
… any objections?

Gregg Kellogg: Relates to round tripping
… not generally possible with other people’s docs

Benjamin Young: Is there a similar framing BP?

Gregg Kellogg: there’s #13

Ivan Herman: I understand what Dave says, not sure I agree with the formulation
… true if you come from JSON then -LD is a stepping stone to real LD
… so more natural. If you come from RDF, and you want to use JSON-LD for various reasons like JSON tools, then it’s almost the opposite
… the natural is dc:whatever because that’s what I’m used to
… setting up vocabularies for all those is not what is normally done

Dave Longley: Can say that in the documents … If you’re primary consumers are JSON oriented, then …

Ivan Herman: Yes, agreed with that qualifier

Benjamin Young: Good to have that recorded in the issue

Rob Sanderson: ;)

Rob Sanderson: does this apply only to keys? or also @vocab values?
… for example, in various spaces that I’m in, we’ve gone back and forth…
… and are wondering if a massive context that maps all the things
… if it’s only keys, then that seems pretty universally friendly

Action #1: add values discussion to BP#19 (Rob Sanderson)

Benjamin Young: https://github.com/w3c/json-ld-bp/issues/18

Benjamin Young: taking existing JSON and turning it into json-ld w ithout any changes to the JSON
… certainly something that’s helpful to explain
… there’s lots of existing JSON to uplift

Gregg Kellogg: There’s some slides on json-ld.org that talk about this
… we can probably take some of this out
… github API, but has probably changed since then

Benjamin Young: this landed me in the odata space
… still need to write that up
… think these are the both good ones, but 18 probably not as easy as 19
… post an issue with basic thoughts about BPs
… thank you all very much!
… see you all next week for Friday the 13th

6. adjourn

7. Resolutions

8. Action Items