15:22:43 <RRSAgent> RRSAgent has joined #json-ld
15:22:43 <RRSAgent> logging to https://www.w3.org/2019/03/22-json-ld-irc
15:22:44 <ivan> rrsagent, set log public
15:22:44 <ivan> Meeting: JSON-LD Working Group Telco
15:22:44 <ivan> Chair: azaroth
15:22:44 <ivan> Date: 2019-03-22
15:22:44 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0036.html
15:22:44 <ivan> ivan has changed the topic to: Meeting Agenda 2019-03-22: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Mar/0036.html
15:22:45 <ivan> Regrets+ simonstey, ruben
15:45:47 <azaroth> azaroth has joined #json-ld
15:49:36 <pchampin> pchampin has joined #json-ld
15:52:21 <azaroth> present+ Rob_Sanderson
15:53:49 <pchampin> present+
15:58:20 <bigbluehat> present+
15:58:30 <gkellogg> present+
16:01:50 <dlehn> present+
16:01:57 <dlongley> scribe: dlongley
16:02:07 <azaroth> scribenick: dlongley
16:02:47 <dlongley> ivan: Ruben is working on a streaming JSON-LD parser.
16:03:24 <dlongley> azaroth: Next week we will still have split DST and the week after that we'll get back together again on DST.
16:03:29 <dlongley> azaroth: Any other announcements or reminders?
16:03:32 <simonstey> simonstey has joined #json-ld
16:03:50 <dlongley> None
16:04:25 <simonstey> present+
16:04:29 <dlongley> present+
16:04:39 <ivan> regrets- simonstey
16:04:42 <workergnome> workergnome has joined #json-ld
16:04:55 <azaroth> PROPOSAL: Approve the minutes of the previous meeting: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-15-json-ld
16:04:59 <azaroth> +1
16:05:00 <dlongley> +1
16:05:01 <bigbluehat> +1
16:05:03 <gkellogg> +1
16:05:04 <simonstey> +1
16:05:06 <dlehn> +1
16:05:06 <pchampin> +1
16:05:15 <workergnome> +1
16:05:19 <ivan> +1
16:05:21 <azaroth> RESOLVED: Approve the minutes of the previous meeting: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-15-json-ld
16:05:38 <azaroth> TOPIC: Issues
16:05:41 <ivan> Topic: Issues
16:05:56 <azaroth> SUBTOPIC: Remove @omitdefault
16:06:05 <azaroth> link: https://github.com/w3c/json-ld-framing/issues/41
16:06:05 <dlongley> azaroth: The first issue we discussed briefly last call before we realized we needed to talk a bit more about it.
16:06:07 <gkellogg> https://github.com/w3c/json-ld-framing/issues/46
16:06:37 <dlongley> gkellogg: Another issue is to provide a better example for its use.
16:06:44 <dlongley> gkellogg: Of `@omitDefault`.
16:07:19 <dlongley> gkellogg: The issue is suggesting that `@omitDefault` is not particularly useful when you can just omit when using default. I think Dave had alluded to some examples where it was useful and that's why there's an issue open to highlight where it's actually useful.
16:07:21 <dlongley> q+
16:07:28 <dlongley> gkellogg: Otherwise we could remove it from the spec.
16:08:03 <dlongley> gkellogg: The only way to make a default is to use `@default`.
16:08:12 <azaroth> ack dlongley
16:08:16 <azaroth> scribenick: azaroth
16:08:48 <azaroth> dlongley: There's a few ways to have a default. THere's an interaction with explicit. A default of null, if the property is specified but not present. Then output has a default value of null
16:08:58 <azaroth> ... sometimes you don't want it with a value of null, but instead absent.
16:09:22 <azaroth> ... Also, if you had specified a default, and some other properties to have flags on them.
16:10:14 <jeff_mixter> jeff_mixter has joined #json-ld
16:10:20 <jeff_mixter> present+
16:10:38 <workergnome_> workergnome_ has joined #json-ld
16:10:40 <azaroth> ... a case would be when you say 'foo' and you want to embed:always for foo.
16:10:52 <azaroth> ... [example]
16:11:07 <azaroth> scribenick: dlongley
16:11:14 <azaroth> q?
16:11:17 <dlongley> gkellogg: Ok, I think you've made a case for why it needs to be there. Having implemented it I still don't understand the need for it. As long as you take on the responsibility of better documenting the use of `@omitDefault`.
16:11:18 <timCole> timCole has joined #json-ld
16:11:52 <dlongley> gkellogg: If you can provide an example so we can adequately spec it that would be sufficient.
16:13:03 <azaroth> ACTION: dlongley to provide example in issue 41 of omitdefault need
16:13:57 <azaroth> SUBTOPIC: `@embed @first`
16:13:59 <azaroth> link: https://github.com/w3c/json-ld-framing/issues/43
16:15:04 <dlongley> gkellogg: We touched on this one. Originally, `@embed` was true or false, if it was true then one of the uses within a node would contain the embedded value vs. just a reference. That was expanded because it was useful to be able to say "we want all of them" because it would make it much simpler so clients don't have to follow pointers. Also embed `@link` was added for navigating an internal representation.
16:15:35 <dlongley> gkellogg: We updated it to be the keyword value. And `@last` was a little arbitrary and the last one expressed in the frame would have the embedded value and `@first` would be a little more efficient as you don't have to remove other embeds.
16:15:51 <pchampin> q+
16:16:22 <dlongley> gkellogg: First and last implies ordering and all of the ordering is optional and if you don't have order then first and last are non-sensical, so Dave said to use `@once` but then testing is hard.
16:16:50 <azaroth> ack pchampin
16:16:51 <workergnome_> q+
16:16:54 <dlongley> gkellogg: This proposal, given that ordering is an option, it makes sense that we also makes sense to be able to say `@first` vs. `@last` and it's a separate issue for how these behave or if we need something different if we are not ordering.
16:17:19 <ivan> q+
16:17:24 <dlongley> pchampin: Just an idea on the terminology, `@first` and `@last` are misleading ... perhaps `@earliest` to `@latest` or something like that. To make the terms less confusing.
16:17:28 <azaroth> ack workergnome_
16:17:59 <dlongley> workergnome_: Going through the issue, I'm trying to understand the optionalness of the sorting. It feels like what we're trying to make sure we can do is compare two JS objects as strings.
16:18:34 <dlongley> gkellogg: That sort of gets into canonicalization -- I believe the tests say we should do a comparison of objects so that ordering isn't important for comparing but also compare the resulting RDF graphs for isomorphism.
16:18:46 <azaroth> q+ to ask about embedding and first/last
16:19:01 <dlongley> gkellogg: But it does make it important to know which of the properties get included in the node or a given subject, in that case, it doesn't change the RDF signature. They all will be references to another object. It's really in the JSON thing.
16:19:14 <dlongley> gkellogg: Whether you compare unordered or ordered, it still matters where the embedding takes place.
16:19:37 <dlongley> gkellogg: The only way to satisfy these cases is so that you run the algorithm so it does process the properties in order. Otherwise you can't do a structural comparison of the result.
16:20:10 <dlongley> workergnome_: I can say that I have sometimes reordered the properties ... to match documentation. It shouldn't do that if you use a different keyword. If you do anything to change the order of the JS it doesn't change the meaning of the graph.
16:20:20 <dlongley> gkellogg: It is sort of a corner case where you have the same thing referred to multiple times.
16:20:25 <pchampin> q+
16:20:39 <dlongley> workergnome_: And it comes up all the time in our data structures. Every time we want to talk about a first name we have an included object that defines first namedness.
16:20:47 <dlongley> workergnome_: We do use repeated signatures throughout the graph.
16:21:21 <dlongley> azaroth: I can dig up an example. The ordering of the name is arbitrary, the order of the ... firstnamedness and middlenamedness you don't want to mix that up.
16:21:29 <dlongley> azaroth: So we do post processing to make sure it's in the right order to look sane.
16:21:30 <azaroth> q?
16:21:31 <azaroth> ack ivan
16:22:33 <dlongley> ivan: In general, I am really bothered by this. As an author of JSON-LD ... if I really want to control how the framing works... I have to be aware of somewhat arbitrary ordering in the system that is against my way of ordering my properties in my object.
16:22:49 <dlongley> ivan: For me, the whole thing is flawed.
16:22:51 <azaroth> q?
16:22:53 <azaroth> ack azaroth
16:22:53 <Zakim> azaroth, you wanted to ask about embedding and first/last
16:23:24 <dlongley> azaroth: My understanding is very similar to David Newberry's ... if the ordering is important and that will determine where things will be embedded...
16:23:24 <dlongley> q+
16:23:55 <dlongley> azaroth: Then the structure will potentially be very very different depending on the names of the keys. It would be very weird to have to put numbers at the beginning of every key to make sure they end up in the right place.
16:24:06 <dlongley> ivan: I have to do this elsewhere and I hate it.
16:24:43 <dlongley> azaroth: If the intent is that the structure should be comparable -- then we don't need `@first` ... it's just a flag that says "it goes here" such that it will be comparable.
16:24:45 <gkellogg> q+ to say that embedding is for developers
16:25:16 <dlongley> azaroth: Then I don't think that alphanumeric sorting will help, you don't want `type` appearing at the end or in the middle.
16:25:31 <azaroth> q?
16:25:35 <azaroth> ack pchampin
16:25:41 <bigbluehat> scribenick: bigbluehat
16:25:48 <bigbluehat> pchampin: I'm not sure I'm following ivan's arguments
16:25:52 <bigbluehat> ...about the expectations of the authors
16:25:58 <bigbluehat> ...to me JSON objects are unordered
16:26:04 <ivan> q+
16:26:18 <bigbluehat> ...as annoying as that is, I don't expect the order I've written to be preserved
16:26:33 <bigbluehat> ...the thing I queued up originally was to ask about `@min` and `@max`
16:26:42 <bigbluehat> ...to be the smallest or highest key that one can find
16:26:46 <azaroth> q?
16:26:47 <bigbluehat> ...that would be reproducable
16:26:49 <azaroth> ack dlongley
16:26:50 <bigbluehat> ...and avoid key ordering
16:27:03 <bigbluehat> dlongley: so just looking at all this, I would remove all of the ordering
16:27:13 <bigbluehat> ...and anything out of any algorithm that would attempt any ordering at all
16:27:32 <bigbluehat> ...and highlights that the ordering of constituents back then was incorrect
16:27:38 <bigbluehat> ...we mostly did this ordering for the test suites
16:27:43 <ivan> +1 to dlongley
16:27:47 <bigbluehat> ...original name was `@once`
16:27:55 <bigbluehat> ...but what we bumped up again was how do we test this?
16:28:02 <bigbluehat> ...because you can get really complicated output
16:28:20 <bigbluehat> ...you can't test from the RDF, because that isn't the point of framing
16:28:58 <bigbluehat> ...what I recommend we do, is in the test suite
16:29:01 <bigbluehat> ...we order the keys in a certain way
16:29:28 <bigbluehat> ...let's somehow get the ordering into the test suite
16:29:32 <bigbluehat> ...and out of the algorithms
16:29:35 <azaroth> +1 to dlongley - ordering in the test suite, not in the spec
16:29:42 <bigbluehat> ...so that we can still test correct ordering in the test suite
16:29:45 <jeff_mixter> +1 to dlongley
16:29:53 <bigbluehat> ...and removing it out of the algorithm will also speed things up
16:29:57 <azaroth> q?
16:30:00 <azaroth> ack gkellogg
16:30:00 <Zakim> gkellogg, you wanted to say that embedding is for developers
16:30:02 <bigbluehat> ...leaving it where it is will just confuse users anyhow
16:30:06 <bigbluehat> ...so removing it is a win for them also
16:30:13 <bigbluehat> gkellogg: ordering in the test suite helps
16:30:23 <bigbluehat> ...it's been updated to not do order based testing of objects
16:30:31 <bigbluehat> ...so I think the issue is about where to do the embedding
16:30:35 <dlongley> -1 !
16:30:42 <dlongley> q+
16:30:43 <bigbluehat> ...so we should either do no embedding or  embed everywhere
16:30:56 <bigbluehat> ...anytime you get into having to compare length of strings, you're doing ordering
16:31:03 <bigbluehat> ...ordering kills performance
16:31:15 <bigbluehat> ...the issue of having `@first` is predicated on having `@last`
16:31:24 <bigbluehat> ...so what I think we're debating now is should there be any reason to have these at all
16:31:34 <azaroth> q?
16:31:37 <azaroth> ack ivan
16:31:40 <bigbluehat> ...so maybe we only normatively require `@none` and `@always`
16:31:44 <gkellogg> https://w3c.github.io/json-ld-api/tests/#json-ld-object-comparison
16:31:53 <bigbluehat> ...there is a section in the test suite README about how we do object comparison
16:32:04 <azaroth> q?
16:32:05 <azaroth> ack dlongley
16:32:06 <bigbluehat> ivan: I wanted to answer pchampin, but I think we've moved past that
16:32:10 <bigbluehat> ...but +1 to dlongley about removing this
16:32:31 <bigbluehat> dlongley: there's no way we can just limit this to `@none` and `@always` because there are lots of reasons to just embed one
16:32:48 <workergnome_> q+
16:32:53 <bigbluehat> ...there are lots of use case where data comes in from somewhere, and you need to pluck out the proof or whatever single thing
16:33:04 <bigbluehat> ...and then you need to do some processing on those
16:33:19 <bigbluehat> ...and if you inject new triples, that will ruin the data for that processing
16:33:43 <azaroth> ack workergnome_
16:33:44 <bigbluehat> ...so you don't care where the data occurs, just that it *does* occure
16:33:51 <bigbluehat> workergnome_: I want to second that
16:34:06 <bigbluehat> ...I'd like to create shallow set of look-up types
16:34:10 <bigbluehat> ...I don't care where it is
16:34:22 <azaroth> q?
16:34:22 <bigbluehat> ...but it would be really obnoxious to have to dedupe it, etc
16:34:25 <gkellogg> q+
16:34:28 <azaroth> ack gkellogg
16:34:32 <bigbluehat> ...but where it shows up in the structure is not something I'd ever trust
16:34:50 <bigbluehat> gkellogg: then what makes since would be to change `@last` to `@once` and then figure out how to test it
16:35:05 <bigbluehat> ...so when we're testing we can't do object comparison
16:35:30 <bigbluehat> ...and again this sort of goes against the whole purpose of framing...but we would need to flatten the structure to do the comparison
16:35:38 <bigbluehat> azaroth: I think we're ready for a proposal
16:36:02 <azaroth> PROPOSAL: Change `@last` (back) to `@once`, don't add `@first` and then figure out testing separately
16:36:05 <dlongley> +1
16:36:06 <azaroth> +1
16:36:07 <gkellogg> +1
16:36:07 <ivan> +1
16:36:07 <workergnome_> +1
16:36:07 <bigbluehat> +1
16:36:09 <dlehn> +1
16:36:20 <timCole> +1
16:36:23 <pchampin> +1
16:36:23 <simonstey> +1
16:36:38 <jeff_mixter> +1
16:36:39 <azaroth> RESOLVED: Change `@last` (back) to `@once`, don't add `@first` and then figure out testing separately
16:36:50 <azaroth> q?
16:37:00 <simonstey> Because, the default for the object embed flag is @first (in addition to the explicit inclusion flag being false), 
16:37:18 <azaroth> q?
16:37:30 <bigbluehat> dlongley: should be `@once` now because it doesn't add any triples to the graph
16:37:40 <bigbluehat> s/should be/default should be
16:37:52 <azaroth> SUBTOPIC: JSON datatype
16:37:52 <bigbluehat> azaroth: we also have discussed the JSON datatype on github
16:37:55 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/4
16:38:11 <bigbluehat> gkellogg: you've been the most involved (as always)
16:38:17 <bigbluehat> ...could you summarize?
16:38:42 <bigbluehat> gkellogg: the issue comes down to representation
16:38:57 <bigbluehat> ...if you are going to describe both the lexical and value space
16:39:00 <bigbluehat> ...somewhat like HTML
16:39:08 <bigbluehat> ...the lexical space cannon be guaranteed
16:39:19 <bigbluehat> ...the JSON literal quality is lost when its turned into a native representation
16:39:23 <azaroth> s/gkellogg: you've/azaroth: gkellogg, you've/
16:39:30 <bigbluehat> ...you loose the original key ordering, key escaping, and lexical numerical representations
16:39:52 <bigbluehat> ...so it seems we will need to canonicalize
16:40:02 <bigbluehat> ...which has been referenced in the issue
16:40:14 <bigbluehat> ...it's sadly not as close to done as I'd hoped
16:40:21 <bigbluehat> ...and we can't count on it being final in time
16:40:32 <bigbluehat> ...so, do we care if two implementations use the same canonicalization
16:40:52 <bigbluehat> ...so we have done some things about do we use Integer or Doubles for numbers
16:41:12 <bigbluehat> ...so when you'd turn the JSON literal into RDF (in the toRDF space), we do need to say something about that at least
16:41:17 <bigbluehat> ...and the elimination of whitespace
16:41:21 <bigbluehat> ...and the ordering of keys
16:41:29 <bigbluehat> ...I think that can be done
16:41:30 <azaroth> q?
16:41:42 <azaroth> q+ to note the HTML canonicalization discussion of last time we talked about it
16:41:42 <bigbluehat> ...there's a lot of detail in that, but we should be able to reference ECMAScript for this
16:41:47 <ivan> q+
16:41:50 <azaroth> ack azaroth
16:41:50 <Zakim> azaroth, you wanted to note the HTML canonicalization discussion of last time we talked about it
16:41:51 <bigbluehat> ...or  we could do it ourselves
16:42:02 <bigbluehat> azaroth: last time we talked about the canonicalization issue
16:42:13 <bigbluehat> ...we also talked about HTML being not easily canonicalizable
16:42:30 <bigbluehat> gkellogg: HTML is a little different
16:42:38 <bigbluehat> ...they will preserve order, and whitespace
16:42:45 <bigbluehat> ...so you do have the opportunity return to that result
16:42:53 <bigbluehat> ivan: well, attribute order and things are not covered
16:43:10 <bigbluehat> ...this would be a problem if you were to attempt to sign an HTML document
16:43:29 <bigbluehat> gkellogg: if we weren't in an era when signatures weren't as important as they are now, then maybe we wouldn't need to care about this so much
16:43:40 <pchampin> q+
16:43:47 <bigbluehat> azaroth: so, is there a JSON-LD document that could include a JSON "native" data type that also needs to be signed
16:44:00 <dlongley> q+
16:44:02 <bigbluehat> ...so if the only use case is to import GeoJSON
16:44:07 <azaroth> ack ivan
16:44:21 <bigbluehat> ...do we need to worry
16:44:28 <bigbluehat> ivan: I have spent time on this issue with others
16:44:39 <bigbluehat> ...aside from the canonicalization problem
16:45:10 <bigbluehat> ...if we do make a native JSON type, we will have to put it into some namespace--rdf: or jsonld:
16:45:11 <azaroth> +1 to RDF namespace
16:45:25 <bigbluehat> ...if we do that, we'll have to write the SWIG mailing list, to announce the new datatype, etc.
16:45:30 <bigbluehat> ...we can do this as part of our document
16:45:42 <bigbluehat> ...the other problem is
16:45:55 <bigbluehat> ...I did put a reference in the issue for the rules we have to follow when we point to something normatively
16:46:24 <bigbluehat> ...my first reading is that unfortunately, this JSON canonicalization specification cannot be referred to normatively
16:46:41 <bigbluehat> ...the third problem is bringing our own canonicalization into our document
16:46:53 <bigbluehat> ...if we do that, I can safely say the Director would say no to that
16:47:14 <bigbluehat> ...so, we can't just take an IETF spec and put it into a W3C spec
16:47:20 <bigbluehat> ...all of these are admin problems
16:47:31 <bigbluehat> ...I am still not convinced that we need the canonicalization as a normative part of our spec
16:47:49 <bigbluehat> ...we could say that someone else may do this and reference forthcoming work
16:48:03 <bigbluehat> ...but when the issue is that we have a JSON portion we want to store in RDF
16:48:22 <azaroth> q+ to propose that having a non-officially-canonicalized JSON datatype is better than no JSON datatype
16:48:28 <bigbluehat> ...we can state that the only expectation is that [the same processor will produce the same output]
16:48:36 <azaroth> q?
16:48:44 <azaroth> ack pchampin
16:48:58 <bigbluehat> ...none of the arguments that I heard is that canonicalization needs to be normative
16:49:09 <azaroth> ack dlongley
16:49:20 <azaroth> q+ dlongley
16:49:33 <pchampin> http://tinyurl.com/y2gmzxf8
16:49:46 <bigbluehat> pchampin: I was wondering about this example
16:49:54 <bigbluehat> ...there's an Integer in the non-canonical form
16:50:00 <bigbluehat> ...would that be canonicalized or not?
16:50:12 <bigbluehat> gkellogg: yes, that would be canonicalized
16:50:22 <bigbluehat> ...I don't know any processors that would properly serialize that with a leading zero
16:50:27 <bigbluehat> ...if you're going to the internal representation
16:50:33 <bigbluehat> ...it is the number 42
16:50:37 <bigbluehat> ...some might do 42.0
16:50:42 <bigbluehat> ...or 42E+0
16:50:52 <bigbluehat> ...that would be fine, but I don't think most JSON serializers would do that
16:50:57 <bigbluehat> pchampin: for the moment, we know how to sign this thing
16:51:01 <azaroth> q?
16:51:02 <azaroth> ack dlongley
16:51:11 <bigbluehat> dlongley: I think this falls into the same category as HTML
16:51:21 <bigbluehat> ...it's a string in the JSON; it's not native HTML
16:51:29 <bigbluehat> ...or a native number in the example's case
16:51:38 <bigbluehat> ...if we're storing stuff in a string, then store it as a string
16:51:48 <bigbluehat> ...but people want a native JSON object in their JSON
16:51:59 <bigbluehat> pchampin: but if you remove the leading 0 you don't get the same signature
16:52:04 <ivan> q?
16:52:08 <ivan> q+
16:52:21 <bigbluehat> ...so I'm assuming that the signature is dealing with the order or absence of order in the object when signed
16:52:34 <bigbluehat> ...so if the object was a native JSON object, then it would already benefit
16:52:38 <azaroth> ack azaroth
16:52:38 <Zakim> azaroth, you wanted to propose that having a non-officially-canonicalized JSON datatype is better than no JSON datatype
16:52:45 <dlongley> q+
16:52:47 <bigbluehat> ...and regardless we already have this problem with other string-expressed literals
16:52:49 <gkellogg> q+
16:52:55 <bigbluehat> azaroth: if you instead make it value 42.0
16:53:07 <bigbluehat> ...since no one really serializes as 042
16:53:17 <bigbluehat> ...whatever you change here will change the signature
16:53:29 <bigbluehat> ...even though it will canonicalize as something different
16:53:34 <bigbluehat> dlongley: I disagree
16:53:39 <bigbluehat> azaroth: what do you disagree with?
16:53:44 <bigbluehat> ack ivan
16:54:02 <bigbluehat> ivan: I think in these examples, the current JSON-LD specification doesn't say anything about what you put in strings
16:54:18 <bigbluehat> ...we don't suggest any sort of mini-canonicalization for things like this
16:54:33 <bigbluehat> ...having built-in canonicalization for the native JSON representation
16:54:37 <azaroth> q?
16:54:38 <azaroth> ack dlongley
16:54:41 <bigbluehat> ...would be a departure from what we've done previously
16:54:55 <bigbluehat> dlongley: my response to all that is that we have very consistent rules about moving non-string data into strings
16:55:01 <bigbluehat> ...so we do have those sorts of specifications
16:55:08 <bigbluehat> ...from a native JSON value into a string
16:55:26 <bigbluehat> ...this same thing would exist for native JSON objects
16:55:37 <bigbluehat> ...for things that come in via a string, those will stay as whatever that string is
16:55:44 <bigbluehat> ...so strings have no issue
16:55:59 <bigbluehat> ...so if you take pchampin's example, and change it to a real number: 42
16:56:13 <azaroth> q+
16:56:13 <gkellogg> 42, 42.0, 42.0E0, 4.2E+1 are all the same number
16:56:14 <bigbluehat> ...and if you put that in the playground, check the nquads tab, you'll find the same number
16:56:21 <bigbluehat> ivan: k. I acknowledge htat
16:56:29 <bigbluehat> azaroth: maybe then it's the playground which is at fault
16:56:48 <bigbluehat> ...I put in several examples, and the signature changes for all of these different 42's as an integer
16:57:03 <bigbluehat> dlongley: you're looking at the RSA signature, so you'll see it change constantly
16:57:08 <bigbluehat> ...because that injects random data
16:57:18 <bigbluehat> ...what you need to look at is the N-Quads or normalized tabs
16:57:22 <bigbluehat> ...the data there stays the same
16:57:25 <azaroth> q?
16:57:27 <azaroth> ack gkellogg
16:57:29 <bigbluehat> gkellogg: this is in the data round tripping section
16:57:31 <azaroth> q-
16:57:40 <bigbluehat> gkellogg: so, imo, if we create a datatype for JSON
16:57:45 <bigbluehat> ...before there is a canonicalization for it
16:57:50 <bigbluehat> ...then we're in danger of doing things too early
16:57:56 <ivan> +1
16:58:02 <bigbluehat> ...ultimately we need to deal with a canonicalized JSON
16:58:03 <pchampin> +1
16:58:07 <bigbluehat> ...so the best thing we can do right now is nothing
16:58:16 <ivan> q+
16:58:16 <bigbluehat> ...and defer this until there is a canonicalized form
16:58:24 <bigbluehat> ...otherwise whitespace, object ordering, etc are all variable
16:58:36 <azaroth> q+
16:58:41 <bigbluehat> ...and the literals really won't be worth doing any lexical representation is important
16:58:42 <azaroth> ack ivan
16:58:51 <bigbluehat> ...better not to do anything until a canonicalization spec exists
16:58:59 <bigbluehat> ivan: my take would be milder
16:59:08 <bigbluehat> ...the GeoJSON example doesn't care about canonicalization
16:59:12 <azaroth> +1 to ivan
16:59:16 <bigbluehat> ...with the canonicalization things differed
16:59:24 <bigbluehat> ...and state that this feature is not recommended
16:59:58 <bigbluehat> ...so we differ it, and if/when the canonicalization becomes standard or whatever, then we at that point suggest that that spec gets used
17:00:00 <dlongley> q+ to say implementations should produce a JSON string (using the same rules from the IETF draft) but it isn't required
17:00:01 <azaroth> ack azaroth
17:00:02 <dlongley> q-
17:00:21 <bigbluehat> azaroth: it would be better to have a JSON datatype and state that later we'll do canonicalization
17:00:29 <azaroth> q?
17:00:36 <dlongley> let's provide rules for how to produce the JSON string that match the draft -- but that you can do something else and be very clear it's preferred that everyone do the same thing
17:00:37 <bigbluehat> ...so we should start with JSON datatypes, and just suggest that you can't sign these
17:00:39 <jeff_mixter> +1 to ivan and azaroth
17:01:15 <bigbluehat> gkellogg: if we don't do canonicalization now, we don't seem to be prevented from doing it later
17:01:33 <bigbluehat> ...if we end up as a living spec, then we could do it that way
17:01:44 <bigbluehat> ...and we could also suggest that for testing purposes it is always canonicalized
17:01:52 <bigbluehat> azaroth: a warning or a note?
17:01:55 <azaroth> PROPOSAL: Move forwards with a JSON native data type, with a warning that it cannot be canonicalized
17:01:55 <bigbluehat> ...I'd suggest a warning
17:02:00 <gkellogg> +1
17:02:01 <jeff_mixter> +1
17:02:02 <ivan> +1
17:02:03 <azaroth> +1
17:02:05 <simonstey> +1
17:02:07 <pchampin> +1
17:02:08 <timCole> +1
17:02:13 <dlongley> +0
17:02:17 <bigbluehat> +0 still have concerns about eager misuse
17:02:19 <ivan> present+ timCole
17:02:28 <bigbluehat> q+
17:02:32 <azaroth> ack bigbluehat
17:02:50 <workergnome> workergnome has joined #json-ld
17:02:53 <dlehn> +0.5
17:03:48 <jeff_mixter> I echo bigbluehat concerns but I also have very valid reasons to add JSON to RDF data.
17:04:15 <dlongley> +1 to everything Benjamin is saying ... but that we should really also have JSON literals ... but they should also all be converted to the same strings in processors :)
17:04:29 <workergnome> +1
17:05:09 <azaroth> RESOLVED: Move forwards with a JSON native data type, with a warning that it cannot be canonicalized
17:05:32 <dlongley> JSON literals can be an escape hatch but ONLY an escape hatch.
17:05:33 <azaroth> TOPIC: Adjourn
17:05:51 <ivan> https://github.com/w3c/json-ld-wg/issues?q=is%3Aissue+is%3Aopen+label%3Aaction
17:09:01 <ivan> rrsagent, draft minutes
17:09:01 <RRSAgent> I have made the request to generate https://www.w3.org/2019/03/22-json-ld-minutes.html ivan