15:36:49 <RRSAgent> RRSAgent has joined #json-ld
15:36:49 <RRSAgent> logging to https://www.w3.org/2018/09/28-json-ld-irc
15:36:50 <ivan> rrsagent, set log public
15:36:50 <ivan> Meeting: JSON-LD Working Group Telco
15:36:50 <ivan> Chair: azaroth42
15:36:50 <ivan> Date: 2018-09-28
15:36:50 <ivan> Regrets+ tcole, bigbluehat
15:36:50 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Sep/0019.html
15:36:51 <ivan> ivan has changed the topic to: Meeting Agenda 2018-09-28: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Sep/0019.html
15:50:28 <azaroth> Yup, doing it now
15:50:36 <azaroth> s/Yup, doing it now//
15:51:49 <ajs6f> present+
15:52:14 <gkellogg> present+ Gregg_Kellogg
15:54:46 <azaroth> present+ Rob_Sanderson
15:56:54 <simonstey> simonstey has joined #json-ld
15:59:19 <ivan> present+
16:00:04 <simonstey> present+
16:00:25 <jeff_mixter> jeff_mixter has joined #json-ld
16:00:29 <jeff_mixter> present+
16:01:01 <workergnome> workergnome has joined #json-ld
16:01:10 <workergnome> present+
16:01:35 <azaroth> TOPIC: Scribe Selection
16:02:19 <azaroth> scribenick: workergnome
16:02:36 <azaroth> TOPIC: Approve minutes of previous call
16:03:37 <azaroth> PROPOSAL: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-21-json-ld
16:03:39 <azaroth> +1
16:03:40 <workergnome> +1
16:03:41 <simonstey> +1
16:03:41 <jeff_mixter> +1
16:03:43 <gkellogg> +1
16:03:44 <ivan> 0
16:04:02 <azaroth> RESOLVED: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-21-json-ld
16:04:06 <workergnome> azaroth: approve the minutes of the call--minutes approved.
16:04:14 <azaroth> TOPIC: Announcements / Reminders
16:04:30 <workergnome> ...announcements.  TPAC, the standard update, though perhaps we should talk about logistics.
16:04:33 <ivan> q+
16:04:49 <dlehn> present+ David_Lehn
16:04:51 <workergnome> ...Rob has filled out the AV requirements, and each room comes with a screen, etc.  So we're OK.
16:05:02 <azaroth>  ack ivan
16:05:07 <workergnome> ... in the next block, we will have agenda, and we will need to have WEBEX setup.
16:05:30 <workergnome> ivan: If we ask, Ivan will set up the webbex.  Are there people who would want to dial in?
16:05:34 <jeff_mixter> that would be helpful for me - won't be able to attend in person
16:05:40 <workergnome> azaroth: There are at least two people who might want to dial in.
16:05:53 <workergnome> ivan: then there will we webex.
16:05:54 <azaroth> ACTION: Ivan to set up webex for TPAC
16:06:08 <workergnome> ... The registration will go up on Monday.  Do it now.
16:06:16 <simonstey> q+
16:06:25 <azaroth> ack simonstey
16:06:49 <workergnome> simonstey: Asking about the link--we were supposed to write our name somewhere, but I've misplaced it?  Do we need to do so?
16:07:14 <workergnome> ivan: In a way, it's not really needed.  But we should know if there are people who want to call in, and we know that.
16:07:20 <azaroth> q?
16:07:29 <workergnome> azaroth: other announcements?
16:07:44 <azaroth> TOPIC: Logistics
16:07:52 <azaroth> SUBTOPIC: TPAC Agenda
16:07:58 <workergnome> ... onto logistics.  We need to come up with an agenda.
16:08:12 <ivan> link: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit
16:08:16 <workergnome> ... Looking at the participants,
16:08:29 <workergnome> plus up to 20 other people who have not been on a call
16:08:54 <workergnome> ... one assumes that some of the observers will drop out, but here is the project link
16:08:57 <azaroth> Project: https://github.com/orgs/w3c/projects/4
16:09:27 <workergnome> ... in the gihub project there is a column that is face-to-face where we've put some of the more involved or controversial discussions, plus ones where we'll need external contributors.
16:09:36 <workergnome>  ...to get those people here, we need an agenda built.
16:10:10 <workergnome> ...if we can go over those seven topics, we can do some dragging of little cards around
16:10:18 <azaroth> q?
16:11:05 <workergnome> gkellogg: two uses cases for content-addressable.  Schema.org wants to announce that the context is not downloaded, but pre-compiled in and that would be announcable
16:11:46 <workergnome> ...the second would be web of things or similar where there's background signaling and off-line support, which is the gist of the content-addressable thing
16:11:59 <workergnome> ...so you can determine that a side-loaded file is a valid one to use
16:12:05 <dlehn> q+
16:12:11 <workergnome> azaroth: so we should talk to web of things, and dan
16:12:24 <azaroth> ack dlehn
16:12:32 <workergnome> gkellogg: Dan's likely there, and I'm sure we can get him to participate
16:12:52 <workergnome> dlehn: Another use case is caching--avoiding having lots of requests if you've got a local contact
16:13:00 <workergnome> gkellogg: we have HTTP caching
16:13:05 <workergnome> ivan: don't have to solve it now
16:13:18 <workergnome> gkellogg: We should know what we're talking about so we can raise with other people
16:14:16 <workergnome> ivan: #8 might not be that complicated
16:14:34 <workergnome> azaroth: it's there so that the we can allign with another working group
16:15:01 <workergnome> azaroth: Thre's a question about #18--absence of being
16:15:19 <workergnome> gkellogg: this is about null and empty list
16:15:34 <workergnome> ...but that's a non-RDF list
16:15:47 <workergnome> ...it's not really even an OWL thing
16:16:11 <workergnome> ...you can talk about carnality, but not null--the pattern language thing is where that gets expressed.
16:16:30 <workergnome> azaroth: I don't think it's a TPAC issue
16:17:07 <workergnome> gkellogg: it's not so much emptiness, but RDF-like processing that happens outside of the RDF algorithms, and we're a bit scattered about it anyway
16:17:26 <workergnome> azaroth: Those seven are good candidates, and there's nothing obvious, and we can work our way backwards if we finish those
16:17:30 <workergnome> ...oh, six
16:17:41 <ivan> q+
16:17:44 <simonstey> q+
16:18:02 <workergnome> ...I will take on a draft agenda, and reach out to web of things, data exchange, and see if they can be present at any specific time to schedule those ones.
16:18:04 <azaroth> ack ivan
16:18:05 <workergnome> ...other things?
16:18:15 <azaroth> ACTION:  Rob to draft agenda from issues plus other WG interactions
16:18:20 <workergnome> ivan: Looking at this, I would expect that it would not completely fill out the two days.
16:18:21 <simonstey> q-
16:18:41 <workergnome> ...I think we should discuss how we will attack the issue of testing implemenation
16:19:02 <workergnome> ...the working group doesn't have a long charter, so we should be prepared.
16:19:34 <workergnome> ...Lots from previous working group, and I don't remember when the CR is to be published, but this might be the last face-to-face before that, and we should have an agreements about this beforehand.
16:19:38 <gkellogg> q+
16:19:41 <workergnome> ... we can at least start that conversation in person.
16:19:50 <azaroth> q?
16:19:52 <azaroth> ack gkellogg
16:20:30 <workergnome> gkellogg: We've also talked about other publications, non-normative ones, say, and splitting them, and we could talk about YAML, HTML, Named Graphs, and are pretty-large in our documents
16:20:55 <workergnome> ivan: And I think that we've chatted about reorganizing the documents...
16:21:02 <workergnome> gkellogg: we've accomplished that already
16:21:44 <workergnome> azaroth: Manu will be there, and we can talk about the blank node issues
16:22:07 <workergnome> gkellogg: if we can target, we can coordinate a time to talk about that, since he'll be there.
16:22:36 <workergnome> ...maybe find a time to do a joint session between us and Verifiable Claims?
16:22:44 <workergnome> ...or just crash their meetings
16:23:03 <workergnome> ...and I think we're going to need to be increasingly needing to raise the "more implementations" issue
16:23:24 <workergnome> azaroth: that's a good set of things, and I'll circulate on the mailing list
16:23:43 <workergnome> azaroth: anything else TPAC?
16:23:55 <azaroth> SUBTOPIC: Echidna publishing
16:23:58 <workergnome> ...OK.  Moving ont o publishing
16:24:16 <workergnome> ...This is the tool that lets up publish to W3C site with less hassle.
16:24:35 <workergnome> ...particularly without more systematic process for the first working draft.
16:24:49 <workergnome> ivan: You've seen what this means for the first working draft
16:25:38 <workergnome> ...there are some details that we have to work out, but the goal is that we will have a separate branch in each repo and if we commit, there is a CI process that will create a new version of the specs
16:26:23 <workergnome> ...there are groups that do that frequently (every draft) and what usually happens is that each equilibrium point, t here is a draft.  This is a good example--it would be acceptable to do a publication right now, since it's better than what's out there now.
16:26:29 <workergnome> ...formally, we need a resolution for that.
16:26:47 <workergnome> ...to do an automatic publishing through the tool so he can get the API keys and the like.
16:27:12 <workergnome> azaroth: do we have enough bnackgound on this?
16:27:14 <azaroth> PROPOSAL: We will use echidna publishing WDs for all three rec track documents
16:27:16 <azaroth> +1
16:27:17 <workergnome> +1
16:27:19 <jeff_mixter> +1
16:27:21 <gkellogg> +1
16:27:23 <simonstey> +1
16:27:24 <ajs6f> +1+1
16:27:26 <ivan> +1
16:27:30 <dlehn> +1
16:27:33 <azaroth> RESOLVED: We will use echidna publishing WDs for all three rec track documents
16:27:58 <workergnome> ivan: I'll get that set up next week.
16:28:11 <workergnome> azaroth: moving on to issues
16:28:29 <azaroth> TOPIC: New Issues
16:28:37 <azaroth> SUBTOPIC: Fragment identifiers with ":"
16:28:44 <ivan> link: https://github.com/w3c/json-ld-syntax/issues/66
16:28:56 <workergnome> ... This was discoved as a bug over the past day
16:29:25 <workergnome> ... We've been discussing it, and it's valid to have : in fragment ids, some we need to fix this in the spec
16:30:02 <workergnome> gkellogg: I think that issue is that JSON-LD does not have a syntax for compact IRIs vs. URLs like RDFa so you can recognize prefixes vs. what is a URI scheme
16:30:07 <workergnome> ...in this case, this is a bug
16:30:27 <workergnome> ...since the pound sign is not a scheme, and it's not a defined term
16:30:41 <workergnome> ...if it were, there wouldn't be a concern.
16:31:12 <workergnome> ...the case we're running across is that #test and #test:2 the first is a relative URI, since it's interpreted as a ID
16:31:41 <workergnome> ...so it's a IRI or a document-relative IRI.  The second case, it could be a compact IRI or an absolute IRI
16:32:04 <workergnome> ...by tightening up the language, it must either match a term or the scheme production and a hash test would not match that production
16:32:09 <workergnome> ...but there are other corner cases
16:32:26 <workergnome> ...where there are other places where the hash sign may occur
16:32:36 <workergnome> ...we need to come up with more breaking cases and tests
16:32:59 <workergnome> ...what about a:b where the base includes a hash?
16:33:24 <workergnome> ...a does match the production of the scheme, and could be an absolute IRI
16:33:52 <workergnome> azaroth: so long as it's deterministic, but it's these cases where it's legal, but not permitted according to the algorithm where there's the issue
16:34:01 <workergnome> ...for fixing it, have we tried it?
16:34:17 <workergnome> gkellogg: I haven't fixed it, but I think it's straightforward if we tighten up what a URI scheme is
16:34:57 <workergnome> azaroth: We can fix this in 1.1, but we should also errata 1.0
16:35:07 <workergnome> gkellogg: I think we should not change the requirements, but highlight the issue
16:35:18 <workergnome> ivan: has it yet been submitted in the errata list?
16:35:23 <workergnome> gkellogg: no
16:35:30 <workergnome> ivan: We should document it
16:35:57 <workergnome> ...editorally, when we have the list of changes, we should make a reference to the eratta so we can change 1.0 because it's a bug
16:36:03 <azaroth> PROPOSAL: Accept the bug, submit errata 1.0 and fix in 1.1 by tightening the definition of a URI scheme
16:36:04 <workergnome> ...this is explicit in our charter
16:36:09 <gkellogg> +1
16:36:09 <ajs6f> +1
16:36:10 <ivan> +1
16:36:10 <azaroth> +1
16:36:11 <workergnome> +1
16:36:11 <jeff_mixter> +1
16:36:25 <dlehn> +1
16:36:47 <simonstey> +1
16:36:48 <azaroth> RESOLVED: Accept the bug, submit errata 1.0 and fix in 1.1 by tightening the definition of a URI scheme
16:36:57 <ajs6f> q+
16:37:01 <azaroth> ack ajs6f
16:37:21 <workergnome> ajs6f: Process:  When we submit an errata, are we supposed to do something, or is it an action?
16:37:25 <workergnome> ivan: just describing it
16:37:34 <azaroth> SUBTOPIC: @vocab property expansion
16:37:42 <azaroth> Link: https://github.com/w3c/json-ld-syntax/issues/56
16:38:25 <workergnome> azaroth: This one is about the expansion of @vocab properties and the issue claims that it is counter-intuitive
16:38:50 <workergnome> ...from my perspective, it goes back to #7 (won't-fix) that the processing model for @type shouldn't be able to customized
16:38:57 <workergnome> ...more than allowing @container: @set
16:39:13 <workergnome> ...to avoid monkeying around and overcomplicating
16:39:28 <workergnome> ...the response is that that fixes #7, but you can't fix this issue with scoped contexts
16:39:41 <workergnome> ...but Gregg has an example that fixes it...
16:39:43 <azaroth> q?
16:39:44 <workergnome> gkellogg: well.....
16:40:14 <workergnome> ...his feeling is that he's willing to do things in a context to hide this, but @base is restricted from being in a remote context, and that doesn't satisfy him
16:40:46 <workergnome> ...this is about discrepancies between vocabularies space and document space, where you can use @vocab: ""
16:41:21 <workergnome> ...and that might get to a point where you're not surprised, but there's overlap with Manu's blank-nodes as properties, where @vocab is a solution, but not a wide enough oe
16:41:42 <workergnome> ...maybe we need to make that a bit wider, make it any relative IRI relevant to the document base
16:42:30 <workergnome> ...in 1.0, you can generate an error with this, and we could make it document relevant, which widens what we can put in vocal, which handles both this and Manu's request
16:42:54 <workergnome> azaroth: can you talk through why the first Barney expands this wy?
16:43:29 <workergnome> gkellogg: if we look at Barney, it's value is a node definition.  In any context, ex2:barney evalutates to the URl
16:43:51 <workergnome> ...But fred has the value, with the value parnet
16:44:25 <workergnome> ...string values are intended to be treated as an IRI within the vocab space, so if barney is the string value of fred, we evaluate barney as vocab-relevant
16:44:53 <workergnome> ...there is no @vocab defined, but barney is a term, so we ill now interpret them as iris, so it's got a value of ex2:barney
16:45:17 <workergnome> ...so when we evaluate things in the vocabulary space, it will look to terms and compact IRIs
16:45:23 <workergnome> ...so it satisfies the term use case
16:45:50 <workergnome> ...when we look at it as ID, which makes it @id, which is in doc space, and we do not interpret things in that space relative to the vocabularies
16:46:03 <workergnome> ... in document space, it cannot be a bare term, so we don't evaluate it
16:46:19 <workergnome> ...it could have been barney:, which would work.
16:46:38 <workergnome> ...he asked why ID can't be treated in the vocab space, and that goes back to our decision
16:46:51 <workergnome> ...why didn't we want terms to be values?
16:46:52 <ajs6f> q+
16:46:56 <workergnome> ...since we allow compact terms?
16:46:59 <ajs6f> q-
16:47:11 <azaroth> q+ to bring up https://github.com/w3c/json-ld-api/issues/33
16:47:26 <workergnome> ...typically, where you see this conflation, you are closer to being in the use case where you're defining a vocabulary
16:47:33 <azaroth> q?
16:47:35 <workergnome> ...where it does make sense
16:47:35 <azaroth> ack azaroth
16:47:35 <Zakim> azaroth, you wanted to bring up https://github.com/w3c/json-ld-api/issues/33
16:47:43 <ivan> q+
16:47:47 <workergnome> azaroth: was that clear?
16:47:47 <azaroth> ack ivan
16:47:55 <workergnome> ivan: so I'm not ashamed to say, no.
16:48:37 <workergnome> ...It is because it is not complicated, bu what this means for us and readers, is that expansions, and the bifurcations, we should have that in a note and understand it
16:48:49 <workergnome> ...frankly, I don't have a clear idea how things work
16:48:54 <ajs6f> q+
16:49:14 <workergnome> ...the other comment is that we should have a rule that when an issue is put in, and when it has an example, the example should be reduced.
16:49:33 <workergnome> ...from the point of this issue, there are additional things that make things more complicated
16:49:35 <azaroth> +1
16:49:49 <azaroth> And +1 to ajs6f's link
16:49:50 <workergnome> ...we should really ask them to make it more simple and to be careful, since much here is not relevant
16:49:59 <azaroth> q?
16:50:01 <azaroth> ack ajs6f
16:50:52 <gkellogg> q+
16:50:55 <workergnome> ajs6f: whatever comes out of this, we might really need a note lays out the spaces around expansion, since the suspicion is that this arises because it's really hard to understand this
16:51:02 <azaroth> ack gkellogg
16:51:19 <ivan> q+
16:51:30 <workergnome> gkellogg: I think that the API document is fairly consistent is clear about this, and the people who are the most likely to be confused are unlikely to read this
16:52:12 <workergnome> ...so we're stuck with the JSON vocab, in turtle there are pnames or iris.  In JSON, we can't do that, so we need to descern the intent around meaning
16:52:17 <ajs6f> q+
16:52:18 <jeff_mixter> q+
16:52:19 <workergnome> ...thus the bifurcation between the spaves
16:52:35 <workergnome> ...it's laid out, and it's easy to get lost, and adding another note in syntax documents.
16:52:45 <workergnome> ...how much detail to be need to get into?
16:52:47 <ajs6f> q-
16:52:51 <workergnome> ...we need a primer
16:53:03 <azaroth> ack ivan
16:53:09 <workergnome> ...and we need a champion for that primer
16:53:25 <workergnome> ivan: I get the problem, and it's not 1.0, it's just...terrible.
16:53:43 <workergnome> ...and I don't think it needs to be in the specification, and a primer would be the ideal place for it.
16:53:58 <workergnome> ...authors will never read the API, and I don't want to.  I just want to put data in JSON-LD
16:54:04 <workergnome> ...that's why the primer is required.
16:54:10 <workergnome> ...otherwise people will be lost
16:54:10 <azaroth> ack jeff_mixter
16:54:14 <azaroth> q+
16:54:55 <workergnome> jeff_mixter: the explanation is helpful, and it would be helpful to have the example to be recreated to be realistic, and it's really confusing with freds and barneys
16:55:05 <workergnome> ...it might be better to have real-world examples
16:55:15 <azaroth> q?
16:55:18 <azaroth> ack azaroth
16:55:41 <workergnome> azaroth: a complication with #33
16:55:42 <azaroth> https://github.com/w3c/json-ld-api/issues/33
16:56:13 <workergnome> ...It would be nice to have the Uris compact to not just ID, but also to @id.  Doesn't this mean changing the space?
16:56:35 <workergnome> gkellogg: the way I take this option is to not compact to allow properties, but not values
16:57:00 <workergnome> ...that things would remain in their expanded state.
16:57:08 <workergnome> ...doing this wouldn't add additional space
16:57:24 <workergnome> ...it's how you interpret string  values.  If you've got an object, it's unambiguious
16:58:05 <workergnome> azaroth: If the context wanted ID: barney to be compacted to id: barney, and another term compacted to a string, then those two otherwise identical lines would have different value spacves
16:59:00 <workergnome> gkellogg: if you were able to specify the value space of a term, as in the first comment of #33...I think the issues comes down to wanting to specifiy for a property when compacting, you want to compact the term, but not the value.
16:59:37 <workergnome> ...if you do this, it continues to be unambiguous, ...something about strings...
16:59:38 <azaroth> q?
16:59:53 <workergnome> azaroth: is there a proposal?
17:00:31 <workergnome> gkellogg: do we need a issue to change the rules about @vocab to use relative IRIs in document space
17:00:45 <ivan> q+
17:00:46 <workergnome> ...I can create that issue
17:00:47 <azaroth> ack ivan
17:00:58 <workergnome> ivan: I would like to move this to face-to-face
17:01:00 <ajs6f> q+
17:01:01 <workergnome> gkellogg: sure
17:01:03 <azaroth> ack ajs6f
17:01:04 <workergnome> azaroth: sure
17:01:16 <workergnome> ajs6f: could we leave a note for the primer?
17:01:27 <workergnome> ...maybe a label?
17:01:42 <workergnome> ...about the spaces?
17:01:51 <workergnome> gkellogg: we should create an issue for the primer about that
17:02:18 <workergnome> azaroth: gregg, create the issue about vocabs, adam, about the primer, and we'll defer this to face-t-face
17:02:38 <ajs6f> +1 to that!
17:03:01 <ivan> rrsagent, draft minutes
17:03:01 <RRSAgent> I have made the request to generate https://www.w3.org/2018/09/28-json-ld-minutes.html ivan