- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 22 Jan 2018 11:57:04 -0800
- To: Dan Brickley <danbri@danbri.org>
- Cc: Linked JSON <public-linked-json@w3.org>, Dan Brickley <danbri@google.com>
- Message-Id: <73526364-AFCE-495F-8660-E22F516B390B@greggkellogg.net>
> On Jan 22, 2018, at 11:42 AM, Dan Brickley <danbri@danbri.org> wrote:
>
> (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?
I suppose a blog post to talk about the new work is in order, but probably the best place to show the new features now is in the TPAC presentation [1].
> 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 ____”?
A worthy bit to put in a blog, but I don’t think it affects schema.org <http://schema.org/> too much.
> Do you have a feeling for how the proposals affect Schema.org-style deployment, or is the focus elsewhere?
Focus is on representation of things like language and id maps, along with scoped contexts. These help tremendously; there’s no reason schema.org <http://schema.org/> couldn’t use things like language maps right now; new work just makes it more normal when compacting.
Version announcement may be important for schema.org <http://schema.org/> partners so they don’t misinterpret data using non-schema.org <http://non-schema.org/> contexts. We discussed being able to add the version in the mime-type, in addition to the context, as not everyone actually interprets the context itself :). This needs to be specified, but could look something like the following:
<script type=“application/ld+json;version=1.1”>
…
</script>
I think id maps might be a cool use case for schema.org <http://schema.org/> for things like comment lists, for which you might otherwise use an array form.
The big thing still to be resolved in the 1.1/2.0 WG timeframe is to provide a means to avoid loading contexts in the first place. There have been some discussions on different URL schemes, IPFS and sub-resource normalization. I think it will come down to encouraging the use of custom document loaders which manage this, and best practice for how to validate and fill an application-specific loader.
Of course, we’re more than interested in any ways in which schema.org <http://schema.org/> partners think JSON-LD could evolve to better address use cases, and hope for your collective support for authorizing a Working Group.
Gregg
> Dan
[1] https://json-ld.org/presentations/JSON-LD-Update-TPAC-2017/assets/player/KeynoteDHTMLPlayer.html#0 <https://json-ld.org/presentations/JSON-LD-Update-TPAC-2017/assets/player/KeynoteDHTMLPlayer.html#0>
> On 22 January 2018 at 19:27, Gregg Kellogg <gregg@greggkellogg.net <mailto: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 <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 <mailto: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 <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 <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 <https://lists.w3.org/Archives/Public/public-linked-json/2018Jan/0001.html>
>
> Topic: WG Charter
>
> https://json-ld.github.io/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/ <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 <mailto: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 <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 <http://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 <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 <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
>
>
>
>
>
Received on Monday, 22 January 2018 19:57:32 UTC