16:17:57 <RRSAgent> RRSAgent has joined #json-ld
16:17:57 <RRSAgent> logging to https://www.w3.org/2020/01/17-json-ld-irc
16:17:59 <Zakim> RRSAgent, make logs Public
16:18:01 <Zakim> please title this meeting ("meeting: ..."), ivan
16:18:15 <ivan> Date: 2020-01-17
16:18:16 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jan/0009.html
16:18:16 <ivan> ivan has changed the topic to: Meeting Agenda 2020-01-17: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jan/0009.html
16:18:17 <ivan> Chair: azaroth
16:18:17 <ivan> Meeting: JSON-LD Working Group Telco
16:42:21 <ajs6f> ajs6f has joined #json-ld
16:42:36 <ajs6f> going to be about 15 minutes late
16:51:34 <pchampin> pchampin has joined #json-ld
16:54:49 <ajs6f> ajs6f has left #json-ld
16:55:02 <ajs6f_> ajs6f_ has joined #json-ld
16:55:48 <azaroth> azaroth has joined #json-ld
16:55:55 <azaroth> present+
16:56:31 <gkellogg> gkellogg has joined #json-ld
16:59:19 <ivan> present+
16:59:24 <gkellogg> present+
17:01:15 <dlongley> present+
17:01:21 <pchampin> present+
17:01:51 <gkellogg> scribe+
17:02:06 <azaroth> TOPIC: Approve minutes of previous call
17:02:16 <azaroth> PROPOSAL Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-10-json-ld
17:02:19 <azaroth> +1
17:02:19 <gkellogg> +1
17:02:20 <dlehn> present+
17:02:21 <dlongley> +0
17:02:30 <pchampin> +1
17:02:32 <azaroth> RESOLVED: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-10-json-ld
17:02:37 <azaroth> TOPIC: Announcements?
17:02:58 <azaroth> TOPIC: Issues
17:03:02 <bigbluehat> present+
17:03:12 <timCole> timCole has joined #json-ld
17:03:14 <azaroth> SUBTOPIC: Syntax #323
17:03:17 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/323
17:03:33 <ivan> q+
17:03:47 <azaroth> ack ivan
17:04:29 <manu> present+
17:04:44 <gkellogg> ivan: This is really pchampin’s area, but there is a problem with how we define the JSON datatype (value space) is that we convert the JSON text into a datatypes defined in XSD and are used in RDF.
17:05:16 <gkellogg> … There are some funny situations that come up, where for example “1”^^rdf:JSON and “1”^^xsd:boolean are the same, which is wrong.
17:05:45 <gkellogg> … THe rdf:HTML datatype uses the DOM, which doesn’t revert to primitive types. We don’t have anything like that in JSON land.
17:05:53 <pchampin> s/xsd:boolean/xsd:integer/
17:06:17 <gkellogg> … I think the only correct way to do it is to say that the value space is a JSON string. This seems odd, but really it’s just a JSON string per the spec.
17:06:55 <gkellogg> … Then we have a way to compare two values, as defined by JSON. We do indeed have a mixture of data in JSON for which we have no control.
17:07:02 <pchampin> q+
17:07:16 <gkellogg> … I think that such a change might be substantial and we’d need to go through a more formal CR update.
17:07:34 <azaroth> So if I understand correctly, the question is whether "true"^^xsd:boolean === "true"^^rdf:json ?
17:08:02 <gkellogg> pchampin: I agree with ivan; I’m not sure we can take your solution, as the JSON RFC may not describe the semantics of equality.
17:08:02 <azaroth> ack pchampin
17:08:08 <azaroth> q+
17:08:17 <gkellogg> ivan: We do have in our space a way to compare two JSON literals.
17:08:28 <hsolbrig> hsolbrig has joined #json-ld
17:08:34 <hsolbrig> present+
17:08:45 <gkellogg> pchampin: We had to do this because the RFC doesn’t. The most natural thing was to refer to other types. Hence the confusion.
17:08:55 <timCole> present+
17:09:13 <gkellogg> ivan: The comparison process goes into converting to the internal representation for comparison. Otherwise, the value space is a string.
17:09:35 <azaroth> ack azaroth
17:09:38 <gkellogg> azaroth: The question is whether or not “true”^^xsd:boolean is the same as “true”^rdf:JSON?
17:10:10 <gkellogg> ivan: The way we define the value space is sort of a union of integers, booleans and and so forth. That’s wrong.
17:10:27 <pchampin> q+
17:10:32 <ivan> q+
17:10:57 <azaroth> ack pchampin
17:10:58 <gkellogg> azaroth: There is no expectation that the syntax of the JSON is comparible to the semantics of other datatypes. You don’t need to understand that “true” is a valid boolean in JSON to implement the rdf:JSON datatype.
17:11:46 <gkellogg> pchampin: I didn’t think it was “wrong”, but it opens a Pandora’s block regarding other specs. It could be expected that OWL processors recognize this value, which could be a problem.
17:12:18 <gkellogg> … There might be issues with numbers which might make it _actually_ wrong, as numbers are not very clear.
17:12:19 <azaroth> q?
17:12:27 <azaroth> ack ivan
17:12:55 <dlongley> +1
17:12:58 <azaroth> +1 to Ivan
17:13:02 <dlongley> +1 rdf:JSON is opaque
17:13:11 <bigbluehat> +1
17:13:19 <gkellogg> ivan: The whole reason we went into this is because we want some portion of the JSON-LD to be opaque for RDF processing; our intention was that, but by turning it into an active datatype, we do something that wasn’t intended.
17:13:21 <gkellogg> q+
17:13:23 <azaroth> ack gkellogg
17:13:26 <azaroth> scribe+
17:13:42 <azaroth> gkellogg: I'll echo ivan's point. Point was not to make a literal that should be cmpard with other things, but is simply JSON
17:13:47 <dlongley> just a way for JSON to travel in RDF
17:14:05 <ivan> q+
17:14:12 <azaroth> ... because of normalization, which is not normative, every processor would create the same literal representation. Should ahve said that the value space is the string representing that serialization
17:14:18 <azaroth> ... and to compare as strings.
17:14:20 <azaroth> ack ivan
17:14:52 <dlongley> +1 to ivan
17:14:54 <gkellogg> ivan: In an ideal world where there was a canonical JSON spec, we could say that the value space is a canonical version of the JSON serialization.
17:15:09 <dlongley> +1 to "value space is a canonical version of the JSON serialization"
17:15:13 <gkellogg> … We do define a canoncialzation.
17:16:06 <gkellogg> ivan: Then we could be a bit more precise based on our C14N description.
17:16:20 <azaroth> PROPOSAL: Change the definition of the value space of rdf:JSON datatype to remove the reference to the internal datatypes and replace with a string which is the canonical form of the serialization of the JSON
17:16:28 <gkellogg> dlongley: Seems like the eright thing to do to me.
17:16:30 <dlongley> +1
17:16:31 <pchampin> +1
17:16:31 <ivan> +1
17:16:32 <hsolbrig> +1
17:16:33 <gkellogg> +1
17:16:33 <timCole> +1
17:16:34 <azaroth> +1
17:16:40 <bigbluehat> +1
17:16:45 <azaroth> RESOLVED: Change the definition of the value space of rdf:JSON datatype to remove the reference to the internal datatypes and replace with a string which is the canonical form of the serialization of the JSON
17:16:51 <pchampin> q+
17:17:31 <gkellogg> azaroth: This is normative text that changes how the datatype is defined/interpreted, I’d have a hard time arguing that it’s an editorial issue.
17:17:36 <gkellogg> q+
17:17:41 <azaroth> ack pchampin
17:18:10 <gkellogg> pchampin: As we’re nit-picking, we should not define it as a subset of XSD represesntations, but as a separate value space.
17:18:18 <azaroth> ack gkellogg
17:18:20 <pchampin> s/XSD/xsd:string/
17:19:05 <azaroth> +1
17:19:18 <gkellogg> ivan: I wasn’t suggesting we republish now.
17:19:38 <gkellogg> azaroth: But, we do think it’s significant enough to re-enter CR.
17:20:00 <gkellogg> ivan: What gkellogg said, when kasei has “finished”, we can do a republication.
17:20:57 <azaroth> PROPOSAL: Above resolution is a significant change, and that we will need to re-start CR. Re-publication would when current commenters issues have been addressed.
17:21:20 <azaroth> +1
17:21:22 <pchampin> +1
17:21:24 <ivan> +1
17:21:24 <dlongley> +1
17:21:25 <gkellogg> azaroth: kasei is using PERL to start with, and will port to a more modern language later.
17:21:25 <bigbluehat> +1
17:21:26 <gkellogg> +1
17:21:26 <timCole> +1
17:21:30 <hsolbrig> +1
17:21:42 <azaroth> RESOLVED: Above resolution is a significant change, and that we will need to re-start CR. Re-publication would when current commenters issues have been addressed.
17:22:02 <azaroth> q?
17:22:12 <ajs6f_> present+
17:22:51 <gkellogg> ivan: Is there a minimum period of implementation? Do we have to delay based on that limitation?
17:23:11 <dlongley> i think you can do a really short CR, especially if changes are not significant
17:23:31 <azaroth> From process 2019:
17:23:41 <azaroth> > Revising a Candidate Recommendation ... must specify the deadline for further comments, which must be at least 28 days after publication, and should be longer for complex documents,
17:23:51 <azaroth> https://www.w3.org/2019/Process-20190301/#revised-cr
17:24:34 <gkellogg> ivan: 28 days is not that bad. Our original deadline was end-of-February.
17:24:49 <gkellogg> … We’d need to postpone the dealine until mid-March if we miss that.
17:25:00 <gkellogg> … We’re still well within our window.
17:25:49 <gkellogg> … We could, in theory, republish syntax without API, but probably best until review is finished.
17:26:46 <gkellogg> azaroth: We can probably consolodate our changes into something simpler.
17:27:05 <azaroth> q?
17:27:08 <gkellogg> ivan: Let’s make them clean.
17:27:28 <azaroth> TOPIC: DID WG and JSON-LD
17:28:10 <gkellogg> manu: It;s again that time of year when a W3C WG is going to re-do JSON-LD :)
17:29:00 <gkellogg> … The DID WG adopted the WG spec some time ago; more recently, there’s a group from the Identity Foundation that says they don’t need JSON-LD, that it adds complexity and security issues and the extensibility model is to complex, etc.
17:29:24 <manu> https://github.com/w3c/did-core/pull/142
17:29:25 <gkellogg> … There all have rational answers, and they don’t really understand JSON-LD to start with.
17:29:55 <gkellogg> … As an example, this PR makes processing more explicit, and it has over 103 comments.
17:30:09 <manu> https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html
17:30:12 <gkellogg> … We built the spec so you don’t need to run a JSON-LD processor.
17:30:21 <gkellogg> … (Note summary is issues).
17:30:58 <gkellogg> … It’s sort of like “XML namespace are bad” and JSON-LD is don’t the same, and the spec (DID) doesn’t need it.
17:31:19 <pchampin> afk for a while
17:31:29 <gkellogg> … In the past, we try to address concerns one by one in the WG, but that takes time.
17:31:56 <gkellogg> … This means that going into feature freeze in March will be difficult, as there are other things to spend time on.
17:32:18 <gkellogg> … It comes up time and time again. (activity pub, credentials, now DiD).
17:32:34 <gkellogg> … I don’t think there’s a clean solution, it’s more social than technical.
17:32:57 <gkellogg> … For example, if you stick to a subset, you don’t need to run through processing.
17:33:25 <gkellogg> … But, that doesn’t seem to be “good enough”.
17:33:44 <gkellogg> … The DiD WG meeting is in 2 weeks, and we’ll discuss there.
17:33:55 <bigbluehat> q+
17:33:59 <gkellogg> q+
17:33:59 <azaroth> ack bigbluehat
17:34:21 <azaroth> q+ to ask what we can do (without inventing teleportation as a dependency)
17:34:41 <gkellogg> bigbluehat: There’s also another call today, and then there’s another call to discuss JSON-LD before F2F.
17:35:14 <gkellogg> … If you could give us a link to those issues, it would help.
17:35:45 <gkellogg> … I wanted to bring this up as it’s a perennial issue, but it’s always a big time sink.
17:35:51 <dlongley> (we've explained to the group that by using `@protected` and an unchanging core `@context` JSON-only software can hard-code checking the `@context` field for a specific string and then just use the JSON keys they know like usual, but this isn't "taking" or isn't good enough at the moment)
17:36:11 <manu> q+ to note that tooling is a big part of the problem.
17:36:14 <dlongley> (either because it isn't understood or it isn't "believed")
17:36:41 <gkellogg> … There’s a myth that noone uses namespaces in JSON, but it’s really don’t all the time.
17:36:53 <dlongley> s/don't/done
17:37:09 <azaroth> q?
17:37:21 <ivan> +1 to bigbluehat
17:37:21 <azaroth> ack gkellogg
17:37:25 <gkellogg> … We need something that can be used to counter such claims. Going down the pure JSON path creatse it’s own problems.
17:37:30 <azaroth> scribe+
17:37:53 <azaroth> gkellogg: My observation is one thing that keeps coming up is the remote loading of contexts.  A profile that did not allow that might satisfy a lot of those issues.
17:38:15 <azaroth> ... it strikes me that something necessary is a note that can encapsulate these various things. A common profile that might be more normative than a note
17:38:23 <dlongley> +1 to the idea that JSON-only software/special verification software should "install" contexts locally and never load them
17:38:24 <azaroth> ... then we can refer to it once and not keep coming vback to it
17:38:25 <azaroth> q?
17:38:27 <azaroth> ack azaroth
17:38:27 <Zakim> azaroth, you wanted to ask what we can do (without inventing teleportation as a dependency)
17:38:28 <dlongley> remotely
17:38:36 <manu> q+ to mention that we've already done a limited profile in VCs and DIDs that don't load remote contexts.
17:38:46 <ivan> q+
17:38:54 <gkellogg> azaroth: I could be on your next call if it would help.
17:39:09 <dlongley> q+
17:39:10 <gkellogg> … What can we do that will help?
17:39:13 <hsolbrig> q+
17:39:24 <azaroth> q?
17:39:25 <azaroth> ack manu
17:39:25 <Zakim> manu, you wanted to note that tooling is a big part of the problem. and to mention that we've already done a limited profile in VCs and DIDs that don't load remote contexts.
17:40:02 <gkellogg> manu: There are a couple of things that feed into it. When you talk to each person, they have different motivations, but their solution is to just use JSON.
17:40:21 <gkellogg> … They haven’t yet walked down the road to need such extensibility.
17:40:51 <gkellogg> … Some people are being ignorant because they have a single simple use case, and are inflicting their “solution” on everyone else.
17:41:26 <gkellogg> … Best was is to engage with that individual to expose other problems that JSON-LD solves.
17:42:01 <gkellogg> … This WG could engage in those issue discussions, so it’s not just me and dlongley being “apologists”
17:42:58 <gkellogg> … The other thing is to be involved more directly in the DiD working group. There is a minority of participants who understand JSON-LD.
17:43:39 <gkellogg> … The people who are using it are doing so on faith. When we have breakouts there is a small minority of people that understand why we’re using JSON-LD, and it creates an awkward social dynamic.
17:44:15 <gkellogg> … In the long-term, the assumptions on writing best practices is that people will read it, which they won’t.
17:44:55 <gkellogg> … The fundamental issue is that there isn’t enough JSON-LD tooling. On Android, there isn’t a good Java processor, so they complain.
17:45:23 <gkellogg> … Also, in RDF Dataset Normalization, those libraries don’t exist in C++/C, and so people can’t do bindings.
17:45:56 <gkellogg> … As a result, they view it as being overly complex. Note that everyone uses SSL and don’t complain about the complexity, because they don’t have to think about it.
17:46:36 <gkellogg> … We’re several years into JSON-LD and still don’t have pervasive implementations. The browser folks have the tooling, so it’s not an issue there.
17:46:50 <gkellogg> … It’s the embedded space where we need implementations.
17:47:07 <azaroth> q?
17:47:08 <gkellogg> … Fundamentally, it’s a tooling issue.
17:47:11 <azaroth> ack ivan
17:48:02 <azaroth> q+ to offer to be present and silent to hear from the horse's mouth
17:48:05 <gkellogg> ivan: I need to mind my dual role, but for the next DiD meeting, I don’t know if it would help if there were suddenly 3-4 more people joining the call. The call is to collect issues to be discussed at F2F.
17:48:18 <manu> I completely agree with Ivan, showing up on that call will help JSON-LD WG understand the concerns from the people that have them.
17:48:26 <gkellogg> … In the last call, we went into some technical meat, but that’s not the goal right now.
17:48:44 <azaroth> q?
17:49:15 <gkellogg> … azaroth and bigbluehat, I’d love to see you regularlly attend, but maybe not just for this call.
17:49:44 <gkellogg> … I agree with manu’s discussion on tooling; We had a similar duality in publishing, but it wasn’t as heavily discussed.
17:50:24 <gkellogg> … We discussed some processing of the context, but ignore the heavy usage of JSON-LD.
17:51:01 <gkellogg> … It turned out to be much less straightforward to use a full library as turning things into a graph resulted in another set of missing tools.
17:51:33 <gkellogg> … What this group could do is to get a huge improvement in the tooling, even in JavaScript.
17:52:00 <manu> q+ to note that it's valuable for JSON-LD WG members to hear the JSON-only people speak about JSON-LD -- these are valid concerns, we are not meeting their needs.
17:52:02 <gkellogg> … Even that rdf.js is hard to use for this community.
17:52:12 <azaroth> ack dlongley
17:53:19 <ivan> q+
17:53:23 <gkellogg> dlongley: We made a couple of mistakes in naming that are hard to change. Such as “remote contexts” could have been called “shared” or “external”; maybe the spec could add some non-normative notes to show that they don’t necessarily need to be retrieved remotely.
17:53:53 <gkellogg> … So, you just “npm install” the packages and they’re available to an implementation,.
17:54:09 <azaroth> ack hsolbrig
17:54:11 <gkellogg> … If we can change the discussion around these things it would help.
17:54:32 <azaroth> zakim, close queue
17:54:32 <Zakim> ok, azaroth, the speaker queue is closed
17:55:19 <gkellogg> hsolbrig: I represent some communities that come from a very differnet space. For example healthcare uses FIHR, which is very much RDF/OWL focused. We’re trying to put these things together, and JSON-LD proved to be necessary to make this happen.
17:55:49 <gkellogg> … We’re putting together a set of tutorials on why RDF is in your future, because if you don’t have it, you’ll need to re-invent it.
17:56:03 <azaroth> q?
17:56:05 <bigbluehat> +1 to dlongley's suggestion for something like `npm install did-context` -- i.e. contexts can be "installed" they don't have to be remote
17:56:12 <gkellogg> … We can assign semantics to things fairly easily using JSON-LD.
17:56:28 <azaroth> ack azaroth
17:56:28 <Zakim> azaroth, you wanted to offer to be present and silent to hear from the horse's mouth
17:56:31 <gkellogg> … There’s a lot of enthusiasm about this, and our group is quite excited.
17:56:50 <gkellogg> azaroth: Would it be valuable to be present and silent?
17:56:52 <azaroth> ack manu
17:56:52 <Zakim> manu, you wanted to note that it's valuable for JSON-LD WG members to hear the JSON-only people speak about JSON-LD -- these are valid concerns, we are not meeting their needs.
17:57:11 <gkellogg> manu: It would be valuable to for this WG to show up and sit and listen.
17:57:24 <dlongley> +1000 to sitting and listening for this stuff and helping understand where others are coming from
17:57:33 <azaroth> q?
17:57:35 <azaroth> ack ivan
17:58:06 <gkellogg> ivan: In our communication there’s an under-exploited feature is that the context can be deivered to a JSON file via HTTP.
17:58:27 <pchampin> you mean vi "http headers"
17:58:27 <dlongley> notes that DID Documents don't necessarily travel over HTTP
17:58:33 <bigbluehat> q+
17:58:36 <gkellogg> … If you have a person working only in JSON a well setup server can deliver JSON easily, and we don’t talk about it.
17:58:37 <dlongley> but useful in other areas
17:58:54 <gkellogg> azaroth: Meaning Link headers.
18:00:13 <azaroth> TOPIC: Adjourn
18:00:21 <ivan> zakim, end meeting
18:00:21 <Zakim> As of this point the attendees have been azaroth, ivan, gkellogg, dlongley, pchampin, dlehn, bigbluehat, manu, hsolbrig, timCole, ajs6f_
18:00:24 <Zakim> RRSAgent, please draft minutes
18:00:24 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/17-json-ld-minutes.html Zakim
18:00:27 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
18:00:31 <Zakim> Zakim has left #json-ld
18:01:19 <ivan> rrsagent, bye
18:01:19 <RRSAgent> I see no action items