16:22:44 <RRSAgent> RRSAgent has joined #json-ld
16:22:44 <RRSAgent> logging to https://www.w3.org/2019/12/06-json-ld-irc
16:22:45 <ivan> rrsagent, set log public
16:22:45 <ivan> Meeting: JSON-LD Working Group Telco
16:22:45 <ivan> Date: 2019-12-06
16:22:45 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Dec/0000.html
16:22:45 <ivan> ivan has changed the topic to: Meeting Agenda 2019-12-06: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Dec/0000.html
16:22:46 <ivan> Chair: bigbluehat
16:22:46 <ivan> Regrets+ pchampin
16:31:35 <rubensworks> rubensworks has joined #json-ld
16:52:35 <azaroth> azaroth has joined #json-ld
16:57:21 <ivan> present+
17:00:07 <gkellogg> gkellogg has joined #json-ld
17:00:22 <rubensworks> present+
17:01:21 <gkellogg> present+
17:01:38 <bigbluehat> present+
17:01:46 <azaroth> present+
17:01:51 <dlongley> present+
17:02:15 <azaroth> scribenick: azaroth
17:02:24 <bigbluehat> Topic: Approve minutes of previous call:   https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-11-22-json-ld
17:02:26 <azaroth> bigbluehat: Approve t he minutes
17:02:27 <bigbluehat> +1
17:02:30 <gkellogg> +0
17:02:32 <rubensworks> +1
17:02:32 <azaroth> +1
17:02:38 <dlongley> +1
17:02:41 <ivan> +1
17:02:45 <dlehn> present+
17:02:49 <bigbluehat> RESOLVED: minutes approved
17:02:52 <azaroth> y
17:02:55 <bigbluehat> Topic: Announcements / Reminders?
17:03:04 <ivan> q+
17:03:07 <bigbluehat> ack ivan
17:03:39 <azaroth> ivan: Practical thing -- mainly for Greg and PA -- I was wrong, we cannot publish CR via echidna. Will come back to this, but we need to go the pedestrian way and go through the webmaster
17:03:51 <azaroth> ... turns out that the  transition requests that have more than one document, then it doesn't work
17:04:00 <azaroth> ... learnt with the Publishing wg
17:04:06 <azaroth> gkellogg: So it's a technical issue, not policy
17:04:15 <azaroth> ivan: Yes, most WGs have published only one doc at a time
17:04:20 <azaroth> gkellogg: I will prepare snapshots
17:04:24 <azaroth> ivan: Thank you@
17:04:31 <azaroth> bigbluehat: Thank you all for the clerical work!
17:04:34 <azaroth> ... anything else?
17:04:45 <bigbluehat> Topic: Call for Consensus for Candidate Recommendation Status Report
17:04:53 <azaroth> ... okay, CfC status...
17:05:02 <ivan> q+
17:05:03 <azaroth> ... waiting on the director. Any other nuances to add?
17:05:13 <azaroth> ... some feedback from Ralph
17:05:14 <hsolbrig_> hsolbrig_ has joined #json-ld
17:05:19 <hsolbrig_> present+
17:05:32 <azaroth> gkellogg: Ralph was suggesting that in the abstract we add a note about compatibility between 1.0 and 1.1
17:06:03 <azaroth> ... I proposed some wording for syntax. API is a different audience and doesn't quite apply. Is an opportunity to discuss how the algorithm is compatible, but they're substantially different in practice
17:06:09 <bigbluehat> Ralph's request https://github.com/w3c/transitions/issues/194#issuecomment-562295741
17:06:23 <azaroth> ... there wasn't a 1.0 spec for framing, but there was the community work as a de facto standard. Worth noting the relationship with that
17:06:38 <azaroth> ... If people are happy with the wording in the issue, I'll make PRs
17:06:49 <azaroth> bigbluehat: Any other thoughts?
17:07:09 <azaroth> gkellogg: Process for this?
17:07:40 <azaroth> bigbluehat: Can we just do it via the PR?
17:07:45 <azaroth> ivan: Yes it's just editorial
17:07:54 <bigbluehat> PROPOSAL: add 1.0 to 1.1 relationship text to the API and Syntax specs; gkellogg to submit PR and to be approved via GitHub by chairs
17:07:55 <azaroth> gkellogg: If Ivan and one of the chairs can +1, that seems fine
17:07:59 <dlongley> +1
17:07:59 <gkellogg> +1
17:07:59 <bigbluehat> +1
17:07:59 <azaroth> +1
17:08:03 <hsolbrig_> +1
17:08:03 <dlehn> +1
17:08:03 <rubensworks> +1
17:08:05 <ivan> +1
17:08:07 <bigbluehat> RESOLVED: add 1.0 to 1.1 relationship text to the API and Syntax specs; gkellogg to submit PR and to be approved via GitHub by chairs
17:08:22 <bigbluehat> ack ivan
17:08:54 <azaroth> ivan: I got in contact with Ralph, and he said that unless something comes up, he should give an answer later today. I may not see it today, but it will come.
17:09:08 <azaroth> ... we should be confident the answer is yes, and decide on next steps so we can move quickly
17:09:19 <azaroth> ... I propose to set the publication date to next Thursday, Dec 12
17:09:48 <azaroth> ... in the webmaster involved case, we can only publish on Tuesday and Thursday ... so can't go to him before afternoon on Monday, so Tuesday is too soon
17:09:57 <azaroth> ... if the snapshots are done by the weekend, that should be okay
17:10:09 <azaroth> ... I can take care of the work to get it on the site and issue a request for publication for the 12th
17:10:12 <azaroth> ... if we're fine with that
17:10:23 <azaroth> gkellogg: Modulo the issues on the call, yes
17:10:27 <azaroth> ivan: Yes
17:10:36 <azaroth> bigbluehat: Awesome. Moving on to issues ...
17:10:38 <bigbluehat> Topic: Issues
17:10:44 <bigbluehat> Subtopic: The propagate option to Create Term Definition is unused.
17:10:46 <timCole> timCole has joined #json-ld
17:10:48 <bigbluehat> https://github.com/w3c/json-ld-api/issues/233
17:10:52 <azaroth> ... first issue is this one ...
17:11:07 <azaroth> ... Propagate option is unused in the create term definition.
17:11:54 <azaroth> gkellogg: At one time, we passed propagate from context parsing to create term definition. Subsequently we reverted that, so now if you look at the API document, in create term definition, if you click that argument, you'll see it's not anywhere in the algorithm
17:12:08 <azaroth> ... I noticed this in the jsonld.js algorithm. Verified in my own implementation
17:12:19 <azaroth> ... so we can simplify it by taking this argument out
17:12:24 <dlongley> +1 to remove it and simplify (it doesn't actually change anything!)
17:12:28 <azaroth> ... question is ... is that a normative change?
17:12:38 <azaroth> ... no processing has changed, just the requirements for calling
17:12:56 <dlongley> q+
17:12:57 <azaroth> ... sure that we'll face other similar things after  publication
17:13:12 <azaroth> ivan: That means I think that the algorithm doesn't change, it just has an unnecessary parameter
17:13:22 <azaroth> gkellogg: Yes, you're passing an argument that is never used
17:13:32 <bigbluehat> ack dlongley
17:13:39 <azaroth> ivan: So if I remove it, then no change ... but it's definitely borderline
17:13:59 <azaroth> dlongley: in no way would the output of the algorithm change, which is what is normatively defined
17:14:17 <azaroth> gkellogg: Yes, that would also speak to making changes to the algorithms in the future ... the results can't change
17:14:29 <azaroth> dlongley: I think this  would be a useful precedent to set
17:15:21 <azaroth> gkellogg: Sense of the WG is that minor changes to the text in algorithms that do not affect the results, as specified, may be considered editorial changes
17:15:24 <dlongley> PROPOSAL: Any changes to algorithm text that do not affect the result of the algorithm may be considered non-normative changes.
17:15:29 <azaroth> +1
17:15:30 <gkellogg> +1
17:15:32 <dlongley> +1
17:15:32 <ivan> +1
17:15:33 <rubensworks> +1
17:15:33 <bigbluehat> +1
17:15:34 <timCole> +1
17:15:36 <hsolbrig_> +1
17:15:37 <dlehn> +1
17:15:43 <gkellogg> +1
17:15:55 <bigbluehat> RESOLVED: Any changes to algorithm text that do not affect the result of the algorithm may be considered non-normative changes.
17:16:33 <bigbluehat> Subtopic: @context as relative IRI
17:16:36 <azaroth> bigbluehat: Next three issues are all marked as editorial
17:16:39 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/311
17:16:49 <azaroth> ... don't need much more than an overview of the issues
17:16:55 <azaroth> ... this one was from Harold ...
17:17:33 <azaroth> hsolbrig_: This started out as a question, as it wasn't clear to me in the docs, where context can be a relative URI as to what it's resolution base is
17:17:47 <azaroth> ...  eprud has code that resolves against an outer context
17:18:24 <azaroth> ... we hope that it remains that way -- that the inner context is done in terms of the outer context -- as we're building a  bunch of fragmentary contexts, and  don't want to have to put  in absolute URIs as that's painful t o maintain
17:18:42 <azaroth> gkellogg: I recalled that we settled in 1.0 but didn't find a test for it
17:18:55 <azaroth> ... eprud submitted one, I tweaked and  it found a  bug
17:19:19 <azaroth> ...  you shouldn't  regard `@base` as a logical  not a physical location. If you load from a document, it should be from  that physical location
17:19:35 <azaroth> ... or from a URI it would be from where it was  retrieved from
17:19:55 <azaroth> ...  writing the test  found issues ... we need to clarify the processing in t he syntax document, not the API doc
17:20:04 <azaroth> ... as  that's where  authors writing contexts will be looking
17:20:19 <azaroth> bigbluehat: Is there some question here  that needs to be resolved?
17:20:46 <azaroth> ivan: Change to the  doc, or just the tests?
17:20:59 <azaroth> gkellogg: syntax doc isn't explicit enough about how they're resolved
17:21:13 <azaroth> ...  informative text in any case, that describes how this happens
17:21:15 <azaroth> q+
17:21:19 <bigbluehat> ack azaroth
17:21:21 <bigbluehat> scribe+ bigbluehat
17:21:55 <azaroth> azaroth: the normative text is in the algorithm in API and  is already correct?
17:22:31 <azaroth> gkellogg: Yes, if  the context is a relative IRI, then it is resolved with respect to the location of the containing document, rather than the base
17:22:50 <azaroth> hsolbrig_: if  I understand eric's example, the  context is  resolved against the outer one.
17:23:07 <azaroth> gkellogg: Yes, the same thing. If you resolve a relative IRI context, it's resolved relative to the document that contains the reference
17:23:23 <azaroth> ... so embedded in a context or in a document, it/s the same
17:23:35 <azaroth> hsolbrig_: This would be nice to know without reading the API, so good to have in the syntax doc
17:23:58 <bigbluehat> Subtopic: Flagging an action for CR https://github.com/w3c/json-ld-syntax/issues/263
17:24:17 <azaroth> bigbluehat: Ivan do you want to   explain this one?
17:24:31 <azaroth> gkellogg: We need to update the ontology for adding  rdf:JSON
17:24:41 <azaroth> ... also the terms for direction
17:24:50 <azaroth> ivan: This is when CR is done, gkellogg and I can do this
17:24:57 <azaroth> bigbluehat: there's no issue with us adding to rdf namespace
17:25:02 <azaroth> ivan: no additional process
17:25:14 <dlongley> q+
17:25:14 <azaroth> ... the only thing that's a question is whether to do it now, or at PR
17:25:24 <azaroth> q+  to argue for CR
17:25:26 <bigbluehat> ack dlongley
17:25:37 <azaroth> dlongley: I argue for doing it now ... we're using  it now
17:26:07 <azaroth> gkellogg: I think it would be useful to do. If it went away from the spec, it wouldn't really ever change
17:26:30 <azaroth> ... the other two terms are properties ... an i18n datatype that we've added
17:26:38 <azaroth> ivan: It's in i18n not rdf
17:26:47 <azaroth> ... we'll need to create a separate file
17:26:58 <azaroth> gkellogg: the other ones in the blank node have been  eliminated
17:27:03 <azaroth> ivan: We'll have to look at it
17:27:12 <azaroth> ... the i18n one ... what URL do  we use?
17:27:20 <azaroth> q-
17:27:50 <azaroth> gkellogg: namespace is ns/i18n#
17:27:51 <bigbluehat> q+ to ask if someone remembers why were not doing these in a jsonld: namespace
17:28:01 <azaroth> ... which serves as base for adding fragments that specify the  direction and language
17:28:08 <azaroth> ivan: okay the ns is fine, just need to create the file
17:28:19 <azaroth> gkellogg: the namespace doesn't already exist ... a new ns document
17:28:49 <azaroth> ivan: when we get the decision there might be a comment ... don't know. Will find out if there's process about adding a new /ns file but i don't think so
17:29:04 <azaroth> gkellogg: We still have 10.4 ... for rdf namespace.
17:29:11 <azaroth> ivan: Yes, that's not a problem
17:29:11 <bigbluehat> ack bigbluehat
17:29:11 <Zakim> bigbluehat, you wanted to ask if someone remembers why were not doing these in a jsonld: namespace
17:29:29 <azaroth> bigbluehat: That's weird that we can add to other people's namespace?
17:29:36 <azaroth> ivan: It's controlled by w3c
17:29:38 <azaroth> q+
17:29:46 <bigbluehat> ack azaroth
17:29:47 <azaroth> bigbluehat: I expected more process
17:30:04 <bigbluehat> azaroth: just to note that in the annotation WG and in the social WG
17:30:14 <bigbluehat> ...we added non-binding notes to explain how to add to the namespace
17:30:32 <bigbluehat> ...by requiring that there should be discussion with the existing CG for those groups
17:30:37 <bigbluehat> ...they're meant to be polite requests
17:30:41 <bigbluehat> ...not enforcement steps
17:30:50 <bigbluehat> ...we did that because of this more flexible process
17:30:59 <azaroth> gkellogg: We've done this for the relevant groups
17:31:18 <azaroth> ... we sent out about proposals for direction and with i18n wg
17:31:30 <azaroth> ivan: As you already have that, can you make a short list of the things we have to add
17:31:42 <azaroth> ... and email so I can forward to Ralph so we have clarity, and if he sees any issues
17:31:46 <azaroth> ... after the call, please
17:31:51 <azaroth> bigbluehat: That's helpful :)
17:32:14 <azaroth> gkellogg: Some NS docs are multiple, it's not always apparent when you look at  the ns that  there's multiple documents. Need to update all the relevant things
17:32:21 <azaroth> ivan: rdf ns doc is only one
17:32:44 <azaroth> ... for i18n I'll do turtle, rdf/xml and set up the usual conneg tricks
17:32:49 <bigbluehat> Subtopic: Better example for included blocks
17:32:49 <azaroth> bigbluehat: Thanks for all that!
17:32:56 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/255
17:33:15 <bigbluehat> bigbluehat: this one's by azaroth, can you 'splain?
17:33:31 <bigbluehat> azaroth: in trying to explain how `@included` work to my engineers, they said it sucks...
17:33:36 <bigbluehat> ...and it's my example...and I agreed
17:33:42 <bigbluehat> ...so this is on me to come up with a better example
17:33:46 <bigbluehat> ...but I've not yet done it
17:34:02 <bigbluehat> bigbluehat: and this won't delay CR, so...good :)
17:34:15 <azaroth> ivan: I hope this is correct, we can use echidna for any cr update that's editorial
17:34:22 <azaroth> gkellogg: it updates the CR, not a wd
17:34:38 <azaroth> ivan: Yes. If we get to that, then don't do it before asking me, but I believe so yes
17:34:47 <azaroth> ... if it's substantial, then we need to go back to the director
17:34:52 <azaroth> ... but for this, it's not substantial
17:35:26 <azaroth> bigbluehat: Some of these should be done sooner rather than later ...
17:35:42 <azaroth> gkellogg: 263 doesn't hold up CR
17:35:51 <azaroth> ... but we should do it sooner rather than later
17:36:04 <azaroth> ... and will email Ivan with the NS  entries
17:36:12 <azaroth> bigbluehat: Do we need any thing formal?
17:36:31 <azaroth> gkellogg: Proposal where we authorize ourselves to update the namespaces?
17:36:39 <azaroth> ivan: I will put this into the issue for CR request
17:37:02 <azaroth> ... for   i18n, can you give me a pointer for what  should go into the document?
17:37:13 <azaroth> gkellogg: It doesn't define anything, only a namespace ... so some text in a comment
17:37:29 <azaroth> ... it's a URI prefix to which we append fragments for indicating language and direction
17:37:33 <gkellogg> i18n:ar-EG_rtl
17:37:39 <azaroth> ... for instance ^^^
17:37:43 <gkellogg> @prefix i18n: <https://www.w3.org/ns/i18n#> .
17:37:47 <azaroth> ivan: one of the alternatives that we use
17:37:58 <gkellogg> https://www.w3.org/TR/json-ld11/#the-i18n-namespace
17:38:01 <azaroth> ... a pointer in one of our docs where we describe that?
17:38:25 <azaroth> gkellogg: The content of the document is probably HTML and contains something extracted from this section
17:39:29 <azaroth> pchampin: For the fragments, we make it hard to comply with linked data principles  to make them dereferencable
17:39:52 <azaroth> ... don't want to list them all in a document ... so if we used /  we could do some smart service that served relevant data for the IRIs
17:39:58 <azaroth> ... if someone felt like that would be a good idea
17:40:26 <azaroth> gkellogg: I see where you're going
17:40:43 <azaroth> ... something  that responded to the location and could give you info about combinations of language tags  and directions
17:40:54 <azaroth> pchampin: Yes, with / instead  of #, then we leave the door open
17:40:59 <azaroth> ... wouldn't fight for it
17:41:03 <bigbluehat> q+ to say this is what IANA does for mime types
17:41:06 <bigbluehat> ack bigbluehat
17:41:06 <Zakim> bigbluehat, you wanted to say this is what IANA does for mime types
17:41:14 <azaroth> bigbluehat: Sounds like the IANA  pages for  media  types
17:41:21 <azaroth> q+ to  agree with ivan re too late
17:41:23 <bigbluehat> https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded
17:41:32 <azaroth> gkellogg: Would be a delay
17:41:37 <azaroth> ... impacts tests and etc
17:41:53 <azaroth> ...  not that it's not a good  idea,  and  now   /would/ be the time to do it  ... or rather a couple of months ago
17:42:00 <azaroth> pchampin: Well, it happens!
17:42:27 <azaroth> gkellogg: It  might be useful.  Another media type for th edocument that  couldbetter describe the fragment identifier space
17:42:32 <azaroth> ... but no practical purpose
17:42:33 <azaroth> q?
17:42:36 <bigbluehat> ack azaroth
17:42:36 <Zakim> azaroth, you wanted to agree with ivan re too late
17:42:48 <bigbluehat> azaroth: wanted to agree with everybody
17:42:53 <bigbluehat> ...it would've been good to do this earlier
17:43:09 <bigbluehat> ...but let's do remember that this is all for a workaround until RDF sorts out it's i18n issues
17:43:19 <bigbluehat> ...this should not be a long term thing
17:43:37 <bigbluehat> ...by the time any of these services to do this dereferences got built, hopefully the real problem would be fix
17:43:41 <bigbluehat> s/fix/fixed
17:43:56 <bigbluehat> ...so I don't think we should delay
17:44:01 <azaroth> gkellogg: Both the sections and tests are non normative
17:45:49 <bigbluehat> PROPOSAL: gkellogg to add explanation to the syntax document around resolving relative IRIs for `@context` values
17:45:53 <gkellogg> +1
17:45:54 <azaroth> +1
17:45:56 <hsolbrig_> +1
17:45:56 <bigbluehat> +1
17:45:56 <rubensworks> +1
17:45:57 <ivan> +1
17:45:59 <timCole> +1
17:46:08 <dlehn> +1
17:46:14 <bigbluehat> RESOLVED: gkellogg to add explanation to the syntax document around resolving relative IRIs for `@context` values
17:46:26 <bigbluehat> Subtopic: Best Practice issues/topic review
17:46:43 <bigbluehat> https://github.com/w3c/json-ld-bp/issues
17:46:51 <azaroth> bigbluehat: there is a  growing list of issues in the  best practice repo
17:47:11 <azaroth> ... that  are actionable  by people. We could  go  through these  and confirm that they're worth doing
17:47:17 <azaroth> ... we could just  see if people  do PRs for them
17:47:31 <azaroth> ... would be helpful to know which ones  would be needed  for which would make hte document  valuable
17:47:40 <azaroth> ... the doc has been around for a long time but we've done some reorganization of   it
17:47:52 <azaroth> ... feedback about what is missing would be good
17:48:15 <azaroth> ... any thoughts about process?
17:48:16 <azaroth> q+
17:48:20 <bigbluehat> ack azaroth
17:48:34 <bigbluehat> azaroth: I like your suggestion of going through the one's we have, and trying to prioritize them
17:48:40 <hsolbrig_> q+
17:48:45 <bigbluehat> ...knowing which ones would have the most impact should help us
17:48:52 <bigbluehat> ...and which ones might be easy
17:49:07 <bigbluehat> ...like mapping `@none` to none is an easy one
17:49:14 <bigbluehat> ...so maybe we can label them as easy, useful
17:49:21 <bigbluehat> ...and that combo is most valuable
17:49:22 <azaroth> gkellogg: Can  assign people  to write different ones
17:49:23 <bigbluehat> ack hsolbrig_
17:49:39 <azaroth> hsolbrig_: Embarrassed to say that  i wasn't aware of the document until  now
17:49:49 <azaroth> ... would be  good to get into it. Can we advertise it somewhere?
17:50:09 <azaroth> bigbluehat: I like  that suggestion
17:50:19 <azaroth> ... it has lived in the specs menu for jsonld.porg
17:50:29 <azaroth> gkellogg: but still points to the old  version
17:50:35 <azaroth> hsolbrig_: is there a stackexchange
17:50:42 <azaroth> bigbluehat: yes, stackexchange :D
17:50:45 <bigbluehat> s/porg/org
17:50:46 <azaroth> ... there is a jsonld tag there
17:50:53 <azaroth> gkellogg: there's stuff posted there almost every day
17:51:05 <azaroth> dlongley: Stack Overflow
17:51:11 <dlehn> https://stackoverflow.com/questions/tagged/json-ld
17:51:21 <dlongley> s/dlongley: Stack/dlehn: Stack
17:51:43 <azaroth> bigbluehat: That looks like a good source of evidence to  mine for  what should go in the BP doc
17:52:00 <azaroth> ... can ask questions in that space to have others answer them and then make it more visible
17:52:22 <azaroth> ... can email the CG and let people there know that they should be able to add to it
17:52:31 <azaroth> ... PRs from anyone anywhere are welcome
17:52:48 <azaroth> ... lets go through the issues...
17:53:45 <bigbluehat> ack dlongley
17:53:46 <azaroth> ... okay ...
17:53:58 <azaroth> dlongley: I think it's a good idea to promote idiomatic json
17:54:10 <azaroth> ... people don't use : in keynames so avoid using CURIEs in json
17:54:18 <azaroth> ... doesn't mean you can't but looks better if you don't
17:54:21 <azaroth> +1 to t his
17:54:33 <azaroth> dlongley: If I took this one I have no idea when I  would get to it
17:54:52 <azaroth> bigbluehat: Hopefully anyone could write this
17:54:56 <azaroth> ... any objections?
17:55:02 <azaroth> gkellogg: Relates to round  tripping
17:55:05 <ivan> q+
17:55:11 <azaroth> ... not generally possible with other people's docs
17:55:17 <azaroth> bigbluehat: Is there a similar framing BP?
17:55:22 <azaroth> q+ re "data"
17:55:31 <azaroth> gkellogg: there's #13
17:55:31 <bigbluehat> ack ivan
17:55:46 <azaroth> ivan: I understand what Dave says, not sure I agree with the formulation
17:55:56 <azaroth> ... true if you come from JSON then -LD is a stepping stone to real LD
17:56:20 <azaroth> ... so more natural. If you come from RDF, and you want to use JSON-LD for various reasons like JSON tools, then it's almost the oppoosite
17:56:33 <azaroth> ... the natural is dc:whatever because that's what I'm used to
17:56:46 <azaroth> ... setting up vocabularies for all those is not what is normally done
17:57:03 <azaroth> dlongley: Can say that in the documents ... If you're primary consumers are JSON oriented, then ...
17:57:16 <azaroth> ivan: Yes, agreed with that qualifier
17:57:32 <azaroth> bigbluehat: Good to have that recorded in the issue
17:57:34 <azaroth> q?
17:57:35 <azaroth> ;)
17:57:38 <bigbluehat> ack azaroth
17:57:39 <Zakim> azaroth, you wanted to discuss "data"
17:57:54 <bigbluehat> azaroth: does this apply only to keys? or also `@vocab` values?
17:58:05 <bigbluehat> ...for example, in various spaces that I'm in, we've gone back and forth...
17:58:32 <bigbluehat> ...and are wondering if a massive context that maps all the things
17:58:45 <bigbluehat> ...if it's only keys, then that seems pretty universally friendly
17:59:03 <azaroth> ACTION: azaroth to add values discussion to #19
17:59:08 <bigbluehat> https://github.com/w3c/json-ld-bp/issues/18
17:59:34 <azaroth> bigbluehat: taking existing JSON and turning it into json-ld w ithout any changes to the JSON
17:59:39 <azaroth> ... certainly something that's helpful to explain
17:59:51 <azaroth> ... there's lots of existing JSON to uplift
18:00:01 <azaroth> gkellogg: There's some slides on json-ld.org that talk about this
18:00:09 <azaroth> ... we can probably take some of this out
18:00:18 <azaroth> ... github API, but has probably changed since then
18:00:25 <azaroth> bigbluehat: this landed me in the odata space
18:00:33 <azaroth> ... still need to write that up
18:00:51 <azaroth> ... think these are the both  good ones, but  18 probably not as easy as  19
18:01:09 <azaroth> ... post an issue with basic thoughts about  BPs
18:01:18 <azaroth> ... thank you  all very  much!
18:01:31 <azaroth> ... see you all next week for   Friday the 13th
18:01:40 <ivan> rrsagent, draft minutes
18:01:40 <RRSAgent> I have made the request to generate https://www.w3.org/2019/12/06-json-ld-minutes.html ivan
18:01:40 <ivan> zakim, bye
18:01:40 <ivan> rrsagent, bye
18:01:40 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2019/12/06-json-ld-actions.rdf :
18:01:40 <RRSAgent> ACTION: azaroth to add values discussion to #19 [1]
18:01:40 <RRSAgent>   recorded in https://www.w3.org/2019/12/06-json-ld-irc#T17-59-03
18:01:40 <Zakim> leaving.  As of this point the attendees have been ivan, rubensworks, gkellogg, bigbluehat, azaroth, dlongley, dlehn, hsolbrig_
18:01:40 <Zakim> Zakim has left #json-ld
18:01:41 <azaroth> topic: adjourn