15:04:13 <RRSAgent> RRSAgent has joined #json-ld
15:04:13 <RRSAgent> logging to https://www.w3.org/2019/08/09-json-ld-irc
15:04:14 <ivan> rrsagent, set log public
15:04:14 <ivan> Meeting: JSON-LD Working Group Telco
15:04:14 <ivan> Date: 2019-08-09
15:04:14 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Aug/0009.html
15:04:14 <ivan> ivan has changed the topic to: Meeting Agenda 2019-08-09: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Aug/0009.html
15:04:15 <ivan> Regrets+ azaroth
15:04:15 <ivan> Chair: bigbluehat
15:17:46 <gkellogg> gkellogg has joined #json-ld
15:42:16 <rubensworks> rubensworks has joined #json-ld
15:52:55 <pchampin> pchampin has joined #json-ld
15:58:01 <timCole> timCole has joined #json-ld
15:58:15 <gkellogg> gkellogg has joined #json-ld
15:58:17 <ajs6f> ajs6f has joined #json-ld
15:59:20 <ajs6f> present+
15:59:22 <bigbluehat> present+
15:59:25 <rubensworks> present+
15:59:29 <pchampin> present+
15:59:41 <gkellogg> present+
15:59:53 <timCole> present+
16:01:34 <ivan> regrets+ workersgnome
16:01:43 <ivan> regrets+ workergnome
16:01:58 <bigbluehat> Topic: Scribe Selection
16:02:36 <bigbluehat> scribenick: pchampin
16:02:41 <bigbluehat> Topic: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-08-02-json-ld
16:02:48 <gkellogg> +1
16:02:49 <rubensworks> +1
16:02:49 <ajs6f> +1
16:02:52 <ivan> +1
16:02:59 <timCole> +1
16:03:00 <pchampin> +0
16:03:06 <bigbluehat> RESOLVED: minutes approved
16:03:16 <dlongley> present+
16:03:20 <bigbluehat> Topic: Announcements / Reminders
16:03:27 <bigbluehat> Subtopic: Standing TPAC reminder
16:03:42 <pchampin> bigbluehat: I home everyone's booked
16:03:44 <ivan> q+
16:03:47 <bigbluehat> ack ivan
16:04:12 <rubensworks> s/home/hope/
16:04:26 <pchampin> ivan: if the DID WG is accepted, there will be a F2F on monday
16:05:07 <pchampin> ... that might cause a conflict with the Web Publishing WG
16:06:55 <ivan> Topic: issues
16:07:07 <bigbluehat> Subtopic: Consider obsoleting use of blank nodes for properties and "generalized RDF"
16:07:12 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/37
16:07:48 <pchampin> bigbluehat: we more or less already aggreed to deprecate this one
16:08:09 <pchampin> ... but it turns out that ActivityStreams is using a bnode `@vocab`
16:08:42 <pchampin> ... Note that AS is part of AvivityPub, which is used by Mastodon and other
16:09:04 <pchampin> ... All those people get worrying warnings when using the AS context.
16:09:10 <gkellogg> q+
16:09:13 <bigbluehat> ack gkellogg
16:09:40 <pchampin> gkellogg: there is a comment in there, indicating that they don't believe that they are actually creating any property.
16:09:56 <bigbluehat> q+ to ask about 1.1 mode
16:10:03 <pchampin> ... pchampin suggested to raise the warning only when the bnode `@vocab` *does* create a bnode property
16:10:19 <pchampin> ... I think that solves Mastodon's issue. I did it in my implementation.
16:10:47 <bigbluehat> ack bigbluehat
16:10:47 <Zakim> bigbluehat, you wanted to ask about 1.1 mode
16:11:01 <pchampin> bigbluehat: could this warning be limited to 1.1 mode?
16:11:05 <pchampin> gkellogg: yes
16:11:32 <pchampin> bigbluehat: is this the default? because these people are not parsing JSON-LD 1.1, AFAIK
16:12:31 <rubensworks> q+
16:12:50 <pchampin> gkellogg: actually, that's right, the warning is not mode dependant
16:13:28 <bigbluehat> ack rubensworks
16:13:29 <pchampin> ... the purpose of the warning is precisely to warn people that his may go away in the *future*
16:13:53 <pchampin> rubensworks: are these warnings specifed in the spec or implem specific?
16:14:31 <pchampin> gkellogg: the spec says "feature at risk". It does not actually says anything about issuing a warning.
16:14:42 <bigbluehat> https://w3c.github.io/json-ld-api/#h-issue-0
16:14:53 <pchampin> ... We indeed do not specify how warnings are issued.
16:15:19 <bigbluehat> https://w3c.github.io/json-ld-api/#h-note-3
16:16:13 <pchampin> ... I usually use a 'validation' flag to decide whether warning are issued or not,
16:16:24 <bigbluehat> q+
16:16:26 <bigbluehat> ack bigbluehat
16:16:26 <pchampin> ... although obviously I didn't to that in that case.
16:16:54 <pchampin> bigbluehat: distributed documents are long lived,
16:17:11 <pchampin> ... we should take this into account when it comes to issuing warnings.
16:17:20 <pchampin> ... The person we are targetting here is the context author.
16:17:59 <pchampin> ... Hence my suggestion to limit the warning to 1.1 mode,
16:18:10 <pchampin> ... meaning "it will still work here, but may break in the future".
16:18:55 <pchampin> ... People mining old 1.0 data will get the warning, but there is nothing they can do about it.
16:20:00 <pchampin> gkellogg: without warnings, the developers will not get pressure from their user to drop deprecated features
16:20:50 <pchampin> ... the 'validation' flag is probably a good way to solve this
16:21:22 <pchampin> dlongley: there are a lot of implementations that can only report errors, not warnings
16:22:12 <pchampin> bigbluehat: so do we need to change the spec?
16:22:17 <gkellogg> https://www.w3.org/TR/json-ld11-api/#algorithm-2
16:23:16 <pchampin> gkellogg: we need to be clearer about the bnode properties
16:24:00 <pchampin> bigbluehat: should we recommend an alterative to the bnode `@vocab`?
16:24:17 <pchampin> ... such as a "fake bnode" IRI acting as a catch-all for undefined properties?
16:25:05 <pchampin> ... The AS context shows that there is a need for that;
16:25:17 <gkellogg> q+\
16:25:23 <pchampin> ... JSON users do not like their properties to *disappear* through JSON-LD processing.
16:25:23 <bigbluehat> ack \
16:25:56 <pchampin> gkellogg: the most suitable replacement would be `"@vocab": "#"`
16:26:03 <pchampin> ... this is common in other uses of RDF,
16:26:04 <dlongley> +1 to `"@vocab": "#"`
16:26:21 <pchampin> ... and the reason why we allowed relative IRIs as `@vocab`
16:27:19 <bigbluehat> scribe+ bigbluehat
16:27:48 <dlongley> q+
16:27:55 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/37#issuecomment-515799176
16:28:05 <bigbluehat> and in the spec at https://www.w3.org/TR/json-ld11/#data-model
16:28:40 <bigbluehat> ack dlongley
16:28:41 <pchampin> ... If we provide such an alternative to bnode properties, we can change the 'AT RISK's to simple notes.
16:29:35 <timCole> q+
16:29:53 <bigbluehat> https://www.w3.org/TR/json-ld11/#h-issue-0
16:29:54 <pchampin> dlongley: when we go to CR, I'm affraid people would object to bnode properties if we remove the 'AT RISK'...
16:30:06 <ivan> q+
16:31:00 <pchampin> gkellogg: these AT RISK are not normative. We could leave them for CR, and remove them afterwards.
16:31:02 <bigbluehat> ack timCole
16:32:19 <pchampin> timeCole: for me the purpose of 'AT RISK' is testing; it draws the attention to points that we are not sure can be implemented.
16:32:41 <bigbluehat> ack ivan
16:32:47 <bigbluehat> PROPOSED: turn blank node issue https://www.w3.org/TR/json-ld11/#h-issue-0 into a note to suggest new context authors avoid using `"@vocab": "_:"` as well as direct use of blank nodes as properties.
16:33:07 <ivan> +1
16:33:08 <timCole> +1
16:33:12 <gkellogg> +1
16:33:15 <bigbluehat> +1
16:33:15 <rubensworks> +1
16:33:28 <ajs6f> This would be a note that accompanies 1.1?
16:33:30 <pchampin> ivan: timCole is right. It is used to mark features that can be removed if they lack implementation, without having to go through CR again.
16:33:41 <dlongley> +0 fine with me
16:33:46 <pchampin> +1
16:34:15 <ajs6f> +0.5
16:34:21 <bigbluehat> RESOLVED: turn blank node issue https://www.w3.org/TR/json-ld11/#h-issue-0 into a note to suggest new context authors avoid using `"@vocab": "_:"` as well as direct use of blank nodes as properties.
16:35:33 <pchampin> gkellogg: we will then turn the 'AT RISK' issues into notes;
16:35:36 <pchampin> ... we will recomment to use `#` relative IRIs instead;
16:35:55 <pchampin> ... we will suggest to issue a warning whenever a bnode property is generated.
16:36:08 <dlongley> q+
16:36:10 <pchampin> ... None of these points are normative. So they don't need more WG action.
16:36:14 <bigbluehat> ack dlongley
16:36:51 <pchampin> dlongley: if don't have a base IRI set and use a relative IRI for the `@vocab`,
16:37:16 <pchampin> ... then properties will *still* be droped when converted to RDF.
16:37:38 <pchampin> ... So we are improving the situation, but not solving it 100%.
16:37:59 <bigbluehat> PROPOSED: close https://github.com/w3c/json-ld-syntax/issues/37 once blank node property issue is changed to a note
16:38:03 <ivan> +1
16:38:04 <bigbluehat> +1
16:38:04 <dlongley> +1
16:38:05 <pchampin> +1
16:38:06 <rubensworks> +1
16:38:10 <gkellogg> +1
16:38:11 <timCole> +1
16:38:15 <bigbluehat> RESOLVED: close https://github.com/w3c/json-ld-syntax/issues/37 once blank node property issue is changed to a note
16:38:30 <bigbluehat> Subtopic: What is null base URL for an embedded json-ld?
16:38:38 <ivan> https://github.com/w3c/json-ld-syntax/issues/103
16:38:38 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/103
16:39:23 <pchampin> bigbluehat: the question is raised when JSON-LD is embedded in HTML or anything.
16:39:46 <pchampin> ivan: someone cameup with this example involving data: URL and iframe,
16:40:02 <pchampin> ... leading to a situation where the base URL is not clear.
16:41:44 <pchampin> gkellogg: the fact that it is in HTML does not change anything,
16:42:43 <pchampin> ... the processor tries to determine the base URL based on the source document URL.
16:43:06 <bigbluehat> PROPOSED: close #103 as wontfix because the JSON-LD document would be treated as if it were alone--and not embedded.
16:43:38 <pchampin> ivan: the problem is the use of the data: URL. The question is not JSON-LD specific. It would be the same with HTML
16:43:52 <pchampin> gkellogg: this is a TAG issue
16:45:30 <pchampin> ivan: It is a HTML problem.  Whatever HTML does, we do it.
16:45:41 <dlongley> +1
16:45:53 <rubensworks> +1
16:45:56 <gkellogg> +1
16:45:56 <bigbluehat> +1
16:45:59 <pchampin> bigbluehat: and if HTML has no answer wrt to the base URL, then you are on your own.
16:46:00 <ivan> +1
16:46:00 <pchampin> +1
16:46:04 <timCole> +1
16:46:09 <bigbluehat> RESOLVED: close #103 as wontfix because the JSON-LD document would be treated as if it were alone--and not embedded.
16:47:23 <gkellogg> https://github.com/w3c/json-ld-api/pull/132
16:47:25 <bigbluehat> Subtopic: Please review https://github.com/w3c/json-ld-api/pull/132
16:47:39 <bigbluehat> Subtopic: Link header for HTML and JSON-LD
16:47:44 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/204
16:48:28 <pchampin> gkellogg: this was trying to rely to danbri's concern about relying on content negociation
16:49:03 <pchampin> ... the best solution I came up with was to rely on a link HTTP header
16:49:12 <ivan> q+
16:49:22 <rubensworks> q+
16:49:30 <bigbluehat> q+ to mention Link headers aren't always possible on static hosting either (seeAlso github pages)
16:49:32 <bigbluehat> ack ivan
16:49:35 <pchampin> ... A JSON-LD processor expecting a context at a given URL would check for this header,
16:49:46 <pchampin> ... and follow the link if any.
16:50:01 <pchampin> ivan: other people do that, with `rel="manifest"`
16:50:27 <pchampin> ... the Web Publication WG does something similar with `rel="publication"`
16:50:28 <pchampin> q+
16:50:47 <bigbluehat> ack rubensworks
16:51:09 <pchampin> ... we can bikeshed about what `rel` value we want. But this makes sense.
16:51:13 <gkellogg> q+
16:51:28 <pchampin> rubensworks: link headers are not always possible on static websites, e.g. github pages.
16:51:38 <bigbluehat> ack bigbluehat
16:51:38 <Zakim> bigbluehat, you wanted to mention Link headers aren't always possible on static hosting either (seeAlso github pages)
16:52:15 <pchampin> bigbluehat: just to be clear, the link header we are talking about is a HTTP header, *not* HTML `<link>`
16:52:28 <pchampin> ... It is not as common as content negociation on static sites.
16:53:08 <pchampin> ... So we should specify that JSON-LD processors should first try content-negociation,
16:53:49 <pchampin> ... it it fails, it should try HTML (which implies embedding a HTML parser)
16:53:59 <pchampin> s/it it fails/if it fails/
16:54:05 <dlongley> +1 to link headers, -1 to involving HTML processing *at all* w/context processing as it breaks the ecosystem
16:54:10 <bigbluehat> ack pchampin
16:54:16 <pchampin> ... then it should check the link header.
16:54:36 <bigbluehat> pchampin: I think this solution makes sense
16:54:50 <bigbluehat> ...whether content negotiation has priority or not, I think this would be nice to have
16:55:17 <bigbluehat> ...the way I saw it this was a way to get rid of a dependency on HTTP
16:55:32 <dlongley> q+
16:56:01 <bigbluehat> ack gkellogg
16:56:21 <pchampin> gkellogg: this is all because the desire of schema.org (and may be others)
16:56:28 <pchampin> ... to avoid doing content negociation.
16:56:53 <pchampin> ... Whenever we can't do conneg nor HTTP headers,
16:56:59 <pchampin> ... we are back to parsing HTML.
16:57:19 <bigbluehat> q+
16:57:24 <bigbluehat> ack dlongley
16:57:48 <pchampin> dlongley: I would be in favor of the link HTTP header solution,
16:57:54 <pchampin> ... even if it does not solve all problems.
16:57:57 <rubensworks> q+
16:58:14 <bigbluehat> ack bigbluehat
16:58:14 <pchampin> ... I am against the reliance on HTML parser. This would break the ecosystem.
16:58:36 <pchampin> ... Also, we should not make decision on the features that github pages have *today*.
16:58:50 <pchampin> ... That may change in the future.
16:59:01 <bigbluehat> ack rubensworks
16:59:10 <pchampin> bigbluehat: (a cosmetic argument that I missed)
16:59:26 <dlongley> q+
16:59:32 <pchampin> rubensworks: I don't see the benefit of the link header over conneg;
16:59:32 <bigbluehat> ack dlongley
16:59:45 <pchampin> ... if a host supports one, it should supports the other, right?
16:59:56 <pchampin> dlongley: some static sites can do link headers.
17:00:07 <pchampin> ... It requires less processing on the server side than conneg.
17:00:11 <pchampin> +1
17:01:09 <ivan> rrsagent, draft minutes
17:01:09 <RRSAgent> I have made the request to generate https://www.w3.org/2019/08/09-json-ld-minutes.html ivan
17:01:09 <ivan> zakim, bye
17:01:09 <ivan> rrsagent, bye
17:01:09 <RRSAgent> I see no action items
17:01:09 <Zakim> leaving.  As of this point the attendees have been ajs6f, bigbluehat, rubensworks, pchampin, gkellogg, timCole, dlongley
17:01:09 <Zakim> Zakim has left #json-ld