15:49:52 <RRSAgent> RRSAgent has joined #json-ld
15:49:52 <RRSAgent> logging to https://www.w3.org/2018/08/17-json-ld-irc
15:49:53 <ivan> rrsagent, set log public
15:49:53 <ivan> Meeting: JSON-LD Working Group Telco
15:49:53 <ivan> Chair: azaroth42
15:49:53 <ivan> Date: 2018-08-17
15:49:53 <ivan> Regrets+ tcole
15:49:53 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0009.html
15:49:54 <ivan> ivan has changed the topic to: Meeting Agenda 2018-08-17: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0009.html
15:51:22 <ivan> regrets+ danbri
15:51:41 <ajs6f> ajs6f has joined #json-ld
15:53:03 <ivan> present+
15:53:30 <simonstey> present+
15:53:43 <dlongley> regrets+ dlongley
15:54:38 <ajs6f> present+
15:56:07 <gkellogg> present+ Gregg_Kellogg
15:58:07 <workergnome> workergnome has joined #json-ld
15:59:16 <azaroth> azaroth has joined #json-ld
15:59:34 <dlehn> present+
15:59:36 <azaroth> present+ Rob_Sanderson
16:00:33 <azaroth> regrets+ Tim_Cole
16:00:38 <azaroth> regrets+ Dan_Brickley
16:01:24 <workergnome> present+
16:01:32 <ajs6f> scribenick ajs6f
16:01:38 <ivan> scribenick: ajs6f
16:01:42 <alejandra> alejandra has joined #json-ld
16:01:56 <azaroth> TOPIC: Approve minutes of previous call
16:02:09 <azaroth> link: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-10-json-ld
16:02:21 <workergnome> +1
16:02:22 <ajs6f> +1
16:02:23 <ivan> +1
16:02:24 <azaroth> +1
16:02:26 <simonstey> +0
16:02:30 <alejandra> present+
16:02:34 <alejandra> +0
16:02:35 <bigbluehat> +1
16:02:36 <gkellogg> +1
16:02:41 <dlehn> +1
16:02:42 <jeff_mixter> jeff_mixter has joined #json-ld
16:02:44 <azaroth> RESOLVED: Approve minutes of previous call
16:02:46 <bigbluehat> present+ Benjamin_Young
16:02:53 <jeff_mixter> present+
16:03:01 <azaroth> TOPIC: Announcements
16:03:16 <ajs6f> azaroth: TPAC, as usual.
16:03:33 <ajs6f> ivan: Face-to-face planning documents are currently practically empty
16:03:44 <azaroth> link: https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2018.10.Lyon
16:04:05 <ajs6f> ivan: we have a Google doc waiting for ideas to discuss
16:04:31 <ajs6f> ivan: add whatever you think, chairs will prioritize and sort
16:05:18 <ajs6f> ivan: our problems will not be culinary
16:05:44 <ajs6f> ivan: do register if you are coming, so that organizers can get the logistics right (meeting rooms, etc.)
16:05:56 <ajs6f> ivan: ten or twelve registered now, more would be good
16:06:06 <ajs6f> azaroth: many requests for observer status
16:06:20 <ajs6f> ivan: up to us how to play that (observer status)
16:06:42 <ajs6f> ivan: Only two months away!
16:06:53 <azaroth> zakim, who is here?
16:06:53 <Zakim> Present: ivan, simonstey, ajs6f, Gregg_Kellogg, dlehn, Rob_Sanderson, workergnome, alejandra, Benjamin_Young, jeff_mixter
16:06:56 <Zakim> On IRC I see jeff_mixter, alejandra, azaroth, workergnome, ajs6f, RRSAgent, Zakim, simonstey, ivan, gkellogg, dlongley, bigbluehat, ChristopherA, dlehn
16:07:15 <azaroth> TOPIC: Introductions
16:07:16 <ajs6f> azaroth: new folks here, so we can do introductions
16:07:56 <ajs6f> azaroth: co-chair w/ bigbluehat, long-standing involvement with cultural heritage domain, many specs
16:08:35 <ajs6f> ivan: Ivan Herman, W3C team contact for this WG, was once Semantic Web activity lead, now doing more digital publishing. part of RDF WG when JSON-LD 1.0 came out
16:08:55 <ajs6f> simon: with WU of Economics and Business, SHACL and other groups
16:08:55 <azaroth> scribenick: azaroth
16:09:23 <azaroth> ajs6f: Adam Soroka, Apache Software Foundation (Jena) also another hat of the Smithsonian Institution, interested in cultural heritage
16:09:29 <ajs6f> scribenick: ajs6f
16:09:30 <azaroth> scribenick: ajs6f
16:10:04 <ajs6f> gkellog: edited the 1.0 doc, into JSON-LD from the beginning, and editor for CG specs
16:10:18 <ajs6f> dlehn: with Digital Bazaar
16:10:41 <ajs6f> workergnome: also from J. Paul Getty Trust, interested in consuming JSON-LD
16:11:17 <ajs6f> alejandra: Coming from Oxford, uses JSON-LD and other SW tools, involved with W3C Dataset Exchange WG
16:11:44 <ajs6f> bigbluehat: with John Wiley, co-chair with azaroth, also part of Web Publications WG,
16:12:12 <ajs6f> jeff_mixter: with OCLC, interested in participating in various LD WGs
16:12:18 <azaroth> TOPIC: Issues
16:12:24 <azaroth> SUBTOPIC: @type related issues
16:12:27 <ivan> chair: bigbluehat
16:12:38 <bigbluehat> https://github.com/w3c/json-ld-api/issues/4
16:12:40 <azaroth> link: https://github.com/w3c/json-ld-api/issues/4
16:13:19 <gkellogg> q+
16:13:23 <bigbluehat> ack gkellogg
16:13:25 <ajs6f> bigbluehat: The issue is "Relax the colliding keywords constraint for @type #4". No obvious reason has been raised not to do this.
16:13:50 <ajs6f> gkellogg: this was wrapped up in the general issue of multiple aliases for keywords
16:14:01 <ajs6f> ... use case: set the container for @type to @set
16:14:15 <ajs6f> ... which would allow it to always compact to an array
16:14:20 <azaroth> q+
16:14:49 <ajs6f> ... wouldn't want to reassign @type to something other than IRI
16:15:09 <bigbluehat> ack azaroth
16:15:28 <ajs6f> azaroth: related to #34
16:16:00 <ajs6f> ... the coverage example in the issue could be solved by allowing @type to be aliases w/i scoped contexts but not at the top level
16:16:08 <ajs6f> s/aliases/aliased
16:16:36 <gkellogg> q+
16:16:46 <bigbluehat> ack gkellogg
16:16:50 <ajs6f> ... having it aliased  "one step down" not globally would make the resolution deterministic
16:17:05 <ajs6f> gkellogg: that wouldn't resolve the collision unless the original alias was also removed
16:17:08 <azaroth> +1 to gkellogg
16:17:32 <ajs6f> ... we have no other case where the rules for scoped contexts are different than general rules for contexts
16:17:34 <azaroth> {"type": null, "profile": "@type"}
16:17:35 <ajs6f> g+
16:17:40 <ajs6f> q+
16:18:05 <bigbluehat> ack ajs6f
16:18:16 <azaroth> scribenick: azaroth
16:18:42 <azaroth> ajs6f: Quickly agree and emphasize that if we do that, we're making a change to treat scoped contexts differently from others
16:18:45 <azaroth> ... that's a big thing!
16:19:01 <azaroth> ... suddenly changes a lot of implementations. So should be very concious of what we're doing.
16:19:02 <gkellogg> q+
16:19:05 <bigbluehat> ack gkellogg
16:19:09 <azaroth> scribenick: ajs6f
16:19:26 <ajs6f> gkellogg: is also worth revisiting the idea of multiple aliases on keywords
16:19:51 <bigbluehat> q+
16:19:53 <bigbluehat> ack bigbluehat
16:19:57 <ajs6f> gkellogg: its a judgement call-- relaxing doesn't introduce incompatibility with 1.0
16:20:21 <ajs6f> ... 1.0 has a prohibition on multiple aliases to keywords
16:20:35 <ajs6f> ... if we relax that, we aren't invalidating any extant 1.0 material
16:20:49 <ajs6f> ... we're just not complaining in places where we previoiusly would have
16:21:01 <ajs6f> azaroth: why was the restriction introduced to begin with?
16:21:35 <ajs6f> gkellogg: It's gone out of my head why, at the moment
16:21:59 <ajs6f> ... was really thinking about the @type container @set use case
16:22:08 <azaroth> q+
16:22:09 <ajs6f> bigbluehat: give this a bit more time?
16:22:14 <bigbluehat> ack ajs6f
16:22:16 <bigbluehat> ack azaroth
16:22:45 <ajs6f> azaroth: shall we get in touch with the original issue creator and ask whwether scoped aliases would solve his problem?
16:22:54 <ajs6f> s/whwether/whether
16:23:03 <ajs6f> ... unless someone else knows of use cases for this issue?
16:23:49 <azaroth> PROPOSAL: Propose scoped contexts as solution to original use case and determine if that is sufficient
16:23:53 <workergnome> +1
16:23:54 <azaroth> +1
16:23:58 <ajs6f> +1
16:24:00 <bigbluehat> +1
16:24:01 <ivan> +1
16:24:04 <gkellogg> +1
16:24:14 <ajs6f> bigbluehat: lots of these issues have a lot of history
16:24:21 <ajs6f> bigbluehat: okay to delve into that
16:24:37 <ajs6f> bigbluehat: don't be afraid to stop the bus to make sure everyone is still on baord
16:24:42 <ajs6f> s/baord/board
16:24:43 <dlehn> +1
16:24:48 <simonstey> +1
16:24:50 <jeff_mixter> +1
16:24:50 <azaroth> RESOLVED: Propose scoped contexts as solution to original use case and determine if that is sufficient
16:24:58 <bigbluehat> SUBTOPIC: @type as @container:@set? https://github.com/w3c/json-ld-syntax/issues/34
16:25:14 <ivan> link: https://github.com/w3c/json-ld-syntax/issues/34
16:25:29 <ajs6f> gkellogg: this was a reason to allow repeated aliasing for keywords
16:25:38 <ajs6f> ... in this case to alias the keyword @type
16:25:43 <workergnome> q+
16:25:53 <ajs6f> ... not to change its identity, just the container treatment
16:26:11 <ajs6f> ... e.g. to @set. Of course, some values wouldn't be valid here, like @list
16:26:26 <ajs6f> ... might want to constrain that. shouldn't be a problem with other keywords
16:26:37 <azaroth> q+ to explain surface syntax use case
16:26:43 <bigbluehat> ack workergnome
16:26:59 <ajs6f> workergnome: examples for both @type and @context are useful
16:27:18 <ajs6f> ... we hit this while trying to support objects that are both IIIF and CIDOC/CRM
16:27:34 <ajs6f> ... objects with multiple rdf:types
16:27:47 <bigbluehat> CIDOC/CRM - http://www.cidoc-crm.org/
16:27:49 <ajs6f> ... then our documentation gets very complex to account for multiple possible shapes.
16:28:06 <bigbluehat> IIIF - http://iiif.io/
16:28:14 <ajs6f> ... the processor has to look for both a string or an array
16:28:17 <bigbluehat> q?
16:28:19 <bigbluehat> ack ajs6f
16:28:20 <azaroth> You can't compact to:   "@type": ["Manifest"]  or "@context": ["http://iiif.io/api/presentation/2/context.json"]
16:28:22 <bigbluehat> ack azaroth
16:28:22 <Zakim> azaroth, you wanted to explain surface syntax use case
16:28:23 <ajs6f> ... so this would make that work easier
16:28:46 <ajs6f> azaroth: basically, you can't compact to @type as a single item in a list
16:28:58 <bigbluehat> q+ to ask about API level configs
16:29:20 <ajs6f> ... having the capacity for both @context and @type would be valuable
16:29:27 <ivan> q+
16:29:33 <bigbluehat> ack bigbluehat
16:29:33 <Zakim> bigbluehat, you wanted to ask about API level configs
16:29:36 <ajs6f> ... seems very reasonable for @type
16:29:57 <ajs6f> bigbluehat: there is a config option for at least some JSON-LD processors to force things into an array when compacted
16:30:05 <azaroth> q+
16:30:11 <bigbluehat> ack ivan
16:30:15 <ajs6f> ... could that be brought to an API parsing level, and not a syntactic level
16:30:19 <azaroth> q+ to disagree that it's API level :)
16:30:26 <ajs6f> ivan: feeling a bit lost!
16:31:08 <ajs6f> azaroth: what we're suggesting is not illegal in 1.0, it just can't be compacted to
16:31:22 <gkellogg> q+ to discuss compactArrays option
16:31:23 <ajs6f> ivan: the difficulty here is when compacted, not the original syntax?
16:31:31 <ajs6f> ... an API-level problem
16:31:57 <ajs6f> ... if I have an author who doesn't know or care about the spec, what can she write down than is valid
16:32:04 <ajs6f> s/than/that
16:32:10 <azaroth> q+ to not disagree any more :D
16:32:15 <ajs6f> azaroth: I agree that it is an API problem
16:32:32 <bigbluehat> ack azaroth
16:32:32 <Zakim> azaroth, you wanted to disagree that it's API level :) and to not disagree any more :D
16:32:35 <ajs6f> ivan: mod'ing the context for the purpose of the APIs-- I have a disconnect
16:33:22 <ajs6f> azaroth: the result of the compaction algorithm has a single class in an array
16:33:35 <ajs6f> ... so we are really making @type be consistent with all the others
16:33:52 <ajs6f> ivan: any exceptions that are not justified are WRONG!
16:34:13 <ajs6f> azaroth: again, an API-level thing. you should be able to spec in the syntax which of the two options you want
16:34:26 <azaroth> q?
16:34:32 <ajs6f> ...  it's a question of the compaction algo and how we signal to it which of the two possible things to do
16:34:33 <bigbluehat> ack gkellogg
16:34:33 <Zakim> gkellogg, you wanted to discuss compactArrays option
16:34:40 <gkellogg> compactArrays
16:34:40 <gkellogg> If set to true, the JSON-LD processor replaces arrays with just one element with that element during compaction. If set to false, all arrays will remain arrays even if they have just one element.
16:35:06 <ajs6f> gkellogg: the "compact arrays" option in the API: if set to false, all values will be represented as arrays
16:35:21 <ajs6f> ... don't know if current alogirthms do that for contexts, but arguably they should
16:35:35 <azaroth> q+ to ask about compaction from triples
16:35:36 <bigbluehat> +1 to adding these config options to the playground
16:35:40 <ajs6f> ... playground doesn't expose these options. that's an issue for us to take up with json-ld.org
16:36:27 <ajs6f> ... the reason to set @type as container @set is to make the use of arrays uniform, but if the option compactArrays already handles that
16:36:37 <ajs6f> ... then let's not complicate the algorithms to do the same thing
16:36:41 <azaroth> +1 to considering weight!
16:37:08 <ajs6f> ... wrt to @type vs @context, you cannot alias @context in a JSON-LD for obvious bootstrapping reasons
16:37:16 <bigbluehat> ack azaroth
16:37:16 <Zakim> azaroth, you wanted to ask about compaction from triples
16:38:02 <ajs6f> azaroth: if I have a bunch of triples from (say) a triplestore than describe a single class, can gkellogg explain how to get to JSON-LD with an array of types
16:38:11 <workergnome> \me Are the options required for implementations?
16:38:21 <ajs6f> gkellogg: let's take a single triple, set compactArrays = false, you should get that.
16:38:36 <ajs6f> ... not just for @type, for anything
16:38:52 <bigbluehat> s/\me Are the options required for implementations?//
16:38:54 <ajs6f> azaroth: how does that interact with @container @set
16:38:56 <workergnome> +q
16:39:17 <bigbluehat> ack workergnome
16:39:22 <ajs6f> gkellogg: if compactArrays=true (the default), then it is overridden by @container @set, if false, @container @set is irrelevant
16:39:35 <ajs6f> workergnome: is compactArrays required?
16:39:43 <dlehn> q+
16:39:44 <ajs6f> gkellogg: normative/required
16:39:47 <bigbluehat> q+ to ask about the normativeness of the API
16:39:55 <ajs6f> ... and we have good coverage in the test suite
16:40:11 <ajs6f> ... might be good to do a sweep and make sure we're getting all the combinatorics
16:40:27 <bigbluehat> compaction tests fwiw https://json-ld.org/test-suite/#Compaction
16:40:35 <ajs6f> ... we might not be getting every possible result in an array right now
16:40:39 <azaroth> q+ to ask if anyone has use case for mixed situation
16:40:48 <ajs6f> workergnome: might be good to add more info about API options to the documentation
16:41:02 <ajs6f> ... only ever seen such docs in the docs for given impls.
16:41:12 <ajs6f> ... which could lead people to assume that they are impl-specific
16:41:19 <ajs6f> ... especially since the playground doesn't expose them
16:41:41 <ajs6f> gkellogg: I have a distiller that exposes them, could use that to expose that in the playground
16:41:42 <bigbluehat> ack dlehn
16:42:16 <ajs6f> dlehn: the compactArrays option will cover everything, @type @container @set is much more controllled/specific
16:42:22 <azaroth> compact arrays would prevent: {"property1": "only ever one value", "property2": ["sometimes multiple values"]}
16:42:34 <azaroth> ?
16:42:39 <bigbluehat> ack bigbluehat
16:42:39 <Zakim> bigbluehat, you wanted to ask about the normativeness of the API
16:42:45 <ajs6f> ... as far as options on the playground, been thinking about that but haven't gotten around to it... help wanted!
16:43:11 <ajs6f> bigbluehat: the normativeness of the API has come up e.g. with Activityhub (sp?)
16:43:35 <ajs6f> ... one of the stones thrown in that conversation was that "JSON-LD hasn't got a normative API"
16:43:50 <ajs6f> ... what I found was from the CG specs, and not connected with JSON-LD 1.0
16:44:06 <ajs6f> gkellogg: the WebIDL that describes the API has been part of the docs from the beginnig
16:44:33 <ajs6f> ... the API is written using "promises", which is really a JS-land feature
16:45:43 <ajs6f> ... the processing steps for "compact" first discuss "expanding", which isn't even in that document
16:45:57 <ajs6f> ... anything passing the test suite has to make use of that aspect of the API anyway
16:46:21 <ajs6f> bigbluehat: the "promises" thing also came up in that conversation, so if there's another way...
16:46:35 <ajs6f> gkellogg: It was important that the API could be asynch, previously we tried a callback style
16:47:00 <ajs6f> ... the API has always been very JS-centric. believe that to be true of all WebIDL use at W3C
16:47:02 <bigbluehat> q?
16:47:06 <bigbluehat> ack azaroth
16:47:06 <Zakim> azaroth, you wanted to ask if anyone has use case for mixed situation
16:48:13 <ajs6f> azaroth: when I first tried to do the #type stuff, I tried to use compactArrays, but when some values can be 1 or more, and some can be 0..1, compactArrays make them all into arrays
16:48:22 <ajs6f> ... which is not what was wanted a
16:48:33 <gkellogg> q+
16:48:35 <bigbluehat> ack gkellogg
16:48:37 <ajs6f> ... so there is still a use case here, in spite of compactArrays
16:49:10 <ajs6f> gkellogg: would support a narrowly-worded resultion that specifically allows aliases for @type, for which the only thing that can be set is @container and the only value
16:49:17 <ajs6f> ... to which it could be set would be @set.
16:49:29 <ajs6f> ... and an alias of that type would have the same restricitons
16:49:43 <ajs6f> azaroth: that meets the use case without overstepping
16:49:52 <azaroth> PROPOSAL:  @type (or an alias of it) can be set to be only a @container, and have only the value of @set
16:49:57 <bigbluehat> +1
16:49:57 <workergnome> +1
16:49:58 <azaroth> +1
16:50:01 <gkellogg> +1
16:50:02 <ivan> +1
16:50:02 <jeff_mixter> +1
16:50:02 <dlehn> +1
16:50:39 <azaroth> RESOLVED:  @type (or an alias of it) can be set to be only a @container, and have only the value of @set
16:50:39 <ajs6f> ivan: need to close off the question for @context
16:50:57 <azaroth> PROPOSAL: @context will not be changed to allow specification of being always an array
16:50:59 <azaroth> +1
16:50:59 <ajs6f> ... @context is so different from anything else...
16:51:03 <ivan> +1
16:51:05 <gkellogg> +1
16:51:05 <simonstey> +1
16:51:06 <bigbluehat> +1
16:51:07 <ajs6f> ... would be very dangerous to touch it
16:51:14 <ajs6f> +1
16:51:19 <workergnome> +1
16:51:34 <azaroth> RESOLVED: @context will not be changed to allow specification of being always an array
16:51:40 <dlehn> +1 but fine to reraise issue if there are good use cases
16:52:07 <ajs6f> ivan: yes, we can reopen
16:52:09 <bigbluehat> SUBTOPIC: Allow processing model of @type to be customized #7
16:52:16 <bigbluehat> https://github.com/w3c/json-ld-api/issues/7
16:52:57 <ajs6f> gkellogg: @type is different, has a different processing model
16:53:19 <ajs6f> ... some complaints about this, requests to change that so that @type uses a diff processing model
16:53:29 <azaroth> +1 to wontfix
16:54:02 <bigbluehat> Chair: azaroth
16:54:12 <ajs6f> azaroth: original issue has an example of what happens now
16:55:21 <ajs6f> azaroth: is there an ambiguity here?
16:55:47 <ajs6f> gkellogg: if you are expanding a bare word "foo", how you expand depends on the presence of an @vocab
16:55:57 <ajs6f> ... but not @type
16:56:10 <ajs6f> ... it being common to define types themselves within the document
16:56:20 <ajs6f> ... so relative IRIs are really useful there
16:56:45 <ajs6f> ... how to process @type is defined by the spec itself, not by the context of a given doc
16:57:02 <ajs6f> ... opening that up could introduce injection attacks via the context,
16:58:32 <ajs6f> azaroth: the result that the original requestor wanted, could be done by taking out @vocab and defining individual entries
16:58:38 <ajs6f> ... they just want to shorten that up
16:58:48 <ajs6f> gkellogg: yep, and could also be done via scoped contexts
16:58:51 <azaroth> q?
16:59:25 <ajs6f> q+
16:59:30 <azaroth> ack ajs6f
16:59:43 <azaroth> scribenick: azaroth
16:59:54 <azaroth> ajs6f: If we do this, we need to offer various solutions in examples in the specs
17:00:01 <azaroth> gkellogg: A best practices document
17:00:04 <azaroth> ajs6f: Exactly! :)
17:00:08 <azaroth> scribenick: ajs6f
17:00:11 <azaroth> q?
17:00:54 <azaroth> PROPOSAL: close #7 wontfix, as the use case can be accomplished with longer, scoped contexts and the precedence has other ramifications
17:00:56 <gkellogg> +1
17:00:57 <simonstey> +1
17:00:58 <azaroth> +1
17:01:01 <ivan> +1
17:01:01 <dlehn> +1
17:01:01 <jeff_mixter> +1
17:01:03 <ajs6f> +!
17:01:10 <ajs6f> s/+!/+1
17:01:42 <workergnome_> workergnome_ has joined #json-ld
17:01:54 <workergnome_> +1
17:01:59 <azaroth> RESOLVED: close #7 wontfix, as the use case can be accomplished with longer, scoped contexts and the precedence has other ramifications
17:02:33 <azaroth> https://waffle.io/w3c/json-ld-wg
17:02:45 <ivan> rrsagent, draft minutes
17:02:45 <RRSAgent> I have made the request to generate https://www.w3.org/2018/08/17-json-ld-minutes.html ivan