15:12:05 <RRSAgent> RRSAgent has joined #json-ld
15:12:05 <RRSAgent> logging to https://www.w3.org/2019/03/15-json-ld-irc
15:12:06 <ivan> rrsagent, set log public
15:12:06 <ivan> Meeting: JSON-LD Working Group Telco
15:12:06 <ivan> Chair: azaroth
15:12:06 <ivan> Date: 2019-03-15
15:12:06 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0028.html
15:12:06 <ivan> ivan has changed the topic to: Meeting Agenda 2019-03-15: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0028.html
15:12:07 <ivan> Regrets+ workergnome, tole
15:12:07 <ivan> Guests+ Kazuyuki_Ashimura, Victor_Charpenay
15:42:39 <ajs6f> ajs6f has joined #json-ld
15:43:35 <rubensworks> rubensworks has joined #json-ld
15:54:48 <kaz-win> kaz-win has joined #json-ld
15:56:16 <azaroth> azaroth has joined #json-ld
15:59:04 <pchampin> pchampin has joined #json-ld
15:59:55 <bigbluehat> present+
16:00:47 <ajs6f> present+
16:00:51 <azaroth> present+ Rob_Sanderson
16:00:54 <gkellogg> gkellogg has joined #json-ld
16:01:00 <rubensworks> present+
16:01:01 <pchampin> present+
16:02:05 <dlongley> present+
16:02:17 <ajs6f> scribenick: ajs6f
16:02:25 <dlehn> present+
16:02:26 <gkellogg> present+
16:02:32 <victor> victor has joined #json-ld
16:03:22 <ajs6f> topic: announcements
16:03:33 <ajs6f> azaroth: DST is upon us, and the call is based on time in Boston, US
16:03:50 <ajs6f> topic: The Berlin graph data workshop
16:03:58 <ivan> present+
16:04:13 <ajs6f> gkellogg: three tracks, diffrent attendance at all
16:04:18 <ajs6f> ... general sense of JSON-LD's importance
16:04:51 <ivan> scribenick, set kaz-win Kazuyuki Ashimura
16:04:59 <ajs6f> ... general acclamation for Olag Hartvig's RDF* (and SPARQL*)
16:05:02 <pchampin> rdf* paper: http://olafhartig.de/files/Hartig_AMW2017_RDFStar.pdf
16:05:11 <ivan> scribejs, set kaz-win Kazuyuki Ashimura
16:05:31 <ajs6f> ... Blazegraph, Neo4j, others implement this
16:05:34 <hsolbrig> hsolbrig has joined #json-ld
16:06:02 <ajs6f> ... a syntax for reification in JSON-LD might work better
16:06:07 <ivan> s/Hartvig/Hartig/
16:06:08 <ajs6f> ... perhaps work for the CG
16:06:27 <ajs6f> ... moves to create a W3C Business Group for this effort
16:06:40 <pchampin> s/Neo4j/Stardog/
16:06:41 <ajs6f> ... which can hopefully draw in some vendors of property graph systems
16:07:18 <ajs6f> ivan: we could have ended with a dog fight between us and property graph people
16:07:28 <ajs6f> ... remember the fightds with Topic Maps folks?
16:07:42 <ajs6f> ... but that didn't happen. Much good will instead and desire for cooperation
16:07:58 <ajs6f> ... JSON-LD clearly considered to be an important player
16:08:09 <ajs6f> ... how that could converge with PG? we shall see.
16:08:35 <ajs6f> pchampin: agreed with gkellogg and ivan
16:08:53 <hsolbrig> present+
16:08:59 <ivan> present+ bigbluehat
16:09:13 <ajs6f> azaroth: other announcements?
16:09:26 <ajs6f> topic: TPAC in Japan
16:09:41 <ajs6f> azaroth: we intend to be in CR before TPAC
16:09:54 <ajs6f> ... so do folks think a F2F @ TPAC would be valuable?
16:10:17 <ajs6f> ... Japan is a long way for many participants, so expensive, but we would need a reaonable number of attendees
16:10:41 <ajs6f> ... but then, people need longer lead time for farther travel
16:10:42 <ivan> +1
16:10:45 <azaroth> +1
16:10:49 <hsolbrig> -1
16:10:56 <pchampin> +0
16:10:56 <gkellogg> +1, but some form of funding would help!
16:10:59 <rubensworks> +0
16:11:08 <ajs6f> +0 (hard to say, given all the things that could happen to the Federal gov't between now and then)
16:11:09 <bigbluehat> +1 (certainly if other groups I'm in are meeting)
16:11:18 <jeff_mixter> jeff_mixter has joined #json-ld
16:11:24 <jeff_mixter> present+
16:11:30 <dlongley> -0.5 (more likely not)
16:11:42 <dlehn> -0.5
16:11:48 <jeff_mixter> -1
16:11:56 <ivan> zakim, who is here?
16:11:56 <Zakim> Present: bigbluehat, ajs6f, Rob_Sanderson, rubensworks, pchampin, dlongley, dlehn, gkellogg, ivan, hsolbrig, jeff_mixter
16:11:59 <Zakim> On IRC I see jeff_mixter, hsolbrig, victor, gkellogg, pchampin, azaroth, kaz-win, rubensworks, ajs6f, RRSAgent, Zakim, ivan, cwebber2, hober, dlongley, dlehn, ChristopherA,
16:11:59 <Zakim> ... bigbluehat
16:12:30 <ajs6f> azaroth: probably below zero total
16:12:35 <ivan> guests+ kaz-win
16:12:37 <ajs6f> ... would it be valuable to meet in Japan at all?
16:12:42 <ajs6f> ... since we intend to be in CR.
16:12:44 <bigbluehat> q+
16:12:51 <ajs6f> -0.5
16:12:52 <kaz> kaz has joined #json-ld
16:12:52 <azaroth> ack bigbluehat
16:12:57 <gkellogg> q+
16:13:07 <azaroth> +0
16:13:16 <ivan> +1
16:13:31 <kaz-win> present+ Kaz
16:13:38 <ajs6f> bigbluehat: besides our own plans, we have groups from which we need horizontal review
16:13:42 <ajs6f> ... e.g. WoT
16:13:48 <ivan> scribejs, set victor Victor Charpenay
16:13:53 <ajs6f> ... so some people have multiple groups to attend
16:13:53 <ivan> guests+ victor
16:14:07 <ajs6f> ... then there's the question of whether we can effectively rep JSON-LD to other groups
16:14:18 <ajs6f> azaroth: yes, that's a separate question
16:14:23 <azaroth> q?
16:14:24 <azaroth> ack gkellogg
16:14:31 <ajs6f> ... we certainly do need representation there, but do we need a full-on meeting?
16:14:38 <bigbluehat> +0 wrt to CR...since we can't do much without our WG's membership
16:15:14 <ajs6f> gkellogg: 1) CR doesn't mean we're done.
16:15:27 <ajs6f> ... and we have other docs for which we are responsible
16:15:41 <azaroth> +1 to gkellogg
16:15:50 <ajs6f> ... and for the purposes of reserving space, we could indicate that we intend to meet, at least at this early stage
16:16:23 <ajs6f> azaroth: how about we put in a "YES", assuming that all the +0s will attend
16:16:35 <ajs6f> ... then we have the space if we need it
16:16:36 <ivan> +1
16:16:39 <ajs6f> +1
16:16:41 <jeff_mixter> +1
16:16:43 <pchampin> +1
16:16:44 <gkellogg> +1
16:16:44 <hsolbrig> +1
16:16:49 <bigbluehat> +1
16:17:37 <ajs6f> topic: issues
16:17:42 <azaroth> link: https://github.com/w3c/json-ld-api/issues/65
16:18:13 <ajs6f> gkellogg: might we briefly discuss framing issue 41 "embed first"?
16:18:33 <ajs6f> azaroth: okay, five minutes for that
16:18:36 <dlongley> https://github.com/w3c/json-ld-framing/issues/43 <-- i think it's this one?
16:18:41 <ivan> Subtopic: `@embed` `@first` issue
16:19:29 <ajs6f> gkellogg: implemented as well as accompanied by tests
16:19:35 <ajs6f> ... seems straightforward
16:20:02 <dlongley> or "@once" (which is a historical name)
16:20:19 <ajs6f> ... another alternative would be to remove first and last and go back to all or none
16:20:30 <dlongley> q+
16:20:35 <azaroth> ack dlongley
16:20:52 <ajs6f> dlongley: there is an important use case for having at least one of @first or @last
16:21:06 <ajs6f> ... frame docs where you don't care where something appears but it must appear
16:21:17 <ajs6f> ... or certain properties must appear in certain places
16:21:27 <ajs6f> ... histroically the name for this was @once
16:21:46 <ajs6f> ... the change was mostly for testing purposes
16:21:49 <ivan> q+
16:21:53 <azaroth> ack ivan
16:22:20 <ajs6f> ivan: I feel uneasy that we are talking about order in an environment that doesn't inherently have order
16:22:29 <ajs6f> gkellogg: that's why the alogirthms do ordering
16:22:41 <ajs6f> ivan: from the user POV they have to know about the algorithms
16:23:01 <ajs6f> ... which is not ideal, but i'm not objecting, just sharing uneasiness
16:23:23 <ajs6f> ivan: can we push this to next week? It's more than five minutes of talk.
16:23:53 <ajs6f> gkellogg: ivan's comment is not about this specific PR, but about the general point
16:24:12 <dlongley> +1
16:24:18 <ivan> Subtopic: RDF Deserialization and `@index`
16:24:22 <ajs6f> ... the existence of @last implies an @first, but the real question is should we be implying ordering at all
16:24:28 <bigbluehat> https://github.com/w3c/json-ld-api/issues/65
16:24:36 <ivan> 	link: https://github.com/w3c/json-ld-api/issues/65
16:25:06 <ajs6f> victor: not much to add to the ticket
16:25:27 <ajs6f> victor: we are working on a Thing Description which is intended to be JSON-LD
16:25:43 <ajs6f> ... espeically with respect to transformation into RDF
16:25:55 <ajs6f> ... in the TD document, we make heavy us of @index
16:26:16 <kaz> -> https://w3c.github.io/wot-thing-description/#note-jsonld10-processing WoT Thing Description - Transformation to JSON-LD&RDF
16:26:39 <ajs6f> ... we want to be able to use SPARQL against the data, or roundtrip it
16:26:55 <ajs6f> ... the intention of the issue is to keep the indexed values in some way
16:27:08 <ajs6f> ... the activity on this issue is appreciated
16:27:15 <ajs6f> azaroth: to summarize the proposals:
16:27:25 <ajs6f> ... indexing by id is one potential solution
16:27:43 <ajs6f> ... but it's possible for a term to be used in different ways within the same document
16:28:05 <ajs6f> victor: and that's not a theoretical problem. we had that real problem as we implemented
16:28:17 <ajs6f> ... oracle ran into this problem in building an API
16:28:42 <ajs6f> azaroth: another proposal; use a property within the graph like "indexkey" to maintain the info
16:28:52 <ajs6f> ... which would afford some degree for roundtripping
16:29:11 <ajs6f> ... and then a lot of discussion about hwich way to go
16:29:46 <ajs6f> gkellogg: i originally thought we might allow an arbitrary IRI to be used in @container, which would have allowed arbitrary indexing
16:30:30 <ajs6f> ... but pchamplain suggested we reuse @index
16:30:43 <pchampin> s/pchamplain/pchampin/
16:30:57 <pchampin> q+
16:31:08 <ivan> q+
16:31:10 <azaroth> ack pchampin
16:31:12 <dlongley> +1 for "light touch" solutions
16:31:41 <ajs6f> pchampin: my concern is that compaction would be more complex, but I know realize that gkellogg could speak to this
16:32:16 <ajs6f> ... would it make a big change if we just looked for a specific property for indexing, and not an arbitrary one
16:33:07 <ajs6f> gkellogg: I think it's similar enogh to what we're already doing with types to not be, but we'd have to try to be sure. E.g. what if it's a node obejct vs. a value object?
16:33:24 <ajs6f> victor: isn't that dealt with in the compaction algo?
16:33:54 <ajs6f> gkellogg: literals become value objects, everything with an id becomes a node object
16:34:21 <bigbluehat> https://w3c.github.io/json-ld-syntax/#dfn-node-object vs. https://w3c.github.io/json-ld-syntax/#dfn-value-object
16:34:33 <azaroth> q?
16:34:37 <azaroth> ack ivan
16:34:37 <dlongley> error if there is no "simple value"
16:34:40 <ajs6f> ... so you could lose other aspects (language, etc.)
16:34:52 <ajs6f> ivan: I come to this as a user
16:34:54 <azaroth> q+ to ask about `properties` and `@nest`
16:35:14 <ajs6f> ... I am in favor of pchampin's proposal because the other one would make this automatic
16:35:20 <ajs6f> ... whether or not I want it
16:35:40 <ajs6f> ... but pchampin's idea makes the creator make this thing explicit
16:35:50 <ajs6f> ... in this case, that's better and cleaner
16:36:12 <ajs6f> ... provided that the extra work is oaky by WoT
16:36:21 <dlongley> +1 to pchampin's approach as well (more natural, no extra artifacts)
16:36:31 <azaroth> ack azaroth
16:36:31 <Zakim> azaroth, you wanted to ask about `properties` and `@nest`
16:36:38 <ajs6f> victor: yes, to use pchampin's approach we just create a new predicate
16:36:44 <dlongley> and doesn't break RDF canonicalization/signature/hashing issues.
16:37:11 <ajs6f> azaroth: do properties of this kind have semantics?
16:37:20 <ajs6f> ... or can we encode them using @nest?
16:37:35 <ajs6f> ... which gives us JSON structure but adds no RDF/graph structure
16:37:52 <ajs6f> victor: a constant effort in the WG has been to make everything linkable
16:38:19 <ajs6f> ... so the property shoul be representatble in something (RDF?)
16:39:43 <ajs6f> victor: a Thing Description should be serializable in RDF
16:39:46 <jeff_mixter> +1 to Rob's concern about what the semantics of the properties in relation to the Thing
16:39:54 <ajs6f> ... everything should be kept, nothing should be "pure JSON"
16:39:55 <pchampin> q?
16:39:57 <pchampin> q+
16:40:00 <jeff_mixter> q+
16:40:07 <ajs6f> ivan: so @nest is not usable?
16:40:10 <ajs6f> victor: correct
16:40:24 <ajs6f> azaroth: in the ontology, what is the range of "properties"
16:40:38 <ajs6f> victor: a singular "propertaffordance"
16:41:03 <ajs6f> ... ths is _NOT_ a representation of the properties of th thing descrivbed
16:41:28 <bigbluehat> q+
16:41:36 <ajs6f> azaorth: so a Thing Desc could have separate properties/predicates/values, each of which has the same key, and each could have diff meanings?
16:41:40 <ajs6f> victor: structurally that's not possible
16:41:48 <bigbluehat> https://w3c.github.io/wot-thing-description/#property-serialization-json
16:41:49 <ajs6f> ... because each key should point to an object
16:42:00 <ajs6f> ... but in RDF, yes, that would be possible
16:42:02 <azaroth> q?
16:42:11 <ajs6f> ... and we want to keep the relationship with RDF
16:42:16 <azaroth> ack pchampin
16:42:33 <bigbluehat> q-
16:42:56 <ajs6f> pchampin: following on azaroth's idea, would it make sense to say that temperature and on/off resolves to _predicates_ that are subclasses of "property"?
16:43:13 <ajs6f> ... so that some kind of inference would provide the affordance?
16:43:14 <azaroth> q?
16:43:16 <azaroth> ack jeff_mixter
16:43:21 <ajs6f> ... becaues my gut tells me that @nest is a good candidate here
16:43:22 <jeff_mixter> q-
16:43:27 <azaroth> q?
16:44:02 <ajs6f> bigbluehat: the WoT is based in part on JSON Schema, so if we solve for this, we solve for the growing list of JSON Schema-based specs
16:44:16 <ajs6f> ... including OpenAPI, which brings a flock of JSON APIs specified in that way
16:44:22 <ajs6f> ... lots of collateral value
16:44:37 <ajs6f> victor: in fact we  intend to publish a vocab for describing JSON Schemas in RDF
16:45:08 <ajs6f> azaorth: are there properties of the blank node that is the propertiy's property's that would confliuct with property's of the thing itelsef
16:45:53 <ajs6f> victor: you are suggesting to take the intermediate object as an individual
16:46:13 <ajs6f> azaroth: yes. I'm trying to explore if there's a reason that "properties" itself needs to be in there
16:46:30 <ajs6f> victor: there is more tio the Thing Desc. there are actions, there are events
16:46:34 <ajs6f> ... they cannot be merged
16:46:39 <ajs6f> ... into the root object
16:46:40 <azaroth> q?
16:46:48 <ajs6f> ... conflicting keys would result
16:47:03 <ajs6f> azaroth: e.g. an on/off action could be distringuished
16:47:09 <ajs6f> victor: yes
16:47:22 <pchampin> which is also a good reason not to use it as an @id map :)
16:47:35 <ajs6f> azaroth: so we can't use @nest? should we run with pchampin's suggestion?
16:47:38 <ajs6f> ... thoughts?
16:47:39 <bigbluehat> q+
16:47:42 <azaroth> ack bigbluehat
16:47:46 <gkellogg> q+
16:47:54 <ajs6f> bigbluehat: the return trip from RDF is inhibited
16:47:59 <ivan> +1 to bigbluehat
16:48:05 <ajs6f> ... @nest would mean that you've lost that properties space
16:48:13 <azaroth> ack gkellogg
16:48:13 <ajs6f> ... you'd have to sort that out outside the compaction algo
16:48:36 <ajs6f> gkellogg: @nest, becaus it has no semantics, can't be used here
16:48:49 <ajs6f> ... so we're back to indexing arbitrary properties, and pchampin's idea is the cleanest
16:48:53 <ivan> q+
16:48:55 <azaroth> ack ivan
16:49:07 <ajs6f> ivan: all in favor of pchampin's idea
16:49:15 <ajs6f> ... but let me throw in some bikeshedding
16:49:29 <ajs6f> ... should we use the syntax as proposed or not?/
16:49:45 <azaroth> q?
16:49:45 <ajs6f> ... we may have to look at whether we need a fresh keyword
16:49:46 <pchampin> I really don't see how it is misleading... but we can discuss this later, definitely :)
16:50:02 <gkellogg> I don’t think it’s misleading, either.
16:50:08 <ajs6f> azaroth: pchampin, will you make a proposal?
16:51:34 <ajs6f> pchampin: I propose adding a new keyword in the term dfns to be used with @container : @index to be used to specifiy an arbitrary property on which to index
16:51:38 <azaroth> PROPOSAL: Add a new keyword to be used with `@container:@index` to indicate the property to use instead of `@index` to solve WoT request
16:51:44 <azaroth> +1
16:51:45 <dlongley> +1
16:51:47 <ajs6f> +1
16:51:48 <jeff_mixter> +1
16:51:48 <gkellogg> +1
16:51:49 <hsolbrig> +1
16:51:50 <ivan> +1
16:51:50 <rubensworks> +1
16:51:53 <pchampin> +1
16:51:59 <bigbluehat> +
16:52:01 <bigbluehat> +1
16:52:15 <dlehn> +1
16:52:18 <azaroth> RESOLVED: Add a new keyword to be used with `@container:@index` to indicate the property to use instead of `@index` to solve WoT request
16:52:35 <ivan> q+
16:52:39 <azaroth> ack ivan
16:52:45 <victor> q+
16:52:58 <ajs6f> ivan: q to kaz and victor: is this the only prob you ahve for us?
16:52:59 <azaroth> ack victor
16:53:05 <ajs6f> kaz: great question!
16:53:22 <ajs6f> ... I was thining abot this several hours ago on the call
16:53:37 <ajs6f> ... if we clarify this point, there should be no big problems
16:53:51 <ajs6f> ... this discussion was really, REALLY, ___REALLY___ appreciated
16:54:07 <ajs6f> ivan: I aked because we are planning to feature-freeze in two weeks
16:54:15 <ajs6f> ... so if there are other issues, we need them now!
16:54:30 <azaroth> ack victor-for-real-this-time
16:55:03 <ajs6f> victor: sebastian made some slides to summarize, one is scoped contexts
16:55:15 <ajs6f> ivan: that's an integral part of our work
16:55:37 <ajs6f> victor: the other one was this feature we just discussed (indexing)
16:56:01 <ajs6f> ... we can do something ad hoc until something apears in draft
16:56:03 <ivan> q+
16:56:08 <azaroth> ack ivan
16:56:10 <ajs6f> ... it's not blocking us from releasing specs
16:56:27 <ajs6f> ivan: what's the timing?
16:56:30 <ajs6f> kaz: right
16:56:54 <ajs6f> ivan: what seems to work with the director is that if we as a WG make it clear that these features are stable
16:57:03 <ajs6f> ... so they won't change out from udner you
16:57:13 <ajs6f> ... we can do that, but we need to know when you need that
16:57:28 <ajs6f> kaz: WG charter goes to the end of June
16:57:58 <ajs6f> ... we wanted a CR by the ehdnf of March, but that's not possible, so maybe April?
16:58:04 <ivan> q+
16:58:07 <ajs6f> ... that's our timeline
16:58:09 <azaroth> ack ivan
16:58:31 <ajs6f> ivan: so from our (JSON-LDs) POV, the scoped context is in the draft, has been there for a long time
16:58:43 <ajs6f> ... it would be good if this new feature gets into the draft soon
16:58:55 <ajs6f> ... pchampin, how much work does this need?
16:59:01 <ajs6f> ... to get it to DR?
16:59:31 <ajs6f> kaz: if you can update your draft based on this dicussion, that would be great
16:59:56 <ajs6f> pchampin: I could have a shot at the syntax doc by the end of next week
16:59:59 <ajs6f> kaz: sounds fine!
17:00:18 <ajs6f> pchampin: I'm not as comfortable with the API doc yet, so that might take a bit longer
17:00:34 <ajs6f> kaz: I appreciate JSON-LD WG's help!
17:00:49 <ajs6f> ... thank you!
17:01:03 <ajs6f> azaorth: you are welcome and thanks to kaz an victor for coming!
17:01:05 <rubensworks> Sure, no problem azaroth!
17:01:58 <ivan> rrsagent, draft minutes
17:01:58 <RRSAgent> I have made the request to generate https://www.w3.org/2019/03/15-json-ld-minutes.html ivan