The W3C JSON-LD Community Group

JSON-LD Syntax and API

Go Back

JSON-LD CG Telecon

Minutes for 2018-02-05

Agenda
https://lists.w3.org/Archives/Public/public-linked-json/2018Feb/0000.html
Topics
  1. Announcements: new playgrounds!
  2. Updates on the Charter
  3. https://github.com/json-ld/json-ld.org/pull/487
  4. https://github.com/json-ld/json-ld.org/pull/573
  5. https://github.com/json-ld/json-ld.org/pull/573
  6. https://github.com/json-ld/json-ld.org/pull/574
  7. https://github.com/json-ld/json-ld.org/pull/578
  8. https://github.com/json-ld/json-ld.org/pull/582
Resolutions
  1. Have one playground that handles both 1.0 and 1.1 ; explore ways to make the processing mode as user friendly as possible
  2. merge #487
  3. Merge #573
  4. (process) Use github milestones to manage PRs (to try and merge) and Issues (to discuss)
  5. Don't merge #582, resolve #477 as won't fix (with rationales from the call)
Action Items
  1. merge 574 and 575
  2. merge 578
  3. Update the charter to explicitly call out framing as a deliverable
Organizer
Gregg Kellogg, Rob Sanderson
Scribe
Benjamin Young
Present
Robert Sanderson, Niklas Lindström, Victor Charpenay, David Newbury, Benjamin Young, Gregg Kellogg, David I. Lehn
Audio Log
Robert Sanderson: :(
Niklas Lindström: I'm having rther choppy sound :/
Victor Charpenay: Hi! I tried to connect to the provided SIP addresses but all three time out.
David Newbury: I'm here, as well
Victor Charpenay: Am I missing something?
Benjamin Young is scribing.

Topic: Announcements: new playgrounds!

Robert Sanderson: You can now try out the in-progress 1.1 spec
...gkellogg would you like to say more?
Gregg Kellogg: I think there is an open question if we want to keep 1.0 playground as primary
...or if we want to move to a single playground
...regarding compatibility, the dev playground does work for all the specs
...with the exception of Framing
...but I'm working on that feature for the playground now
Robert Sanderson: So. one playground or more
...given the version compatibility scenario/compatibility, we might need to make it clear
Niklas Lindström: Maybe just a visual switch in the interface
...so you can test them both in one playground, but switch between them
Niklas Lindström: I was thinking something similar
Niklas Lindström: I type
Niklas Lindström: I agree, something visual
Niklas Lindström: But a very clear "pending / in development" cue for 1.1 mode
Gregg Kellogg: I'll point out that 1.1 is almost entirely compatible with 1.0
...so unless you use new features in 1.1, you should have no trouble using a single playground
...compacting IRIs is different
...also, the playground does do sanity checking on definition keywords and container values
...whereas the 1.0 spec did not
...so I'm not sure that there's a value to switching between processors
...maybe it would help someone to have the fallback to test things
...but from the way a processor should operate, they should be the same
Robert Sanderson: So. I ran into is issue #581
...it's hard to understand the fallback handling
Gregg Kellogg: So. maybe some switch in the HTML to invoke one version of the processor
...there are two ways to turn on the mode
...either the @version in the @context
...or via the API
...right now we're mostly talking about using the API to toggle it
...to avoid using @version all the time
...there are also other API flags we might want to expose also
David I. Lehn: I do agree there's good stuff we can expose
...but I would be concerned about it getting too complicated
Robert Sanderson: Sounds like everyone's +1 on a single playground, but with some way to make it user friendly for switching
Gregg Kellogg: Do we want to put an action or proposal out there?
PROPOSAL: Have one playground that handles both 1.0 and 1.1 ; explore ways to make the processing mode as user friendly as possible
Robert Sanderson: +1
David I. Lehn: +1
Gregg Kellogg: +1
Benjamin Young: +1
Niklas Lindström: +1 (Preferably with 1.0 as default until 1.1 is REC)
RESOLUTION: Have one playground that handles both 1.0 and 1.1 ; explore ways to make the processing mode as user friendly as possible
Robert Sanderson: As niklasl_ said we should discuss default
...I believe the default has to be 1.0
...and you'd have to use UI or @version to toggle it on
Gregg Kellogg: Well. the way that the proposal was worded, it's a bit unclear
...is it a 1.0 implementation and a UI to switch to a 1.1 implementation?
...or is it a 1.1 implementation with a toggle to process the 1.0?
Niklas Lindström: True. Yes, I think that'd be wise. (With a caveat about the default having the known 1.0 bugs perhaps...)
Robert Sanderson: Perhaps an amendment to the proposal would clarify it to a 1.1 implementation to a 1.0 default and the ability to toggle it
David Newbury: That sounds reasonable to me.
PROPOSAL: (amendment) The playground handles 1.0 with a 1.0 implementation, rather than a 1.1 algorithm in 1.0 mode. 1.0 will be the default algorithm.
Robert Sanderson: Bigbluehat you had thoughts on evangelism?
Robert Sanderson: +1
Benjamin Young: We'd like to encourage folks to use 1.1, but not too quickly as they're still using 1.0 in the wild
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: We'll have to make sure that's doable given namespace collisions
Gregg Kellogg: Could you just switch libraries as you can with switching HTML pages?
David I. Lehn: Possibly. it depends on the details, but we can sort those out if that's what's wanted
Robert Sanderson: I'd suggest we move on to the other topics
Gregg Kellogg: I would like to look at open pull requests on the call today

Topic: Updates on the Charter

Robert Sanderson: Bigbluehat has volunteered to co-chair the group
...should it be approved
...along with iherman as our staff contact
...so far, there's not been much of an opportunity to step forward, but if anyone has a concern, please email me
...assuming everything goes according to plan, we have our two chairs
...so we can be sure we have enough folks to do calls and admin stuff
...we have our editors
...and a staff contact
...it was announced to the Advisory Board (AB)
...no one seemed to flinch or bat an eyelid, so it's so far so good
...we have to work out the details of what, by when, and by whom
...but it looks promising to become a WG in the not too distant future
Gregg Kellogg: Just a note to say the charter points to this wiki page
...which explains the changes in the CG drafts
Robert Sanderson: Anything else we need to add here
Gregg Kellogg: There are pull requests that need addressing
...if we could add those to the agenda
...along with the other open issues you highlighted
...there is a longstanding PR on authorship

Topic: https://github.com/json-ld/json-ld.org/pull/487

...issue #487 handles adding a few more authors based on contribution
...it's something the group ultimately needs to decide on
PROPOSAL: merge #487
...the other ones are basically pulling through open PRs
Gregg Kellogg: +1
Robert Sanderson: +1
Niklas Lindström: +1
David Newbury: Apologies--have to drop off early.
RESOLUTION: merge #487

Topic: https://github.com/json-ld/json-ld.org/pull/573

Gregg Kellogg: This one's about relative IRIs in JSON-LD
...this updates it to more clearly define them relative to the document
...rather than relative to the vocabulary
...the issue remains open, though, for dealing with vocab position
...such as @type
...that's been confusing for some folks coming from the RDF field
...this PR clarifies the intention of what the documents say curently
...and its been properly accepted by the people who raised the issue
Gregg Kellogg: Example <#foo>
Robert Sanderson: So. for example.
Gregg Kellogg: If you had something like <#foo> in Turtle that might be a property location relative to the document
Gregg Kellogg: {"#Foo": "bar"}
...you can't do that in JSON-LD where you might have {"#foo": "bar"}
...and unless you've setup your vocabulary to handle that, it might be ignored
...we might want to setup some text that describes what happens if a term starts with an IRI delimiter
Gregg Kellogg: "@Vocab": "@base"
...or a way to say the vocabulary base is the same as the document base
...such as "@vocab": "@base"
...but none of those concerns really need to prevent this PR, because this leaves the door open to more discussion
...while still clarifying things
Robert Sanderson: Right, so this is a clarifying PR, not a change in functionality
Gregg Kellogg: I'm trying to remember why we chose string concatenation vs. IRI processing

Topic: https://github.com/json-ld/json-ld.org/pull/573

Gregg Kellogg: Let's take that back to issue #488
Niklas Lindström: Clarification: terms aren't *resolved* against vocab, they are string-concatenated.
...so we can at least get the text inline with current behavior
Robert Sanderson: Any other questions?
PROPOSAL: Merge #573
Niklas Lindström: .... This because vocab can end with "#", and if we didn't concatenate, keys (and type values) would have to begin with a "#".
Robert Sanderson: +1
Gregg Kellogg: +1
Benjamin Young: +1
Niklas Lindström: +1 (With clarification on vocab concatenation)
David I. Lehn: +1
RESOLUTION: Merge #573
Niklas Lindström: ... This concatenation is equal to prefix handling in Trig/Turtle, RDFa and RDF/XML

Topic: https://github.com/json-ld/json-ld.org/pull/574

Gregg Kellogg: This is about a document relative flag
...it seems to be entirely editorial
...and #575 is also editorial
...trying to make it scan more easily for people
...but does not change anything technically about it
Robert Sanderson: Take a quick look at #574
...any objections?
ACTION: merge 574 and 575
...similarly any objections to #575?
...it does make things easier to read, so it'd be hard to object to :)

Topic: https://github.com/json-ld/json-ld.org/pull/578

Gregg Kellogg: This is to make the example match what actually happens
...it gets closer, but it's still not quite there
...as a positive side-effect this extracts the examples
...which has value for use in the playground
...there's also been discussion of using YAML instead of JSON
Robert Sanderson: So this isn't even merely editorial, just infrastructure tweaks?
Gregg Kellogg: Correct
Robert Sanderson: No actually content changes
...so not sure we even need a proposal
David I. Lehn: I have a question around why we're merging things like this?
...vs. just using GitHub?
Gregg Kellogg: Well, it's about establishing process around how changes are made
...if all of these had already had discussion and acceptance, then that'd be one thing
...but this gives us a chance to get some feedback
David I. Lehn: Yeah...understand, but it just feels weird for the few of use that are here to confirm stuff already available online
Robert Sanderson: Mainly we're trying to keep things up-to-date, and processing things on the call helps push things forward
...and re-enforces process
...and as we move to a WG, it will become more important
...does that help taaz ?
David I. Lehn: Yeah. it's fine, I guess
Gregg Kellogg: Yeah. it also goes back to the roll of the editor
...if there's controversy, then the editor should seek to get it resolved
...I do think it's helpful to get things discussed
Benjamin Young: Maybe we could use milestones for the calls?
...we could group the issues to be considered/closed in the milestone
ACTION: merge 578
PROPOSAL: (process) Use github milestones to manage PRs (to try and merge) and Issues (to discuss)
Gregg Kellogg: +1
Robert Sanderson: +1
Benjamin Young: +1
David I. Lehn: +1
Niklas Lindström: +1
RESOLUTION: (process) Use github milestones to manage PRs (to try and merge) and Issues (to discuss)

Topic: https://github.com/json-ld/json-ld.org/pull/582

Gregg Kellogg: This PR explains the spec text around framing
...it doesn't change any of the substance in the framing document
...it just moves it into the API document
Robert Sanderson: Travis-ci isn't happy
Gregg Kellogg: Yes. that's because CI is applied and there's an issue with an earlier PR
...I've since turned that off
...we do hope to turn it back on
...to validate examples and things
Niklas Lindström: I do have a concern about this making the API document longer
Niklas Lindström: Sure
David I. Lehn: I may be repeating what niklasl_ has mentioned
...is merging this going to cause problems for implementors?
...what if someone doesn't want to include framing?
Niklas Lindström: I've been a bit concerned that framing is a bit complex, and I've done alternate approaches in a couple of implementations
...won't implementers need to include framing to pass validation?
Gregg Kellogg: Not sure there are any out there that don't support framing
...google's maybe
David I. Lehn: Yeah. that's one of the key ones to be concerned about
Gregg Kellogg: It might be useful to suggest different levels of conformance
Niklas Lindström: Rdflib-jsonld doesn't have one; it has a pending one which is simpler, it just "autoframes" based on @id
...for instance, expansion and things are easier to implement without getting into compaction
...so the bar is lower for integrating with RDF toolsets
...and framing might be a feature that's beyond compaction
Robert Sanderson: As niklasl_ says, one of the python implementations doesn't
...and framing seems like a separate beast than compaction
...I'm not -1, but I'm not sure we need to have a single API document
Gregg Kellogg: The issues I was seeing were around options
Niklas Lindström: Recall that e.g. redland (librdf) hasn't gone near json-ld because "too complex"
...and having framing here means a single set of options for both
...perhaps a way to handle it is through different levels of conformance
Niklas Lindström: Really, it only needs expansion to get any json-ld into RDF, and it does only have to emit expanded json-ld to be useful for "full" json-ld processors...
Benjamin Young: Getting a gold star from the W3C via testing goes up with very MUST in the text
PROPOSAL: Don't merge #582, resolve #477 as won't fix (with rationales from the call)
Gregg Kellogg: So we need a counter proposal for not-merging
Gregg Kellogg: +0.5
Benjamin Young: +1
Niklas Lindström: +1 (We can still publish a separate framing doc for 1.1 REC if we want to, right?)
Robert Sanderson: So, requirement in specs can cascade, but the testing tools don't get that conditional nature of the text
...where "if you do section X, then you MUST do the following"
RESOLUTION: Don't merge #582, resolve #477 as won't fix (with rationales from the call)
...the testing just doesn't map to that
Gregg Kellogg: We should also then reconsider our charter text
ACTION: Update the charter to explicitly call out framing as a deliverable
...to make sure its clear which dcuments contain which thing
Robert Sanderson: K. we're a bit past time, so off we go
...gkellogg thanks so much for your work here!
...and we'll also be looking into our voip options before next call
...thanks everyone!
Robert Sanderson: Adjourn :)
Robert Sanderson: Oh, and thanks to Benjamin for scribing!
You're welcome! :)
Robert Sanderson: Anything else you need from me?
Robert Sanderson: I don't think so
Robert Sanderson: I'll add the comment to #477 about rationale for wontfix