[MINUTES] W3C JSON-LD CG Call -2018-01-08

Thanks to Dave Longley for scribing this week! The minutes for this week’s JSON-LD CG teleconference are now available: file:///Users/gregg/Projects/json-ld-minutes/2018-01-08/index.html.

Full text of the discussion follows for W3C archival purposes.

Gregg Kellogg
gregg@greggkellogg.net

JSON-LD Community Group Minutes for 2018-01-08

Agenda:
  https://lists.w3.org/Archives/Public/public-linked-json/2018Jan/0000.html
Topics:
  1. Introductions
  2. Community Group details and process
  3. Possible road to Recommendation?
  4. Review current 1.1 work
  5. JSON-LD Test Suite
Resolutions:
  1. same call every other week at this time.
  2. accept issue 560 pending lanthaler approval
Organizer:
  Gregg Kellogg and Rob Sanderson
Scribe:
  Dave Longley
Present:
  Gregg Kellogg, Niklas Lindström, Dave Longley, Robert Sanderson, 
  Paul Warren, Eleanor Joslin, Paolo Ciccarese, Chris Webber, David 
  I. Lehn, Herm Fisher, Paul Simmonds
Audio:
  https://json-ld.github.io/minutes/2018-01-08/audio.ogg

Gregg Kellogg: Voip 0302 is azaroth
Niklas Lindström:  Can’t hear you. [scribe assist by Gregg 
  Kellogg]
Niklas Lindström: Hm, no, I hear nothing... I'll try another 
  device.
Gregg Kellogg: Void: 0306 is Herm
Dave Longley is scribing.
Gregg Kellogg: How to scribe a meeting: 
  https://www.w3.org/2009/CommonScribe/manual.html
Robert Sanderson: We hear you, Niklas
Niklas Lindström: Weird, I heard nothing; and lost the carriee.
Paul Warren: Paul Warren also here on the same line as Herm
Gregg Kellogg: Hi Paul!
Niklas Lindström:  Can you hear us now? [scribe assist by Robert 
  Sanderson]
Eleanor Joslin: Eleanor Joslin here on the same line as Herm and 
  Paul
Robert Sanderson: Great to have such a turn out :)

Topic: Introductions

Gregg Kellogg:  I'm Gregg Kellogg, one of the editors on the 1.0 
  spec, and I've been doing a fair amount of work pushing the 1.1 
  spec forward. I'm mostly independent but also affiliated with 
  Spec Ops.
Robert Sanderson:  I'm Rob Sanderson, I followed along the 1.0 
  work and we've become more deeply involved using JSON-LD 1.1 
  features in a couple of situations. Including IIIS, which uses 
  several 1.1 features and new language map functionality and in 
  the cultural heritage domain we use it in linked arts -- trying 
  to provide linked open usable data with museum objects and so 
  forth.
Herm Fisher: I'm involved with XBRL a standard on XML base. 
  Financial reporting for bank transfers, securities, for 
  US/China/etc. Trying to move forward using JSON. Trying to get a 
  better understanding of how to fit into the JSON-LD work.
Paul Warren: Technical director at [fill] International, we're 
  currently using JSON-LD in one of the drafts for XBRL.
Eleanor Joslin:  I'm a developer, here for the same reason as 
  Herm and Paul. [missed]?
David Newbury: Enterprise software architect with Rob, many of 
  the projects we're doing involve JSON-LD in various forms.
Paul Warren: Technical director at xbrl International
David Lehn: I'm with Digital Bazaar, been working on JSON-LD for 
  quite some time, been around for quite some time working on 
  JSON-LD libs and helping with specs as I can.
Dave Longley:  I work with Digital Bazaar, I worked a lot on the 
  1.0 spec; I also maintain Javascript, Python and PHP JSON-LD 
  libraries [scribe assist by Gregg Kellogg]
Paolo Ciccarese:  Focus on biomedical data, hence main interest 
  in JSON-LD, worked with Rob.
Chris Webber:  I'm Chris Webber, I work with Spec Ops. Also a 
  recently implementer of JSON-LD for Scheme, also did partial 
  implementation for Guile. I may not been on many calls but around 
  from time to time.
Robert Sanderson:  Proposal is that, at least for the mean time, 
  we have a call every 2 weeks at this time. Trying to just get 
  through the issues, get outstanding issues discussed, etc.
Dave Longley:  Sure, just que me in :) [scribe assist by Niklas 
  Lindström]
Niklas Lindström: Cue...
Robert Sanderson:  We'll probably keep using this call bridge, it 
  has some nice tool integrations, but niklasl_ is having some 
  difficulties so if others do as well we'll look into other 
  options to make sure everyone can participate.
Niklas Lindström: Yes

PROPOSAL:  same call every other week at this time.

Gregg Kellogg: +1
Robert Sanderson: +1
Chris Webber: +1
Paolo Ciccarese: +1
David I. Lehn: +1
Herm Fisher: +1
Dave Longley: +1 Though i may not be able to join all of them :)
Niklas Lindström: I’m Niklas Lindström, works for the National 
  Library of Sweden
And Niklas was also a major contributor to JSON-LD 1.0.

RESOLUTION: same call every other week at this time.

Eleanor Joslin: This time is workable for me, but slightly 
  earlier in the day would be better
Eleanor Joslin: OK
Niklas Lindström: I was involved in JSON-LD 1.0. We use it all 
  over the place in the new Library System at KB (National Library 
  of Sweden)
Gregg Kellogg:  We may put out another doodle to see if we get a 
  different response.
Niklas Lindström: +0 Re time
Robert Sanderson:  We'll do the next call at this time just for 
  consistency but there's a possibility for an earlier call.

Topic: Community Group details and process

Robert Sanderson:  Mostly to emphasize that this is a W3C CG, it 
  is not a Working Group. That means we can write specifications 
  but they don't have any formal standing. We can have any process 
  that we want, any of us can write a bunch of HTML and put it up 
  somewhere, the most effective process to get JSON-LD 1.1 into 
  standards track is to follow the process WGs use.
Niklas Lindström: I will attempt to follow JSON-LD 1.1, as we’re 
  dependent on 1.0 and want to see if 1.1 works for us. I have few 
  cycles to spare at work alas, and a 1 year old daughter at home, 
  so I’m pressed for call times as well. ;)
Robert Sanderson:  It gives the air of legitimacy and gives all 
  the background and requirements a WG would need to take 1.1 
  forward. That means the use of github for tracking issues, the 
  pull request model for making edits to documents and so forth.
Robert Sanderson:  That's how 1.0 was done so not new.
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues
Gregg Kellogg:  Also important for CGs to operate as much as 
  possible online to preserve the call time for more challenging 
  issues.
Gregg Kellogg: https://github.com/json-ld/json-ld.org/projects/2?
Gregg Kellogg:  The github repo where specs and issues are kept 
  in IRC.
Gregg Kellogg:  Also a project tracker there.
Gregg Kellogg:  I encourage people to weigh in there, 
  particularly if you support a PR or an issue, there is a nice 
  thumbs up/thumbs down tool.
Gregg Kellogg:  We can try to drive things as much as possible 
  that way -- but can also use email as well.
Niklas Lindström: Just a quick re ”1.1”, will the CG version be 
  called that?
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/548
Niklas Lindström: What I’m after is: will there be a ”JSON-LD CG 
  1.1” and *then* a possible WG 1.1?
Robert Sanderson:  We'll delay that question until we get to the 
  issue for it. Any thoughts or questions about the CG details, 
  etc.?
Robert Sanderson:  Anyone not been part of a CG or WG at W3C in 
  the past?
Paul Simmonds:  I have not.
Gregg Kellogg: Also an open issue, chartering a WG would be 
  useful, but challenging.
Eleanor Joslin:  Me neither.
Robert Sanderson:  Thanks for participating!
Gregg Kellogg:  Right; but either way, is ”X.Y CG flavour” vs ”WG 
  flavour” a risk? [scribe assist by Niklas Lindström]
Robert Sanderson:  There are a few oddities that you'll quickly 
  understand how they work or why they happen. For the most parts 
  W3C process is aimed at transparency and participating. Trying to 
  ensure that everything is well documented.
Niklas Lindström: (Thinking a little bit about WHATWG…)
Gregg Kellogg: Niklasl, Open question. I have concerns about that 
  to
Robert Sanderson:  For example, scribing everything everyone is 
  saying. They can go back and look at the minutes later if not on 
  the call.
Robert Sanderson:  This is more consistent and thorough than 
  writing some bullet points later.
Gregg Kellogg:  OK, great! [scribe assist by Niklas Lindström]
Robert Sanderson:  This level of transparency is a relatively 
  new. So the notion of having everything as public as possible is 
  important.
Gregg Kellogg:  Relevant to that, these calls are being recorded. 
  The practice has been, in the minutes, to include a link to the 
  audio in the recording.
Gregg Kellogg:  So that's a fair warning. If there are specific 
  things you don't want minuted please say so and we won't minute 
  it.
Gregg Kellogg:  But it will still be in the audio call.
Robert Sanderson:  I don't imagine there would be much call for 
  something so secret we need to pause the audio.
Dave Longley:  We can edit the audio later if super important but 
  would prefer not to.
Robert Sanderson:  There is also a waiver that you need to sign 
  to participate in the CG. If you haven't joined the CG, as an 
  individual or representing your institution if your institution 
  is a member, please do so.
Robert Sanderson:  The waiver is minimal, mostly don't sue.
Robert Sanderson:  Just some minor but important administrivia.
Robert Sanderson:  Any other comments on this topic?
None

Topic: Possible road to Recommendation?

Robert Sanderson:  If I recall correctly, JSON-LD 1.0 got to REC 
  not by having a JSON-LD WG, but through the RDF WG.
Gregg Kellogg:  Correct.
Robert Sanderson:  That was some very fortunate timing because it 
  meant that we didn't need to have a charter and all of the W3C 
  members vote to create a WG with its own team contact and so on.
Robert Sanderson:  For 1.1, we are unlikely to be so lucky.
Robert Sanderson:  In terms of getting to REC, the initial 
  barrier to entry is a bit higher. We'll need to get a WG up. 
  Which means that, the more solid the work is that we do the more 
  likely we'll get a WG. If it looks like a slam dunk at W3C, it's 
  not rubber stamping of course, but if it's possible to show 
  implementations, adoption, and good well-written specs out of the 
  gate, then getting a WG approved is much easier.
Robert Sanderson:  At TPAC we had some brief discussions with 
  team leads, Ralph Swick and Ivan Herman, and it's not only up to 
  them, but they seemed reasonable confident with a path forward 
  towards a WG.
Robert Sanderson:  The more work we do now, the more likely it is 
  to happen in a timely fashion. In particular, the more members 
  that are using it and building products around it, that require 
  1.1 features, that may be the most critical.
Robert Sanderson:  It's great to have the folks here from XBRL 
  here as new adopters and the consistency and continuity of 
  everyone else.
Robert Sanderson:  Gregg, others, want to talk about timelines?
Gregg Kellogg:  I guess there's a couple of ways we could 
  continue. We could basically try to wrap up the work we're doing 
  now in a bow so a WG could simply adopt, or we could push towards 
  going to a WG earlier and defer. A WG charter would need to be 
  created, it would be at least 6 months before a WG is chartered, 
  if one is ever chartered at all.
Gregg Kellogg:  In these areas I think the CG output can be quite 
  useful. It's not something that was available to people in the 
  past, but CG output is more of a social standard, not the end of 
  the world, but we'd like to see a WG.
Gregg Kellogg:  It would be nice to wrap things up with 1.1 and 
  then work to set up a WG to ideally adopt that work or perhaps 
  tag on to some other existing group to which the work is 
  sympathetic.
Robert Sanderson:  I don't know how you thought about Annotation 
  WG transition.
Robert Sanderson:  Paolo.
Robert Sanderson:  From my perspective, having a reasonably 
  thorough spec -- there was space for additional work, if desired, 
  seemed to be reasonably productive.
Robert Sanderson:  Paolo co-chaired the Annotation CG and then 
  the WG, which concluded at the beginning of 2017.
Robert Sanderson:  The community group did not talk about 
  protocol, there was no way of sharing annotations between 
  systems, there was some good discussion in doing that in the WG 
  context. That meant that the modeling side, while it was fully 
  discussed, that was more about fine tuning than designing from 
  scratch.
Robert Sanderson:  Having the design space for people to sink 
  their space into rather than people thinking it was just a rubber 
  stamping was helpful.
Robert Sanderson:  So the work we're doing here to get things 
  started would be valuable.
Paolo Ciccarese:  I agree with what you said, I think what 
  happened is -- we had some ideas before starting the WG. There 
  were boundaries changed and pushed in some ways, but a good 
  roadmap for the model and vocab to start. Not everyone was 
  extremely happy about that.
Paolo Ciccarese:  Some people who didn't participate in the CG 
  were offput because there were specs to work off of that had to 
  be brought in. But to have something solid before starting is a 
  good idea in general.
Niklas Lindström: ;)
Gregg Kellogg:  A point of admin here, if you are in IRC and have 
  a question or would like to contribute something, you can type 
  "q+" to use the queue.
Gregg Kellogg:  You can do "q-" to take yourself off.
Gregg Kellogg:  Q? to see the queue.
Robert Sanderson:  I agree with Gregg that 6 months is the 
  earliest to start on a charter and a target milestone would be 
  TPAC in 2018.
Robert Sanderson:  Talking with potential staff contacts, etc. 
  working through a charter to be proposed.
Robert Sanderson:  That would be November then, about 11 months, 
  to propose a charter.
Robert Sanderson:  Having the support of W3C management is 
  absolutely critical to getting things through. Talking in person 
  is more productive than phone calls.
Robert Sanderson:  Any further thoughts or questions around the 
  process?
None
Robert Sanderson:  A former co-chair of mine said, if you're not, 
  as chair, feeling like the silence is uncomfortable then you 
  haven't waited long enough for people to ask questions :)
Robert Sanderson:  It is 20 to the hour, which gives us the right 
  amount of time to review the 1.1 spec differences per Gregg's 
  slides.
Gregg Kellogg: TPAC slides 
  https://json-ld.org/presentations/JSON-LD-Update-TPAC-2017/assets/player/KeynoteDHTMLPlayer.html#5

Topic: Review current 1.1 work

Gregg Kellogg:  I don't think we want to try and accomplish too 
  much in the first week, doing an overview of what has transpired 
  is a good place to conclude what we're doing here.
Gregg Kellogg:  I pasted in a link to the slide deck that 
  describes the work that's been done since 1.0.
Gregg Kellogg:  There was quite a lot of time languishing between 
  1.0 and when we started getting more serious about moving 
  forward. During that time there were a number of issues or 
  errors, shortcomings of the 1.0 work. And new areas where people 
  would like to see JSON-LD move in.
Gregg Kellogg:  That was enough to give us a general consensus of 
  how to move forward. In particular, it was mostly about letting 
  more JSON to take on JSON-LD meaning. And better ways to 
  normalize the results. Additionally in the 1.0 time frame we were 
  working principally, Dave Longley's work on framing, ... it has 
  become quite important and more work as been done to improve the 
  spec.
Gregg Kellogg:  We'd like to consider framing to be part of the 
  1.1 effort and part of the API instead of a separate spec.
Gregg Kellogg:  Looking at the slides, the versioning 
  announcement creates a backwards compatibility effort. So some 
  people are suggesting that we should do JSON-LD 2.0.
Gregg Kellogg:  Rather than "1.1".
Gregg Kellogg:  In this case we need to make sure that a 1.0 
  processor doesn't misinterpret the data -- and we have done that 
  by introducing a version into the @context to cause a 1.0 to blow 
  up rather than misinterpret the data.
Gregg Kellogg:  So the example does that -- in particular here to 
  handle a @container that's different.
Robert Sanderson: (Slide 7)
Gregg Kellogg:  In order to move more like JSON and use more 
  objects and object keys to reference multiple things rather than 
  arrays of things, we looked to increase the types of things for 
  @container.
Robert Sanderson: (Slide 8, identifier maps)
Gregg Kellogg:  Previously we could set @language, @index, on a 
  term definition and that would cause a JSON-LD processor to 
  interpret the object value of that term as a map. The keys would 
  be language identifiers for @language and so on. When expanding 
  it turns into an array of value objects with language tags 
  within.
Gregg Kellogg:  We wanted to be able to do more things like that, 
  for example, with ids and types.
Gregg Kellogg:  Examples on slide 8.
Robert Sanderson: Eg the triple would be: <http://example.com/> 
  schema:blogPost <http://example.com/posts/1/en> .
Gregg Kellogg:  Property nesting -- many uses of JSON include 
  ways, where there's nominally an entity where properties aren't 
  keys of the entity but part of some structure underneath (has no 
  meaning in the data model). Slide 9 we see using that with 
  "labels".
Gregg Kellogg:  This @nest feature folds values up a layer.
Gregg Kellogg:  When expanded, it's as if the nested keys are 
  just properties of the top entity.
Robert Sanderson: Hence the triple here is:  
  <http://example.org/myresource> skos:prefLabel "This is the main 
  label..." .
Gregg Kellogg:  Scoped contexts solve a number of issues. If you 
  find yourself importing JSON-LD from another scope and you've 
  been frustrated with having to add an embedded @context 
  definition to define the @context in play for deeper values, this 
  allows you to use a term definition instead.
Gregg Kellogg:  Slide 10 has examples.
Gregg Kellogg:  The "interest" term has its own context for its 
  value without having to embed it.
Gregg Kellogg:  The feature is recursive so terms and is 
  round-tripping. Particularly useful for framing.
Gregg Kellogg:  A scoped context in the frame definition will be 
  applied to the framed results.
Gregg Kellogg:  You can also use scoped contexts on types.
@Type scoped contexts are useful for "object oriented" like 
  designs
Robert Sanderson: (Slide 12, compact IRIs)
Gregg Kellogg:  Improving Compact IRIs is meant to make the use 
  of curies less unexpected.
Gregg Kellogg:  There's a change where a term will only be 
  considered to be used as a prefix if the prefix key is set or if 
  the term ends in '/' or '#'.
Gregg Kellogg:  There are a variety of open issues after that.
Gregg Kellogg:  There are more open issues on github but they 
  aren't tagged with 1.1. They may relate to the website or 
  playground, but aren't critical towards updating the 1.1 specs 
  themselves.
Gregg Kellogg:  Any question?
Gregg Kellogg:  Issues for us to consider soon -- do we want to 
  stick with 1.1 and preserve 2.0 for a WG or stick with semantic 
  versioning and move towards 2.0.
Robert Sanderson:  This discussion continued at TPAC in November. 
  One thing that would be useful to inform it, would be what ... 
  what are the actual breaking changes and breaking for whom? For 
  example, a 1.1 processor that is using a 1.0 definition will work 
  fine vs. a 1.0 processor that will break in some situation.
Robert Sanderson:  As was brought up in November, that's probably 
  what we want in many of the situations.
Robert Sanderson:  Could you talk a bit more about what is broken 
  by the changes?
Gregg Kellogg:  Probably not as much as you would want. One of 
  the largest users of JSON-LD is Google. It is non-conforming 
  though, they don't look at a @context and they presume it's the 
  one that they've deployed. If you were to use this in there and 
  expect schema.org partners to interpret it properly you'd be 
  disappointed perhaps.
Gregg Kellogg:  Someone did report their processor breaking on a 
  1.1 version. But that's exactly the intent. But that raises the 
  question about adoption.
Herm Fisher: For XBRL we found a need to "certify" processors 
  against a set of standard test suites.
Gregg Kellogg:  And how it would work. The side conversations 
  I've had with Dan Brickley at Google -- they are not likely to 
  dereference a @context would be ... it would be useful as a URI 
  parameter. In the case when they are seeing a type definition in 
  a script tag in HTML, if the type was 
  "application/ld+json;version=2.0" that would give them the 
  opportunity to make use of these features without actually having 
  to dereference and process @contexts.
Gregg Kellogg:  In IIIF, Web of Things, things such as @id maps 
  are required functionality, it might be slow adoption from some 
  existing uses it could introduce cases where 1.0 compat isn't an 
  issue.
Herm Fisher:  We've always had a set of standard test suites, 
  that's part of every step of building changes to the spec. There 
  was enough cowboy behavior that it was decided to provide a 
  service that a product was part of the suite.
Paul Simmonds:  It's been nice to know how many conforming 
  implementations have come out of the work as a result [missed?].

Topic: JSON-LD Test Suite

Gregg Kellogg: https://json-ld.org/test-suite/
Robert Sanderson:  We also have test suites for JSON-LD. From a 
  process perspective, one of the W3C requirements is that there is 
  a test suite that implementers can use to ensure that they have 
  implemented the features in conformance with the spec.
Robert Sanderson:  It's a little fuzzy as to what a feature is 
  and what tests are needed, but overall, it's very much part of 
  the work that we need to do.
Gregg Kellogg:  There is a test suite that was begun in the 1.0 
  phase and has been continued. My practice has been, for every 
  update to the spec, that there are tests to test for appropriate 
  behavior.
Gregg Kellogg:  Those tests are marked with 1.1 so it's possible 
  for a 1.0 processor to continue to run tests and not trip over 
  things they aren't expecting. There is a quite comprehensive and 
  maintained test suite.
Gregg Kellogg:  This test suite was also and the implementation 
  reports were important for using a transition doc for showing 
  wide implementation and at any time we choose we can put forward 
  -- and do a call for implementations and accept implementation 
  documents.
Gregg Kellogg:  That would allow us to show conformance we have.
Gregg Kellogg:  At this point the only fully conformant processor 
  is my own, the Ruby processor, but work is underway on other 
  processors as well.
Robert Sanderson:  It's the top of the hour. Any questions or 
  comments?
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/560
Chris Webber:  So I was originally pinged to join the call to 
  suggest we take on the W3C's permissive software license for the 
  standard. It didn't exist when 1.0 came out. I found I wanted to 
  copy a lot of the language from the JSON-LD spec into the 
  implementation I was writing and wanted to ensure it was legally 
  feasible.

PROPOSAL:  accept issue 560

Chris Webber:  I wanted to raise it possibly for next week since 
  it was the reason I came onto this call.
Dave Longley: +1
Chris Webber: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Robert Sanderson: +1
Do you want the +1 here or on the issue?
David I. Lehn: +1
David I. Lehn:  Does this need approval from a wider audience? 
  Perhaps from the other contributors?
Robert Sanderson:  It might be prudent to ping Markus about it.

RESOLUTION: accept issue 560 pending lanthaler approval

Robert Sanderson:  Pending acceptance, as long as Markus is not 
  -1.
Robert Sanderson: Thanks everyone :)
Robert Sanderson: So ... SIP on Mac ... a good free client?
Gregg Kellogg: Linphone works well.
Robert Sanderson: Okay, I think I have it set up. Will try next 
  time.

Received on Monday, 8 January 2018 20:39:11 UTC