15:44:00 <RRSAgent> RRSAgent has joined #json-ld
15:44:00 <RRSAgent> logging to https://www.w3.org/2019/10/11-json-ld-irc
15:44:01 <ivan> rrsagent, set log public
15:44:01 <ivan> Meeting: JSON-LD Working Group Telco
15:44:01 <ivan> Date: 2019-10-11
15:44:01 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0004.html
15:44:01 <ivan> ivan has changed the topic to: Meeting Agenda 2019-10-11: hhttps://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0004.html
15:44:02 <ivan> Chair: azaroth
15:44:02 <ivan> Regrets+ bigbluehat
15:47:07 <azaroth> azaroth has joined #json-ld
15:48:08 <pchampin> pchampin has joined #json-ld
15:48:30 <azaroth> regrets+ Ruben_Taelman
15:55:59 <gkellogg> gkellogg has joined #json-ld
15:58:26 <gkellogg> present+
15:58:57 <ivan> present+
15:59:55 <dlongley> dlongley has changed the topic to: Meeting Agenda 2019-10-11: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0004.html
16:00:36 <dlongley> present+
16:01:35 <azaroth> TOPIC: Scribe Selection
16:01:38 <dlongley> scribe: dlongley
16:01:42 <ivan> scribe+ dlongley
16:01:43 <bigbluehat> present+ bigbluehat
16:01:51 <azaroth> TOPIC: Approve minutes of previous call:
16:02:00 <azaroth> PROPOSAL: Approve minutes of previous call   https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-04-json-ld
16:02:02 <gkellogg> +1
16:02:03 <azaroth> +0
16:02:04 <dlongley> +1
16:02:06 <bigbluehat> +1
16:02:09 <ivan> +1
16:02:12 <azaroth> RESOLVED: Approve minutes of previous call   https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-04-json-ld
16:02:17 <pchampin> +1
16:02:25 <dlongley> Topic: Announcements and reminders
16:02:37 <dlongley> azaroth: I wasn't on the call last week, any follow ups on the discussion on implementations?
16:02:43 <dlongley> gkellogg: No discussion last week on implementations.
16:02:55 <ivan> q+
16:02:57 <dlongley> azaroth: Anything else?
16:02:58 <azaroth> ack ivan
16:03:21 <dlongley> ivan: I think chairs already have the mail but on the 27th Europe goes winter time but the US does not yet, but we should expect the 2 weeks of biannual big mess.
16:03:52 <dlongley> November 3rd US
16:04:20 <dlongley> azaroth: Anything else?
16:04:28 <azaroth> TOPIC: Issues
16:04:43 <azaroth> SUBTOPIC:  Language-maps and @direction
16:04:51 <azaroth>  https://github.com/w3c/json-ld-syntax/issues/280
16:05:32 <ivan> q+
16:05:54 <dlongley> azaroth: With our introduction with `@direction` we can't then use the direction in a language map because you can't put the `@value` object as the value of the language map. We could change language maps to allow that but it's very very late in the day and it doesn't seem like there's a big need. No one is clamoring for this particular functionality.
16:06:01 <ivan> q-
16:06:26 <dlongley> azaroth: Any further clarification?
16:06:29 <dlongley> ivan: No.
16:06:33 <dlongley> gkellogg: It's pretty clear.
16:06:41 <bigbluehat> q+
16:06:45 <azaroth> ack bigbluehat
16:07:06 <dlongley> bigbluehat: Just a quick note that I've never seen direction in a key -- this language map format is semi common, even outside of JSON-LD, but never seen it.
16:07:10 <dlongley> bigbluehat: +1 to defer.
16:07:45 <dlongley> gkellogg: What you might imagine would be a combination of language and direction that would be similar for what we do with the i18n datatype. Where we separate language and direction with an underscore. I can imagine some future version that might do that. That might be more useful than allowing values that were value objects.
16:07:58 <dlongley> gkellogg: There's no demonstrated need to do this, so it's reasonable for us to hold off until a need is demonstrated.
16:07:58 <azaroth> PROPOSAL: Defer use of direction for text in language maps to a future version
16:08:01 <dlongley> +1
16:08:01 <ivan> +1
16:08:01 <azaroth> +1
16:08:02 <pchampin> +1
16:08:07 <gkellogg> +1
16:08:10 <bigbluehat> +1
16:08:21 <azaroth> RESOLVED: Defer use of direction for text in language maps to a future version
16:08:37 <azaroth> SUBTOPIC: Relationship with RDF/JS dataset
16:08:51 <dlongley> gkellogg: I'm wondering if it's more pressing for us to discuss the language tag normalization?
16:08:59 <ivan> q+
16:09:01 <azaroth> https://github.com/w3c/json-ld-api/issues/166
16:09:01 <dlongley> azaroth: Let's do this one first because I hope it will be equally quick then we'll do that.
16:09:04 <gkellogg> q+
16:09:04 <azaroth> ack ivan
16:10:00 <dlongley> ivan: It's a little bit like the previous thing. It's probably way too late to touch this, it's a bit unfortunate that this is the case, I'm playing with something that's using the RDF output of the jsonld parser in JavaScript. While I realized there is another API by the CG out there but I have to convert what I get from json-ld to that and it's unfortunate, but it's just too late.
16:10:16 <azaroth> q+
16:10:20 <dlongley> ivan: I think this is something we should put into the same bin as postponing ... and there may be backwards compatibility issues and it's not that simple to handle it.
16:10:22 <azaroth> ack gkellogg
16:11:06 <dlongley> gkellogg: I think perhaps we should lobby RDF/JS to include some additional interfaces to do it. We basically invented interfaces for datasets to support the needs of the algorithm to iterate over graphs and triples within that graph, the RDF/JS only allows iterating over quads.
16:11:28 <dlongley> gkellogg: If there was a way to add something to create a subset of a dataset that just represented just the quads for a graph then we could use that and it would be great.
16:12:03 <dlongley> gkellogg: Then we could align with these things, but given our need to separate the triples from the graph and that's true for pretty much everything else, TriG for instance, it seems like it would be really useful for that interface to provide for that.
16:12:08 <azaroth> ack azaroth
16:12:13 <dlongley> gkellogg: If they had that we could use it, otherwise we just have to defer.
16:12:16 <dlongley> +1 to gregg
16:12:32 <dlongley> azaroth: Given it's a CG spec we can't normatively refer to it.
16:12:42 <dlongley> azaroth: I'm also in favor of deferring.
16:12:47 <dlongley> q+
16:12:51 <dlongley> ivan: And keeping it open.
16:12:51 <azaroth> ack dlongley
16:13:26 <azaroth> PROPOSAL: Defer RDFJS integration to a future version, and work with the CG to ensure consistency
16:13:29 <gkellogg> +1
16:13:30 <ivan> +1
16:13:30 <azaroth> +1
16:13:34 <dlongley> +1
16:13:36 <pchampin> +1
16:13:38 <bigbluehat> +1
16:13:41 <azaroth> RESOLVED: Defer RDFJS integration to a future version, and work with the CG to ensure consistency
16:13:45 <dlongley> dlongley: As an author of the JS implementation we've tried to get alignment as much as possible up to this point.
16:13:53 <dlongley> dlongley: With RDF/JS's APIs.
16:13:59 <azaroth> SUBTOPIC: Language tag normalization
16:14:21 <gkellogg> https://github.com/w3c/json-ld-api/issues/167
16:14:46 <timCole> timCole has joined #json-ld
16:15:29 <dlongley> gkellogg: This is a slightly different issue, but they are quite related. One is that JSON-LD requires that language tags be normalized to lowercase. All other RDF concepts says that implementations MAY do that. My implementation does that and it is important for SPARQL querying otherwise you have to implement that at query time which is impractical for most of us.
16:15:36 <timCole> present+ Tim Cole
16:15:46 <dlongley> gkellogg: That's the genesis of that -- the fact that JSON-LD makes it a requirement is a little odd but it makes it easier to test the results.
16:15:51 <dlongley> gkellogg: Dave might have a recollection of that.
16:15:59 <ivan> q+
16:16:24 <azaroth> q+ re backwards compability
16:16:25 <azaroth> ack ivan
16:16:26 <dlongley> gkellogg: My thought is that we pull back on MUST and go to MAY and add a provision in the testing README that says for testing purposes, implementations need to consider that language tags need to vary so they can properly report.
16:16:30 <dlongley> q+
16:16:56 <dlongley> ivan: The problem I see with the current setup, if I do roundtripping, if I do one of the various algorithms and I take the outcoming one then it will all be normalized to lowercase.
16:17:06 <dlongley> gkellogg: It's not just RDF roundtripping, it happens in expansion.
16:17:43 <azaroth> q?
16:17:45 <dlongley> ivan: Yes, and the problem is that the habit in the i18n community is for whatever reason to say "en-UK" in capital letters. There are all kinds of additional rules that users may expect to see and that they use when they create JSON-LD and it will go away when it roundtrips and this may be surprises.
16:17:49 <dlongley> q-
16:17:50 <azaroth> ack azaroth
16:17:50 <Zakim> azaroth, you wanted to discuss backwards compability
16:18:19 <dlongley> azaroth: One thing to consider -- while, technically worth the proposal, we should consider the backwards compatibility with 1.0 that we're changing a requirement to reduce it down to a MAY.
16:18:32 <dlongley> azaroth: Any processor that's relying on that requirement may stop functioning.
16:18:34 <dlongley> q+
16:19:05 <ivan> q+
16:19:10 <azaroth> scribe+
16:19:13 <dlongley> gkellogg: That should properly exist in the normalization algorithm, it can sign any RDF, so if you're coming from any other format, so there is no guarantee coming from other syntaxes.
16:19:14 <azaroth> ack dlongley
16:19:22 <ivan> scribe+ azaroth
16:19:34 <azaroth> dlongley: Was just going to say it does need to be normalized for signing. Can put it to a different layer, but we can't prohibit it
16:19:50 <azaroth> ... tried to make it clear that normalization can happen and does need to with a concrete syntax
16:20:09 <azaroth> ... when you're serializing you need to output lowercase so it's the same binary stream of bytes to sign
16:20:14 <azaroth> ivan: only when you do a signature
16:20:22 <azaroth> ... but if you're just producing turtle there's no requirement
16:20:37 <azaroth> gkellogg: The output of the normalization routine is quads with special for bnodes
16:21:03 <azaroth> ivan: Question arose is that even if we agree to do it in an upper layer, the question to answer is there software that will break?
16:21:09 <dlongley> q+
16:21:13 <azaroth> ... other implementations of the signature for example
16:21:19 <azaroth> ack dlongley
16:21:25 <ivan> ack ivan
16:21:43 <azaroth> gkellogg: Not part of JSON-LD. If you were to normalize from another serialization it would still exist
16:21:57 <azaroth> dlongley: You are right. Not sure if we're changing from MUST or MUST NOT ... that would also have an impact
16:22:11 <azaroth> ... but as gregg is saying, the libraries should be normalizing
16:22:22 <azaroth> gkellogg: Recommendation is to follow RDF concepts and go with a MAY
16:22:40 <dlongley> azaroth: Any other thoughts?
16:23:23 <dlongley> azaroth: General agreement that the canonize libraries should be outputting lowercase anyway and we can remove this hard restriction.
16:23:49 <dlongley> azaroth: It seems like we should resolve to do it. It probably means creating a lot of changes to the test suite.
16:24:03 <dlongley> s/azaroth: It seems/gkellogg: It seems
16:24:15 <azaroth> PROPOSAL: Change requirement to lowercase language tags to be a MAY from MUST
16:24:20 <ivan> +1
16:24:20 <timCole> +1
16:24:20 <azaroth> +1
16:24:21 <pchampin> +1
16:24:22 <dlongley> +1
16:24:23 <bigbluehat> +1
16:24:24 <gkellogg> +1
16:24:32 <azaroth> RESOLVED: Change requirement to lowercase language tags to be a MAY from MUST
16:25:21 <dlongley> azaroth: There was a suggestion to do SHOULD...
16:25:31 <dlongley> gkellogg: No, I don't think we should do that, this aligns with other RDF serializations.
16:25:44 <azaroth> SUBTOPIC: Language tag values and validation
16:25:45 <dlongley> gkellogg: The other thing -- whether language tag values need to be validated.
16:26:34 <dlongley> gkellogg: Currently the specs say different things. The definition says the language tag MUST be well formed according to BCP47. But the algorithm says implementations must not attempt to fix any invalid IRIs or language tags. I think that's been interpreted to not validate language tags.
16:26:37 <dlongley> ivan: Why is it there?
16:26:46 <dlongley> gkellogg: I can see why you shouldn't fix URIs, but not language tags.
16:26:51 <dlongley> I don't recall either.
16:26:59 <azaroth> q+
16:27:23 <ivan> q+
16:27:27 <azaroth> ack azaroth
16:27:37 <gkellogg> JSON-LD Processors MUST NOT attempt to correct malformed IRIs or language tags; however, they MAY issue validation warnings. IRIs are not modified other than conversion between relative and absolute IRIs.
16:27:38 <dlongley> gkellogg: Clearly, to be consistent, to say they must be well formed then the algorithms should be updated and a version of Ruben's PR should be updated.
16:28:28 <dlongley> azaroth: I agree we're inconsistent. For the correcting, is the implementation that if there was say, an errant space, "en " that you shouldn't try to guess that it was just supposed to be "en"?
16:29:02 <dlongley> gkellogg: That's what the current text says. I believe the new text would say that that form of a language tag would be invalid and that processing for that step ... either the algorithm would be aborted at that point or that particular language tag would be ignored.
16:29:14 <azaroth> q?
16:29:17 <dlongley> gkellogg: I think for it to be an error would be that the promise would be rejected.
16:29:18 <azaroth> ack ivan
16:29:47 <dlongley> ivan: I think my feeling is that -- the promise is rejected but the whole JSON-LD processing throws up its arms or the language tag is ignored?
16:29:59 <dlongley> gkellogg: If we do that, the only way we have to do that is to issue a warning. Rejecting the promise means we abort the whole step.
16:30:23 <dlongley> azaroth: The question to me ... is this more like a syntax error, in which case we should abort because it's rubbish.
16:30:31 <dlongley> gkellogg: For any other RDF serialization it's an error.
16:30:32 <pchampin> q+
16:30:42 <dlongley> azaroth: Or is it more like an undefined property name at which point we'd ignore it.
16:30:46 <dlongley> q+ to say it's a syntax error and we should abort
16:31:00 <azaroth> ack pchampin
16:31:44 <dlongley> pchampin: I think we're very much in the case where we might break schema.org data. We have no data that people out there are using proper language tags and old processors accept them than we might make Dan Brickley very angry and rightfully so.
16:31:55 <azaroth> q?
16:31:57 <dlongley> pchampin: I would lean towards ignoring them as undefined properties.
16:31:59 <azaroth> ack dlongley
16:31:59 <Zakim> dlongley, you wanted to say it's a syntax error and we should abort
16:32:06 <gkellogg> 1+
16:32:09 <gkellogg> q+
16:32:20 <azaroth> dlongley: I'm of two minds. If this was a fresh spec without implementations, theres no question we should abort
16:32:23 <ivan> +1 to dlongley
16:32:31 <bigbluehat> +1 to dlongley
16:32:39 <azaroth> ... if we're concerned about existing systems, we should keep it rather than dropping it
16:32:39 <ivan> q+
16:32:42 <azaroth> ack gkellogg
16:33:18 <dlongley> gkellogg: I think that's a compelling argument. We should issue a warning but continue processing. The exception would be for the i18n datatype and compound literal, that would be an opportunity to lock that down. What we currently say is that we can't generate any invalid triples.
16:33:51 <dlongley> gkellogg: In the case that this was a language tag that didn't match the REGEX then it would be reasonable that we reject one coming from the i18n URI or the compound literal as a hard failure.
16:34:06 <azaroth> q?
16:34:09 <azaroth> ack ivan
16:34:10 <dlongley> gkellogg: That being the case, for warning purposes and rejection purposes, there are two options of REGEXes for how to verify that.
16:34:46 <dlongley> ivan: Yes, Dave's argument is compelling. The only thing we can say without any problems -- is that the processor MUST issue a warning from now on that this is illegal. But we should not stop processing.
16:34:52 <dlongley> +1 not testable
16:35:04 <dlongley> gkellogg: We don't have a way to test for warnings.
16:35:06 <azaroth> q?
16:36:03 <pchampin> q+
16:36:07 <dlongley> gkellogg: From Pierre-Antoine and Dave both -- I don't know how much data is there from schema.org ... we could say if you're in a hard 1.0 mode you let it pass but reject in 1.1 but that flies in the face of what we've been doing.
16:36:15 <azaroth> ack pchampin
16:36:21 <dlongley> gkellogg: We drop triples that are invalid and that's it, that's the current behavior.
16:36:52 <dlongley> pchampin: If we did specify a way to turn warnings into errors, and that's often a standard kind of thing, we could force those tests to use this mode and get the error and that would make it testable.
16:37:07 <dlongley> gkellogg: I think the way we'd do that is to add an option to treat language tag problems as errors.
16:37:25 <dlongley> gkellogg: There are other places we generate warnings.
16:37:46 <dlongley> azaroth: The current behavior, per the issue, is that current processors may issue validation warnings but they don't have to.
16:37:47 <dlongley> q+
16:37:50 <azaroth> ack dlongley
16:39:08 <dlongley> dlongley: I would only support doing a hard error if we found that existing implementations already did it.
16:39:08 <dlongley> gkellogg: I think since all expansion tests are toRDF tests -- anything that failed to transform would have been caught.
16:41:12 <azaroth> PROPOSAL: Update the API conformance section to say that invalid language tags SHOULD generate a warning
16:41:17 <ivan> +1
16:41:17 <azaroth> +1
16:41:23 <bigbluehat> +1
16:41:24 <gkellogg> +1
16:41:26 <timCole> +1
16:41:31 <pchampin> +1
16:41:32 <dlongley> +1
16:41:38 <azaroth> RESOLVED: Update the API conformance section to say that invalid language tags SHOULD generate a warning
16:42:07 <dlongley> gkellogg: The question becomes how do we validate language tags, there are some different REGEXes out there.
16:42:36 <dlongley> gkellogg: RDF might accept something that is not a valid language tag ... because it's REGEX is more loose.
16:43:08 <dlongley> gkellogg: In the RDF translation it's not just a warning.
16:43:10 <dlongley> q+
16:43:13 <azaroth> ack dlongley
16:43:26 <gkellogg> [144s] LANGTAG                        ::= "@" [a-zA-Z]+ ( "-" [a-zA-Z0-9]+ )*
16:43:39 <azaroth> +1
16:43:50 <gkellogg>  obs-language-tag = primary-subtag *( "-" subtag )
16:43:50 <gkellogg>    primary-subtag   = 1*8ALPHA
16:43:51 <gkellogg>    subtag           = 1*8(ALPHA / DIGIT)
16:44:45 <dlongley> ivan: Turtle is much looser -- the regex from BCP47 is way more complicated, multi line, etc.
16:44:49 <pchampin> q+
16:44:58 <dlongley> gkellogg: There may be something even more complicated than what's in BCP47.
16:45:44 <pchampin> a-
16:45:45 <pchampin> q-
16:45:45 <azaroth> PROPOSAL: Use the less strict RDF regex, not BCP47's, to determine validity
16:45:49 <dlongley> pchampin: I wanted to point out -- Ivan you pointed me at the awful regex and that one is trying to qualify the different parts of the BCP47. It was for capturing the various parts in a language tag, the other one for validation is much simpler.
16:45:52 <azaroth> +1
16:45:58 <pchampin> +1
16:45:58 <dlongley> +1
16:45:59 <ivan> +1
16:46:45 <timCole> +0
16:46:59 <dlongley> gkellogg: Given that, I'd vote for BCP47 ... I think the only difference is in specifying it, it's not a real difference.
16:47:00 <dlongley> q+
16:47:03 <azaroth> ack dlongley
16:47:06 <gkellogg> +0
16:47:51 <dlongley> gkellogg: It's only compatible when other syntaxes have accepted something that's incompatible with BCP47.
16:48:04 <bigbluehat> +1
16:48:13 <dlongley> ivan: I think we would get problems if we weakened our check from before. From the i18n people in particular.
16:48:17 <dlongley> ivan: They checked Turtle.
16:48:43 <dlongley> ivan: It might be a bug report for Turtle/on the RDF specs.
16:48:53 <dlongley> gkellogg: Because they can accept things that aren't legal BCP47.
16:49:12 <dlongley> q+
16:49:26 <azaroth> ack dlongley
16:50:27 <azaroth> PROPOSAL: Use stricter BCP47 syntax and file an errata for RDF to request an update to its definition to match BCP47
16:50:28 <dlongley> ivan: The i18n review was ineffective ... it was much weaker. Let alone the issue around direction. This also shows it was weak, I didn't realize that but that's the way it is. I think it's a bug over there.
16:50:34 <azaroth> +1
16:50:35 <dlongley> +1
16:50:37 <ivan> +1
16:50:39 <gkellogg> +1
16:50:40 <pchampin> +1
16:50:43 <timCole> +1
16:50:46 <bigbluehat> +1
16:50:53 <azaroth> RESOLVED: Use stricter BCP47 syntax and file an errata for RDF to request an update to its definition to match BCP47
16:51:35 <azaroth> SUBTOPIC: Lazy evaluation of processing mode
16:52:33 <dlongley> azaroth: At TPAC, we discussed with Dan Brickley and others some of the requirements for enforcing a processor mode and why we have `@version` and why it's a number and so forth. Manu was there and the discussion was that there are times that you need to enforce the processing mode and it's valuable and other times you don't need it and you can do a lazy upgrade.
16:53:00 <dlongley> azaroth: We can determine this via the test suite because the tests are flagged with version/proceessing mode. It would therefore be better for backwards compatibility to allow 1.1 to upgrade without requiring the other 1.1 things.
16:53:27 <dlongley> azaroth: So it would be better that you must use 1.1 processing vs. only doing it when you see version 1.1 declared.
16:53:29 <gkellogg> q+
16:53:32 <azaroth> ack gkellogg
16:54:18 <dlongley> gkellogg: That is essentially it. The issue is, what happens when a 1.1 processor does differently than a 1.0 processor because it fails to detect those features and the sense of the group was that that consideration is in publisher's hands by choosing to use 1.1 features and not putting 1.1 in their context they are saying they are ok with that.
16:54:29 <dlongley> gkellogg: For the usage of their particular data. Whereas we would encourage that they do it, we won't enforce it.
16:54:38 <ivan> q+
16:54:42 <azaroth> ack ivan
16:54:47 <dlongley> gkellogg: The benefit of that is that we can get much more incremental adoption of 1.1 features with minimal downside.
16:55:24 <dlongley> ivan: The only additional thing we said at TPAC is that, to be careful, we would mark this lazy eval as At Risk -- because there was a general feeling that we might discover it's too complicated for implementation reasons and therefore we drop it and do it the strict way.
16:55:33 <azaroth> q?
16:55:38 <dlongley> q+
16:55:42 <bigbluehat> scribe+ bigbluehat
16:55:48 <azaroth> ack dlongley
16:56:03 <bigbluehat> dlongley: I wasn't at TPAC, but I'm in favor of trying to get more 1.1 adoption
16:56:13 <bigbluehat> ...I'm in favor of it being marked "at risk" in case it doesn't work out
16:56:26 <bigbluehat> ...I think this is a good path forward to find out if we can make it happen
16:56:34 <bigbluehat> timCole: the "at risk" approach sounds right to me
16:57:08 <dlongley> ivan: This should be put into the document.
16:57:28 <azaroth> ACTION: gkellogg to update docs regarding lazy evaluation of processing mode
16:57:51 <dlongley> azaroth: Any other business?
16:58:35 <dlongley> azaroth: That's it, thanks to Dave for scribing, we'll have a call in another week, thanks to Gregg for all the work.
16:58:37 <dlongley> +1
16:59:15 <ivan> rrsagent, draft minutes
16:59:15 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/11-json-ld-minutes.html ivan
16:59:15 <ivan> zakim, bye
16:59:15 <Zakim> leaving.  As of this point the attendees have been gkellogg, ivan, dlongley, bigbluehat, Tim, Cole
16:59:15 <Zakim> Zakim has left #json-ld
16:59:17 <azaroth> TOPIC: Adjourn