W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2018

[MINUTES] W3C JSON-LD CG Call 2018-02-05

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 5 Feb 2018 12:17:23 -0700
Message-Id: <BBDCF268-8873-48B1-AE7A-1FFEA4B837BB@greggkellogg.net>
To: Linked JSON <public-linked-json@w3.org>
Thanks to Benjamin Young for scribing this week! The minutes for this week’s JSON-LD CG teleconference are now available: https://json-ld.org/minutes/2018-02-05/index.html.

Full text of the discussion follows for W3C archival purposes.

Gregg Kellogg

JSON-LD Community Group Minutes for 2018-02-05

  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
  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 
  Gregg Kellogg and Rob Sanderson
  Benjamin Young
  Robert Sanderson, Ivan Herman, Niklas Lindström, Victor 
  Charpenay, David Newbury, Benjamin Young, Gregg Kellogg, David I. 

Robert Sanderson: :(
Ivan Herman: Trying to connect with linphone, it seems to do 
  something but then breaks
Ivan Herman: Giving up...
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 
  ...maybe it would help someone to have the fallback to test 
  ...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 
  ...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 
Gregg Kellogg:  Do we want to put an action or proposal out 

PROPOSAL:  Have one playground that handles both 1.0 and 1.1 ; 
  explore ways to make the processing mode as user friendly as 

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 

RESOLUTION: Have one playground that handles both 1.0 and 1.1 ; 
  explore ways to make the processing mode as user friendly as 

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 
  ...or is it a 1.1 implementation with a toggle to process the 
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 
  ...should it be approved
Gregg Kellogg: https://json-ld.github.io/charter/
  ...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 
  ...so we can be sure we have enough folks to do calls and admin 
  ...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 
  ...we have to work out the details of what, by when, and by 
  ...but it looks promising to become a WG in the not too distant 
Gregg Kellogg: 
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: https://github.com/json-ld/json-ld.org/pulls
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

Robert Sanderson: https://github.com/json-ld/json-ld.org/pull/487 
  ...issue #487 handles adding a few more authors based on 
  ...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

Gregg Kellogg: PR https://github.com/json-ld/json-ld.org/pull/573

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 
  ...rather than relative to the vocabulary
  ...the issue remains open, though, for dealing with vocab 
  ...such as @type
  ...that's been confusing for some folks coming from the RDF 
  ...this PR clarifies the intention of what the documents say 
  ...and its been properly accepted by the people who raised the 
Gregg Kellogg: Example <#foo>
Robert Sanderson:  So. for example.
In Turtle that might be a property location relative to the 
Gregg Kellogg: {"#Foo": "bar"}
  ...you can't do that in JSON-LD where you might have {"#foo": 
  ...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: https://github.com/json-ld/json-ld.org/issues/488
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
Gregg Kellogg: PT https://github.com/json-ld/json-ld.org/pull/574

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 
  ...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 
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 

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: PR 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 
  ...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 
  ...won't implementers need to include framing to pass 
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 
Gregg Kellogg:  It might be useful to suggest different levels of 
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 
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 
  ...perhaps a way to handle it is through different levels of 
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...
Gregg Kellogg: Related issue 
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 

  ...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 
  ...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
Received on Monday, 5 February 2018 19:17:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:51 UTC