15:39:20 <RRSAgent> RRSAgent has joined #json-ld
15:39:20 <RRSAgent> logging to https://www.w3.org/2019/06/07-json-ld-irc
15:39:21 <ivan_> rrsagent, set log public
15:39:21 <ivan_> Meeting: JSON-LD Working Group Telco
15:39:21 <ivan_> Chair: azaroth
15:39:21 <ivan_> Date: 2019-06-07
15:39:21 <ivan_> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0002.html
15:39:21 <ivan_> ivan_ has changed the topic to: Meeting Agenda 2019-06-07: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0002.html
15:41:06 <azaroth> present+
15:41:36 <rubensworks> rubensworks has joined #json-ld
15:42:33 <ivan_> ivan_ has joined #json-ld
15:43:34 <ivan_> ivan_ has joined #json-ld
15:44:10 <ivan_> rrsagent, who is here?
15:44:10 <RRSAgent> I'm logging.  Sorry, nothing found for 'who is here'
15:44:19 <azaroth> present+
15:50:55 <azaroth> regrets+ gkellogg
15:50:59 <azaroth> regrets+ dlongley
15:53:29 <pchampin> pchampin has joined #json-ld
15:56:51 <bigbluehat> present+
15:57:45 <pchampin> present+
15:58:00 <ivan_> present+
15:58:10 <ivan_> present+ rubensworks
16:00:03 <timCole> timCole has joined #json-ld
16:00:12 <workergnome> workergnome has joined #json-ld
16:01:31 <azaroth> scribe: timCole
16:01:36 <ivan> present+ timCole
16:01:42 <pchampin> present+
16:01:49 <azaroth> TOPIC: Approve minutes of previous call
16:02:02 <azaroth> PROPOSAL: Approve minutes of the previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-31-json-ld
16:02:03 <bigbluehat> +1
16:02:04 <rubensworks> +1
16:02:05 <azaroth> +1
16:02:06 <ivan> +1
16:02:15 <pchampin> +1
16:02:16 <workergnome> +1
16:02:23 <azaroth> RESOLVED: Approve minutes of the previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-31-json-ld
16:02:31 <azaroth> TOPIC: Announcements / Reminders
16:02:39 <azaroth> SUBTOPIC: TPAC
16:02:52 <workergnome> present+
16:03:10 <timCole> azaroth: TPAC registration is open. Please remember to register before 21 June close to early registration
16:03:24 <timCole> ... this is earlier than usual because TPAC is in Sept
16:03:57 <timCole> ... any other announcements?
16:04:10 <azaroth> SUBTOPIC: Horizontal Review
16:04:22 <ajs6f> ajs6f has joined #json-ld
16:04:26 <ajs6f> present+
16:04:32 <timCole> ivan: we really need to get the horizontal reviews done in a timely fashion
16:04:50 <timCole> ... don't expect issues but reviewers will appreciate if we get to these early
16:05:34 <timCole> ... we need somebody for security and privacy
16:05:59 <timCole> ... privacy wants our person to attend IG call and gives an overview
16:06:32 <timCole> ... we would like people for horizontal reviews to volunteer asap
16:06:52 <bigbluehat> regrets+ simonstey
16:07:00 <timCole> azaroth: happy to volunteer (depending on time) but would be good to have Greg and others help
16:07:23 <azaroth> q?
16:07:27 <timCole> pchampin: also happy to help but less comfortable about API
16:08:03 <timCole> ivan: Rob should send email to privacy group asking time when they can fit us on their agenda
16:08:30 <timCole> ... probably Rob and pchampin for sure, Ivan and Greg as available
16:08:43 <timCole> ... same thing for security - they'll come to us
16:08:56 <timCole> ... for accessibility we start with their questionaire
16:09:08 <ivan> https://w3c.github.io/apa/fast/checklist.html
16:09:37 <timCole> ... once this is done then we contact them as next step
16:10:14 <timCole> azaroth: one person will need to take lead on filling out questionaire - others could be on irc to help
16:11:04 <timCole> ... so, we should ask Greg about availability when he gets back
16:11:09 <ivan> q+
16:11:24 <azaroth> ack ivan
16:11:27 <timCole> ... Rob and Pierre-Antoine will do best to make themselves available
16:11:36 <timCole> ... other volunteers would be appreciated.
16:11:55 <azaroth> SUBTOPIC: I18N
16:11:58 <timCole> ivan: we will need one more to work with internationalization
16:12:35 <timCole> ... the big issue we may have is ability to add base string direction
16:12:59 <timCole> ... (Rob should still contact soon to deal with any other issues)
16:13:18 <azaroth> reference: https://github.com/w3c/json-ld-syntax/issues/11
16:13:30 <timCole> ... with regard to string direction this is coming up with a lot of WGs and we have talked about it in this WG
16:14:02 <timCole> ... we should discuss next week when Greg is back and we've had a little more time to catch up on topic
16:14:24 <ivan> -> https://w3c.github.io/rdf-dir-literal/ discussion on direction issue
16:14:27 <timCole> azaroth: any other issues or announcements
16:15:08 <azaroth> TOPIC: Issues
16:15:39 <timCole> azaroth: tried to pick issues for this week less related to API and more related to syntax and policy
16:15:43 <azaroth> SUBTOPIC: Profile IRIs
16:15:53 <ivan> https://github.com/w3c/json-ld-syntax/issues/170
16:16:03 <ivan> q+
16:16:16 <azaroth> ack ivan
16:16:32 <timCole> ivan: one background - transition calls with WOT people
16:16:45 <timCole> ... they were interested in a profile for their own needs
16:16:51 <dlehn> present+
16:17:04 <timCole> ... but what came up is what is policy with regard to what is said in W3C documents
16:17:47 <timCole> ... by default each WG has its own profile space (e.g., ns/jsonld...)
16:17:57 <timCole> ... and that's it
16:18:18 <timCole> azaroth: there are profile URIs (e.g., Web Annotation)
16:18:35 <timCole> ... if you don't understand it, you must ignore it
16:18:36 <azaroth> q?
16:19:34 <azaroth> PROPOSAL: Accept #170, with the clarification that processors MUST ignore IRIs that that they do not recognize, and that json-ld* IRIs are reserved for future WG use
16:19:45 <azaroth> +1
16:19:46 <ajs6f> +1
16:19:46 <timCole> +1
16:19:49 <rubensworks> +1
16:19:53 <ivan> +1
16:20:02 <bigbluehat> +1
16:20:08 <pchampin> +1
16:20:19 <dlehn> +1
16:20:21 <workergnome> +1
16:20:27 <azaroth> RESOLVED: Accept #170, with the clarification that processors MUST ignore IRIs that that they do not recognize, and that json-ld* IRIs are reserved for future WG use
16:21:21 <timCole> azaroth: Action to implement this resolution is on pchampin or greg
16:21:27 <azaroth> ACTION: pchampin to update syntax with issue #170 resolution
16:21:43 <azaroth> SUBTOPIC: Compact IRIs and URI Schemes
16:22:01 <ivan> https://github.com/w3c/json-ld-syntax/issues/177
16:22:22 <timCole> azaroth: we discussed this a few weeks ago, but only to point of introducing the issue.
16:22:29 <timCole> ... hopefully people have thought about it
16:22:57 <timCole> ... the issue is that IRI schemes that don't start with // are seen as compact IRIs
16:23:20 <timCole> ... e.g., icon:... is seen as a compact IRI not a full IRI
16:23:43 <timCole> ... we could define these as undefined (rather than a prefix)
16:24:07 <ivan> q+
16:24:18 <azaroth> ack ivan
16:24:20 <timCole> ... this approach adds a little security without banning all non // schemes
16:24:32 <bigbluehat> q+
16:24:54 <timCole> ivan: I don't fully understand - so in your example in the issue, what's the role of protected
16:25:13 <azaroth> ack bigbluehat
16:25:21 <timCole> azaroth: avoids someone stealing the meaning of prefix (e.g., mailto:)
16:25:51 <timCole> bigbluehat: the goal is to allow continued use of these kinds of IRI prefixes
16:26:17 <pchampin> q+
16:26:23 <ivan> q+
16:26:33 <timCole> azaroth: having it in the context seems a good solution since it allows you to specify only the scope where you use the scheme
16:26:38 <timCole> rather than everywhere
16:26:44 <azaroth> ack pchampin
16:26:50 <timCole> bigbluehat: yes, it is good to scope this
16:27:13 <timCole> pchampin: it seems to me the protected approach would not be very efficient
16:27:57 <timCole> ... I'm not sure I fully grasp the use cases, but it seems you still get around protected
16:28:35 <timCole> ... the only way to really protect against redirection of mailto: is to protect the individual properties (e.g., email)
16:28:55 <timCole> azaroth: so you say that email values not to be expected
16:29:17 <azaroth> q?
16:29:18 <azaroth> ack ivan
16:29:19 <timCole> pchampin: not sure this requires anything additional since we already have prefix
16:29:28 <timCole> ... seems a matter of best practice
16:29:57 <timCole> ivan: in the example you have two approaches nul and prefix=false
16:30:29 <timCole> azaroth: probably prefix=false, this works well since we already have prefix
16:30:34 <timCole> ivan: do we?
16:30:42 <timCole> azaroth: issue 76
16:30:48 <azaroth> ref;: https://github.com/w3c/json-ld-api/issues/76
16:31:10 <pchampin> a more efficient protection would be { "email": { "@id": "http://example.org/emailAddress", "@type": "@id", "@protected": true, "@context": { "mailto": { "@prefix": false } } }
16:31:24 <azaroth> q?
16:31:34 <timCole> ... proposal was made to add prefix with 3 allowed values (one of which would be false, as required by issue 177)
16:32:27 <timCole> ... the issue in doing this was that you need to have an @id, which is why we might still need @id nul
16:32:48 <timCole> ... seems like we shouldn't need that if prefix: false
16:32:56 <azaroth> q?
16:33:00 <rubensworks> q+
16:33:03 <azaroth> ack rubensworks
16:33:13 <timCole> ... Pierre-Antoine, does prefix: false already sufficient?
16:33:19 <timCole> pchampin: not sure
16:33:37 <timCole> rubensworks: doesn't seem to work right now
16:33:58 <timCole> azaroth: but maybe it protects against intentional mischief
16:34:24 <timCole> ... anyone willing to take action to verify that prefix: false does work or can be made to work?
16:34:59 <timCole> pchampin: okay, put this action on me
16:35:28 <azaroth> ACTION: pchampin to test if `@prefix: false` without `@id` works as expected
16:35:42 <dlehn> q+
16:36:03 <timCole> dlehn: find it a little hard to understand the attack line here
16:36:31 <timCole> ... if we assume all contexts are a risk, seems a bigger problem
16:36:58 <timCole> ... protect should be more about extension and override
16:37:34 <timCole> azaroth: we have run into this issue with regard to content being incorrectly expanded
16:37:37 <bigbluehat> q+
16:37:43 <azaroth> ack dlehn
16:37:45 <azaroth> ack bigbluehat
16:38:15 <timCole> bigbluehat: not directly on point, but it feels like a lot of our issues have had to do with managing context intermingling
16:38:34 <timCole> ... we may need to zoom out a little
16:39:09 <timCole> ... while there are issues here it seems like its about trust of contexts, ownership of contexts, etc.
16:39:38 <timCole> ... this fragility that is still there is where we may have issues with security and privacy reviews
16:40:06 <timCole> ... I sometimes feel like we're applying pressure to the wrong part of the ecosystem
16:40:26 <timCole> ... it's not clear the role and motivation of the actors
16:40:51 <timCole> ... so maybe we need a broader view
16:41:09 <timCole> ... would not be an issue if you always trusted the context file you reference
16:41:38 <timCole> azaroth: not certain about that. If you define mailto: you need to undefine it elsewhere in your instance
16:42:01 <timCole> bigbluehat: so this is partly about remixing within instance / context
16:42:46 <timCole> azaroth: I think at least we need to determing how prefix: false works without @id or @id: nul
16:43:29 <ivan> q+
16:43:31 <timCole> ... need to be able to treat these as resource IRI when you want to
16:43:33 <azaroth> ack ivan
16:43:54 <timCole> ivan: I share bigbluehat's concerns in a general way
16:44:19 <timCole> ... for this issue you are asking if prefix: false solves current issue
16:44:54 <timCole> ... since prefix is a 1.1 key, we need it to work as we want and so if it's not working that way now, let's make it work
16:44:59 <azaroth> q?
16:45:05 <pchampin> the questions becoming: is it possible (i.e. not over-complicated) to implemet `@prefix` to work like this
16:45:25 <timCole> azaroth: the action should allow us to do this
16:45:51 <pchampin> q+
16:47:07 <timCole> pchampin: i just realized during discussion we have already introduced redefining a term that looks like an IRI because no useful use case for doing this
16:47:44 <timCole> ... in a way this desire to limit prefixes that are sometimes used as schemes
16:48:05 <timCole> ... not clear how critical the use cases are
16:48:17 <ivan> q+
16:48:21 <ivan> ack pchampin
16:48:32 <timCole> ... may confuse users to say some IRIs cannot be anything else, but some could be compact IRIs in disguise
16:49:15 <timCole> ivan: does this mean we should have a list of prefixes that are schemes?
16:49:28 <timCole> pchampin: no, trying hard not to say that
16:49:39 <timCole> ... current rule is scheme://
16:49:54 <timCole> ... and this is clear cut, non-ambiguous
16:50:27 <timCole> ... it might be confusing to do this for non // schemes
16:50:51 <timCole> azaroth: so our approach is to leave this to context authors rather than trying to maintain a universal list
16:51:07 <timCole> ... this will almost certainly come up in security horizontal review
16:51:20 <timCole> ... it would be nice to solve or improve it
16:51:39 <timCole> ... if prefix: false works, we're done
16:51:45 <azaroth> PROPOSAL: If `@prefix: false` works, then we can turn 177 into a best practice.  If not, then 177 becomes an issue to improve `@prefix` to allow it.
16:51:51 <azaroth> +1
16:51:52 <ivan> +1
16:51:52 <rubensworks> +1
16:51:53 <pchampin> +1
16:51:54 <timCole> ... otherwise we have to improve prefix: false so it does work
16:51:57 <timCole> +1
16:52:00 <ajs6f> +1
16:52:05 <dlehn> +1
16:52:14 <bigbluehat> +1
16:52:16 <workergnome> +1
16:52:18 <azaroth> RESOLVED: If `@prefix: false` works, then we can turn 177 into a best practice.  If not, then 177 becomes an issue to improve `@prefix` to allow it.
16:52:53 <azaroth> SUBTOPIC: IRI expansion
16:53:07 <azaroth> ref: https://github.com/w3c/json-ld-syntax/issues/191
16:53:45 <timCole> azaroth: essentially, what I took away from this issues, is that what is wanted is a way to set defaults per prefixe
16:54:00 <timCole> ... e.g., everything with x prefix, everything is a list
16:55:05 <timCole> ... since we declare intent to close to new features (after last published draft)
16:55:19 <bigbluehat> q+
16:55:23 <timCole> ... so, can we defer this?
16:55:24 <ivan> q-
16:55:25 <azaroth> ack bigbluehat
16:55:30 <timCole> ... or is it a bug we have to address
16:55:51 <timCole> bigbluehat: the use of this seems to want ad hoc terms mixed in with the prefix declaration
16:56:04 <timCole> ... the first example seems that way
16:56:32 <ajs6f> q+
16:56:35 <timCole> ... seems he could get same result with slightly more verbose (less confusing) instance
16:56:36 <azaroth> ack ajs6f
16:56:56 <timCole> ajs6f: this reminds me of java server ads
16:57:07 <timCole> s/ads/tags
16:57:26 <timCole> ... not clear that this is something json-ld was supposed to do.
16:57:47 <timCole> ... this seems to be about complex structures, almost transformative
16:57:59 <ivan> q+
16:58:03 <azaroth> ack ivan
16:58:06 <timCole> ... this is not the focus of json-ld. important to do, but not really our intent here
16:58:34 <timCole> ivan: so what I understood from the issue is that this is not a bug, but really is a new feature
16:58:45 <ajs6f> q+
16:58:49 <azaroth> ack ajs6f
16:59:02 <timCole> ... so the answer should simply be that we defere because of the feature freeze and avoid discussing the details
16:59:05 <azaroth> q?
16:59:13 <timCole> ajs6f: should we send to CG
16:59:29 <timCole> ivan: since we are not closing issue, we don't need to send to CG
16:59:29 <azaroth> q?
16:59:38 <timCole> ... the person submitting may want to do so.
17:00:19 <azaroth> PROPOSAL: Defer syntax#191 and api#94 as new features after feature freeze
17:00:21 <workergnome> +1
17:00:25 <timCole> azaroth: will do same for issue in api
17:00:27 <rubensworks> +1
17:00:28 <bigbluehat> +1
17:00:30 <azaroth> +1
17:00:31 <timCole> +1
17:00:34 <ivan> +1
17:00:37 <ajs6f> +1
17:00:50 <pchampin> +1
17:01:03 <azaroth> RESOLVED: Defer syntax#191 and api#94 as new features after feature freeze
17:01:13 <azaroth> ACTION: azaroth to post blog reference for feature freeze
17:01:14 <timCole> ivan: please add to issue link to blog where we declared feature freeze
17:01:41 <timCole> azaroth: can we add mention of feature freeze in repos readme
17:02:24 <azaroth> ACTION: bigbluehat to add feature freeze note to the syntax, api, and framing READMEs and issue template for bugs only
17:02:51 <timCole> adjourn - next call in a week (azaroth regrets)
17:02:52 <azaroth> TOPIC: Adjourn
17:03:31 <ivan> rrsagent, draft minutes
17:03:31 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/07-json-ld-minutes.html ivan