15:11:40 <RRSAgent> RRSAgent has joined #json-ld
15:11:40 <RRSAgent> logging to https://www.w3.org/2019/05/03-json-ld-irc
15:11:41 <ivan> rrsagent, set log public
15:11:41 <ivan> Meeting: JSON-LD Working Group Telco
15:11:41 <ivan> Chair: azeroth
15:11:41 <ivan> Date: 2019-05-03
15:11:41 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0000.html
15:11:41 <ivan> ivan has changed the topic to: Meeting Agenda 2019-05-03: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019May/0000.html
15:41:23 <rubensworks> rubensworks has joined #json-ld
15:50:04 <azaroth> azaroth has joined #json-ld
15:58:29 <gkellogg> present+
15:58:50 <ivan> present+
15:58:52 <rubensworks> present+
15:59:43 <ivan> chair- azeroth
15:59:52 <ivan> chair+ azaroth
16:00:28 <ivan> chair- azaroth
16:00:33 <ivan> chair+ bigbluehat
16:00:41 <bigbluehat> present+
16:00:59 <dlongley> present+
16:02:08 <ivan> present+ dlongley
16:02:17 <ivan> present+ dlehn
16:02:35 <pchampin> pchampin has joined #json-ld
16:02:48 <bigbluehat> scribenick: pchampin
16:02:52 <pchampin> present+
16:02:59 <bigbluehat> Topic: Approve minutes of previous cal:
16:02:59 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-26-json-ld
16:03:03 <ajs6f> ajs6f has joined #json-ld
16:03:08 <ajs6f> present+
16:03:30 <bigbluehat> +1
16:03:32 <rubensworks> +1
16:03:35 <ivan> s/cal/call/
16:03:39 <dlongley> +1
16:03:41 <dlehn> +1
16:03:41 <pchampin> +1
16:03:43 <timCole> timCole has joined #json-ld
16:03:45 <ivan> resolved: last week's minutes accepted
16:03:46 <bigbluehat> RESOLVED: minutes approved
16:03:55 <bigbluehat> Topic: Announcements / Reminders
16:04:07 <jeff_mixter> jeff_mixter has joined #json-ld
16:04:12 <jeff_mixter> present+
16:04:21 <timCole> present+ Tim_Cole
16:04:50 <pchampin> bigbluehat: Ivan and I will be at the Publishin WG next week
16:05:56 <bigbluehat> Topic: Issues
16:05:56 <pchampin> ... The call on the 17th is during The Web Conference. Should we cancel?
16:06:04 <bigbluehat> Subtopic: Indexing without a predicate: https://github.com/w3c/json-ld-syntax/issues/19
16:06:35 <gkellogg> Related https://github.com/w3c/json-ld-wg/issues/52
16:06:38 <pchampin> bigbluehat: this is issue is also known as `@included`
16:06:44 <pchampin> ... proposed by azaroth
16:07:15 <pchampin> ... there is a relatad proposal by gkellogg
16:07:24 <rubensworks> s/relatad/related/
16:07:44 <pchampin> gkellogg: there are several ways of doing something alla id-ref
16:08:14 <pchampin> ... one of them would be to combine `@nest` and `@container:@id`
16:08:44 <pchampin> ... Rob's proposal would better be handled in expansion (this is where syntactic sugar is removed).
16:09:53 <pchampin> ... Properties declared as e.g. `@container:@include` would look into a special `@include` container.
16:10:28 <pchampin> ... Problem with compaction, which can not easily reverse this kind of extension.
16:10:43 <pchampin> ... More appropriate in Framing.
16:10:56 <pchampin> ... Seems quite complex and convoluted, with a lot of corner cases.
16:11:08 <bigbluehat> q?
16:11:22 <pchampin> ivan: azaroth asks to defer that topic until he can join
16:11:27 <bigbluehat> Subtopic: More compact @prefix: https://github.com/w3c/json-ld-api/issues/76
16:12:44 <pchampin> bitbluehat: proposal from rubenworks, to make it simpler to declare `@prefix` terms
16:12:56 <bigbluehat> s/bitbluehat/bigbluehat
16:13:14 <dlongley> q+
16:13:18 <bigbluehat> ack dlongley
16:13:22 <gkellogg> q+
16:13:31 <pchampin> rubenworks: a similar thing is already possible with `@reverse`, so it should not be too hard to add in implementations
16:13:58 <pchampin> dlongley: is this an error?
16:14:01 <bigbluehat> ack gkellogg
16:14:08 <gkellogg> https://github.com/w3c/json-ld-api/pull/77
16:14:10 <dlongley> dlongley: what do we do when `@id` and `@prefix` are both strings and they disagree? is that an error?
16:14:31 <pchampin> gkellogg: it is with `@reverse`, so it should be an error, yes
16:15:32 <pchampin> gkellogg: there is a point in the issue about terms which are not appropriate as prefixes
16:16:00 <ivan> q+
16:16:22 <bigbluehat> q+ rubensworks
16:16:58 <dlongley> my understanding is that the proposal is that `"@prefix": <string>` is just syntactic magic for `"@id": <string>, "@prefix": true`
16:17:15 <dlongley> not a replacement
16:17:50 <pchampin> ... there are two aspects in the PR: 1/ use `@prefix` where the value is an IRI, while the current practice is to use `@id` with an IRI, and `@prefix` is a boolean. Should we obsolete the current practice?
16:18:06 <bigbluehat> ack ivan
16:18:06 <ivan> q-
16:18:10 <pchampin> 2/ what if the value of `@prefix` is a pname?
16:18:16 <bigbluehat> ack rubensworks
16:20:47 <rubensworks> q+
16:20:49 <ivan> q+
16:20:52 <bigbluehat> ack rubensworks
16:21:00 <pchampin> rubenworks: [answers to gkellogg]
16:21:14 <pchampin> gkellogg: we must keep in mind the JSON 1.0 behaviour
16:21:36 <bigbluehat> ack ivan
16:21:37 <pchampin> rubenworks: I see this as an alternate representation
16:22:02 <pchampin> ivan: does the combination of `@id` and `@prefix:false` come up in practice?
16:22:22 <pchampin> gkellogg: there are reasons to use it. I don't know if it is used in the wild?
16:22:40 <pchampin> ivan: that would be a reason to keep the current practice, and consider the new version as a shorthand
16:23:28 <bigbluehat> q?
16:23:35 <pchampin> ... and I wouldn't be shocked if the new notation `@prefix:IRI` was roundtriped to `@id+@prefix:true`
16:23:44 <pchampin> gkellogg: we don't roundtrip contexts anyway
16:24:12 <pchampin> bigbluehat: there seems to be a consensus on considering the proposal as a shorthand for the current syntax
16:24:16 <gkellogg> q+
16:24:22 <bigbluehat> ack gkellogg
16:24:59 <pchampin> gkellogg: there are some implications; must be some working on the implications of combinations of `@id` and `@prefix`
16:25:07 <bigbluehat> https://w3c.github.io/json-ld-syntax/#compact-iris (for current text)
16:25:31 <pchampin> ... you probably would not use the prefix term as a property
16:25:37 <bigbluehat> q+
16:25:41 <bigbluehat> ack bigbluehat
16:25:45 <dlongley> perhaps if `@prefix` is an error, then also including `@id` is an error ... and then process `@prefix` as a string first and do the transformation to `@id: <string>, @prefix: true`
16:26:03 <bigbluehat> https://w3c.github.io/json-ld-syntax/#example-32-using-explicit-prefix-declaration-to-create-compact-iris
16:26:09 <dlongley> s/`@prefix` is an error/`@prefix` is a string/
16:26:17 <pchampin> bigbluehat: `@id+@prefix:true` feels a lot like using `@vocab`
16:26:38 <pchampin> gkellogg: it works a little differently in the compactIRI algo
16:27:16 <pchampin> ... we are going contrary the trend of moving compact IRIs away
16:27:24 <gkellogg> q=
16:27:26 <gkellogg> q+
16:27:30 <bigbluehat> ack gkellogg
16:28:03 <pchampin> ... the reason it is there is that, in 1.0, many terms were used to build compact IRIs, but were not intended to do that
16:28:16 <dlongley> lots of unwanted CURIEs being greedily generated
16:28:38 <dlongley> in 1.0
16:28:39 <pchampin> ... eg: Sport := schema:Sport, then using Sport:Event
16:29:07 <pchampin> ... `@prefix` was a way of capturing the intention of the creator of the term
16:29:19 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/155
16:30:33 <dlongley> q+
16:30:34 <pchampin> bigbluehat: strange compact IRIs can be used maliciously, to misdirect users to an unexpected endpoint URL
16:30:37 <bigbluehat> ack dlongley
16:31:00 <pchampin> dlongley: I like the syntax, makes it more obvious that the term is intended to be used as a prefix
16:31:23 <azaroth> present+ Rob_Sanderson
16:31:27 <pchampin> ... even though I don't like CURIEs in general
16:31:30 <bigbluehat> curie spec of yor https://www.w3.org/TR/curie/
16:31:31 <pchampin> ... in JSON-LD
16:31:46 <pchampin> ... It was a mistake in 1.0 to allow any term to be used as a prefix
16:32:08 <pchampin> bigbluehat: I agree with that
16:32:09 <pchampin> q+
16:32:15 <bigbluehat> ack pchampin
16:32:20 <bigbluehat> scribenick: rubensworks
16:33:01 <gkellogg> q+
16:33:14 <rubensworks> pchampin: Proposal is not to make @prefix:true the default?
16:33:21 <rubensworks> dlongley: No
16:33:27 <bigbluehat> scribenick: pchampin
16:33:33 <ivan> q+
16:33:34 <bigbluehat> ack gkellogg
16:33:40 <dlongley> s/@prefix:true/@prefix:false/
16:33:40 <pchampin> s/@prefix:true/`@prefix:false`/
16:34:09 <pchampin> gkellogg: we *did* change 1.0 behaviour by limiting the terms that can be used as prefixes
16:34:11 <dlongley> s/@prefix:false/`@prefix:false`/
16:34:15 <bigbluehat> ack ivan
16:34:48 <pchampin> ... only IRIs ending with slash or hash can be used as prefixes
16:36:00 <dlongley> instead of just "property"
16:36:06 <pchampin> ivan: what does `@prefix:false` means?
16:37:05 <bigbluehat> gendelim https://tools.ietf.org/html/rfc3986#section-2.2
16:37:10 <bigbluehat> q?
16:37:16 <ivan> for the records: https://tinyurl.com/yxw7qv98 (example)
16:37:24 <pchampin> gkellogg: it means that we do not want this term to be used by compaction to generate a compact IRI
16:37:54 <rubensworks> q+
16:37:56 <gkellogg> https://w3c.github.io/json-ld-syntax/#example-32-using-explicit-prefix-declaration-to-create-compact-iris
16:38:15 <pchampin> s/with slash or hash/gen-delims/
16:38:39 <dlongley> q+
16:38:45 <dlongley> q+ to explain the difference
16:38:46 <pchampin> ... for expansion, it does not matter whether `@prefix` is true or false
16:39:07 <rubensworks> q-
16:39:21 <bigbluehat> ack dlongley
16:39:21 <Zakim> dlongley, you wanted to explain the difference
16:39:43 <pchampin> dlongley: if you click on compact in the link above
16:40:02 <bigbluehat> q+
16:40:08 <bigbluehat> ack bigbluehat
16:40:30 <pchampin> ... by copying the context to the right and changing the value of `@prefix`
16:40:38 <pchampin> ... you can see the difference
16:41:08 <pchampin> ... but you can't make a term *only* a prefix, this is a 1.0 problem, we can't go back
16:41:22 <pchampin> gkellogg: but we could define `@prefix:IRI` to  mean exactly that
16:41:49 <pchampin> ... but we still mean `@prefix:false`
16:42:17 <pchampin> dlongley: yes, but that would differ from what we said earlier. This is not syntactic sugar anymore
16:42:18 <pchampin> q+
16:42:26 <bigbluehat> ack pchampin
16:43:35 <rubensworks> pchampin: another way would be add 3 values for @prefix
16:43:37 <azaroth> +1 to PA
16:43:39 <rubensworks> default: @default would say you can use this prefix as a term
16:43:45 <dlongley> q+
16:43:45 <rubensworks> ...false as you can not use this as prefix
16:43:50 <bigbluehat> ack dlongley
16:43:51 <rubensworks> ... true, the proposed new meaning that gregg proposed about @prefix IRI
16:43:57 <rubensworks> ... this way we can keep backwards compat with 1.0
16:44:19 <pchampin> s/default:/pchampin:/
16:45:18 <bigbluehat> PROPOSAL: dlongley and pchampion to craft alternate proposal to #76 with `@prefix` having 3 values
16:45:24 <gkellogg> +1
16:45:26 <ajs6f> +1
16:45:29 <bigbluehat> +1
16:45:32 <rubensworks> +1
16:45:33 <ivan> +1
16:45:35 <dlongley> +1 sure
16:45:37 <dlehn> +1
16:45:38 <pchampin> dlongley: the third value would be an IRI, and we're back to what gkellogg just proposed
16:45:41 <azaroth> +1
16:45:57 <bigbluehat> RESOLVED: dlongley and pchampion to craft alternate proposal to #76 with `@prefix` having 3 values
16:46:10 <bigbluehat> Topic: spec release cadence
16:46:11 <pchampin> gkellogg: we are processing issues slowly
16:46:26 <pchampin> ... we have not released a draft in a while
16:46:43 <bigbluehat> q?
16:47:30 <pchampin> s/pchampion/pchampin/g
16:47:42 <pchampin> gkellogg: some issues in the management console are editorial work
16:48:21 <bigbluehat> discussing this column: https://github.com/orgs/w3c/projects/4#column-3279307
16:48:27 <pchampin> ... [enumerates which issues should be addressed after or before the next working draft]
16:48:42 <pchampin> ... I would like to segment the issues for discussion,
16:48:56 <pchampin> ... between those who are standing in the way of releasing a WD,
16:49:04 <pchampin> ... and those that can be discussed afterwards
16:51:06 <gkellogg> https://w3c.github.io/json-ld-syntax/#inheriting-base-iri-from-html-s-base-element
16:52:48 <dlongley> +1 to consolidating all the HTML stuff under document loader
16:52:49 <pchampin> ivan: we can close the issue about HTML base; there is a text in the document
16:53:16 <pchampin> gkellogg: another editorial issue is pushing forward the documentLoader,
16:53:37 <pchampin> ... so that we can move all the HTML processing into the documentLoader
16:53:58 <pchampin> ... problem: this changes the interface of the documentLoader,
16:54:09 <pchampin> ... so might be consider as a backward compatibility issue
16:54:10 <azaroth> +1 as well
16:54:20 <azaroth> q+
16:54:26 <bigbluehat> ack azaroth
16:54:37 <dlongley> q+
16:54:54 <pchampin> azaroth: working drafts are just... working draft
16:55:13 <pchampin> ... we can release one now, as long as the editors are not embarassed by what's in there
16:55:23 <pchampin> ... it is still to be considered as work in progress anyway
16:55:34 <ivan> +1 to azaroth
16:55:41 <pchampin> ... we don't neet to finish anything before releasing it
16:56:09 <pchampin> gkellogg: given how long it's been since the last WD, the next one is going to be quite consequential
16:56:56 <pchampin> ... if we decide to defer the discussion on documentLoader, I can release a WD this afternoon
16:57:05 <bigbluehat> ack dlongley
16:57:06 <bigbluehat> q+
16:57:42 <pchampin> ... We still should address bigbluehat's discussion about contexts being IRIs (identifiers) or URLs (dereferenceable)
16:58:02 <pchampin> dlongley: I'm surprised that the spec says that documentLoader returns a string;
16:58:19 <pchampin> ... any other text in the spec is written as if it returned a document
16:58:38 <pchampin> ... so the returning a string is a spec error
16:58:40 <azaroth> q+
16:58:58 <pchampin> gkellogg: I agree. This could be fixed easily.
16:59:03 <bigbluehat> ack bigbluehat
16:59:04 <azaroth> q-
16:59:14 <dlongley> q+
16:59:21 <pchampin> ... The error may have been introduced after 1.0, with the migration to the next ReSpec version.
16:59:38 <pchampin> bigbluehat: regarding my remarks on contexts IRI vs. URL,
16:59:55 <pchampin> ... the abstracting behind documentLoader would solve that problem.
17:00:29 <bigbluehat> ack dlongley
17:00:49 <pchampin> ... Putting this change in a WD, very early after we have discussed it,
17:01:14 <pchampin> ... would be new for this WG. We have to be awer of that.
17:01:43 <pchampin> dlongley: I checked: the problem with the definition of documentLoader was not in 1.0; it has been introduced by 1.1.
17:01:44 <bigbluehat> PROPOSAL: gkellog should publish a new WD containing the proposed documentLoader changes https://github.com/w3c/json-ld-api/issues/85 which will be discussed at a future time.
17:01:50 <pchampin> ... so we can safely fix it back.
17:01:54 <gkellogg> +1
17:01:55 <dlongley> +1
17:01:56 <rubensworks> +1
17:01:56 <bigbluehat> +1
17:01:57 <azaroth> +1
17:01:57 <ajs6f> +1
17:01:59 <pchampin> +1
17:02:00 <timCole> +
17:02:01 <dlehn> +1
17:02:05 <timCole> +1
17:02:08 <bigbluehat> RESOLVED: gkellog should publish a new WD containing the proposed documentLoader changes https://github.com/w3c/json-ld-api/issues/85 which will be discussed at a future time.
17:02:25 <dlongley> s/gkellog/gkellogg
17:03:13 <ivan> rrsagent, draft minutes
17:03:13 <RRSAgent> I have made the request to generate https://www.w3.org/2019/05/03-json-ld-minutes.html ivan