15:25:30 <RRSAgent> RRSAgent has joined #json-ld
15:25:30 <RRSAgent> logging to https://www.w3.org/2018/09/14-json-ld-irc
15:25:36 <azaroth> zakim, this is json-ld
15:25:37 <Zakim> got it, azaroth
15:25:44 <azaroth> chair: azaroth
15:25:50 <azaroth> regrets+ ivan
15:25:57 <azaroth> present+ Rob_Sanderson
15:26:39 <azaroth> azaroth has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Sep/0013.html
15:26:54 <azaroth> rrsagent make minutes public
15:32:54 <azaroth> rrsagent, set log public
15:33:03 <azaroth> Meeting: JSON-LD Working Group Telco
15:33:13 <azaroth> Date: 2018-09-14
15:33:26 <azaroth> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Sep/0013.html
15:43:59 <bigbluehat> present+ Benjamin_Young
15:51:16 <workergnome> workergnome has joined #json-ld
15:52:07 <ajs6f> ajs6f has joined #json-ld
15:53:41 <workergnome> present+
15:56:06 <gkellogg> present+ Gregg_Kellogg
16:00:40 <timCole> timCole has joined #json-ld
16:00:42 <jeff_mixter> jeff_mixter has joined #json-ld
16:00:46 <jeff_mixter> present+
16:02:40 <simonstey> simonstey has joined #json-ld
16:03:26 <timCole> present+ Tim_Cole
16:03:33 <azaroth> TOPIC: Scribe Selection
16:04:09 <azaroth> scribenick: timCole
16:04:27 <azaroth> TOPIC: Approve minutes
16:04:28 <simonstey> present+
16:04:30 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-07-json-ld
16:04:41 <azaroth> PROPOSAL: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-07-json-ld
16:04:44 <azaroth> +1
16:04:45 <jeff_mixter> +1
16:04:47 <timCole> bigbluehat: Any objections to minutes from last call?
16:04:48 <gkellogg> +1
16:04:53 <timCole> +1
16:04:59 <workergnome> =1
16:05:01 <workergnome> +1
16:05:02 <azaroth> RESOLVED: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-07-json-ld
16:05:06 <simonstey> +1
16:05:15 <azaroth> TOPIC: Announcements / Reminders
16:05:30 <timCole> bigbluehat: now at fpwd stage!
16:05:42 <timCole> ... we now have 3 URLs
16:05:56 <timCole> ... also had a blog post go up
16:05:56 <ajs6f> present+
16:06:03 <bigbluehat> https://www.w3.org/blog/news/archives/7270
16:06:18 <timCole> ... 1.1 specs are available for people to review and provide feedback
16:06:42 <timCole> ... by doing this, we are seeing some people taking a fresh look at json-ld and that is beneficial
16:06:44 <dlehn> present+ David_Lehn
16:06:46 <bigbluehat> q?
16:07:00 <azaroth> e.g. https://github.com/w3c/json-ld-framing/issues/13 and https://github.com/w3c/json-ld-framing/issues/14
16:07:08 <timCole> gkellogg: next thing to discuss is policy and mechanism for regular working drafts
16:07:17 <timCole> bigbluehat: so, what cadence
16:07:42 <timCole> gkellogg: yes, and we should have a relatively low bar when we update
16:08:01 <timCole> ... does anyone have experience keeping link checker happy?
16:08:23 <timCole> bigbluehat: do we want an issue about these matters?
16:08:32 <timCole> gkellogg: will do.
16:08:35 <bigbluehat> q?
16:08:41 <gkellogg> ACTION: gkellogg to add issues related to continuous publication of working drafts
16:08:52 <timCole> TOPIC: TPAC
16:09:09 <timCole> bigbluehat: getting close. Scheduled for Thurs and Fri of TPAC
16:09:21 <timCole> ... may also have an informal WG dinner earlier in week
16:09:33 <timCole> ... we have also put a doc up for discussing our agenda.
16:09:36 <bigbluehat> https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#
16:09:47 <azaroth> q+
16:10:03 <bigbluehat> ack azaroth
16:10:10 <timCole> ... includes rsvp for TPAC WG meeting and for those wanting to call in
16:10:12 <azaroth> https://github.com/orgs/w3c/projects/4
16:10:24 <timCole> azaroth: in the project we have a column for discuss face-to-face
16:10:49 <timCole> ... so people should add / move to make sure this column has all the items we want to cover in f2f
16:11:08 <timCole> ... as time allows we will then work our way through other issues
16:11:12 <simonstey> q+
16:11:36 <bigbluehat> ack simonstey
16:11:50 <timCole> simonstey: will there be remote access?
16:12:14 <timCole> bigbluehat: we are planning on it - you can rsvp for that in planning doc
16:12:16 <jeff_mixter> +1 to remote access
16:12:37 <bigbluehat> q?
16:12:38 <azaroth> q+
16:12:41 <bigbluehat> ack azaroth
16:13:12 <timCole> azaroth: minor note - in the doc there is a list to TPAC reg list, includes people requesting observer status
16:13:45 <timCole> ... as of last week azaroth told observers who had registered were welcome
16:13:53 <timCole> ... looks like a good group of observers
16:14:12 <timCole> bigbluehat: encourage others as appropriate
16:14:24 <timCole> ... any other announcements or agenda items for today?
16:14:32 <timCole> ... hearing none, we will proceed
16:14:39 <azaroth> TOPIC: Issues
16:14:57 <bigbluehat> SUBTOPIC: IRI vs URL - https://github.com/w3c/json-ld-syntax/issues/25
16:15:08 <timCole> azaroth: discussions a little quiet this week, but IRI vs. URL has gotten some discussion
16:15:28 <timCole> ... issue - should we adopt URL or should we stick with IRI
16:16:33 <gkellogg> q+
16:16:48 <timCole> ... for example, HTML has a note about why that spec uses URL, but Web annotation has a note from member from Sony about differences between URL and IRI
16:16:51 <azaroth> q?
16:16:54 <azaroth> ack gkellogg
16:17:06 <timCole> ... on the table is idea to defer until it becomes more clear
16:17:25 <azaroth> q+ to note the editors of microdata
16:17:46 <timCole> gkellogg: microdata spec uses URL and includes some RDF, possibly providing a model for using URL in context of RDF
16:17:53 <bigbluehat> current Working Draft of the Microdata spec https://www.w3.org/TR/microdata/
16:18:09 <timCole> ... issues lurking about impact on SPARQL, etc.
16:18:15 <azaroth> q?
16:18:18 <bigbluehat> ack azaroth
16:18:18 <Zakim> azaroth, you wanted to note the editors of microdata
16:18:25 <timCole> ... probably this means we need a wider scope than just json-ld
16:19:05 <timCole> azaroth: one of the editors of microdata is Dan Bri who is in this WG, another is Charles
16:19:08 <bigbluehat> +1
16:19:09 <azaroth> q?
16:19:16 <bigbluehat> s/+1//
16:19:22 <timCole> ... so lets grab them at TPAC and get a better sense of their feelings
16:19:33 <bigbluehat> PROPOSAL: Defer any change until the extent to which technical differences between URL and IRI can be determined, especially any difference between web browser and other stacks.
16:19:42 <ajs6f> +1
16:19:45 <azaroth> +1
16:19:46 <gkellogg> +1
16:19:46 <bigbluehat> +1
16:19:46 <simonstey> +1
16:19:48 <timCole> +1
16:19:52 <dlehn> +1
16:19:54 <workergnome> +1
16:20:17 <jeff_mixter> +1
16:20:59 <timCole> gkellogg: another factor is whether json-ld use of IRI makes some people see json-ld as not web browser friendly
16:21:24 <bigbluehat> RESOLVED: Defer any change until the extent to which technical differences between URL and IRI can be determined, especially any difference between web browser and other stacks.
16:21:26 <azaroth> SUBTOPIC: Inverse of @container:@set
16:21:37 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/17
16:21:42 <timCole> azaroth: next is issue #17
16:21:56 <timCole> ... this came from a discussion with Dan that is broader than just schema.org
16:22:43 <gkellogg> q+
16:22:47 <timCole> ... so with @container @set, we can say if this resource is present then its always an array, even if a single item
16:23:19 <timCole> ... the issue in terms of expressing json-ld we don't have the opposite
16:23:35 <timCole> ... we can't say I would like it compacted to a single value rather than an array
16:24:29 <timCole> ... e.g., for reciepe use case was to show value for single step reciepe as a string rather than array
16:24:32 <bigbluehat> q+
16:24:35 <azaroth> ack gkellogg
16:24:45 <timCole> ... so this would mean some changes to compacting
16:25:05 <timCole> gkellogg: this impacts first, compaction
16:25:26 <azaroth> +1 to gkellogg
16:25:48 <timCole> ... but second how does a processor when expanding interpret a string value when defined that it could be array
16:26:13 <timCole> ... this latter seems to impact schema.org users and instruction to them especially
16:26:29 <timCole> ... I explained this in my last comment on the issue thread
16:27:16 <timCole> ... I personally don't think the compaction issue is on its own a big deal, given that trend is encouragement to always use arrays when allowed as value for key
16:27:18 <azaroth> q?
16:27:18 <bigbluehat> +1
16:27:20 <azaroth> ack bigbluehat
16:28:04 <timCole> bigbluehat: the actual listing issue on allreciepes is microdata related because microdata can't do lists
16:28:21 <gkellogg> q+
16:28:39 <timCole> ... so if run that use case through current microdata processor you get RDF that looks a little different
16:28:44 <azaroth> ack gkellogg
16:29:39 <timCole> gkellogg: to beat a deadhorse - decision was made to not overcomplicate things, but when microdata is dumb, we shouldn't want to dumb json-ld down to match
16:29:50 <azaroth> q?
16:29:57 <bigbluehat> +1 to gkellogg yet again
16:30:07 <timCole> azaroth: any other thoughts?
16:30:51 <timCole> ... to clarify expansion part of issue, what happens now if you have a single string value for a key that is defined to be an array
16:31:00 <timCole> gkellogg: it gets turned into array
16:31:19 <timCole> azaroth: so close, won't fix, no compelling use cases
16:31:29 <azaroth> q?
16:31:32 <timCole> gkellogg: we could include note in primer
16:31:51 <azaroth> PROPOSAL: Close #17 won't fix, as no use cases for compaction, and expansion already works as expected
16:31:53 <azaroth> +1
16:31:53 <bigbluehat> +1
16:31:54 <jeff_mixter> +1
16:31:55 <gkellogg> +1
16:31:56 <timCole> +1
16:31:57 <workergnome> +1
16:32:10 <bigbluehat> RESOLVED: Close #17 won't fix, as no use cases for compaction, and expansion already works as expected
16:32:12 <dlehn> +1
16:32:21 <simonstey> +1
16:32:26 <ajs6f> +1
16:32:47 <bigbluehat> SUBTOPIC: Recursion and @reverse - https://github.com/w3c/json-ld-framing/issues/5
16:33:12 <azaroth> q?
16:33:42 <timCole> gkellogg: issue #5 is about how framing for reverse properties, but not adequate support
16:34:21 <timCole> ... if you have a reverse property expressed in a frame, that property may have its own reverse properties, currently framing does not handle this
16:34:40 <timCole> ... so seems a good idea to improve, but devil is in the details
16:35:02 <azaroth> q?
16:35:10 <workergnome> q+
16:35:14 <timCole> ... this could be turned into an editors action, assuming we can get some support from other implementers
16:35:14 <azaroth> ack workergnome
16:35:41 <timCole> workergnome: support this approach, we anticipate running into this issue at the Getty
16:35:49 <timCole> azaroth: agree
16:35:59 <timCole> ... principle of least surprise
16:36:08 <bigbluehat> q?
16:36:36 <timCole> ... so how does the WG feel about how we should continue to track and make sure it gets addressed?
16:37:11 <timCole> ... not ready to go into detailed solution on this call, but do need other implementers to work with gkellog
16:37:53 <timCole> gkellogg: that sounds right - its partly a bandwidth issue of having a single editor
16:38:00 <azaroth> PROPOSAL: Accept framing#5 but seek additional support in terms of implementation experience
16:38:03 <gkellogg> +1
16:38:04 <azaroth> +1
16:38:04 <bigbluehat> +1
16:38:06 <timCole> +1
16:38:13 <simonstey> +1
16:38:25 <ajs6f> +1
16:38:27 <workergnome> +1
16:38:31 <dlehn> +1
16:38:33 <jeff_mixter> +1
16:38:38 <azaroth> RESOLVED: Accept framing#5 but seek additional support in terms of implementation experience
16:38:44 <azaroth> SUBTOPIC: Indexing with a predicate
16:39:00 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/19
16:39:17 <timCole> azaroth: issue #19 came up at Getty and IIIF over the past year
16:39:38 <timCole> ... it's hard at API level to determine where you would find a repeated description of a resource
16:40:01 <timCole> ... e.g., there's a bunch of items in a list with various properties
16:40:42 <timCole> ... if you building an application consuming descriptions as json (rather than RDF), it would be nice to be able to find these descriptions
16:41:24 <timCole> ... looking for a json surface level construct that makes it easier to find relevant descriptions further down
16:41:31 <gkellogg> q+
16:41:59 <timCole> ... there has been promising development, but relies on a new keyword
16:42:11 <jeff_mixter> q+
16:42:13 <azaroth> ack gkellogg
16:42:17 <timCole> ... so, do people support the feature? and then if yes, we can talk about solutions.
16:42:25 <bigbluehat> q+
16:42:50 <workergnome> q+
16:42:56 <timCole> gkellogg: we can certainly come up with solutions, but is this semantic overhead we want to add to json-ld just because it's available in other approaches
16:43:15 <timCole> ... framing may help with this, but would result in repetition of statements
16:43:47 <timCole> ... consistent with RDF which is happy with repetition of statements, although that is not a natural json approach
16:44:18 <timCole> ... question is whether framing/repetition approach is sufficient
16:44:31 <azaroth> q?
16:44:34 <azaroth> ack jeff_mixter
16:44:42 <azaroth> q+ to discuss service in IIIF
16:44:54 <timCole> jeff_mixter: agree with usefulness of this, would be super-convenient
16:45:07 <timCole> ... but I do have concerns about adding a keyword to do this
16:45:34 <timCole> ... and I do think like @gkellog that there may be ways to do this without a new keyword
16:45:39 <azaroth> q?
16:45:41 <azaroth> ack bigbluehat
16:46:18 <timCole> bigbluehat: my concerns echo Jeff's. We should look at how close we can get to this without existing json-ld mecahnisms
16:46:35 <azaroth> q?
16:46:36 <azaroth> ack workergnome
16:46:49 <timCole> ... and not move forward with introducing something new until we've exhausted existing options
16:47:08 <timCole> workergnome: when we started on this we tried 3 ways
16:47:28 <timCole> ... the size of the document you have to send over the wire gets large, really verbose
16:47:43 <azaroth> q?
16:47:53 <timCole> gkellogg: of course it is compressed when sent over the wire
16:48:33 <timCole> workergnome: 3rd way we've done this is with reverse properties
16:48:50 <timCole> ... saying this concept is inside this container, etc.
16:48:52 <azaroth> q?
16:48:58 <azaroth> ack azaroth
16:48:58 <Zakim> azaroth, you wanted to discuss service in IIIF
16:49:09 <azaroth> http://iiif.io/api/auth/1.0/#example-description-resource-with-authentication-services
16:49:21 <timCole> azaroth: to give a sense of repeated data (see link above)
16:49:58 <timCole> ... in IIIF we have idea of authentication service, which needs to be repeated for each resource
16:50:12 <workergnome> http://aat-web-services-staging.getty.edu/aat/300390918.json
16:50:17 <timCole> ... so service block in example linked above is actually about the shortest
16:50:32 <gkellogg> q+
16:50:33 <workergnome> is the example of where we're doing it, with the `seeAlso` predicate
16:50:43 <timCole> ... and if you repeat it 500 times in the same document, the memory usage gets rediculous
16:51:04 <workergnome> q+
16:51:12 <azaroth> q?
16:51:21 <azaroth> ack gkellogg
16:51:25 <timCole> ... may not be significant for modern browsers, but does become problem in mobile environment
16:51:43 <timCole> gkellogg: wondering how much this comes down to a data modelling issue?
16:52:11 <timCole> ... can you model it by indirect reference approach?
16:52:24 <timCole> ... this is more like what the framing would support
16:52:36 <jeff_mixter> +1 to the reference to a separate node for the iiif service issue
16:52:45 <timCole> ... you end up with references rather than having to include
16:53:13 <azaroth> q?
16:53:16 <azaroth> ack workergnome
16:53:24 <timCole> ... we're looking for another way to avoid repeating all properties up at node level
16:53:59 <timCole> workergnome: in most consuming applications we've been using, the practice they recommend is shallow references as opposed to deeply nested structures
16:54:07 <jeff_mixter> q+
16:54:11 <timCole> ... so we end up building a flatter structure
16:54:21 <azaroth> ack jeff_mixter
16:54:26 <azaroth> q?
16:54:31 <timCole> ... having a pattern that allows expressing in flatter structure would be good
16:54:43 <timCole> jeff_mixter: i agree with David's comments
16:55:35 <gkellogg> q+
16:55:35 <timCole> ... want to differentiate between graph-based use cases and IIIF use cases that want to cache and focus on json, not the RDF
16:55:35 <azaroth> q?
16:55:38 <azaroth> ack gkellogg
16:56:05 <timCole> gkellogg: I'm wondering, should we explore a new framing mechanism as a way to address this?
16:56:20 <ajs6f> q+
16:56:26 <timCole> ... something indirection mechanism in the framing
16:56:43 <timCole> ... might not end up with round tripping solution
16:56:45 <azaroth> ack ajs6f
16:56:59 <workergnome> q+
16:57:02 <timCole> ... or do we need to keep in the existing expansion / compression options
16:57:26 <timCole> ajs6f: you're talking about a way to add to document when framed
16:57:50 <azaroth> ack workergnome
16:57:51 <ajs6f> q+
16:58:03 <timCole> gkellogg: yes, for example if framing could allow you to pull info from references into the object being framed
16:58:20 <timCole> ... don't have full solution yet, but trying to explore solution space
16:58:45 <timCole> workergnome: I think this goes beyond framing, more about how we structure the data
16:59:01 <timCole> ... the rdf should be the same however we do it
16:59:08 <azaroth> ack ajs6f
16:59:18 <timCole> ... could end up with data section and included section
16:59:50 <timCole> ajs6f: some of the same concerns come up when we talk about using context to add new data
16:59:51 <azaroth> q+
17:00:23 <azaroth> ack azaroth
17:00:26 <timCole> ... always a little worried about solutions that draw beyond the source, you end up with multiple sources
17:00:33 <gkellogg> We might reconsider @default, then
17:00:57 <timCole> azaroth: noting it is top of the hour, first agree with Adam, also agree this is a framing (rather than compaction) issue
17:01:14 <ajs6f> gkellogg: yes, and I admit that I don't have clear thinking about that
17:01:23 <timCole> ... let's have a bit homework on this one.
17:01:41 <timCole> ... please find examples and add to the issue, and look at framing rather than compaction
17:01:47 <timCole> ... and add use cases
17:01:55 <azaroth> q?
17:02:22 <timCole> ... not ready to resolve, but this discussion was promising. Revisit next week.
17:02:29 <timCole> ... Adjourn
17:02:37 <ajs6f> bye y'all
17:03:00 <azaroth> rrsagent, draft minutes
17:03:00 <RRSAgent> I have made the request to generate https://www.w3.org/2018/09/14-json-ld-minutes.html azaroth
17:03:39 <azaroth> rrsagent, set log public
17:04:14 <azaroth> Date: 14 Sep 2018
17:04:17 <azaroth> rrsagent, draft minutes
17:04:17 <RRSAgent> I have made the request to generate https://www.w3.org/2018/09/14-json-ld-minutes.html azaroth
17:04:19 <azaroth> Date: 14 Sep 2018
17:04:22 <azaroth> rrsagent, set log public
17:06:35 <azaroth> zakim, bye
17:06:35 <Zakim> leaving.  As of this point the attendees have been Rob_Sanderson, Benjamin_Young, workergnome, Gregg_Kellogg, jeff_mixter, Tim_Cole, simonstey, ajs6f, David_Lehn
17:06:35 <Zakim> Zakim has left #json-ld
17:06:41 <azaroth> rrsagent, bye
17:06:41 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2018/09/14-json-ld-actions.rdf :
17:06:41 <RRSAgent> ACTION: gkellogg to add issues related to continuous publication of working drafts [1]
17:06:41 <RRSAgent>   recorded in https://www.w3.org/2018/09/14-json-ld-irc#T16-08-41