16:21:55 <RRSAgent> RRSAgent has joined #json-ld
16:21:55 <RRSAgent> logging to https://www.w3.org/2019/01/04-json-ld-irc
16:21:56 <ivan> rrsagent, set log public
16:21:56 <ivan> Meeting: JSON-LD Working Group Telco
16:21:56 <ivan> Chair: bigbluehat
16:21:56 <ivan> Date: 2019-01-04
16:21:56 <ivan> Regrets+
16:21:56 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html
16:21:57 <ivan> ivan has changed the topic to: Meeting Agenda 2019-01-04: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html
16:46:32 <pchampin> pchampin has joined #json-ld
16:52:49 <ajs6f> ajs6f has joined #json-ld
16:52:55 <ivan> present+
16:53:48 <workergnome> workergnome has joined #json-ld
16:55:10 <bigbluehat> present+
16:55:44 <workergnome> present+
16:56:53 <ivan> I do not hear anybody...
16:57:38 <ajs6f> I can hear you, bigbluehat
16:57:46 <ajs6f> yes, ivan, I can hear you too
16:57:58 <ajs6f> Volume control?
16:58:11 <ajs6f> s/Volume control?//
16:58:24 <ajs6f> present+
17:01:38 <gkellogg> present+ Gregg_Kellogg
17:02:46 <jeff_mixter> jeff_mixter has joined #json-ld
17:02:56 <jeff_mixter> present+
17:03:18 <ivan> regrets+ azaroth
17:03:44 <ivan> present+ pchampin
17:03:59 <ivan> scribenick: ajs6f
17:04:10 <bigbluehat> Topic: Approve minutes of previous call
17:04:15 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-12-14-json-ld
17:04:26 <hsolbrig> hsolbrig has joined #json-ld
17:04:26 <timCole> timCole has joined #json-ld
17:04:33 <ivan> present+ harold_solbrig
17:04:38 <bigbluehat> Topic: Announcements / Reminders
17:04:41 <ajs6f> +1
17:04:47 <jeff_mixter> +1
17:04:47 <hsolbrig> present+ hsolbrig
17:04:50 <workergnome> +1
17:04:55 <hsolbrig> +1
17:05:03 <ivan> resolved: last year's last minutes accepted
17:05:12 <bigbluehat> Topic: Announcements / Reminders
17:05:17 <bigbluehat> Subtopic: 2019 Winter Face-to-Face - February 7-8 in Washington, DC
17:05:53 <bigbluehat> ajs6f: if the govt is open at the time.
17:05:58 <bigbluehat> scribenick: bigbluehat
17:06:09 <bigbluehat> ajs6f: if the govt is open at the time.
17:06:15 <bigbluehat> ...if it's closed, these buildings will not be open
17:06:27 <bigbluehat> ...I'm consequently on furlough at the moment
17:06:39 <bigbluehat> ...and my time will need to go elsewhere depending on how this plays out
17:07:06 <bigbluehat> ...however the F2F is scheduled in a government office
17:07:14 <bigbluehat> ...so if that doesn't change, we won't be able to meet there
17:07:36 <bigbluehat> [general moans, etc]
17:07:47 <bigbluehat> scribenick: ajs6f
17:07:50 <ajs6f> scribenick: ajs6f
17:08:04 <ajs6f> \bigbluehat: will investigate Wiley as an alternative host
17:08:14 <ajs6f> bigbluehat: which wouldimply rebooking flights
17:08:18 <ajs6f> ivan: that's a problem!
17:08:32 <timCole> q+
17:08:32 <ajs6f> bigbluehat: yes, let's try to meeting DC, to avoid changing tickets
17:08:51 <bigbluehat> ack timCole
17:09:03 <workergnome> q+
17:09:05 <ajs6f> timCole: we might want to find a contact at UMaryland
17:09:08 <ajs6f> q+
17:09:09 <bigbluehat> q+
17:09:16 <hsolbrig> +1
17:09:35 <bigbluehat> scribenick: bigbluehat
17:09:40 <hsolbrig> q+
17:09:44 <bigbluehat> ajs6f: I do know some of those folks too, and would be happy to take that on
17:09:48 <bigbluehat> scribenick: ajs6f
17:09:49 <bigbluehat> ack workergnome
17:09:52 <ajs6f> q-
17:09:53 <ivan> ack hsolbrig
17:10:05 <hsolbrig> q-
17:10:09 <ajs6f> workergnome: Could reach out to the Folger Library
17:10:32 <dlehn> present+
17:10:34 <ivan> q+ hsolbrig
17:10:41 <bigbluehat> q-
17:10:43 <bigbluehat> ack hsolbrig
17:10:45 <ajs6f> bigbluehat: also I know some folks at the american geophysical unoin
17:11:04 <ajs6f> hsolbrig: potentially JHU could host if needed, but sounds like we have some options closer
17:11:21 <ajs6f> bigbluehat: let's list our potential sites in the planning Google Doc
17:11:32 <ajs6f> hsolbrig: Shall we set a cut-off date for this?
17:11:40 <ajs6f> bigbluehat: prudent.
17:11:44 <ajs6f> ivan: end of the month/
17:11:56 <ajs6f> bigbluehat: Yes, 31 jan
17:12:12 <ajs6f> bigbluehat: let's use the google Doc with the agenda to plan this as well
17:12:32 <bigbluehat> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit
17:12:45 <bigbluehat> Topic: Pending Pull Requests
17:12:55 <bigbluehat> Subtopic: Improve [framing] intro
17:13:04 <bigbluehat> https://github.com/w3c/json-ld-framing/pull/33
17:13:13 <ajs6f> bigbluehat: there's a PR pending review, has had some feedback
17:13:21 <ajs6f> bigbluehat: dlehn offered some tweaks
17:13:33 <ajs6f> ... if folks could help move that forward, that would be great
17:13:37 <ajs6f> ivan: this seems editorial
17:13:40 <ericP> ericP has left #json-ld
17:13:43 <ajs6f> ... can just leave this to the editor
17:13:56 <bigbluehat> Topic: Issues
17:14:05 <ajs6f> bigbluehat: just announcing this to make sure everyone knows what's about tto be merged
17:14:05 <bigbluehat> Subtopic: HTTP parameters for specifying context or frame
17:14:12 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/8
17:14:28 <bigbluehat>       syntax - https://github.com/w3c/json-ld-syntax/pull/111
17:14:28 <bigbluehat>       framing - https://github.com/w3c/json-ld-framing/pull/34
17:14:28 <bigbluehat>       api - https://github.com/w3c/json-ld-api/pull/56 (work in progress)
17:14:29 <ajs6f> bigbluehat: gkellogg has the lion's share of the work done on this
17:15:12 <ajs6f> gkellogg: the first PR (syntax doc, #111) pretty much ready to go
17:15:24 <ajs6f> ... removed language about quotes for the value of profile params
17:15:33 <ajs6f> ... which is not true in general
17:15:33 <ivan> q+
17:15:51 <ajs6f> ... only if multiple URIs are used, and added some examples with different types of profile params
17:16:18 <bigbluehat> ack ivan
17:16:30 <ajs6f> ivan: I had a comment on that
17:16:40 <ajs6f> ... content, not editorial
17:17:01 <ajs6f> ... a sentence says that JSON-LD processors may restrict URIs for context and frames
17:17:23 <ajs6f> ... which I read as saying, "If I'm a JSON-LD processor, I can refuse any context except this particular one
17:17:29 <ajs6f> ... is that really what we mean
17:17:46 <ajs6f> gkellogg: well, this could become an attack vector, so we allow servers to restrict the action
17:18:11 <ajs6f> gkellogg: framing is potentially expensive comutationally
17:18:20 <ajs6f> ... and people have demonstrated attacks via context
17:18:37 <ajs6f> ... which we think we've mostly fixed, but obviously we can't rule it entirely out
17:18:44 <bigbluehat> q+ to ask about delimiters and quotes (once this more important topic is done)
17:18:51 <ajs6f> ... going back to the CG, there was this desire to restrict present there
17:18:57 <ajs6f> ivan: i have two problems...
17:19:06 <ajs6f> ... this is clearly non-editorial
17:19:17 <ajs6f> .. have we discussed/voted on this restriction?
17:19:31 <ajs6f> ... shouldnt be in an editorial PR.
17:19:41 <ajs6f> ... I don't understand the problem this solves
17:19:59 <ajs6f> gkellogg: this is part of the request header.
17:20:11 <ajs6f> ivan: oh, the request header? (not the response)
17:20:21 <ajs6f> gkellogg: this signals the server as to what the client wants
17:20:36 <ajs6f> ... the server must examine the profile param and if it isn't acceptible, return a 406
17:20:57 <ajs6f> ... this new language just gives license to the server to do just that if the context is unacceptable
17:21:05 <ajs6f> ... you could also fall-back in various ways
17:21:22 <ajs6f> ivan: Okay, I misunderstood what was done, so that's okay
17:21:30 <ajs6f> ... but still, this is more than editorial
17:21:42 <ajs6f> gkellogg: I don't say that this _is_ editorial
17:21:55 <ajs6f> ... i folded in the previous discussions on this
17:22:19 <ajs6f> ivan: sorry to interrupt, fine with this. I will put in a link to this discussion into the PR
17:22:27 <ajs6f> ... must be documented, now it is
17:22:38 <bigbluehat> ack bigbluehat
17:22:38 <Zakim> bigbluehat, you wanted to ask about delimiters and quotes (once this more important topic is done)
17:22:38 <ajs6f> ... we just want to document that everyone is fine with this
17:22:49 <ajs6f> bigbluehat: I've got a nit
17:23:03 <ajs6f> ... about the quotes being optional save for multiple URIs
17:23:14 <ajs6f> gkellogg: for spaces
17:23:25 <ajs6f> ... and I show examples of this
17:23:46 <ajs6f> ... we don't madate that single spaces must be used
17:23:54 <ajs6f> ... it's just whitespace as defined by the rFC
17:24:00 <ajs6f> bigbluehat: okay, thanks
17:24:00 <bigbluehat> https://tools.ietf.org/html/rfc6906
17:24:37 <ajs6f> gkellog: we have also the PR for the API doc
17:24:49 <gkellogg> https://github.com/w3c/json-ld-api/pull/56
17:24:57 <ajs6f> ... there is w-i-p on the API at that PR
17:25:04 <ajs6f> ... framing was a more minor change
17:25:08 <gkellogg> https://github.com/w3c/json-ld-framing/pull/34
17:25:47 <ajs6f> ... the controversial point bigbluehat raised is whether adding a framing URI changes the semantics enough to make it inappropriate
17:25:52 <ajs6f> ... as a profile param
17:25:59 <ajs6f> ... online discussion indicates not
17:26:19 <ajs6f> ... the change requires the profile param
17:26:32 <ajs6f> ... which changes current behavior for people requesting frames
17:26:45 <ajs6f> ... there might b more changes requireed for this for optinality
17:27:35 <ajs6f> gkelllogg: the idea was that a frame would be represented by a mimetype
17:27:40 <ajs6f> ... but no one implemented that
17:27:54 <ajs6f> ... and now we've moved to using a profile param for frame
17:28:15 <ajs6f> ... so the question is, must the profile param appear, or is it optional/advisory
17:28:29 <ajs6f> ... this param is for getting a doc that _is_ a frame
17:28:35 <ajs6f> and would appear on the response as well
17:28:46 <ajs6f> bigbluehat: yes, we would want that on the response as well
17:28:56 <ajs6f> gkellogg: we need more discussion on that PR
17:29:08 <ajs6f> https://github.com/w3c/json-ld-framing/pull/34
17:29:32 <ajs6f> gkelllogg: the API PR (https://github.com/w3c/json-ld-api/pull/56) is just tests for this new behavior
17:29:45 <ajs6f> ... I couldn't see what language to add to the API, otherwise
17:30:08 <ajs6f> ... the Api do is concerned with what happens once you've requested a doc and are processing the result
17:30:40 <ajs6f> ... we don't need to specify how to use an Accept header
17:30:58 <ajs6f> bigbluehat: this would only be for requesting a single doc in various representation
17:31:11 <ajs6f> ... I'm glad that framed docs aren't new mediatypes
17:31:36 <ajs6f> ... but it seems unlikely that one document would be all the things at once (frame, context, instance)
17:31:47 <ajs6f> gkellogg: but you aren't requesting a doc, you are requesting a resource.
17:31:59 <workergnome> +q
17:32:01 <ajs6f> ... e.g. for SPARQL users
17:32:34 <workergnome> \me no worries!
17:32:45 <ajs6f> gkellogg: profile contains one or more of our URIs, as well as URLs to contexts, frames, etc.
17:33:08 <bigbluehat> ack workergnome
17:33:21 <bigbluehat> s/\me no worries!//
17:33:45 <ajs6f> workergnome: a real-world example: we have resources we'd like to be able to provide either as schema.org or CIDOC-CRM
17:33:55 <ajs6f> ... same data, difference context/framing
17:34:46 <ajs6f> gkellogg: only the non-registered URLS would be treated as dereferencable
17:35:26 <ajs6f> ... similar to when the mimetype is just application/json and you stick the contet in a header
17:36:32 <ajs6f> bigbluehat: this is where I get concerned about violating the RFC-- the profile param shouldn't be dereferenced
17:36:37 <ajs6f> gkellogg: good point...
17:36:52 <ajs6f> ... my impression was that we could define this behavior, but we do need to review
17:37:43 <ajs6f> bigbluehat: in the Web Annotation we avoided triggering new representations via the profile param, only selecting from extant representations
17:37:43 <ivan> q+
17:37:53 <bigbluehat> ack ivan
17:37:56 <ivan> https://tools.ietf.org/html/rfc6906
17:37:59 <ajs6f> ... this is a supernice feature, but is this where it belongs?
17:38:11 <ajs6f> ivan: what it does say is:
17:38:19 <ivan> "A profile MUST NOT change the semantics of the
17:38:19 <ivan>    resource representation when processed without profile knowledge, so
17:38:19 <ivan>    that clients both with and without knowledge of a profiled resource
17:38:19 <ivan>    can safely use the same representation."
17:38:30 <bigbluehat> https://tools.ietf.org/html/rfc4288#section-4.3
17:38:58 <ajs6f> ivan: so this may indeed be a problem
17:39:20 <ajs6f> gkellogg: the use of a context _does not_ change the semantics of a representation, just the syntax
17:39:27 <ajs6f> bigbluehat: it's the functionality concern
17:39:46 <ajs6f> ... if these are URLs (not merely URIs) they will be looked up and used for computation
17:39:56 <ivan> "Profiles are identified by URI.  However, as is the case with, for
17:39:56 <ivan>    example, XML namespace URIs, the URI in this case only serves as an
17:39:56 <ivan>    identifier,"
17:40:15 <ajs6f> ivan: it is an identifier
17:40:53 <ivan> https://tools.ietf.org/html/rfc6906#section-3
17:41:09 <ajs6f> ivan: at the beginning of that section
17:41:24 <ajs6f> q+
17:41:28 <bigbluehat> ack ajs6f
17:42:32 <gkellogg> q+
17:42:46 <bigbluehat> q+
17:43:02 <bigbluehat> ack gkellogg
17:43:20 <ajs6f> gkellogg: rfc4288#section-4.3 is a different case of profile
17:43:28 <ajs6f> .. that's the header vs the mimetype
17:43:46 <ajs6f> ... e.g. dc:name vs schema:name
17:43:54 <ajs6f> ... totally different graphs
17:44:03 <ajs6f> ... but for framing, it's the same graph
17:44:21 <ajs6f> ... and client can reframe or recompact or whatever
17:44:45 <ajs6f> ... for bigbluehat's case, where there's a range of possible contexts...
17:44:53 <ivan> (for the minutes, the quote above was also from rfc 9606 section 3)
17:44:58 <ajs6f> ... two ways to interpret that: first, I want the Schema context vs the DC context
17:45:08 <pchampin> q+
17:45:12 <bigbluehat> ack bigbluehat
17:45:17 <ajs6f> .... or, I want "name" vs "schema:name" where the terms used are diffferent
17:45:38 <ajs6f> bigbluehat: in the case of conneg, you could list _several_ contexts
17:45:55 <ajs6f> ... and the sever will compute on your request and select something
17:46:09 <ajs6f> ... that's not a processing instruction
17:46:15 <ivan> q+
17:46:20 <bigbluehat> ack pchampin
17:46:33 <ajs6f> ... that's a great idea, but it should go in a different box
17:46:49 <ajs6f> pchampin: not fully agree with gkellogg about changing strings in the JSON for different contexts
17:46:57 <ajs6f> ... in both cases, the semantics are the same
17:47:19 <ajs6f> ... the condition for selecting different vocabularies is that the semantics of the vocabularies is the same
17:47:20 <workergnome> q+
17:47:20 <gkellogg> q+
17:47:30 <ivan> q- later
17:47:41 <ajs6f> ... in both cases, the changes are at the syntax level, just at concrete or abstract syntax
17:47:59 <ajs6f> gkellogg: if we look at the test suite, what might be considered?
17:48:14 <ajs6f> ... one, you can take the result, expand it, and compare
17:48:32 <ajs6f> ... or two, turn them into RDF and compare the graphs for isomorphism
17:48:34 <ivan> +1 to gregg
17:48:45 <ajs6f> ... (or in framing, a strict subgraph relationship)
17:48:48 <bigbluehat> ack workergnome
17:49:20 <bigbluehat> ack gkellogg
17:49:25 <bigbluehat> ack ivan
17:49:32 <ajs6f> workergnome: I'm assuming that I have all the data and am just selecting from it, not doing new processing
17:49:45 <ajs6f> ivan: whither shall we wander?
17:49:56 <ajs6f> ... what do we do if profiles are not the correct choice?
17:50:01 <ajs6f> ... our own request header?
17:50:11 <ajs6f> ... is there an extant header we can adopt?
17:50:37 <ajs6f> bigbluehat: Profile seems like the wrong vehicle for this signalling, but we cannot discard the use case
17:50:42 <ajs6f> q+
17:50:46 <gkellogg> q+
17:52:07 <bigbluehat> PROPOSAL: limit `profile` parameter use to URI's, but continue to pursue an alternative to the `profile` media type parameter for client-signaled frames and contexts URLs for servers to (potentially) use when providing responses
17:52:14 <bigbluehat> ack ajs6f
17:52:17 <bigbluehat> ack gkellogg
17:52:19 <gkellogg> https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld
17:52:28 <ajs6f> gkellogg: we might borrow from the way we handle application/json
17:52:42 <ajs6f> ... in a response header, we add a link header targeting the context
17:53:16 <ajs6f> ... we could use a Link header on the request
17:53:18 <bigbluehat> q+
17:53:27 <bigbluehat> ack bigbluehat
17:53:31 <ajs6f> ivan: we would need a more detailed description
17:53:32 <bigbluehat> https://tools.ietf.org/html/rfc8288
17:53:45 <ajs6f> bigbluehat: you sure can use a Link header on the request
17:53:51 <ajs6f> ... but let's get to a proposal
17:54:07 <ajs6f> ... we need to get URLs out of the profiles
17:54:19 <ajs6f> ... and there is clear desire in the group for this functionality
17:54:29 <bigbluehat> PROPOSAL: limit `profile` parameter use to URI's, but continue to pursue an alternative to the `profile` media type parameter for client-signaled frames and contexts URLs for servers to (potentially) use when providing responses
17:54:30 <ajs6f> ... link rel= might be a nice way to do that
17:54:37 <gkellogg> +1
17:54:46 <bigbluehat> +1
17:54:48 <ajs6f> +1
17:54:53 <jeff_mixter> +1
17:54:54 <hsolbrig> +1
17:54:55 <timCole> +1
17:54:57 <ajs6f> ivan: do we suspecd all three PRs?
17:55:10 <ajs6f> gkellogg: not necessarily framing, but that needs its own discssion
17:55:13 <workergnome> +1
17:55:14 <pchampin> +1
17:55:16 <ivan> +1
17:55:57 <ajs6f> gkellogg: if there is no actual language in the API doc, the tests that have been addded there might belong in the syntx doc
17:56:01 <ivan> RESOLVED:  limit `profile` parameter use to URI's, but continue to pursue an alternative to the `profile` media type parameter for client-signaled frames and contexts URLs for servers to (potentially) use when providing responses
17:56:13 <bigbluehat> Subtopic: Content addressable contexts & hashlink
17:56:20 <bigbluehat> https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0000.html
17:56:20 <ajs6f> bigbluehat: let's leave it to gkellogg as to how he'd like to manage the PRs, whether to add more commits or start afresh or whatever
17:56:21 <ivan> q+
17:56:26 <gkellogg> q+
17:56:41 <bigbluehat> ack ivan
17:56:56 <ajs6f> ivan: it is interesting, no doubt
17:57:02 <ajs6f> ... (puts admin hat on)
17:57:09 <ajs6f> ... these are very early drafts
17:57:16 <bigbluehat> q+
17:57:27 <ajs6f> ... Manu made this proposal in December, very early days
17:57:32 <ajs6f> ... we're fine, though.
17:57:51 <ajs6f> ... if the technique becomes a standard form for URIs, we can use it as such
17:58:01 <ajs6f> ... I'm happy to have us say that we are interesting
17:58:09 <ajs6f> s/interesting/interested
17:58:24 <bigbluehat> ack gkellogg
17:58:32 <ajs6f> ... we should try to see whether this tech really can be used to annotate links whhile we also pursue other avenues
17:58:40 <ajs6f> gkellogg: really like the idea, could be very useful
17:58:42 <ajs6f> q+
17:58:57 <ajs6f> gkellogg: but not clear that it really affects our docs at all
17:59:12 <ajs6f> ... what would we change?
17:59:23 <ajs6f> ivan: we shouln't close issues just because this new thing is a new thing
17:59:40 <bigbluehat> ack bigbluehat
17:59:49 <ajs6f> gkellogg: unless we think that we can do that via a reference in the best practice dics
17:59:57 <bigbluehat> ack ajs6f
18:00:19 <bigbluehat> scribenick: bigbluehat
18:00:39 <gkellogg> s/dics/docs/
18:00:42 <bigbluehat> ajs6f: if hashlink solves for problems we have, then we may not want to recreate alternative features that solve the same issues
18:00:47 <bigbluehat> scribenick ajs6f
18:00:57 <ajs6f> bigbluehat: although this new hash URI tech isn't standardized, it _has_ been put into use
18:01:09 <ivan> rrsagent, draft minutes
18:01:09 <RRSAgent> I have made the request to generate https://www.w3.org/2019/01/04-json-ld-minutes.html ivan