Re: [MINUTES] W3C JSON-LD CG Call 2018-01-22

(unlurking)

If I wanted to share a quick overview of the proposed new JSON-LD work
(including examples, and implications for classic/older parsers) to
colleagues, what should I show them?

Is there a doc that says "in the bad old days we used to have to write
_____, whereas if everyone updates their json-ld parsers, we'll be able to
write ____"?

Do you have a feeling for how the proposals affect Schema.org-style
deployment, or is the focus elsewhere?

Dan

On 22 January 2018 at 19:27, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> Thanks to Gregg Kellogg for scribing this week! The minutes for this
> week’s JSON-LD CG teleconference are now available:
> https://json-ld.org/minutes/2018-01-22/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-22
>
> Agenda:
>   https://lists.w3.org/Archives/Public/public-linked-json/
> 2018Jan/0003.html
> Topics:
>   1. WG Charter
>   2. issue #569 maps with no keys
> Resolutions:
>   1. Ivan to ask W3M about JSON-LD working group, as okay to send
>     notice to the AC
>   2. Use public-linked-json for the discussions of the charter
>   3. The scope and timing as laid out in the draft charter covers
>     the work appropriately
>   4. Accept PR #569, and address concerns in new issues
> Organizer:
>   Gregg Kellogg and Rob Sanderson
> Scribe:
>   Gregg Kellogg and Robert Sanderson
> Present:
>   Niklas Lindström, David I. Lehn, Robert Sanderson, Gregg Kellogg,
>   Paolo Ciccarese, Ivan Herman, Herm Fisher
> Audio:
>   https://json-ld.github.io/minutes/2018-01-22/audio.ogg
>
> [SIP/sip.linphone.org-000003d3] has joined the conference.
> [SIP/sip.linphone.org-000003d5] has joined the conference.
> Niklas Lindström: I heard someone but I cannot be heard it seems
> [SIP/sip.linphone.org-000003db] has joined the conference.
> [SIP/sip.linphone.org-000003dd] has joined the conference.
> David I. Lehn: I can only lurk on call today, busy working on
>   something else
> [SIP/sip.linphone.org-000003dd] has left the conference.
> Robert Sanderson: Good morning folks :)
> [SIP/sip.linphone.org-000003d3], gkellogg
>   [SIP/sip.linphone.org-000003d5], Niklas Lindström
>   [SIP/sip2sip.info-000003d8], 15056034108
>   [SIP/69.65.34.216-000003d9], 18184044708
>   [SIP/69.65.34.216-000003da], gkellogg
>   [SIP/sip.linphone.org-000003db], David Lehn [SIP/6003-000003dc].
> [SIP/sip.linphone.org-000003e0] has joined the conference.
> [SIP/sip.linphone.org-000003e0] has left the conference.
> Gregg Kellogg: Voip 03e1 is me
> Robert Sanderson: I'm getting tons of echo ... everyone else is
>   okay? Just my line?
> Robert Sanderson: Will reconnect
> Sounds distorted and echoing to me (dialed in voice line and on
>   mute)  - Herm
> Robert Sanderson: Likewise
> Robert Sanderson: Almost incomprehensible
> Niklas Lindström:  You're line was going crazy [scribe assist by
>   David I. Lehn]
> Niklas Lindström:  Can you reconnect?  you were ok before [scribe
>   assist by David I. Lehn]
> Niklas Lindström: Sure
> [SIP/sip.linphone.org-000003d3], gkellogg
>   [SIP/sip.linphone.org-000003d5], 18184044708
>   [SIP/69.65.34.216-000003da], gkellogg
>   [SIP/sip.linphone.org-000003db], David Lehn [SIP/6003-000003dc],
>   Niklas Lindström [SIP/sip2sip.info-000003df], 14156868603
>   [SIP/69.65.34.216-000003e1], 15056034108
>   [SIP/69.65.34.216-000003e3].
> Niklas Lindström:  You have weird crackling feedback [scribe
>   assist by David I. Lehn]
> Niklas Lindström: Still? i lowered my mic volume too now
> [SIP/sip.linphone.org-000003d3], gkellogg
>   [SIP/sip.linphone.org-000003d5], Herm
>   [SIP/69.65.34.216-000003da], gkellogg
>   [SIP/sip.linphone.org-000003db], David Lehn [SIP/6003-000003dc],
>   gkellogg [SIP/69.65.34.216-000003e1], azaroth
>   [SIP/69.65.34.216-000003e3], Niklas Lindström
>   [SIP/sip2sip.info-000003e5], Unknown [SIP/69.65.34.216-000003e4].
> Paolo Ciccarese: Hi with, just joined SIP/69.65.34.216-000003e4 -
>   with brittle connection and also hearing badly
> Niklas Lindström: Sure
> Gregg Kellogg is scribing.
> [SIP/sip.linphone.org-000003d3], gkellogg
>   [SIP/sip.linphone.org-000003d5], Herm
>   [SIP/69.65.34.216-000003da], gkellogg
>   [SIP/sip.linphone.org-000003db], David Lehn [SIP/6003-000003dc],
>   gkellogg [SIP/69.65.34.216-000003e1], azaroth
>   [SIP/69.65.34.216-000003e3], Niklas Lindström
>   [SIP/sip2sip.info-000003e5], Unknown [SIP/69.65.34.216-000003e4].
> Minutes from last call:
>   https://lists.w3.org/Archives/Public/public-linked-json/
> 2018Jan/0001.html
>
> Topic: WG Charter
>
> https://json-ld.github.io/charter/
> Robert Sanderson:  Over the last couple of weeks we’ve been
>   talking with Ivan Herman at W3C on forming a WG.
> Ivan Herman:  My name is Ivan Herman, I’m on the W3C team, and
>   have a long history with RDF; I was staff contact on the RDF
>   working group where JSON-LD was standardized, also on RDFa and
>   Annotations.
> Robert Sanderson:  We’ve been talking about how to charter a WG
>   towards a next version of the JSON-LD specs (1.1 or 2.0).
> Robert Sanderson: https://json-ld.github.io/charter/
>   … We started a very draft version of a proposed charter. We
>   should talk though some things, the first being chairs and
>   editors.
>   … There were difficulties with having the same person being
>   both a chair and an editor at the same time; this creates a
>   possibility for roles to be confused, so it’s best to avoid the
>   perception.
>   … As a result, you’ll notice that Rob is listed as chair, but
>   does not include gkellogg, who is chair in the CG, but without
>   gkellogg, there is no continuity in editing the specs.
> Ivan Herman:  I know there was such a discussion, but it’s a more
>   general issue, having one person playing too crucial a role. I’ve
>   been in other groups where there is a similar situation, and
>   there’s always a dependency on both editors and chairs.
>   … Having too high a dependency creates practical difficulties.
>   However, I think this is probably not the most urgent issue.
>   … For those of you not involved with setting up a WG, we have a
>   long way ahead; defining another chair can be done in a couple of
>   weeks.
>   … The process is such that we should get agreement from W3C
>   management to start at all. I need to submit a request to W3M and
>   send a note to the AC with a draft to get feedback.
>   … The goal is that by the time we get to formal voting, we’ve
>   sorted out all the issues and voting becomes easier. Of course,
>   some people wait to object to the end anyway.
>   … For that to happen, we could do that very quickly, as there
>   is already a draft charter; it doesn’t need to be fully done, I
>   think what’s there is pretty much good to go.
>   … What we need is a decision by this group to go forward. If
>   you agree, I’ll send the request to W3CM tomorrow.
>   … The practical step to settle is that we have a github repo,
>   and people can submit issues there, but there are outliers that
>   want to use email. We could use existing
>   public-linked-json@w3.org email address, or set up one
>   specifically for this purpose.
> Robert Sanderson:  I imagine that everyone is enthusiastic about
>   this.
>
> PROPOSAL:   Ivan to ask W3M about JSON-LD working group, as okay
>   to send advance warning/warming to the AC
>
> Gregg Kellogg: +1
> Advance notice
> Robert Sanderson: +1
> Paolo Ciccarese: +1
> Niklas Lindström: +1
> David I. Lehn: +1
>
> RESOLUTION: Ivan to ask W3M about JSON-LD working group, as okay
>   to send notice to the AC
>
>   … two process questions: can we used a non-W3C Github repo, or
>   does it need to be a repo within the w3c org.
> Ivan Herman:  For now, it’s fine, when the formal vote comes,
>   I’ll need to put the charter text on W3C space.
>   … For the WG as well, should we continue to use the current
>   repos, or more to w3c?
> Ivan Herman:  I think the CSS people use another org, but there
>   may be practical issues that make using the w3c oranzization
>   useful.
>   … If your in a w3c org, most of the team members have access,
>   so if ivan has a problem, you can get help from someone else.
>   Just practical issues, nothing required.
>   … We can settle this later.
> Robert Sanderson:  We should discuss, so we can move CG work
>   there too.
> Ivan Herman:  Are there other discussions that wouldn’t be of CG
>   interest.
> Robert Sanderson:  The list isn’t that high a volume that charter
>   discussions would overwhelm it.
>   … you may need to agree to IPR requirements to sign up for the
>   CG mailing list.
>   … I agree that the visibility of using the CG list is more
>   valuable than setting up a new list.
>
> PROPOSAL:   Use public-linked-json for the discussions of the
>   charter
>
> Gregg Kellogg: +1
> Robert Sanderson: +1
> Niklas Lindström: +1
> Paolo Ciccarese: +1
> Robert Sanderson: Ivan - poll for call times:
>   https://doodle.com/poll/s634w8ced3264pbx
> Ivan Herman:  I’ll start the process tomorrow, and put Rob on the
>   CC list.
>
> RESOLUTION: Use public-linked-json for the discussions of the
>   charter
>
> Robert Sanderson:  Although this time worked for people, there
>   are some for whom this is late, and there might be another
>   prefereable time that would be better for people in Europe.
>   … further on the charter, I mentioned the chair issue, and it
>   shouldn’t be Gregg.
>   … Scope is pretty well defined, which boils down to
>   serialization and API, which would also include framing.
>   … The serialization spec will include discussions we’re working
>   on now.
>   … the last big issue is the bit about splitting out the
>   JSON-specific bits to enable things like YAML-LD. If we have an
>   abstract syntax that can be made concrete as JSON-LD, YAML-LD and
>   whatever else.
> Gregg Kellogg:  Also worth looking at the time line [scribe
>   assist by Robert Sanderson]
> Robert Sanderson: ... Not sure that we have 18 months of work to
>   do. Might consider intermediate milestones, and continue work on
>   something that follows on
> Robert Sanderson: ... And how to address that in the timeline
>   section.  If we continue as now, we might have a PR in the first
>   quarter of next year or earlier
> Robert Sanderson: ... Based on 18 month overall, so finish up
>   about Dec 2019
> Robert Sanderson:  In my experience, there are several months of
>   testing and implementation, although may be simpler in our case,
>   as we have a base of implementations to go on.
>   … Even so, I think 18 months is right, and we’d rather not file
>   for an extension.
> Herm Fisher:  Is there a test-suite?
> Robert Sanderson:  Part of the process of getting the Rec is that
>   we must have a test suite, every normative statement must be
>   tested, and implemented by at least two implementations.
>   … There is a test suite already for 1.0, which may need to be
>   updated.
>   … We may want to pull out the test suite from the current repo.
> Gregg Kellogg:  Need to look for corner cases not being tested
>   [scribe assist by Robert Sanderson]
> Robert Sanderson: ... One was pointed out this morning for using
>   none in language maps
> Robert Sanderson: ... Having an infrastructure and reasonable
>   coverage for the features, we're in pretty good shape
> Robert Sanderson: ... One issue is that there are some specific
>   behaviors for looking at redirects and other headers that are
>   called for in the spec, but make it difficult to run from a
>   github repo
> Robert Sanderson: ... One of the reasons why we used json-ld.org
> Robert Sanderson: ... In w3c space, we would need an alternative
>   way to handle that
> Robert Sanderson:  In the annotation work, we had a similar
>   problem. We created a server that could be run locally to do this
>   as well.
>
> PROPOSAL:   The scope and timing as laid out in the draft charter
>   covers the work appropriately
>
> Robert Sanderson: +1
> Gregg Kellogg: +1
> Niklas Lindström: +1
> Paolo Ciccarese: +1
>
> RESOLUTION: The scope and timing as laid out in the draft charter
>   covers the work appropriately
>
> Robert Sanderson:  Comments can also be done on email.
> Robert Sanderson:
>   https://rawgit.com/json-ld/json-ld.org/maps-with-no-keys/
> spec/latest/json-ld/index.html#data-indexing
> Robert Sanderson:  There’s also a doodle poll open.
> Robert Sanderson: Issue: #569 maps with no keys
>
> Topic: issue #569 maps with no keys
>
> Robert Sanderson is scribing.
> Paolo Ciccarese: https://github.com/json-ld/json-ld.org/pull/569
> Gregg Kellogg:  This resolves an issue with the representation of
>   values without a language in language maps
>   ... previously it would not select a value without a language
>   to be used in a language map
>   ... sometimes this is what you want, sometimes it makes it more
>   difficult
>   ... this PR addresses it for index, id, graph, and type maps to
>   allow anything to be added to a map with the key `@none`
>   ... (example, per Example 66 etc in the spec)
>   ... all of these are just syntactic, there's no interpretation
>   in RDF
>   ... the expansion removes the maps
>   ... it complicates the term selection algorithm.  We create a
>   prioritized set of containers to look at
>   ... need to add the data in different places in the algorithm
>   to prioritize @none when there is a container
>   ... primary cost is the increased complexity and the number of
>   options to consider during term selection
> Robert Sanderson:  The value of this is that language is
>   inconsistently recorded in real data. Language maps are a great
>   pattern, but it can lead to inconsistent experience in navigating
>   data when data does not match the pattern. The addition of @none
>   is quite valuable, as all values can be represented using maps
>   now. [scribe assist by Gregg Kellogg]
> Niklas Lindström:  I am in favor of this PR, as I’ve seen similar
>   use cases. I’m a bit concerned regarding the possibility of using
>   a term bound with a null language to represent the value of
>   something without a language in tandom. It is an existing
>   complication, but I haven’t had time to consider changes to the
>   PR. [scribe assist by Gregg Kellogg]
> Gregg Kellogg: … I don’t think we can change previous
>   compatibility.
> Robert Sanderson:  I think backwards compatibility is an open
>   discussion, but as far as I know, this is the only time where
>   data would be backwards incompatible. [scribe assist by Gregg
>   Kellogg]
> Gregg Kellogg:  We've avoided the use of empty string as a key as
>   PHP implementations pre 7 have difficulties with it
> Paolo Ciccarese:  I like the solution in a vacuum, but wondered
>   about how empty strings are handled. [scribe assist by Gregg
>   Kellogg]
> Paolo Ciccarese:  So @none means we have a key
>   ... and an empty string would be a second way to do it
> Gregg Kellogg:  The algorithm would be treated as a value, and
>   you'd end up with a value object that had a language and a
>   language that was empty string, rather than no language at all
>   ... You could do that in RDF (I think)
>   ... so they're not isomorphic
>   ... even if most systems would treat them that way
> Gregg Kellogg: … So @none is a way of doing it, but would not be
>   treated the same way.
> Gregg Kellogg:  Backwards compatibility ... if you have a term
>   that allows a language map in 1.0, you would use that for all the
>   values with a language
>   ... and an absolute URI for things that didn't have a language
>   ... in 1.1 it would go into the map with @none. The issue is
>   with two different properties, one for language map and one for
>   language of none
>   ... want to be sure that we'd use a specific term that didn't
>   match /no/ language, and hence compatible with 1.0
>   ... the failing case is in not using a term at all
>   ... the fallback to absolute IRIs is already broken :)
>   ... if that is an issue we could change the behavior based on
>   the version, and hence a 1.1 mode processor could do it one way
>   and a 1.0 processor the current way
>   ... backwards compatible with bugs isn't something I put value
>   on, personally
> Niklas Lindström:  I agree that the absolute IRI case doesn’t
>   seem intentional, I just wanted to reflect on the empty language
>   tag: I think the lexical representation of language prohibits the
>   use of an empty language. [scribe assist by Gregg Kellogg]
> Gregg Kellogg: … Regarding the empty string, I’m pretty sure that
>   was a PHP implementation issue which has since been fixed, I
>   don’t think Python had the issue. Still, I think that the usage
>   of empty strings as keys is a problem. I’ll likely map @none to
>   something else.
> Robert Sanderson:  Any objections on the PR? [scribe assist by
>   Gregg Kellogg]
> Gregg Kellogg: … We can always revisit if issues come up.
>
> PROPOSAL:   Accept PR #569
>
> Robert Sanderson: +1
> Gregg Kellogg: +Q
> Niklas Lindström: +0.5
> Gregg Kellogg: +1
> Clarification:  We'll continue to address issues, but accept the
>   majority of the change
> Niklas Lindström: Thanks all!
>
> RESOLUTION: Accept PR #569, and address concerns in new issues
>
>
>
>
>