15:45:52 <RRSAgent> RRSAgent has joined #json-ld
15:45:52 <RRSAgent> logging to https://www.w3.org/2018/07/13-json-ld-irc
15:45:57 <azaroth> zakim, this is json-ld
15:45:58 <Zakim> got it, azaroth
15:46:40 <azaroth> rrsagent start
15:46:48 <azaroth> rrsagent listen
15:47:33 <azaroth> present+ Rob_Sanderson
15:49:03 <azaroth> azaroth has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0010.html
15:51:32 <workergnome> workergnome has joined #json-ld
15:57:35 <simonstey> simonstey has joined #json-ld
15:57:40 <timCole> timCole has joined #json-ld
16:00:33 <bigbluehat> present+ Benjamin_Young
16:00:34 <gkellogg> present+ Gregg_Kellogg
16:00:50 <simonstey> present+
16:00:54 <ajs6f> ajs6f has joined #json-ld
16:02:12 <timCole> present+ Tim_Cole
16:02:20 <workergnome> present+ David_Newbury
16:02:29 <bigbluehat> rrsagent, set log public
16:02:30 <azaroth> ScribeNick: timCole
16:02:37 <jeff_mixter> jeff_mixter has joined #json-ld
16:03:12 <timCole> Topic: Minutes from 6 July
16:03:13 <bigbluehat> Meeting: JSON-LD Working Group Telco
16:03:13 <bigbluehat> Chair: bigbluehat, azaroth
16:03:13 <bigbluehat> Date: 2018-07-13
16:03:13 <bigbluehat> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0010.html
16:03:33 <azaroth> regrets+ Ivan
16:04:03 <azaroth> Proposed: Approve minutes: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0010.html
16:04:03 <azaroth> +1
16:04:06 <bigbluehat> +1
16:04:07 <gkellogg> +1
16:04:07 <jeff_mixter> present +Jeff
16:04:10 <jeff_mixter> +1
16:04:12 <timCole> +1
16:04:28 <jeff_mixter> present + Jeff
16:04:40 <hsolbrig> hsolbrig has joined #json-ld
16:04:41 <jeff_mixter> present+ Jeff
16:04:45 <hsolbrig> present+ hsolbrig
16:04:50 <ajs6f> present+ ajs6f
16:05:00 <azaroth> RESOLVED: Approve minutes: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Jul/0010.html
16:05:16 <timCole> Topic: Announcements/Reminders?
16:05:44 <timCole> bigbluehat: Any announcements or reminders
16:06:00 <timCole> ... TPAC discount ends at the end of July for registration
16:06:23 <timCole> ... hotel discounted rates are first come first serve
16:06:52 <timCole> Adam: what was tpac rate?
16:07:14 <timCole> azaroth: rate is 110 Euros per day (including VAT)
16:07:37 <timCole> Jeff: I was on last call but not listed in minutes
16:07:47 <timCole> bigbluehat: will fix
16:08:32 <timCole> bigbluehat: if you are on the nickname list, it is sufficient to just do present+
16:08:52 <timCole> ... if not in nickname list, then need to present+ full_name
16:08:53 <bigbluehat> https://github.com/w3c/json-ld-wg/blob/master/assets/nicknames.json
16:09:18 <timCole> azaroth: either do pull request or ping Rob, Ben, or Ivan to add you, if not already in the nickname list
16:09:57 <timCole> azaroth: no need for introductions this week
16:10:07 <timCole> Topic: Discussion of Guiding Principles
16:10:18 <azaroth> https://github.com/w3c/json-ld-wg/pull/6
16:10:28 <timCole> azaroth: not absolute rules but things we think are useful / important
16:11:09 <timCole> ... we will keep walking our way down the document today, hopefully getting through the remaining issues today.
16:11:11 <azaroth> rendered: https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md
16:11:52 <timCole> ... starting with first item starting 'Proposed:...
16:12:10 <bigbluehat> https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-simplicity-is-determined-by-end-users-not-library-implementers
16:12:15 <dlehn> present+ David_Lehn
16:12:21 <gkellogg> q+
16:12:31 <ajs6f> q+
16:12:34 <timCole> ... related to previous, but also focused on helping developers generally
16:13:04 <azaroth> q?
16:13:07 <azaroth> ack gkellogg
16:13:18 <timCole> ... so if you are a Webmaster you determine what simpler more than the spec writers
16:13:33 <timCole> gkellogg: this is how we did it for json-ld 1.0
16:13:49 <bigbluehat> ack ajs6f
16:14:02 <timCole> ... we have gotten feedback on the complexity of the algos, but this is result of making it easier for end-users
16:14:18 <azaroth> q+
16:14:21 <timCole> Adam: 'usability' may be a little more on point than simplicity
16:14:37 <bigbluehat> ack azaroth
16:14:40 <workergnome> q+
16:14:41 <timCole> ... could we go to usability or ease of use to make principle more pointed. Agree with main point.
16:14:59 <timCole> azaroth: should we replace simple with useable above as well?
16:15:33 <timCole> Adam: I would not suggest doing that now, because this current principle focuses on the audience at hand
16:15:42 <azaroth> +1 to adam
16:15:44 <bigbluehat> ack workergnome
16:16:05 <bigbluehat> s/Adam:/ajs6f:
16:16:13 <timCole> workergnome: going back to question last week - are data producers different than data consumers?
16:16:17 <azaroth> q?
16:16:52 <timCole> azaroth: I think there is an additional distinction between audience using data as JSON and audience using data as RDF
16:16:57 <bigbluehat> q+
16:17:08 <timCole> ... given target audience is software developers generally
16:17:28 <timCole> ... could be explicity that we mean both Web developers and developers that work more broadly
16:18:04 <timCole> ... is it easy for developers who have RDF to use vs. an IIIF developer who thinks of it as JSON (RDF is a side-effect)
16:18:51 <timCole> workergnome: In IIIF we've worked on issues like do we allow arrays or just an object
16:19:04 <ajs6f> q+
16:19:07 <timCole> ... do we make it simple to make appropriate documents, even if difficult consume
16:19:16 <bigbluehat> ack bigbluehat
16:19:25 <bigbluehat> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
16:19:28 <timCole> ... or do we make it easier to consume and harder to produce
16:19:49 <azaroth> q+ to assert a lack of opinion about JSON specific design (e.g. always arrays if ever an array is a context designer's choice)
16:19:50 <timCole> bigbluehat: what to connect to HTML design principles
16:20:10 <timCole> ... this prioritize groups in a fashion similar to what Rob mentioned
16:20:14 <azaroth> ACTION: Add priority of constituencies to guiding principles doc
16:20:14 <bigbluehat> ack ajs6f
16:20:43 <bigbluehat> ACTION: add Jeff Mixter (jeff_mixter) to last weeks present list in the minutes
16:20:48 <timCole> ajs6f: almost no one wants to do RDF , or even JSON
16:21:07 <timCole> ... they want to focus on their business. JSON (or RDF) is a means to an end
16:21:18 <bigbluehat> +1 to ajs6f's conjecture that devs don't "want" formats, they want things to work / be done (etc)
16:21:20 <bigbluehat> q?
16:21:20 <azaroth> q?
16:21:24 <bigbluehat> ack azaroth
16:21:24 <Zakim> azaroth, you wanted to assert a lack of opinion about JSON specific design (e.g. always arrays if ever an array is a context designer's choice)
16:21:28 <timCole> ... so if we distinguish between consumers and producers we should prioritize consumers
16:21:45 <workergnome> +q
16:21:53 <timCole> azaroth: I want to assert that we should not be opiniated about JSON patterns
16:22:33 <timCole> ... so for example in IIIF if there can ever be multiple values it's always an array. But this is not the only pattern.
16:23:14 <timCole> ... So, for example schema.org does not do it this way - allows strings and arrays as object for a given property
16:23:18 <ajs6f> +1 to JSON pattern agnosticism
16:23:20 <bigbluehat> q?
16:23:25 <bigbluehat> ack workergnome
16:23:33 <timCole> ... this puts the oneous back on the context designer for a particular community
16:24:00 <timCole> workergnome: The HTML design principles expresses exactly what I want to get at
16:24:14 <bigbluehat> https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-provide-on-ramps
16:24:40 <timCole> azaroth: next principle is to provide on-ramps (important in LA)
16:25:04 <timCole> ... allows features to be incrementally
16:25:18 <bigbluehat> +1
16:25:18 <timCole> ... not sure how often it comes up, but it does help with managing complexity
16:25:22 <workergnome> q+
16:25:24 <bigbluehat> ack workergnome
16:25:26 <ajs6f> +1
16:25:57 <timCole> workergnome: Where this tends to come is up is in sense that complicated patterns build on simple ones
16:25:59 <azaroth> And +1 to workergnome
16:26:18 <timCole> ... this can make the complex patterns a little more complex (essentially for backward compatibility)
16:26:22 <azaroth> q?
16:26:29 <bigbluehat> https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-define-success-not-failure
16:26:51 <timCole> azaroth: next - define success, not failure
16:27:04 <gkellogg> q+
16:27:09 <timCole> ... means specify conformance rather than non conformance
16:27:42 <timCole> ... the few NOT constraints the easier our lives will be in the future and the easier to add extensions
16:28:34 <simonstey> q+
16:28:36 <bigbluehat> ack gkellogg
16:28:55 <timCole> gkellogg: this overlaps with 1.0 decisions that came back to bite us
16:29:28 <timCole> ... for example we decided to be more perscriptive in the context, but we weren't perscriptive enough about @ signs etc.
16:29:33 <azaroth> q+ to note @type being fixed by the 1.0 spec as another affected issue in the other direction
16:30:01 <timCole> ... when we later wanted to add type containers, because we had not identified the list of possible containers
16:30:12 <timCole> ... we had to add the @id
16:30:15 <bigbluehat> ack simonstey
16:30:47 <timCole> ... if we had avoided saying that containers had to be one of those listed, it would have been easier
16:31:10 <azaroth> q?
16:31:14 <timCole> simonstey: not entire clear what we're trying to do. Is it like closed vs. open world? or what is the difference?
16:31:15 <bigbluehat> ack azaroth
16:31:15 <Zakim> azaroth, you wanted to note @type being fixed by the 1.0 spec as another affected issue in the other direction
16:31:20 <gkellogg> q+
16:31:32 <timCole> azaroth: yes, the open vs. closed world is exactly on point
16:31:52 <timCole> ... if we are silent then you are not out of conformance if you add that feature on your own
16:32:09 <timCole> ... it remains undefined, but it is avoids non-conformance
16:32:30 <timCole> ... like being rigorous with what you send, not what you get
16:33:15 <timCole> ... but on the flip side of being overly perscriptive on 1.0, @type does constrain
16:33:33 <bigbluehat> ack gkellogg
16:34:16 <timCole> gkellogg: when looking schema.org examples, I came across an example that used @Url where @id was clearly meant
16:34:24 <azaroth> Also there's a proposal for @label as thinking the @ is magical
16:34:57 <bigbluehat> q?
16:35:04 <timCole> ... 1.0 processor is okay with this, although would have been nice if we had been more prescriptive in this case
16:35:13 <azaroth> @type as @container:@set issue:  https://github.com/w3c/json-ld-syntax/issues/34
16:35:35 <azaroth> @label for rdfs:label issue: https://github.com/w3c/json-ld-syntax/issues/6
16:36:29 <timCole> azaroth: next, follow existing standards and best practices where possible
16:36:42 <bigbluehat> https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-follow-existing-standards-and-best-practices-where-possible-and-where-they-do-not-conflict-with-other-principles
16:36:50 <timCole> ... allows us to ignore a standard that has gone bad, but we should not reinvent
16:37:02 <bigbluehat> +1
16:37:05 <ajs6f> +1
16:37:12 <workergnome> +1
16:37:15 <timCole> ... between new and reuse, pick reuse unless reuse creates a problem
16:37:25 <bigbluehat> https://github.com/w3c/json-ld-wg/blob/e07e37d59b1df9d04d8ca389b31d118cd85832ea/WorkMode/guiding_principles.md#proposed-the-underlying-data-model-is-rdf
16:37:47 <timCole> ... last, the underlying data model is RDF - this may be controversial and we may decide to leave off
16:37:54 <gkellogg> q+
16:38:31 <timCole> ... Manu has already objected, noting that 1.0 used generic graph set data model (rather than including RDF constraints on graph model)
16:38:37 <jeff_mixter> q+
16:38:43 <timCole> ... so this also has to do with round-tripping discussion
16:39:11 <timCole> ... if we stay with RDF, we then would defer non-RDF compatible features to future
16:39:49 <workergnome> q+
16:40:01 <timCole> ... for example, assuming RDF, would mean not allowing blanknodes as predicate, direction of strings
16:40:03 <bigbluehat> ack gkellogg
16:40:44 <timCole> gkellogg: Manu is on record that json-ld data model does is not same as RDF
16:41:26 <timCole> ... allowing blanknodes as predicates allows creating new identifiers (ala CURIE).
16:41:36 <bigbluehat> here's our current "Relationship to RDF" section https://w3c.github.io/json-ld-syntax/#relationship-to-rdf
16:41:50 <timCole> ... this does not seem a very useful use case, so the WG could decide that this is an obsolete pattern
16:42:43 <timCole> ... the other use case is data indexing, e.g., data value as key - when json-ld is compacted value becomes subject...
16:43:00 <timCole> ... this is an area of json-ld where it is difficult to create a round trip
16:43:39 <timCole> ... went back and looked at list of list issue history, we abandoned because we didn't have a use case and at time looked not to be worth it
16:43:53 <timCole> ... but perhaps we should revisit if we have a use case now
16:44:17 <timCole> ... so the main issue right now seems to be the @data issue
16:44:25 <hsolbrig> q+
16:44:44 <timCole> ... regarding where RDF might go, we probably do not want to get ahead of RDF
16:44:50 <timCole> ... so that we could defer to future.
16:44:53 <bigbluehat> ack jeff_mixter
16:45:37 <timCole> jeff_mixter: from a practical standpoint when we do ingest linked data, we tend to normalize to triples to facilitate ingest into triple store or process
16:46:05 <timCole> ... so if json-ld didn't align with RDF might cause problems
16:46:31 <bigbluehat> ack workergnome
16:46:44 <timCole> ... in library community there is a growing interest in RDF (BibFrame, etc.) so not being able to stay consistent would be a problem
16:47:21 <timCole> workergnome: agree with Jeff, if we really were doing a json serialization of graph would look significantly different
16:47:38 <bigbluehat> ack hsolbrig
16:47:39 <ajs6f> +1
16:47:43 <timCole> ... since we are already 95% with RDF, we really should go whole hog and be 100%
16:47:44 <azaroth> q+ to ask about warning on non-RDF data model, both in spec and in libraries
16:47:44 <simonstey> +1
16:48:02 <timCole> hsolbrig: this proposal is slightly confusing, seem to be two possible understandings
16:48:28 <timCole> ... one is RDF needs to be able to represent everything we say with json-ld
16:48:51 <timCole> ... the other interpretation is json-ld needs to be able say everything you can say in RDF.
16:48:55 <bigbluehat> q+ to ask about current implementations / use cases for JSON-LD which reach "beyond" RDF
16:48:56 <bigbluehat> ack azaroth
16:48:56 <Zakim> azaroth, you wanted to ask about warning on non-RDF data model, both in spec and in libraries
16:49:04 <timCole> ... the second interpretation may not be all that useful for our users
16:49:52 <timCole> azaroth: I agree previous speakers, so as a way forward, can we call out when there's a 1.0 non-RDF feature
16:50:13 <jeff_mixter> q+
16:50:23 <timCole> ... we have to stay backward compatible, but we can make it very obvious why not to use that feature
16:50:41 <timCole> ... and for any new features we don't add anything to 1.1 that would be non-RDF
16:51:02 <bigbluehat> ack bigbluehat
16:51:02 <Zakim> bigbluehat, you wanted to ask about current implementations / use cases for JSON-LD which reach "beyond" RDF
16:51:04 <timCole> ... so the principle becomes a gating one rather than normative. What features should we not add
16:51:19 <azaroth> +1 to understanding costs of adding / not adding
16:51:28 <timCole> bigbluehat: may also want to consider the cost of adding / not adding
16:51:51 <timCole> ... we also want to understand who's using parts of 1.0 that are not expressable in RDF
16:52:20 <timCole> ... we also want to be aware how json developers are using json-ld without caring about RDF
16:52:39 <timCole> ... want avoid letting RDF data model become our albatross
16:53:32 <bigbluehat> q?
16:53:34 <bigbluehat> ack jeff_mixter
16:53:37 <timCole> ... practically we'll have to weigh the trade-offs and do the best we can
16:53:49 <azaroth> +1 as well
16:54:13 <gkellogg> q+
16:54:23 <timCole> azaroth: Are there changes to text that would make this last principle clearer?
16:54:27 <hsolbrig> q+
16:54:47 <bigbluehat> ack gkellogg
16:54:48 <timCole> ... something that would sound less like we want to stop the trains
16:55:38 <timCole> gkellogg: to drive this (it will be contentious) should we create a proposal for the WG to adopt as a way of making clear what we're doing
16:55:41 <azaroth> +1 to being clear about rdf 1.1
16:55:59 <jeff_mixter> +1 for rdf 1.1
16:55:59 <timCole> ... e.g., make clear features from 1.0 that we might deprecate
16:56:22 <timCole> ... alternatively we could propose that the underlying data model is not RDF as a way to provoke feedback
16:56:32 <bigbluehat> ack hsolbrig
16:56:36 <timCole> ... we need to put stakes in the ground and promote them to get healthy feedback
16:56:53 <azaroth> +1!
16:57:10 <timCole> hsolbrig: following-up it rolls back to a fundemental issue that we need to be able to speak to. We used to say its
16:57:32 <timCole> ... a RDF serialization format. But we need a better answer to what is json-ld?
16:58:00 <timCole> azaroth: defer process items on agenda to next week
16:58:25 <timCole> ... Rob will revise PR and tag all of us as reviewer
16:58:44 <timCole> ... if discussion and changes are okay with you, then ignore, otherwise comment
16:59:14 <timCole> ... we need to find happy medium between it's just a graph and it's rdf
16:59:36 <bigbluehat> +1 to merging with review on github
16:59:51 <timCole> ... do we need a resolution or will we make do with gitHub review
17:00:06 <timCole> bigbluehat: will be in touch about upcoming calls
17:00:13 <timCole> adjourn
17:00:20 <azaroth> ACTION: Rob to merge changes from the discussion into guiding principles doc
17:00:22 <azaroth> Aye
17:39:34 <timCole> rrsagent, make log public
17:40:18 <timCole> rrsagent, generate minutes
17:40:18 <RRSAgent> I have made the request to generate https://www.w3.org/2018/07/13-json-ld-minutes.html timCole
19:10:12 <Zakim> Zakim has left #json-ld
22:49:14 <gkellogg> gkellogg has joined #json-ld