JSON-LD Working Group Telco — Minutes

Date: 2020-05-08

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Ivan Herman, Benjamin Young, David I. Lehn, Pierre-Antoine Champin, Gregg Kellogg

Regrets:

Guests:

Chair: Benjamin Young

Scribe(s): Gregg Kellogg, Benjamin Young

Content:


1. Announcements / Reminders?

1.1. let’s throw a party for our success! :)

Benjamin Young: gkellogg: as noted, the end of PR is after the end of the working group

Rob Sanderson: PR: https://www.w3.org/TR/json-ld11/ :)

Ivan Herman: it’s not a problem that end of PR is after end of WG. The publishing of a REC is a Team decision, not really a WG decision.
… There might be a few days off, but we can extend by a couple of weeks, if necessary.

Ivan Herman: https://www.w3.org/2002/09/wbs/33280/json-ld11/

Rob Sanderson: WG Note: https://www.w3.org/TR/json-ld11-streaming/ :)

Ivan Herman: https://www.w3.org/2002/09/wbs/33280/jsonld-charter/

Ivan Herman: Please get your AC reps to vote on the charter.

Gregg Kellogg: there’s some RDF* conversations happening on Twitter
… much about the JSON-LD integration/expression of the new things there
… could we work on that stuff in the maintenance group?

Ivan Herman: we’re in a “don’t ask” period of time right now
… if the new Process comes into the picture, then we can make some changes that could make it possible
… we’re in a gray zone, for right now. If the new process comes into the picture, an incremental change of the recommendation becomes possible. In theory, the WG may be able to do that.
… but it’s just a theory right now
… I’ve made the noises in the Team that this group would like to be able to do incremental improvement, but we can’t right now.
… The problem with RDF*, is that there is no underlying datamodel. The two CGs can collaborate.

Benjamin Young: The CGs can work together.

Ivan Herman: No comment :)

2. JSON-LD*

Gregg Kellogg: s/:)/:(/

2.1. recommended context redirects

Ivan Herman: Is the group fine with with the recommended context, then I can set up redirections.
… That involves the redirections for the RDFa initial context (html, RDF/XML, Turtle, and JSON-LD), plus the json-ld context.

Benjamin Young: why change names?

Ivan Herman: because management is done on GitHub, but they should be served from w3.org
… It’s easier to do with .htaccess, rather than a 302 redirect.

Rob Sanderson: If it’s a redirect, then when you go to the official name, you get redirected, so a copy/paste will be from the redirected location, not w3.org.

Ivan Herman: If you look at the website, it’s also a redirect, but you don’t see that in the browser’s address bar.

Pierre-Antoine Champin: I think the .htaccess rules are similar to a redirect, but technically, it’s not a redirect. It’s really a proxy.

Rob Sanderson: > RewriteRule ^info/sitemap.xml http://api.info.futures.co.uk/sitemap.xml [P]

Ivan Herman: This is what we have for the WG homepage

RewriteEngine on
RewriteBase /2018/json-ld-wg/
# make everything HTTPS
RewriteCond %{HTTPS} =off
RewriteRule (.*) [https://www.w3.org/2018/json-ld-wg/$1](https://www.w3.org/2018/json-ld-wg/$1) [L]
# This tree is proxied from (and maintained in) GitHub
<Limit PUT>
   Require all denied
</Limit>
# maps to github,io
RewriteRule (.*) [https://w3c.github.io/json-ld-wg/$1](https://w3c.github.io/json-ld-wg/$1) [P]

Rob Sanderson: Per https://stackoverflow.com/questions/27504762/reverse-proxy-htaccess

Benjamin Young: that’s what I was asking that we do.

Rob Sanderson: The [P] is the magic bit :)

Rob Sanderson: +1 :)

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Benjamin Young: +1

Ivan Herman: +1

Ivan Herman: Let’s be practical, I’m the one maintaining that stuff, so I can really have license to do it how I feel best.

Proposed resolution: rewrite original initial/recommended context URLs to GitHub for JSON-LD Maintenance Group to maintain longterm (Benjamin Young)

Gregg Kellogg: +1

Ivan Herman: +1

Benjamin Young: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Resolution #1: rewrite original initial/recommended context URLs to GitHub for JSON-LD Maintenance Group to maintain longterm

3. Open issue

3.1. Compacting IRIs associated to multi types values/nodes #484

Benjamin Young: https://github.com/w3c/json-ld-api/issues/484

Gregg Kellogg: we’ll add a new test for this–which is OK post PR
… it will be a good test of adding tests after PR
… we may need a more formal way of monitoring these changes under the Maintenance Group
… so that’s partly why this is worth discussing here

Ivan Herman: The future WG will need to decide. I’m not sure how formal other groups are for doing this. It’s not a process question.

Gregg Kellogg: there is an RDF Test curation CG
… and it has some recent activity to add some SPARQL cases
… which Andy Seaborne put in

Ivan Herman: and what’s their process?

Gregg Kellogg: people submit PRs
… I encourage discussion on the PR or on the mailing list
… and then based on discussion we merge it or don’t merge it
… there’s even an old one that’s unmerged which never got enough consensus
… and nothing’s come along to unblock it
… but anyway, there is a curation group that maintains the tests
… there was some thought to update the implementation reports
… but it was assigned to Eric and it never happened…think it just ran out of steam behind it
… but there is this CG, and our charter is specifically for managing these types of things
… regarding what a future WG/CG might do
… they would have authority for it
… and currently our current WG does have authority over this
… and so we should decide a process for this

Ivan Herman: I’d propose we just discuss these as we have been, and if we’re all fine with it, we merge it
… my proposal is that we decide whether or not to add a test and the maintenance group can agree with the CG on what happens.
… If the chairs of the CG and WG are common, there are other considerations.
… For this case, we can agree to do this as we did before.

Gregg Kellogg: more specifically, do we create a PR for tests, get buy-in for the PR, have a meeting, and then reach a resolution before we merge it?

Ivan Herman: this is not a normative change thing, so I don’t think that’s necessary

Gregg Kellogg: works for me
… yep. it will all happen on GitHub
… and silence will–after a time period–equal approval

Ivan Herman: anything else?
… We have a bit more than a month left. Is there anything more this WG intends to do?
… There are some pending NOTES that seem stalled.

Benjamin Young: Those things could be published by the CG in the json-ld.org space, and then brought to this or a future WG.

Ivan Herman: do we need to keep meeting?

Benjamin Young: We can set up a call in the CG to replace this and invite a wider group.
… That might get more people involved.
… Maybe meet in 2 weeks on the 22nd, with more people hopefully.
… The CG chairs can decide on minuting.

Ivan Herman: formally speaking, the WG doesn’t have any more to do.
… I’ll ask about continued use of the Zoom account by the CG.

Proposed resolution: no more official WG calls (unless needed to deal with PR vote issues); CG will use this same space/time (and possibly Zoom) to run future calls for community growth/awareness (Benjamin Young)

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

David I. Lehn: +1

Resolution #2: no more official WG calls (unless needed to deal with PR vote issues); CG will use this same space/time (and possibly Zoom) to run future calls for community growth/awareness


4. Resolutions