17:05:03 <RRSAgent> RRSAgent has joined #json-ld
17:05:03 <RRSAgent> logging to https://www.w3.org/2020/02/21-json-ld-irc
17:05:05 <Zakim> RRSAgent, make logs Public
17:05:07 <Zakim> please title this meeting ("meeting: ..."), bigbluehat
17:05:37 <bigbluehat> Meeting: JSON-LD Working Group Telco
17:05:40 <bigbluehat> Chair: bigbluehat
17:05:58 <bigbluehat> Regrets: ivan, azaroth
17:06:16 <gkellogg> present+
17:06:20 <pchampin> present+
17:06:20 <bigbluehat> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Feb/0022.html
17:06:21 <rubensworks> present+
17:06:24 <timCole> present+
17:06:24 <dlongley> present+
17:06:31 <dlehn> present+
17:06:32 <bigbluehat> present+
17:06:56 <bigbluehat> Meeting Agenda 2020-02-21: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Feb/0022.html
17:07:00 <hsolbrig> hsolbrig has joined #json-ld
17:07:18 <hsolbrig> present+
17:08:02 <bigbluehat> Topic: Scribe Selection
17:08:44 <bigbluehat> scribenick: hsolbrig
17:09:35 <bigbluehat> Topic: Announcement / Reminders?
17:09:54 <bigbluehat> scribenick+ bigbluehat
17:10:12 <bigbluehat> hsolbrig: I posted something on the mailing list about a semantic web meeting in Raleigh
17:10:22 <bigbluehat> ...I've got 90 minutes to say good things about JSON-LD
17:10:49 <bigbluehat> ...I can fill the 90 minutes, but wanted to share the opportunity with others who might want to chip in
17:10:55 <bigbluehat> gkellogg: there's some past material that might be useful
17:10:57 <gkellogg> https://json-ld.org/learn.html
17:11:06 <bigbluehat> hsolbrig: yeah, I've been digging through those, but hope to take a different approach
17:11:14 <bigbluehat> ...I'm going to go from the RDF side and then to JSON-LD
17:11:23 <bigbluehat> ...which is what finally helped me understand it all
17:11:33 <bigbluehat> ...90 minutes is a long time, and I'd love other contributors
17:11:59 <bigbluehat> gkellogg: would be great to get these on json-ld.org
17:12:02 <bigbluehat> hsolbrig: yeah, that'd be great.
17:12:07 <bigbluehat> bigbluehat: sadly can't make it, but wish I could
17:12:23 <bigbluehat> hsolbrig: David Booth is presenting content on Easier RDF
17:12:28 <bigbluehat> gkellogg: yeah, that's a community group
17:12:36 <bigbluehat> hsolbrig: yeah, much of that seems covered by JSON-LD
17:12:44 <bigbluehat> ...and it's just a matter of understanding what you can do.
17:12:55 <gkellogg> https://github.com/w3c/EasierRDF
17:13:07 <hsolbrig> scribenic+ hsolbric
17:13:13 <hsolbrig> scribenic+ hsolbrig
17:13:26 <hsolbrig> bigbluehat: Ruben got his PhD
17:13:36 <hsolbrig> .... applause
17:13:49 <hsolbrig> s/applause/loud applause/
17:13:57 <bigbluehat> Topic: Issues
17:14:07 <bigbluehat> Subtopic: [monitor] Consider context by reference with metadata
17:14:15 <bigbluehat> https://github.com/w3c/security-review/issues/24
17:14:46 <bigbluehat> Born out of https://github.com/w3c/json-ld-syntax/issues/108
17:14:49 <hsolbrig> bigbluehat: I think it was plh who posted this issue, not sure what solicited the issue
17:15:01 <hsolbrig> ... issue 108 discussed last week
17:15:19 <hsolbrig> ... if you are curious, subscribe to it
17:15:42 <hsolbrig> ... we should watch in case conversation begins before we hear about it
17:16:01 <hsolbrig> bigbluehat:  Ivan put out transition request for CR
17:16:38 <bigbluehat> Subtopic: Transition request for syntax and api https://github.com/w3c/transitions/issues/230
17:17:14 <hsolbrig> ... formal request -- subscribe if you are interested in monitoring its progress
17:17:26 <hsolbrig> gkellogg:  effective pub data needs updated
17:17:57 <hsolbrig> ... will also be publishing an update to the framing document.  All three have CR end date extended to March 30
17:18:16 <hsolbrig> ... so far mine is the only implementation report in there.  jsonld.js should be ready soon
17:18:33 <gkellogg> https://w3c.github.io/json-ld-api/reports/
17:19:12 <hsolbrig> bigbluehat: we expect other IR's to submit reports as described in this document
17:19:21 <rubensworks> q+
17:19:26 <bigbluehat> ack rubensworks
17:19:27 <hsolbrig> ... anyone willing to jump in on testing their implementation
17:19:47 <hsolbrig> robensworks: report on streaming parser - 83% of the to-rdf spec tests pass
17:20:04 <hsolbrig> ... majority of failing are due to type-scoped context, still needs implementation
17:20:04 <dlongley> q+
17:20:08 <bigbluehat> ack dlongley
17:20:44 <hsolbrig> dlongley: The only thing jsonld.js needs is the html piece -- also a bit of framing
17:20:56 <hsolbrig> ... could put an interim report up there
17:21:08 <hsolbrig> q+
17:21:35 <hsolbrig> gkellogg: if we have incomplete reports, it gives a sense of progress
17:21:49 <bigbluehat> ack hsolbrig
17:21:58 <bigbluehat> rubensworks: I think I can run reports later today
17:22:17 <bigbluehat> hsolbrig: is `@included` implemented?
17:22:28 <bigbluehat> dlehn: it's done, but not released yet
17:22:38 <bigbluehat> hsolbrig: some of the stuff we're doing will be much prettier once that stuff shows up
17:22:54 <bigbluehat> ...we're using it to tack on an ontology header
17:23:02 <bigbluehat> ...right now we're using `@graph` which makes peoples brains hurt
17:23:12 <bigbluehat> dlehn: we should be close
17:23:28 <bigbluehat> hsolbrig: as an aside, we forked the playground and put samples in for our use cases
17:23:48 <bigbluehat> dlehn: yeah...the playground is out of date...and it'd be great to get fresh content there
17:24:05 <bigbluehat> hsolbrig: some of these are specific to us, but may be helpful to others
17:24:16 <bigbluehat> ...it might encourage others to use the playground other places
17:25:26 <gkellogg> https://github.com/schemaorg/schemaorg/issues/2468
17:25:28 <hsolbrig> bigbluehat:  There is an issue with schema.org conneg
17:26:02 <hsolbrig> gkellogg: recommends that the highest priority context type ...  results in getting html, which is wrong
17:26:13 <hsolbrig> ... hopefully there will be an update on their site.
17:26:36 <hsolbrig> bigbluehat:  python code has been merged -- an hour ago
17:27:00 <hsolbrig> gkellogg: merge references something in my implementation.
17:27:23 <hsolbrig> bigbluehat: you may be able to rerun the tests shortly
17:28:17 <hsolbrig> bigbluehat: On to issues
17:28:22 <bigbluehat> Subtopic: Suggestion about `@prefix` https://github.com/w3c/json-ld-syntax/issues/329
17:28:43 <bigbluehat> hsolbrig: ah yes. that was quite a discovery
17:29:05 <bigbluehat> ...some of the prefixes an upstream group used weren't making it through
17:29:11 <bigbluehat> ...we chased it down to an errata on 1.0
17:29:25 <bigbluehat> ...if the URI didn't end in `#` or `/`, then it was being treated different
17:29:31 <bigbluehat> gkellogg: gendelim characters
17:29:45 <bigbluehat> hsolbrig: before that errata came through, they were doing all sorts of things with URIs
17:30:17 <bigbluehat> ...one part of the issue is related to 1.0
17:30:28 <bigbluehat> ...and hopefully anything we do for 1.1 can be back rev'd
17:30:41 <bigbluehat> ...we first looked at 1.1's expanded context form processing
17:31:19 <bigbluehat> ...we started using `@prefix: true` to call these out
17:31:28 <bigbluehat> ...but folks are using JSON parsers as well as JSON-LD parsers
17:31:32 <gkellogg> `”CHEBI”: {“@id”: "http://example.org/CHEBI_”, “@prefix”: true}`
17:31:47 <bigbluehat> ...i.e. they're only using strings for prefix values
17:31:58 <bigbluehat> ...`"CHEBI": "http://...."`
17:32:20 <bigbluehat> ...one proposed alternative was `@prefix: true` on the surrounding `@context` object
17:32:31 <bigbluehat> ...but in further discussions with the group, it still gives them some major work to do
17:32:49 <bigbluehat> ...what they asked (and I think makes sense) was, can we add a parameter to the API as if it was `@prefix: true`
17:33:13 <bigbluehat> ...now, I'd still like to look at the `@prefix` on the surrounding `@context` object as it organizes the intent
17:33:28 <bigbluehat> ...it's otherwise not always obvious what the author meant
17:33:38 <gkellogg> q+
17:33:46 <pchampin> q+
17:33:46 <bigbluehat> ...but in the immediate term, if we could get something at the API level, that would be helpful
17:33:58 <bigbluehat> ...we forked jsonld.js and made this change, and got it working for this communities use case
17:34:13 <bigbluehat> ack gkellogg
17:34:31 <bigbluehat> gkellogg: sadly, the problem we face is that we're in our second round of CR
17:34:36 <bigbluehat> ...and have been in feature freeze for sometime
17:34:41 <bigbluehat> ...and all of these are normative changes
17:34:47 <bigbluehat> ...so that would mean either a third CR
17:35:07 <bigbluehat> ...or postpone what we're doing to address some of these other late-breaking suggestions
17:35:16 <bigbluehat> ...there's a few things here:
17:35:25 <bigbluehat> ...`@prefix` directly on `@context`
17:35:40 <bigbluehat> ...your API parameter--which I'm less in favor of, but understand the motivation of
17:35:50 <bigbluehat> ...if Ivan were here, he would not be pleased
17:36:06 <bigbluehat> ...and I'm not sure how we would address such late breaking changes
17:36:08 <bigbluehat> ack pchampin
17:36:17 <bigbluehat> pchampin: big +1 to what gkellogg just said
17:36:27 <bigbluehat> ...seems to me there might be another solution that might be as breaking
17:36:36 <bigbluehat> ...that could perhaps even be considered non-normative
17:36:46 <bigbluehat> ...the errata on 1.0 was to avoid any arbitrary IRI to be used as a prefix
17:37:04 <bigbluehat> ...but the use case here isn't about that
17:37:16 <bigbluehat> ...they're consistently using an underscore...corect?
17:37:33 <bigbluehat> hsolbrig: sadly, no. it ends in `_`, `=`, and even `:` or alphanumeric characters
17:37:51 <bigbluehat> pchampin: gendelim includes `:` at least
17:37:58 <bigbluehat> ...but alphanumerics...no...
17:38:10 <gkellogg> `gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / “@“`
17:38:22 <bigbluehat> ...my idea was to "extend" the use of gen-delims in this case
17:38:29 <bigbluehat> ...but that sounds like it won't work
17:38:42 <bigbluehat> hsolbrig: this was an early adopter community, and I'd hate to break this for them
17:38:58 <bigbluehat> pchampin: so, my proposal would be...asking the group around CR compliance....
17:39:25 <bigbluehat> ...that the intention of the gen-delim choice would be preserved even if we proposed extending that list of characters
17:39:47 <bigbluehat> gkellogg: we specifically call out a lot of this use in the docs...
17:40:19 <bigbluehat> ...we could do some of this at the API level, but I think it's still normative changes
17:40:31 <bigbluehat> ...really it's the prefix: true behaviour that seems necessary
17:40:39 <bigbluehat> ...it's not a technical question really
17:40:44 <bigbluehat> ...it'll be normative regardless
17:41:00 <bigbluehat> ...and I don't see how we could do that without doing another CR
17:41:02 <bigbluehat> q+
17:41:10 <bigbluehat> ack bigbluehat
17:41:26 <dlongley> do we still have time to push CR #2 back? and if so ... how much time would we need?
17:41:31 <hsolbrig> bigbluehat: I am not a CR cop and don't know what we can and can't do
17:41:37 <dlongley> q+
17:41:48 <hsolbrig> ... I second harold on supporting the new community
17:41:58 <hsolbrig> ... this is not the first group to get tangled up in this
17:42:10 <hsolbrig> ... probably there is a need to address this
17:42:30 <hsolbrig> ... we need a staff contact to make this call from a staff contact
17:42:41 <bigbluehat> ack dlongley
17:42:45 <hsolbrig> ... we may have to table it until Ivan comes back
17:43:05 <hsolbrig> dlongley: do we still have time to push second CR back and how much time do we need
17:43:24 <hsolbrig> ... which gets to next issue.  Want to avoid slow drip drip drip...
17:43:45 <hsolbrig> ... can we add a legacy flag which allows transitioning?
17:44:07 <hsolbrig> ... I don't see any other way than pushing CR back
17:44:21 <hsolbrig> ... we should also talk about the next issue as well, which would also push CR back
17:45:16 <hsolbrig> bigbluehat: I do think that situation is a mix of two paths -- yea, that's not quite JSON-LD vs. changing everything about how JSON-LD vs. bumping CR back
17:46:18 <hsolbrig> gkellogg:  What we're looking at is calendar math w/ June deadline, are we at the point where we're going to have to ask for an extension
17:46:42 <hsolbrig> bigbluehat:  that used to be a bad thing, but maybe not so much
17:47:14 <hsolbrig> ... now that we're going to print, folks are starting to dive in.  Very real reasons to get an extension done ...
17:47:52 <hsolbrig> ... propose we table this issue and 379, as likely cause for CR extension, will become broad topic for next week
17:48:29 <bigbluehat> Subtopic: Inconsistent management of empty terms https://github.com/w3c/json-ld-api/issues/379
17:48:34 <hsolbrig> bigbluehat: API topic - Issue 379
17:49:08 <hsolbrig> gkellogg: this is not a normative change.  We say term may not be an empty string
17:49:22 <hsolbrig> ... we just don't have any tests to validate processors.
17:49:32 <hsolbrig> ... adding that doesn't represent the same problem with prefixes
17:49:34 <hsolbrig> q+
17:49:42 <bigbluehat> ack hsolbrig
17:49:56 <bigbluehat> hsolbrig: as that was discovered, I asked about their use cases for `""`
17:50:08 <bigbluehat> ...they weren't actually sure, but they wouldn't object if they were flagged as errors
17:50:38 <bigbluehat> ...they're happy if the processor flags the errors and they'll fix the errors
17:50:48 <bigbluehat> bigbluehat: you mentioned they have "plain JSON" parsers also?
17:50:49 <pchampin> this is already rejected by the playground
17:51:01 <bigbluehat> hsolbrig: yeah, but here it doesn't matter. That was on the `@prefix` side of things
17:51:43 <bigbluehat> ...they're using a Java based JSON-LD processor and rdflib JSON-Ld
17:52:03 <hsolbrig> bigbluehat: any actions?
17:52:17 <rubensworks> q+
17:52:22 <bigbluehat> ack rubensworks
17:52:37 <gkellogg> q+
17:52:42 <hsolbrig> rubensworks: One possible why they used it is that they're coming from formats like turtle
17:52:49 <hsolbrig> ... which would be similar to this.
17:53:24 <bigbluehat> hsolbrig: yeah. it's the same sort of issue we face with `@base`
17:53:34 <bigbluehat> ...they import lots of `@context` files
17:53:45 <bigbluehat> ...and `@default` doesn't make sense for them
17:53:52 <bigbluehat> gkellogg: I don't think this is close `wont-fix`
17:54:00 <bigbluehat> ...I think we need to make sure processors throw proper errors
17:54:05 <bigbluehat> ...and have specifics about it and tests
17:54:07 <hsolbrig> bigbluehat: This isn't close, don't fix.  Should be add a test to make sure the processors generate an error
17:54:10 <bigbluehat> ...but that should be non-normative
17:55:00 <bigbluehat> PROPOSAL: pchampin to send in a PR for implementations to raise proper errors around `""` + tests
17:55:07 <dlongley> +1
17:55:07 <gkellogg> +1
17:55:10 <bigbluehat> +1
17:55:11 <timCole> +1
17:55:11 <pchampin> +1
17:55:24 <rubensworks> +1
17:55:26 <hsolbrig> +1
17:56:05 <bigbluehat> Subtopic: Expansion does not take property-scoped contexts for nested properties into account
17:56:11 <bigbluehat> https://github.com/w3c/json-ld-api/issues/380
17:56:17 <dlongley> q+
17:56:20 <gkellogg> q+
17:56:26 <bigbluehat> ack gkellogg
17:56:30 <bigbluehat> ack dlongley
17:56:32 <gkellogg> q+
17:56:39 <hsolbrig> bigbluehat:  dave mentioned that this might be potentially worth another CR
17:57:12 <hsolbrig> dlongley: I am surprised that this isn't something we already cover -- @gkellogg -- will this one change get us to where we want to be
17:57:36 <hsolbrig> gkellogg: I think it is similar to last one.  We don't say anything about it, but it doesn't mean it is a new feature
17:57:51 <hsolbrig> ... for the most part, suggestion works for expansion.  Haven't looked at compaction
17:58:10 <hsolbrig> ... implemenation impact is that you have to check impact when iterating through.
17:58:19 <dlongley> q+
17:58:24 <bigbluehat> ack gkellogg
17:58:25 <hsolbrig> ... I think we could handle this as needs tests and tweak, not a normative change.
17:58:27 <bigbluehat> ack dlongley
17:58:31 <gkellogg> ack gkellogg
17:58:57 <hsolbrig> dlongley: I would like a resolution from group that this is non-normative, we will handle this
17:59:39 <hsolbrig> dlongley: If we agree that it won't effect CR, we can postpone
17:59:42 <bigbluehat> PROPOSAL: #380 would not need normative changes, but does needs tests. We will discuss further next week to confirm.
17:59:45 <gkellogg> +1
17:59:48 <dlongley> +1
17:59:48 <hsolbrig> +1
17:59:48 <timCole> +1
17:59:50 <bigbluehat> +1
17:59:52 <rubensworks> +1
17:59:55 <dlehn> +1
18:00:00 <pchampin> +1
18:00:05 <bigbluehat> RESOLVED: #380 would not need normative changes, but does needs tests. We will discuss further next week to confirm.
18:00:17 <bigbluehat> RESOLVED: pchampin to send in a PR for implementations to raise proper errors around `""` + tests
18:01:25 <bigbluehat> Topic: Adjourn
18:01:26 <bigbluehat> zakim, end meeting
18:01:26 <Zakim> As of this point the attendees have been gkellogg, pchampin, rubensworks, timCole, dlongley, dlehn, bigbluehat, hsolbrig
18:01:28 <Zakim> RRSAgent, please draft minutes
18:01:28 <RRSAgent> I have made the request to generate https://www.w3.org/2020/02/21-json-ld-minutes.html Zakim
18:01:31 <Zakim> I am happy to have been of service, bigbluehat; please remember to excuse RRSAgent.  Goodbye
18:01:35 <Zakim> Zakim has left #json-ld
18:03:03 <bigbluehat> RRSAgent, please excuse us
18:03:03 <RRSAgent> I see no action items