15:04:58 <RRSAgent> RRSAgent has joined #json-ld
15:04:58 <RRSAgent> logging to https://www.w3.org/2018/10/05-json-ld-irc
15:04:59 <ivan> rrsagent, set log public
15:04:59 <ivan> Meeting: JSON-LD Working Group Telco
15:04:59 <ivan> Chair: azaroth42
15:04:59 <ivan> Date: 2018-10-05
15:04:59 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Oct/0001.html
15:04:59 <ivan> ivan has changed the topic to: Meeting Agenda 2018-10-05: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Oct/0001.html
15:45:55 <azaroth> azaroth has joined #json-ld
15:50:35 <ajs6f> ajs6f has joined #json-ld
15:53:44 <azaroth> present+ Rob_Sanderson
15:54:45 <simonstey> simonstey has joined #json-ld
15:57:02 <bigbluehat> present+ Benjamin_Young
15:57:12 <bigbluehat> Chair: bigbluehat
15:57:54 <simonstey> present+
16:00:10 <timCole> timCole has joined #json-ld
16:01:04 <gkellogg> present+ Gregg_Kellogg
16:01:40 <ajs6f> present+
16:02:57 <ivan> present+
16:03:23 <timCole> present+ Tim_Cole
16:03:27 <bigbluehat> scribenick: timCole
16:03:40 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-28-json-ld
16:03:42 <timCole> Topic: Minutes approval
16:04:00 <timCole> bigbluehat: any objections to the minutes as drafted?
16:04:23 <azaroth> PROPOSAL:  Approve minutes of last call (https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-28-json-ld)
16:04:24 <ajs6f> +1
16:04:25 <azaroth> +1
16:04:26 <timCole> +1
16:04:26 <bigbluehat> +1
16:04:29 <ivan> +1
16:04:32 <simonstey> +1
16:04:38 <azaroth> RESOLVED  Approve minutes of last call (https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-28-json-ld)
16:04:43 <azaroth> RESOLVED:  Approve minutes of last call (https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-28-json-ld)
16:04:46 <timCole> Topic: TPAC Reminder
16:04:54 <ivan> q+
16:05:14 <timCole> bigbluehat: Agenda in progress in Google Doc
16:05:16 <azaroth> q+ for tpac joint session update
16:05:16 <bigbluehat> ack ivan
16:05:21 <bigbluehat> https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#
16:05:50 <timCole> ivan: most important item, there will be a list from organizers for evening dinners.
16:06:11 <timCole> ... conference center a little distance from center of town
16:06:40 <timCole> bigbluehat: there's a spot in Google Doc for suggesting dinner location
16:06:49 <timCole> ... on Thursday
16:07:02 <azaroth> q?
16:07:03 <jeff_mixter> jeff_mixter has joined #json-ld
16:07:07 <jeff_mixter> present+
16:07:30 <timCole> ivan: just to be sure everyone got it, I have created WebEx details for remote
16:07:44 <bigbluehat> ack azaroth
16:07:44 <Zakim> azaroth, you wanted to discuss tpac joint session update
16:07:44 <timCole> ... do not put the WebEx details out publicly
16:07:45 <azaroth> ack azaroth
16:08:30 <timCole> azaroth: I have reached out to Manu and Dan B., Manu is tied up, but suggested Dave Longley will be his proxy in json-ld 1.1 discussions
16:08:59 <timCole> ... Data Exchange WG has profile negotiation within their charter. We will talk that topic at 1:30 on Friday
16:09:08 <ivan> q+
16:09:16 <timCole> ... 3 or 4 reps from Data Exchange will join us for this discussion
16:09:25 <timCole> ... will ping Dan B. again
16:09:37 <timCole> ... are there other groups we should try to interface with?
16:10:00 <timCole> bigbluehat: Web of Things group?  or maybe that's more informal?
16:10:04 <azaroth> ack ivan
16:10:37 <timCole> ivan: publishing WG is m-tu, group is json-ld and schema.org for WP manifest
16:11:19 <timCole> ... could be a significant use case. So if any from this group want to / are available to join Publishing WG sessions, might be useful
16:11:42 <timCole> gkellogg: Will likely spend time at Pub WG
16:11:46 <timCole> Topic: Issues
16:11:58 <bigbluehat> ack gkellogg
16:12:18 <timCole> gkellogg: Can we first get update on continuous publication?
16:12:37 <timCole> ivan: it will be a token per document, and it's on my calendar for Monday
16:13:23 <timCole> azaroth: today we will revisit some issues previously discussed but still open
16:13:31 <azaroth> SUBTOPIC: Infinite @reverse framing recursion (Gregg's findings)
16:13:45 <azaroth> link: https://github.com/w3c/json-ld-framing/issues/5
16:14:32 <timCole> gkellogg: raises question about framing design criteria
16:14:45 <timCole> ... if there is no frame to be matched, algo constructs one
16:15:25 <timCole> ... so if you have something that infinitely recurses on @reverse, would mean a change to algo
16:15:32 <gkellogg> https://github.com/w3c/json-ld-framing/issues/5#issuecomment-426846317
16:15:52 <timCole> ... solution suggested in my latest comment is to use frame as really intended
16:16:11 <timCole> ... you would create necessary children finitely
16:16:37 <timCole> azaroth: does this mean it works any differently for @reverse?
16:17:09 <timCole> gkellogg: not really. In the absence of a property in the reverse it would create it.
16:17:45 <azaroth> q?
16:17:55 <timCole> azaroth: so if wanted to be explicit in the non-reverse direction you would just ???
16:18:22 <timCole> gkellogg: no change, but describe behavior / example in primer
16:18:45 <timCole> azaroth: questions?
16:18:50 <azaroth> s/???/include them explicitly in the frame, the same as for @reverse/
16:19:24 <timCole> ... if not, how do we want to resolve? example in spec or note in primer?
16:19:30 <bigbluehat> q+
16:19:34 <azaroth> ack bigbluehat
16:20:05 <timCole> bigbluehat: willing to take a crack at what should go into primer
16:20:25 <timCole> ajs6f: agree
16:20:41 <timCole> azaroth: a note in the spec and then a longer discussion in primer?
16:21:00 <azaroth> PROPOSAL: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document
16:21:25 <azaroth> PROPOSAL: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion
16:21:26 <gkellogg> +1
16:21:29 <azaroth> +1
16:21:30 <bigbluehat> +1
16:21:30 <ivan> +1
16:21:30 <timCole> +1
16:21:31 <ajs6f> +1
16:21:35 <simonstey> +1
16:21:38 <jeff_mixter> +1
16:21:45 <ivan> q+
16:21:45 <azaroth> RESOLVED: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion
16:21:48 <azaroth> ack ivan
16:22:21 <timCole> ivan: related question - we are talking about the primer, but I'm a little concerned that it will become a bit of a dumping ground
16:22:29 <ajs6f> Q+
16:22:32 <azaroth> +1
16:22:53 <bigbluehat> +1
16:22:53 <timCole> ... need someone to step up and actively take on the primer (and maybe someone else help Greg as editor of main specs)
16:22:53 <azaroth> ack ajs6f
16:23:09 <gkellogg> q+
16:23:51 <timCole> ajs6f: possibility that one rule of thumb we could use, primer should be for people not familiar with json-ld, but may need a separate doc for real best practices
16:24:06 <timCole> ivan: we can discuss at dinner at TPAC
16:24:08 <azaroth> ack gkellogg
16:24:44 <timCole> gkellogg: there is a CG best practices that might serve as a starting point (or could be updated in place)
16:24:44 <bigbluehat> CG's primer https://json-ld.org/primer/latest/
16:24:54 <bigbluehat> CG's best practices https://json-ld.org/spec/latest/json-ld-api-best-practices/
16:25:06 <timCole> ... for our primer, could we create a repo to make it easy to get started
16:25:07 <azaroth> q?
16:25:27 <bigbluehat> q+
16:25:33 <azaroth> ack bigbluehat
16:25:39 <timCole> ivan: I will do this and will add link from WG, but wait until we have someone who is going to take it own
16:26:15 <timCole> bigbluehat: we may want to migrate CG docs asap so we have somewhere to raise issues
16:26:17 <azaroth> SUBTOPIC: Do not compact to string (Rob's new understanding)
16:27:23 <timCole> ivan: agree setting up repo is easy, but do we need to wait for editors, etc. so we now exactly how many repos to create
16:27:49 <bigbluehat> https://github.com/w3c/json-ld-wg/issues/17 oh look! an issue related to this topic :)
16:27:57 <timCole> azaroth: agree. Let's put it on the agenda for next week. By time of TPAC we will then have a start
16:28:17 <azaroth> link: https://github.com/w3c/json-ld-api/issues/33
16:28:26 <timCole> azaroth: next issue, not compact urls to string
16:29:20 <timCole> ... raised in CG, suggested to use @id and @value to avoid this. @gkellog suggested @none.
16:29:52 <ivan> q+
16:29:53 <timCole> ... because @none would go in the context, you are simply saying that object has no type declared in context
16:30:03 <azaroth> ack ivan
16:30:07 <gkellogg> q+
16:31:18 <timCole> ivan: the point is we do have this issue of using @type differently than how those of us from rdf world think of rdf:type
16:31:27 <azaroth> ack gkellogg
16:31:31 <timCole> ... we need to be very, very clear about this.
16:31:59 <timCole> gkellogg: the way to think about @type is more like datatype
16:32:38 <timCole> ... really comes down to question of how different this concept is from original intent of @type (rdf:type)
16:33:11 <azaroth> q+ to note the reuse of @type as rdf:type as source of confusion, with best practice (ha!) of aliasing
16:33:37 <timCole> ... @type @id says treat as is URI, @type @none just says there is no datatype so you can't compact down to a string
16:33:58 <timCole> ... when we expand, do we default to something or do we raise error?
16:33:59 <azaroth> q?
16:34:04 <azaroth> ack azaroth
16:34:04 <Zakim> azaroth, you wanted to note the reuse of @type as rdf:type as source of confusion, with best practice (ha!) of aliasing
16:34:46 <timCole> azaroth: in the data @type is how you express rdf:type
16:35:14 <timCole> ... we need to make obvious the aliasing of @type to type and explain in the primer
16:36:00 <timCole> ... in terms of error vs. default when expanding, I would favor an error
16:36:24 <timCole> ... picking (guessing) seems dangerous
16:36:26 <ajs6f> q+ @type: @none vs. no @type
16:36:29 <azaroth> q?
16:36:33 <azaroth> ack ajs6f
16:37:22 <bigbluehat> q?
16:37:27 <timCole> ajs6f: we can get into confusion about there is not a @type vs none
16:37:30 <bigbluehat> ack @type:
16:37:36 <azaroth> ack @none
16:37:37 <bigbluehat> ack @none, vs., no, @type
16:37:43 <azaroth> ack vs.
16:37:45 <azaroth> ack no
16:37:50 <azaroth> ack @type
16:37:53 <timCole> gkellogg: when you expand a document and type is not specified default is treat them as simple literals
16:38:20 <timCole> ... equivalent to saying default rdf:type is xsd:string
16:38:51 <bigbluehat> q+
16:38:54 <azaroth> "value": {"@type": "@none"}
16:39:00 <azaroth> "value": "string"
16:39:17 <azaroth> "value": {"@id": "rdf:value"}
16:39:35 <timCole> azaroth: if we had @type @none for value then if in the data value : string, would be treated as a string
16:40:47 <timCole> gkellogg: if in the context, would mean value is alias for string, if in data, either treated as error or treated as string
16:40:51 <azaroth> {"@context": {"value1": {"@id": "rdf:value", "@type": "@none"}, "value2": {"@id": "rdf:value"}} ...
16:41:02 <azaroth> "value1": "string", "value2: "string"}
16:41:45 <timCole> azaroth: for the above example, both would be understood the same
16:41:47 <azaroth> q?
16:41:49 <azaroth> ack bigbluehat
16:41:53 <timCole> gkellogg: or value1 would generate an error
16:42:13 <ajs6f> q+
16:42:32 <simonstey> q+
16:42:35 <timCole> bigbluehat: want to make sure rest of us aren't just become spectators on this
16:43:02 <ivan> +10000 to bigbluehat
16:43:12 <bigbluehat> ack ajs6f
16:43:47 <timCole> ajs6f: so in response to @bigbluehat, let me offer my understanding
16:44:08 <timCole> ... so in rdf we distinguish between literals and strings
16:44:21 <simonstey> -q thanks adam
16:44:31 <simonstey> -q
16:44:32 <timCole> ... not the same in json-ld
16:44:47 <timCole> ... so in json-ld @type is doing several things at once
16:45:31 <timCole> ... so we keep adding more to what @type does, but it breaks down when moved into the rdf world
16:45:46 <timCole> ... so some uses of @type will add triples, some will not
16:45:54 <azaroth> q?
16:46:02 <timCole> ... baked into the 2 different data models
16:46:16 <timCole> azaroth: seems 100% correct to me
16:46:44 <ivan> q+
16:46:49 <timCole> ... if you alias @type it aliases both for rdf:type and as datatype in the json-ld documents
16:47:03 <gkellogg> q+
16:47:15 <azaroth> ack ivan
16:47:16 <timCole> ... not good, but we are stuck with it, I think. So we need to document thoroughly
16:48:01 <timCole> ivan: yes, we are stuck with it, but nevertheless as a helping measure we could define a fixed alias and encouraging people to use alias differently
16:48:14 <timCole> ... down the line could become separate keys
16:48:26 <azaroth> q+ to discuss alias technicalities
16:48:30 <timCole> ... more than just a best practice, but also a temporizing solution
16:48:35 <azaroth> ack gkellogg
16:49:23 <timCole> gkellogg: these issues came up in 1.0, but it's good to mindful of the original json-ld which was find a way to understand your json as rdf
16:49:54 <timCole> ... so this is why we have context, and this is why we have to deal with URIs vs Strings
16:50:22 <timCole> ... we have discussed a default context (as a way to create default alias)
16:50:40 <timCole> ... does create an issue when compacting, because one of the aliases has to win out
16:50:59 <timCole> ... so round-tripping leads to these kinds of issues.
16:51:18 <azaroth> Thus {"@context": {"type": "@type", "@datatype": "@type"} ... }  would allow people to use @datatype for data types, but compaction would always select one or the other for all situations
16:51:22 <timCole> ... we are restricted a bit on what we do for 1.1 (may be able to do more for 2.0)
16:51:28 <azaroth> q?
16:51:33 <azaroth> ack azaroth
16:51:33 <Zakim> azaroth, you wanted to discuss alias technicalities
16:52:24 <timCole> azaroth: so if we put aliases type and datatype, works for expansion, but would not roundtrip through compaction
16:52:39 <timCole> ... so maybe datatype has to more than just a context item
16:53:00 <azaroth> q?
16:53:15 <timCole> gkellogg: but it would break some compaction rules, so would require 1.1 being explicit
16:53:48 <timCole> azaroth: are we ready to move forward? Or do we need more time
16:53:52 <timCole> ivan: the latter
16:54:17 <jeff_mixter> I would like to mull this over more
16:55:04 <timCole> azaroth: will make new issue about disambiguting different uses of @type
16:55:35 <timCole> ... will provide a framework for resolving issue
16:55:49 <timCole> gkellogg: may take some time to resolve at f2f
16:56:03 <azaroth> q?
16:56:10 <timCole> azaroth: please add initial thoughts and then expect we may discuss in greater detail at f2f
16:56:44 <azaroth> PROPOSAL: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object
16:56:47 <timCole> +1
16:56:49 <azaroth> +1
16:56:51 <bigbluehat> +1
16:56:55 <ivan> +1
16:57:18 <gkellogg> +1
16:57:19 <ajs6f> If LD isn't about making the +1
16:57:21 <jeff_mixter> +1
16:57:22 <ajs6f> +1
16:57:26 <simonstey> +1
16:57:28 <azaroth> RESOLVED: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object
16:58:39 <timCole> ivan: next topic would be about embedded json (if we had time), this is a topic we need to discuss Dan B. and prioritize
16:58:57 <timCole> gkellogg: can we see if he could be availble for call?
16:59:13 <timCole> azaroth: will try
16:59:18 <bigbluehat> q+
16:59:23 <azaroth> ack bigbluehat
16:59:37 <timCole> ivan: but if he's not available will need to wait until tpac
17:00:32 <timCole> bigbluehat: proposal suggested last week is consistent with what schema.org does, but need to know if its what they want
17:01:07 <timCole> ivan: but what current tool does may not be relevant - seems like schema.org is working on major tool revision
17:01:46 <timCole> azaroth: will also need to address blank node issue with Davel Longley (as proxy for Manu)
17:02:14 <ivan> rrsagent, draft minutes
17:02:14 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/05-json-ld-minutes.html ivan
17:02:14 <ivan> zakim, bye
17:02:14 <ivan> rrsagent, bye
17:02:14 <RRSAgent> I see no action items
17:02:14 <Zakim> leaving.  As of this point the attendees have been Rob_Sanderson, Benjamin_Young, simonstey, Gregg_Kellogg, ajs6f, ivan, Tim_Cole, jeff_mixter
17:02:14 <Zakim> Zakim has left #json-ld
17:02:17 <timCole> azaroth: think about topics for next week if Dan B can't attend