00:04:32 RRSAgent has joined #json-ld 00:04:32 logging to https://www.w3.org/2019/09/19-json-ld-irc 00:04:33 rrsagent, set log public 00:04:33 rrsagent, this meeting spans midnight 00:04:33 Meeting: JSON-LD Working Group F2F in Fukuoka — First day 00:04:33 Date: 2019-09-19 00:04:33 Agenda: http://tinyurl.com/y34nfpfg 00:04:33 ivan has changed the topic to: Meeting Agenda 2019-09-19: http://tinyurl.com/y34nfpfg 00:04:34 Regrets+ 00:04:34 Chair: azaroth, bigbluehat 00:04:43 present+ 00:04:56 present+ 00:05:50 present+ 00:06:08 azaroth has joined #json-ld 00:06:08 present+ 00:09:05 azaroth has joined #json-ld 00:10:14 ttps://mit.webex.com/mit/j.php?MTID=m792442d12074490aa495ecaa0df1ff3a 00:10:16 https://mit.webex.com/mit/j.php?MTID=m792442d12074490aa495ecaa0df1ff3a 00:14:13 We hear you :) 00:16:14 scribe+ gkellogg 00:16:29 topic: Introductions 00:16:51 azaroth: I’m Rob, co-chair. Architect at J Paul Getty Trust 00:16:54 scribe+ 00:17:08 gkellogg: Gregg Kellogg, chief editor for the spec, and invited expert to the group 00:17:26 ivan: Ivan Herman, W3C staff contact, mostly in France 00:17:50 bigbluehat: Benjamin Young, co-chair, work for J Weily 00:18:37 scribejs, set tpk Duy-Tung Luu 00:18:39 s/J Weily/John Wiley & Sons, Inc. 00:18:51 guests+ tpk 00:19:03 tpk: Duy-Tung Luu, in data science and ML. I did a PhD in statistics. In my company, there is a web semantics project, so I came here ot lear. 00:19:15 … Canton Consulting 00:19:44 scribejs, set ssstolk Sanders Tolk 00:19:50 guests= ssstolk 00:19:54 ssstolk: Saunders Stolk, I work for Semmtech. 00:20:01 guests+ ssstolk 00:20:05 s/Saunders/Sanders/ 00:20:09 guests+ tpk 00:20:23 … We’re using LD for our clients to help in infrastructure to share information on buildings from design, building to maintanence. 00:20:34 … In NL near Shipol 00:20:49 azaroth: topic: Review of accomplishments 00:20:53 s/Shipol/Schiphol/ 00:21:02 TOPIC: Review of Accomplishments 00:21:21 bigbluehat: Virtual click-through slide deck 00:21:36 azaroth: We’re close to CR. There are three open issues. 00:22:04 pchampin: Pierre-Antoine Champin, an assoiate professor at Univ. Lyon. 00:22:26 … I’ve been on the WG for a year. My research is in SemWeb, also in RDF WG 00:22:35 … Also co-editor of the syntax doc. 00:23:02 azaroth: Three issues to consider, two this morning. 00:23:24 bigbluehat: This afternoon, we want to talk about string direction, which may bring in more outside visitors. 00:23:54 … Its of keen interest to a wide group; we thought it would be solved in RDF, but it may be on our shoulders. 00:24:53 ivan: Formally speaking, it may be worth adding an explicit issue, or reopening the old issue. #11 00:25:11 present+ 00:26:13 bigbluehat: version triggering is something to consider. 00:26:42 scribe+ bigbluehat 00:27:11 gkellogg: in most statements we do not include the nulls. one exception is JSON literals 00:27:27 ...but null is a valid JSON value, so there are reasons to keep them 00:27:48 ...pchampin pointed out a similar situation with strings, but that was an implementation issue 00:27:52 ...but it did help us find this 00:28:08 ...you can keep the `null` value currently by using the `@type: @json` 00:28:13 ...but in other cases we take it out 00:28:17 ...so we're at least inconsistent 00:28:27 ...it implies that there's some missing algorithm text 00:28:54 ...for preserving a key/value with a value of `null` 00:29:15 ...there are various options for preserving them 00:29:20 ...we could also decide not to 00:29:23 ...but I do think we can 00:30:13 ...if you expand it, and then re-expand it the `null` goes away...even when using the `@json` value type 00:30:42 issue: https://github.com/w3c/json-ld-syntax/issues/258 00:30:46 ...it's an editorial issue once we figure out how we want to handle it 00:30:50 ...because it's a lack of clarity 00:30:56 ...should be the work of an hour or two 00:31:39 azaroth: the question then is should the `null` be treated as a JSON literal null or should we remove the property 00:32:49 bigbluehat: Apache CouchDB and MongoDB (iirc) will remove keys set to `null` 00:32:59 azaroth: that's what this does in every other case...except the new `@json` type 00:33:45 ...I think it's more surprising for the `null` to go away if the type is `@json` than for it to stay around 00:34:38 ...but...do we want to still provide a way to remove the key/value? 00:34:49 ivan: why would we want to remove key/values? 00:34:54 bigbluehat: databases do it 00:34:59 azaroth: but this would be full statements 00:35:32 gkellogg: so most of the testing I've done was with numeric values and objects 00:35:42 q+ 00:36:08 ack pchampin 00:36:19 bigbluehat: is `null` on it's own a valid JSON value/document? 00:36:22 ...what would JSON.parse do? 00:36:25 gkellogg: it would keep it 00:36:45 pchampin: I'm playing around with the code right now, and gkellogg mentioned that re-expansion would get rid of it 00:36:55 ...I added the `@version: 1.1` 00:37:01 ...otherwise it doesn't work at all 00:37:15 ...and when I do it, it looks like we get an invalid value 00:37:47 gkellogg: part of the use of `null` is to eliminate contexts 00:38:28 ...you can certainly handle these by setting a 1.1 at the processor level--if the document itself doesn't set it 00:38:34 azaroth tests `JSON.parse("null")` in chrome, and the result is a real null 00:38:54 ...but you're right it could be restricted to 1.0-based processing 00:39:12 ...so we may need to update tests to use 1.1 mode 00:39:18 ...and test with expanded values 00:39:29 ...so setting the processing mode is probably the way to do it 00:42:13 PROPOSAL: WG believes that it is least surprising to process null as a JSON literal in this case, and not to remove the property in the internal representation, and thus the null should be preserved. 00:42:15 +1 00:42:18 +1 00:42:18 +1 00:42:21 +1 00:42:29 +1 00:42:42 RESOLVED: WG believes that it is least surprising to process null as a JSON literal in this case, and not to remove the property in the internal representation, and thus the null should be preserved. 00:42:43 +1 00:43:04 jc has joined #json-ld 00:43:09 present+ dlehn 00:44:16 Subtopic: keyword alias for `@id` and `@type` cannot be singly `@protected` 00:44:33 https://github.com/w3c/json-ld-syntax/issues/246 00:44:53 azaroth: if you alias `@type` to `type` it can still be a set 00:47:54 ...however, using `@protected` on an object-based term definition will not protect the `id` aliasing 00:48:07 ...so my proposal is that we change `@protected` to be a legal keyword for keyword aliases 00:48:59 gkellogg: does `@protected` protect the `@type` based aliasing? 00:49:27 azaroth: [adds more examples to 246] 00:50:27 ivan: the examples don't show any reason for the `@protected` 00:51:17 azaroth: [fixes examples] 00:51:32 q+ 00:52:29 q- 00:53:43 azaroth: [reads text from 4.1.5] 00:53:51 ...[reads text from 4.3.3] 00:55:10 gkellogg: looks like the API is correct 00:55:16 azaroth: ah, so they're out of sync 00:55:29 gkellogg: we do need more `@protected` text in this API section 00:57:09 azaroth: so the syntax fix is editorial 01:00:26 PROPOSAL: Allow the use of `@protected` as a valid keyword in term definitions which are aliases of keywords or where the term is `@type`. 01:00:28 +1 01:00:29 +1 01:00:33 +1 01:00:34 +1 01:00:44 +1 01:00:47 RESOLVED: Allow the use of `@protected` as a valid keyword in term definitions which are aliases of keywords or where the term is `@type` 01:01:05 Issue above: https://github.com/w3c/json-ld-syntax/issues/246 01:04:45 gkellogg: before we go on to the next issue, there are some visual things maybe we can solve 01:04:51 ...I've never liked the green stuff 01:04:53 ...for new items 01:05:23 ...since we already have some active JS in there 01:05:29 ...maybe we can toggle highlight changes in 1.1 01:14:08 group: [discusses various CSS related tweaks...decides to leave things as is] 01:14:23 gkellogg: but then there's "[Exposed=Window]" 01:14:29 ivan: why is that even needed? 01:14:34 ...let's just display: none it 01:14:43 ...it doesn't apply to us 01:16:36 ...since our use of WebIDL is not language specific or browser specific, there's no reason for this exposed window object thing 01:18:10 azaroth: there are a few other issues we should chip away at 01:18:24 Subtopic: 220 in syntax; move 9.3 and "default object" to framing only? 01:18:39 https://github.com/w3c/json-ld-syntax/issues/246 01:18:56 gkellogg: so things show up when they've been referenced 01:19:09 ...and the terminology here does make this confusing 01:19:26 ...we introduce these concepts, because many people who use these don't look at API documents 01:19:33 ...the frame is more of a hybrid document of syntax and api 01:19:40 ...we might just be being to explicit here 01:19:50 ...we even describe a frame object here for that matter... 01:20:10 azaroth: this doesn't really add much...and I'd suggest just removing 9.3 01:20:23 gkellogg: and there is an earlier reference to framing earlier 01:20:27 azaroth: so...yeah 01:20:37 gkellogg: and farther down, we introduce expansion, compaction, etc. 01:20:53 ...and there's a framed document form 01:23:27 bigbluehat: off topic, but I'd love to have expanded form explained earlier 01:23:35 ...too big a change right now...but maybe in the primer 01:23:42 ivan: it helps me too to think about expanded form 01:23:52 gkellogg: but back to this specific issue 01:24:04 ivan: right. frames are valid 1.1 documents now 01:24:11 ...so the syntax document has to call this out 01:24:30 azaroth: right, 5.4. explains it, and you can't understand 5.4 without 9.3 01:24:43 gkellogg: this issue can capture why its there 01:25:43 Subtopic: regarding expanded form earlier in the doc 01:26:02 gkellogg: maybe we just add a new section that talks a bit more about expanded form in the intro 01:26:17 ...that highlights that various forms exist and how they work 01:27:40 ivan: it's true that these other forms are helpful 01:28:10 bigbluehat: do we need an action for this? 01:29:40 gkellogg: maybe we can put a basic overview of just expanded form and its use in the intro/basic concepts section 01:29:56 ...and then to note that semantically the compacted + expanded are equivalent 01:30:14 ...even though syntactically they look different 01:30:48 Action: gkellogg to write a couple paragraphs + example(s) for explaining expanded form and its use 02:00:51 ivan has joined #json-ld 02:15:13 ivan has joined #json-ld 02:15:19 group: [discussing the implementations available and needed] 02:15:32 ...primarily C++ and Java need the most attention 02:23:14 ssstolk has joined #json-ld 02:24:22 http://drobilla.net/pages/contact.html 02:30:19 present+ 02:39:11 { 02:39:11 "@context": { 02:39:11 "@vocab": "https://example.com/", 02:39:13 "schema": "https://schema.org/", 02:39:15 "name": "schema:name" 02:39:17 }, 02:39:19 "name": { 02:39:21 "@value": "fish", 02:39:23 "@language": "en", 02:39:25 "@direction": "ltr" 02:39:27 } 02:39:29 } 02:41:20 +1 02:41:39 { "@context": ["http://schema.org/", { "@direction": null }], "tag:p": { "@value": "foo", "@language": "en", "@direction": "ltr" } } 02:41:49 scribe: manu 02:42:03 Discussion around use of @direction and how it affects JSON-LD 1.0 processors. 02:43:15 Seems that there is an issue wrt. the use of @vocab and @direction... processors are choking. 02:44:01 A bug exists in 1.0 and 1.1 that doesn't flag the use of @direction and @vocab. 02:44:07 Issue created: https://github.com/w3c/json-ld-syntax/issues/259 02:44:45 Current 1.0 processors are going to ignore use of @direction in various places. 02:47:17 {"@version": null} :-D 02:52:01 rob: Moving on to whether or terms can start with @ symbol. 02:52:26 rob: Currently, the spec is not clear wrt. SHOULD NOT vs. MUST NOT. 02:52:59 bigbluehat: This is why HTML is not versioned. 02:53:25 bigbluehat: I'm less concerned about two documents processing two documents differently... we don't want to touch old data, but we don't want to prevent accomodation of the future at the same time. 02:54:37 gkellogg: If HTML pages had something that wasn't interpreted, but then it would... like span, or blink, or marquee ... then there could be issues. 02:55:09 bigbluehat: When I use a newer processor, I'm aware that it's going to look different... I don't touch old data. 02:55:46 bigbluehat: I'd suggest you use a switching mechanism in processor... nuclear option is to use 1.1. 02:56:21 bigbluehat: If I point towards the past... I provide HTML5 document to HTML 3 processor, you don't lose data 02:56:36 bigbluehat: If you give @version to 1.0 processor, it explodes. 03:04:14 q+ 03:04:39 q- 03:05:03 manu: Yes, but the only consumers are schema.org and they'll just do 1.1. 03:05:10 q? 03:05:39 bigbluehat: yes, the evergreen browser argument 03:05:42 q+ 03:05:58 pchampin: Changing 1.0 parsers, if they don't fail on 1.1 parsers, they'll break on other things 03:06:10 q+ to mention feature detection/upgrades. 03:06:42 Feature Detection issue https://github.com/w3c/json-ld-syntax/issues/33 03:08:04 gkellogg: We have to do something intelligent when we hit @container: subway -- 1.0 will throw a syntax error, it should throw errors when it sees an issue. My feeling is that we should remove the explicit version announcement, and do feature detection when things are discovered and throw errors when they don't understand. 03:08:08 ack ivan 03:09:16 ivan: Another reason why I'm in favor of incremental stuff, in a weaker way than what you say, is because we have to look ahead, we'll have 1.1 now, but there'll be a different discussion on how to proceed when this WG stops... listening to presentation from yesterday, next charter whatever 2.0 - essentially, admin and names put aside, we'd be in a position to put one feature that we want to add to the language like direction. 03:09:30 q+ 03:09:33 ivan: If in a year from now, we add @direction, what do we do -- version 1.1.1 or version 1.2? 03:09:54 q? 03:10:02 q+ to note lunch :) 03:10:12 q+ 03:10:55 ack manu 03:10:55 manu, you wanted to mention feature detection/upgrades. 03:10:55 ivan: We get into versioning/naming issue... it's difficult to maintain... sometimes they release 5.3, they do incremental changes, then implementations catch up... we might have the same sort of future ahead of us, we should be careful to not make things too difficult... 1.1 as a standard adds new features, not necessarily a thing called a 1.1 processor, we hope we have processors that implement everything, that's the goal. 03:11:13 manu: so. the original `@version` proposal was a list of features 03:11:22 ...so if you were to process this document, you must support those features 03:11:32 ...if a processor can't support those, then it just blows up 03:11:40 ...and 1.1 was just an alias for a bundle of features 03:11:49 ...the issue we saw was that there might be a feature...well... 03:11:58 ...one, announcing them doesn't mean you'll be using them 03:12:14 ...or it might just get forgotten that you've left the "opt-in" around when you ended up not using it after all 03:12:24 ...so, the feature detection works best when it's also BC friendly 03:12:33 ...and that turns out to be rather hard 03:12:48 ...we'd have to go through each feature and determine how detectable they are 03:12:57 ...but the reason against that is that it's a huge amount of spec text 03:13:09 ...and we weren't sure that every new feature weren't able to figure those out 03:13:26 ...and they might determined it differently 03:13:35 ...which is why we were ultimately in favor of 1.1 03:13:48 ivan: so does that mean if we go into continuous development 03:13:53 manu: ...yeah. I'm against that also 03:14:08 ...I was opposed to this 1.1 work earlier...the 4 year gap was helpful for the stability of the data and community 03:14:17 q+ 03:14:18 q? 03:14:27 ivan: k...but if we keep shipping, then we'd just keep shipping these version number things 03:14:38 manu: yeah...but that gets complicated again 03:14:53 ...and if you look at HTML5, feature detection is insane 03:14:54 ack gkellogg 03:15:39 ...the earlier issues were about feature announcement not detection 03:15:55 gkellogg: the point of 1.1 was not so we'd have a 1.2 03:16:02 ...it was so we'd be locking things down 03:16:11 ...and that's principally done in context processing 03:16:19 ...and we did not do that properly in 1.0 03:17:01 ...so, virtually, I'd say 90% of features are discovered in `@context` processing 03:17:06 gkellogg: The original version was 1.1, was not to do 1.2, it was so we could detect things that should not be there in 1.0... if 1.2 added @direction, a 1.1 processor would fail if it saw it because it was not in the whitelist. 1.2 is not necessary to say @version 1.2 to do the right thing... virtually, 90% of feature issues are discovered in context processing, the exception is when processing expanded documents where there are some features used. 03:17:08 ...the others show up in expansion 03:17:27 q? 03:17:27 gkellogg: We do look for those in 1.1 mode and 1.0 mode... frame processing mode... 03:18:00 gkellogg: I think where we are detecting these things in expansion processing, maybe more needed for forward compatability, everything else is pretty much be in the @context processing phase. 03:18:15 ivan: If we had it today, @direction wouldn't be detected in @context. 03:18:22 gkellogg: If we had it in the context it would be. 03:18:43 ivan: If I just use it as part of the value, it's a 1.1 feature that I don't see in the @context. 03:19:16 gkellogg: Anything that looks like a keyword and the processor doesn't understand it, it should abort. 03:21:05 gkellogg: I disagree w/ manu, I think we can do feature detection. 03:21:26 manu: I don't think I said we'd use 1.1 when doing JSON-LD 5.0 03:21:42 ivan: isn't this an issue for stream processor? 03:21:43 ack azaroth 03:21:43 azaroth, you wanted to note lunch :) 03:21:56 gkellogg: Well, you could throw an error if you hit something... 03:22:00 q- 03:22:06 gkellogg: I think we'd be in a better position if we don't use @version. 03:22:27 ack ssstolk 03:22:33 rob: We need to break for lunch soon. 03:23:03 ssstolk: In some cases, it's important to break down with newer features used... it's a conscious choice to move from a 1.0 to a 1.1 interpreter... 03:23:45 ssstolk: There is something to be said to an interpreter breaking on a feature it doesn't understand, vs. a feature thing... parser, or implementation... 03:24:13 ssstolk: Depending on level of confidence, you use one or the other... this is something that people should be aware of anyway. 03:24:26 gkellogg: In some cases, in order to get behavior, you should be in validation mode. 03:25:28 bigbluehat: I want as much of data out of top of page, don't care about reviews, give me what you can give me. 03:26:00 ssstolk: To be able to post a snippet in a web page, does this have any unknown features for 1.1... so people can know, am I going outside of that... 03:26:40 gkellogg: It is using features that are defined in 1.1... if your parser dies, sometimes it helps if you have it all gathered. 03:27:01 azaroth has joined #json-ld 03:36:07 azaroth has joined #json-ld 03:42:15 simonstey has joined #json-ld 03:51:19 present+ 03:55:18 azaroth has joined #json-ld 04:01:04 azaroth__ has joined #json-ld 04:04:14 --> #wot 04:13:07 ivan has joined #json-ld 04:19:22 pchampin has joined #json-ld 04:26:43 ivan has joined #json-ld 04:41:49 gkellogg_ has joined #json-ld 04:47:30 addison has joined #json-ld 04:59:39 azaroth has joined #json-ld 05:00:49 azaroth_ has joined #json-ld 05:01:20 ivan has joined #json-ld 05:01:40 addison_ has joined #json-ld 05:02:01 ssstolk has joined #json-ld 05:02:12 Topic: I18N 05:02:48 Bert has joined #json-ld 05:02:48 chaals has joined #json-ld 05:02:53 present+ 05:02:58 present+ 05:02:58 scribe: manu 05:02:59 r12a has joined #json-ld 05:02:59 guests+ dan, chaals, addison, r12a, hadley, danbri 05:03:02 present+ 05:03:20 scribejs, set hadleybeeman Hadley Beeman 05:03:35 scribejs, set r12a Richard Ishida 05:03:48 scribejs, set chaals Charles Neville 05:03:57 burn has joined #json-ld 05:04:08 scribejs, set chaals Chaals Nevile 05:04:10 present+ Dan_Burnett 05:04:18 azaroth_: The issue that we want to talk about is notion of internationalization and feature of text direction of strings, which is not possible in underlying RDF data model. Proposal that came out of discussion was that it would be better for the infrastructure overall if JSON-LD did text direction. Absence of it already existing at RDF concepts layer... it would be better back port it into RDF from JSON-LD. 05:04:42 DavidClarke has joined #json-ld 05:04:57 r12a: We move the upper stories of the Eiffel tower first :) 05:05:14 s/r21a/aphillips/ 05:05:20 s/r12a/aphillips/ 05:05:43 present+ 05:05:44 aphillips: We are concerned that there is a window opened right now that so many specs are dependent on JSON-LD, we would like to make sure common serialization form for handling this, if we don't have something, we might have non-interop solutions for this. 05:05:53 scribejs, addison_ Addison Phillips 05:06:00 aphillips: We are interested in seeing if we can do something at this level, see if we can move this down to RDF level. 05:06:02 scribejs, set addison_ Addison Phillips 05:06:16 azaroth_: One question that would be good to answer, why isn't language sufficient to do this? 05:06:27 guests+ Bert 05:06:28 q+ to talk language 05:06:31 azaroth_: Why can't we just say English is ltr, arabic is rtl, and be done... 05:07:03 aphillips: You can infer base direction, but not the same as base direction information, like when you don't have accurate language metadata, or applying base direction isn't applicable. 05:08:05 present+ sangwhan 05:08:06 q+ 05:08:16 https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags 05:08:18 aphillips: Rather than doing coercion, we should have metadata slot rather than infering... that's the basis of it. Key aspect is that it has to do w/ mixed directional text... text that flows in one direction isn't a problem, text that starts or ends with an opposite direction, bring multiple strings together, you have spillover effects that are desirable. That's a challenge that we see as fairly fundamental. 05:08:20 ack chaals 05:08:20 chaals, you wanted to talk language 05:08:48 q? 05:08:53 chaals: There is another problem in RDF in particular, which is that RDF doesn't know anything about the language... lang=ar, you know it's rtl... the only modern language that you can't depict. 05:08:58 r12a: No, not true by a long shot. 05:09:15 s/depict/detect is azeri/ 05:09:17 chaals: RDF doesn't understand ar-kw ar-?? is all arabic 05:09:34 r12a: And new subtags are added all the time... 05:09:41 q? 05:09:51 chaals: You'd have to parse RDF language tags to get this partial solution 05:09:55 q+ danbri 05:09:58 q+ sanders 05:10:19 r12a: There was a point where we thought it would work... the URL that I just posed in IRC is the result of that. 05:10:24 https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags 05:10:58 q? 05:11:36 ack ivan 05:11:39 r12a: The conclusion we came to was that language wouldn't do the job... wrote two articles on Kashmiri - the language tagging that I used in both documents was ks, didn't put script info because I didn't need to... there is a lot of human stuff going on there. You don't know if it's rtl or ltr. Even I didn't feel like I needed to put subscript and relying on language. 05:12:20 ivan: Coming back to what addison said, whatever we do, there are cases that we cannot handle directly, and we shouldn't even go there. If we have text that internally mixes language, the only way we could handle that is to fall back on HTML encoding of content. 05:12:28 ivan: metadata only on the one string. 05:12:46 ivan: When yo uhave mixed text, we can't do that. 05:12:48 q? 05:13:34 ack danbri 05:13:36 aphillips: We just want base direction of whole string... there are bidi things that can happen on whole string. Supplied in form of HTML... set the base here... we're not talking about internal changes 05:13:50 q+ to follow the subtopic of what breaks if we make the proposed change 05:14:18 danbri: What RDF understands of the language structure... a lot of stuff you just pass through RDF... if you want to be able to write SPARQL queries, you'd have to have advanced knowledge of those language fields, you push the solution into the application. 05:15:02 aphillips: Language tag mapping, don't know what the subtags mean... SPARQL just does string matching, if you say 'bs' which stands for "bosnian", you need a "bs range" to match. 05:15:46 q? 05:15:50 aphillips: You still don't need to know what the tags and subtags mean... the hyphens tell you what the boundaries mean... it's deliberate, keep away from needing to read registry, use complex logic. 05:15:53 q+ 05:16:03 q+ to ask why this wasn't handled in BCP47? 05:16:28 aphillips: If you are doing complex matching, you need application logic. 05:16:46 ack sanders 05:16:53 danbri: We don't need to address fancy SPARQL query. 05:17:47 q? 05:18:23 sander: I was going to talk about lang matches, doens't fix solution for direction... you're probably aware of, if a solution is found for direction in JSON-LD, there may be multiple other types of language interpretation attributes to help with something that goes beyond direction... if there is a solution found in JSON-LD, it should also be a solution that should allow for other attributes as time goes by... it can be placed into the same construct. 05:18:35 q+ 05:18:50 ack chaals 05:18:50 chaals, you wanted to follow the subtopic of what breaks if we make the proposed change 05:19:04 chaals: If we follow this plan, what breaks? 05:19:21 ivan: What's the plan? Add syntax for @direction and add a new property 05:20:14 q? 05:20:59 -> https://w3c.github.io/rdf-dir-literal/#json-ld the proposed json-ld syntax 05:21:46 q+ danbri 05:21:52 Group looks at directions in rdf-dir-literal document. 05:22:55 ivan: Note that the document we are referring to (link above) describes a range of possible solutions. We suggested implementing the json-ld syntax in json-ld as a starting point, because it doesn't yet have a representation in RDF semantics 05:23:13 danbri has joined #json-ld 05:23:18 q? 05:23:19 ivan: We ended up saying this, if I put RDF hat on, there are downsides in practice, there are duplicated ways to represent literals in RDF... literal w/ language that RDF has today, in parallel we have another approach, might break some deployed OWL mechanisms, object properties, data properties, not a good solution, but possible solution... 05:23:22 ack ivan 05:23:28 gkellogg: We also discussed that this was a transitional solution. 05:24:04 q+ to emphasise loose coupling between json-ld surface syntax and current mapping to rdf 1.1 (does json-ld have flags/modes for parser) 05:24:24 ivan: Hope is in time, there is a more general mechanism in RDF, don't know if this will happen. Current proposed approach, maps nicely to JSON-LD, covers what sander wants. 05:24:54 ivan: What we discussed today, yes, this is doable, but what happens w/ existing JSON-LD data out there, and what are the effects... and answer is not that simple... 05:25:24 ack manu 05:25:24 manu, you wanted to ask why this wasn't handled in BCP47? 05:25:25 ivan: Adding the feature is easy, what happens to the process is not a big deal.... 05:25:48 manu: I really pushed to fix this, for verifiable credentials to be able to move on... 05:25:50 scribe+ chaals 05:26:16 … we rushed in to getting good ideas on the table. I am going to check whether this is really the right course. 05:26:17 q+ to question the damage of punning properties (equivalent to new datatype) vs -x BCP extension 05:26:19 q? 05:26:31 … seems like language tag does 95% of what we want, a lot of times. 05:26:53 … so it is true that people extract some text direction out of the language tag 05:27:03 addison: mostly right now it isn't used… 05:27:25