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
- 2. Announcements / Reminders?
- 3. Call for Consensus for Candidate Recommendation Status Report
- 4. Issues
- 5. Best Practice issues/topic review
- 6. adjourn
- 7. Resolutions
- 8. Action Items
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
- Resolution #1: minutes approved
- 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
- Resolution #3: Any changes to algorithm text that do not affect the result of the algorithm may be considered non-normative changes.
- Resolution #4: gkellogg to add explanation to the syntax document around resolving relative IRIs for
@context
values
8. Action Items
- Action #1: add values discussion to BP#19 (Rob Sanderson)