IRC log of json-ld on 2019-09-19
Timestamps are in UTC.
- 00:04:32 [RRSAgent]
- RRSAgent has joined #json-ld
- 00:04:32 [RRSAgent]
- logging to https://www.w3.org/2019/09/19-json-ld-irc
- 00:04:33 [ivan]
- rrsagent, set log public
- 00:04:33 [ivan]
- rrsagent, this meeting spans midnight
- 00:04:33 [ivan]
- Meeting: JSON-LD Working Group F2F in Fukuoka — First day
- 00:04:33 [ivan]
- Date: 2019-09-19
- 00:04:33 [ivan]
- Agenda: http://tinyurl.com/y34nfpfg
- 00:04:33 [ivan]
- ivan has changed the topic to: Meeting Agenda 2019-09-19: http://tinyurl.com/y34nfpfg
- 00:04:34 [ivan]
- Regrets+
- 00:04:34 [ivan]
- Chair: azaroth, bigbluehat
- 00:04:43 [gkellogg]
- present+
- 00:04:56 [bigbluehat]
- present+
- 00:05:50 [pchampin]
- present+
- 00:06:08 [azaroth]
- azaroth has joined #json-ld
- 00:06:08 [ivan]
- present+
- 00:09:05 [azaroth]
- azaroth has joined #json-ld
- 00:10:14 [gkellogg]
- ttps://mit.webex.com/mit/j.php?MTID=m792442d12074490aa495ecaa0df1ff3a
- 00:10:16 [gkellogg]
- https://mit.webex.com/mit/j.php?MTID=m792442d12074490aa495ecaa0df1ff3a
- 00:14:13 [azaroth]
- We hear you :)
- 00:16:14 [gkellogg]
- scribe+ gkellogg
- 00:16:29 [gkellogg]
- topic: Introductions
- 00:16:51 [gkellogg]
- azaroth: I’m Rob, co-chair. Architect at J Paul Getty Trust
- 00:16:54 [azaroth]
- scribe+
- 00:17:08 [azaroth]
- gkellogg: Gregg Kellogg, chief editor for the spec, and invited expert to the group
- 00:17:26 [gkellogg]
- ivan: Ivan Herman, W3C staff contact, mostly in France
- 00:17:50 [gkellogg]
- bigbluehat: Benjamin Young, co-chair, work for J Weily
- 00:18:37 [ivan]
- scribejs, set tpk Duy-Tung Luu
- 00:18:39 [bigbluehat]
- s/J Weily/John Wiley & Sons, Inc.
- 00:18:51 [ivan]
- guests+ tpk
- 00:19:03 [gkellogg]
- 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 [gkellogg]
- … Canton Consulting
- 00:19:44 [ivan]
- scribejs, set ssstolk Sanders Tolk
- 00:19:50 [ivan]
- guests= ssstolk
- 00:19:54 [gkellogg]
- ssstolk: Saunders Stolk, I work for Semmtech.
- 00:20:01 [ivan]
- guests+ ssstolk
- 00:20:05 [azaroth]
- s/Saunders/Sanders/
- 00:20:09 [ivan]
- guests+ tpk
- 00:20:23 [gkellogg]
- … We’re using LD for our clients to help in infrastructure to share information on buildings from design, building to maintanence.
- 00:20:34 [gkellogg]
- … In NL near Shipol
- 00:20:49 [gkellogg]
- azaroth: topic: Review of accomplishments
- 00:20:53 [ivan]
- s/Shipol/Schiphol/
- 00:21:02 [azaroth]
- TOPIC: Review of Accomplishments
- 00:21:21 [gkellogg]
- bigbluehat: Virtual click-through slide deck
- 00:21:36 [gkellogg]
- azaroth: We’re close to CR. There are three open issues.
- 00:22:04 [gkellogg]
- pchampin: Pierre-Antoine Champin, an assoiate professor at Univ. Lyon.
- 00:22:26 [gkellogg]
- … I’ve been on the WG for a year. My research is in SemWeb, also in RDF WG
- 00:22:35 [gkellogg]
- … Also co-editor of the syntax doc.
- 00:23:02 [gkellogg]
- azaroth: Three issues to consider, two this morning.
- 00:23:24 [gkellogg]
- bigbluehat: This afternoon, we want to talk about string direction, which may bring in more outside visitors.
- 00:23:54 [gkellogg]
- … 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 [gkellogg]
- ivan: Formally speaking, it may be worth adding an explicit issue, or reopening the old issue. #11
- 00:25:11 [dlehn]
- present+
- 00:26:13 [gkellogg]
- bigbluehat: version triggering is something to consider.
- 00:26:42 [bigbluehat]
- scribe+ bigbluehat
- 00:27:11 [bigbluehat]
- gkellogg: in most statements we do not include the nulls. one exception is JSON literals
- 00:27:27 [bigbluehat]
- ...but null is a valid JSON value, so there are reasons to keep them
- 00:27:48 [bigbluehat]
- ...pchampin pointed out a similar situation with strings, but that was an implementation issue
- 00:27:52 [bigbluehat]
- ...but it did help us find this
- 00:28:08 [bigbluehat]
- ...you can keep the `null` value currently by using the `@type: @json`
- 00:28:13 [bigbluehat]
- ...but in other cases we take it out
- 00:28:17 [bigbluehat]
- ...so we're at least inconsistent
- 00:28:27 [bigbluehat]
- ...it implies that there's some missing algorithm text
- 00:28:54 [bigbluehat]
- ...for preserving a key/value with a value of `null`
- 00:29:15 [bigbluehat]
- ...there are various options for preserving them
- 00:29:20 [bigbluehat]
- ...we could also decide not to
- 00:29:23 [bigbluehat]
- ...but I do think we can
- 00:30:13 [bigbluehat]
- ...if you expand it, and then re-expand it the `null` goes away...even when using the `@json` value type
- 00:30:42 [azaroth]
- issue: https://github.com/w3c/json-ld-syntax/issues/258
- 00:30:46 [bigbluehat]
- ...it's an editorial issue once we figure out how we want to handle it
- 00:30:50 [bigbluehat]
- ...because it's a lack of clarity
- 00:30:56 [bigbluehat]
- ...should be the work of an hour or two
- 00:31:39 [bigbluehat]
- 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]
- bigbluehat: Apache CouchDB and MongoDB (iirc) will remove keys set to `null`
- 00:32:59 [bigbluehat]
- azaroth: that's what this does in every other case...except the new `@json` type
- 00:33:45 [bigbluehat]
- ...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 [bigbluehat]
- ...but...do we want to still provide a way to remove the key/value?
- 00:34:49 [bigbluehat]
- ivan: why would we want to remove key/values?
- 00:34:54 [bigbluehat]
- bigbluehat: databases do it
- 00:34:59 [bigbluehat]
- azaroth: but this would be full statements
- 00:35:32 [bigbluehat]
- gkellogg: so most of the testing I've done was with numeric values and objects
- 00:35:42 [pchampin]
- q+
- 00:36:08 [azaroth]
- ack pchampin
- 00:36:19 [bigbluehat]
- bigbluehat: is `null` on it's own a valid JSON value/document?
- 00:36:22 [bigbluehat]
- ...what would JSON.parse do?
- 00:36:25 [bigbluehat]
- gkellogg: it would keep it
- 00:36:45 [bigbluehat]
- pchampin: I'm playing around with the code right now, and gkellogg mentioned that re-expansion would get rid of it
- 00:36:55 [bigbluehat]
- ...I added the `@version: 1.1`
- 00:37:01 [bigbluehat]
- ...otherwise it doesn't work at all
- 00:37:15 [bigbluehat]
- ...and when I do it, it looks like we get an invalid value
- 00:37:47 [bigbluehat]
- gkellogg: part of the use of `null` is to eliminate contexts
- 00:38:28 [bigbluehat]
- ...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]
- azaroth tests `JSON.parse("null")` in chrome, and the result is a real null
- 00:38:54 [bigbluehat]
- ...but you're right it could be restricted to 1.0-based processing
- 00:39:12 [bigbluehat]
- ...so we may need to update tests to use 1.1 mode
- 00:39:18 [bigbluehat]
- ...and test with expanded values
- 00:39:29 [bigbluehat]
- ...so setting the processing mode is probably the way to do it
- 00:42:13 [azaroth]
- 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 [azaroth]
- +1
- 00:42:18 [bigbluehat]
- +1
- 00:42:18 [gkellogg]
- +1
- 00:42:21 [pchampin]
- +1
- 00:42:29 [ivan]
- +1
- 00:42:42 [azaroth]
- 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 [dlehn]
- +1
- 00:43:04 [jc]
- jc has joined #json-ld
- 00:43:09 [ivan]
- present+ dlehn
- 00:44:16 [bigbluehat]
- Subtopic: keyword alias for `@id` and `@type` cannot be singly `@protected`
- 00:44:33 [bigbluehat]
- https://github.com/w3c/json-ld-syntax/issues/246
- 00:44:53 [bigbluehat]
- azaroth: if you alias `@type` to `type` it can still be a set
- 00:47:54 [bigbluehat]
- ...however, using `@protected` on an object-based term definition will not protect the `id` aliasing
- 00:48:07 [bigbluehat]
- ...so my proposal is that we change `@protected` to be a legal keyword for keyword aliases
- 00:48:59 [bigbluehat]
- gkellogg: does `@protected` protect the `@type` based aliasing?
- 00:49:27 [bigbluehat]
- azaroth: [adds more examples to 246]
- 00:50:27 [bigbluehat]
- ivan: the examples don't show any reason for the `@protected`
- 00:51:17 [bigbluehat]
- azaroth: [fixes examples]
- 00:51:32 [pchampin]
- q+
- 00:52:29 [pchampin]
- q-
- 00:53:43 [bigbluehat]
- azaroth: [reads text from 4.1.5]
- 00:53:51 [bigbluehat]
- ...[reads text from 4.3.3]
- 00:55:10 [bigbluehat]
- gkellogg: looks like the API is correct
- 00:55:16 [bigbluehat]
- azaroth: ah, so they're out of sync
- 00:55:29 [bigbluehat]
- gkellogg: we do need more `@protected` text in this API section
- 00:57:09 [bigbluehat]
- azaroth: so the syntax fix is editorial
- 01:00:26 [azaroth]
- 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 [azaroth]
- +1
- 01:00:29 [gkellogg]
- +1
- 01:00:33 [bigbluehat]
- +1
- 01:00:34 [pchampin]
- +1
- 01:00:44 [ivan]
- +1
- 01:00:47 [azaroth]
- 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 [azaroth]
- Issue above: https://github.com/w3c/json-ld-syntax/issues/246
- 01:04:45 [bigbluehat]
- gkellogg: before we go on to the next issue, there are some visual things maybe we can solve
- 01:04:51 [bigbluehat]
- ...I've never liked the green stuff
- 01:04:53 [bigbluehat]
- ...for new items
- 01:05:23 [bigbluehat]
- ...since we already have some active JS in there
- 01:05:29 [bigbluehat]
- ...maybe we can toggle highlight changes in 1.1
- 01:14:08 [bigbluehat]
- group: [discusses various CSS related tweaks...decides to leave things as is]
- 01:14:23 [bigbluehat]
- gkellogg: but then there's "[Exposed=Window]"
- 01:14:29 [bigbluehat]
- ivan: why is that even needed?
- 01:14:34 [bigbluehat]
- ...let's just display: none it
- 01:14:43 [bigbluehat]
- ...it doesn't apply to us
- 01:16:36 [bigbluehat]
- ...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 [bigbluehat]
- azaroth: there are a few other issues we should chip away at
- 01:18:24 [bigbluehat]
- Subtopic: 220 in syntax; move 9.3 and "default object" to framing only?
- 01:18:39 [bigbluehat]
- https://github.com/w3c/json-ld-syntax/issues/246
- 01:18:56 [bigbluehat]
- gkellogg: so things show up when they've been referenced
- 01:19:09 [bigbluehat]
- ...and the terminology here does make this confusing
- 01:19:26 [bigbluehat]
- ...we introduce these concepts, because many people who use these don't look at API documents
- 01:19:33 [bigbluehat]
- ...the frame is more of a hybrid document of syntax and api
- 01:19:40 [bigbluehat]
- ...we might just be being to explicit here
- 01:19:50 [bigbluehat]
- ...we even describe a frame object here for that matter...
- 01:20:10 [bigbluehat]
- azaroth: this doesn't really add much...and I'd suggest just removing 9.3
- 01:20:23 [bigbluehat]
- gkellogg: and there is an earlier reference to framing earlier
- 01:20:27 [bigbluehat]
- azaroth: so...yeah
- 01:20:37 [bigbluehat]
- gkellogg: and farther down, we introduce expansion, compaction, etc.
- 01:20:53 [bigbluehat]
- ...and there's a framed document form
- 01:23:27 [bigbluehat]
- bigbluehat: off topic, but I'd love to have expanded form explained earlier
- 01:23:35 [bigbluehat]
- ...too big a change right now...but maybe in the primer
- 01:23:42 [bigbluehat]
- ivan: it helps me too to think about expanded form
- 01:23:52 [bigbluehat]
- gkellogg: but back to this specific issue
- 01:24:04 [bigbluehat]
- ivan: right. frames are valid 1.1 documents now
- 01:24:11 [bigbluehat]
- ...so the syntax document has to call this out
- 01:24:30 [bigbluehat]
- azaroth: right, 5.4. explains it, and you can't understand 5.4 without 9.3
- 01:24:43 [bigbluehat]
- gkellogg: this issue can capture why its there
- 01:25:43 [bigbluehat]
- Subtopic: regarding expanded form earlier in the doc
- 01:26:02 [bigbluehat]
- gkellogg: maybe we just add a new section that talks a bit more about expanded form in the intro
- 01:26:17 [bigbluehat]
- ...that highlights that various forms exist and how they work
- 01:27:40 [bigbluehat]
- ivan: it's true that these other forms are helpful
- 01:28:10 [bigbluehat]
- bigbluehat: do we need an action for this?
- 01:29:40 [bigbluehat]
- gkellogg: maybe we can put a basic overview of just expanded form and its use in the intro/basic concepts section
- 01:29:56 [bigbluehat]
- ...and then to note that semantically the compacted + expanded are equivalent
- 01:30:14 [bigbluehat]
- ...even though syntactically they look different
- 01:30:48 [bigbluehat]
- Action: gkellogg to write a couple paragraphs + example(s) for explaining expanded form and its use
- 02:00:51 [ivan]
- ivan has joined #json-ld
- 02:15:13 [ivan]
- ivan has joined #json-ld
- 02:15:19 [bigbluehat]
- group: [discussing the implementations available and needed]
- 02:15:32 [bigbluehat]
- ...primarily C++ and Java need the most attention
- 02:23:14 [ssstolk]
- ssstolk has joined #json-ld
- 02:24:22 [gkellogg]
- http://drobilla.net/pages/contact.html
- 02:30:19 [manu]
- present+
- 02:39:11 [azaroth]
- {
- 02:39:11 [azaroth]
- "@context": {
- 02:39:11 [azaroth]
- "@vocab": "https://example.com/",
- 02:39:13 [azaroth]
- "schema": "https://schema.org/",
- 02:39:15 [azaroth]
- "name": "schema:name"
- 02:39:17 [azaroth]
- },
- 02:39:19 [azaroth]
- "name": {
- 02:39:21 [azaroth]
- "@value": "fish",
- 02:39:23 [azaroth]
- "@language": "en",
- 02:39:25 [azaroth]
- "@direction": "ltr"
- 02:39:27 [azaroth]
- }
- 02:39:29 [azaroth]
- }
- 02:41:20 [pchampin]
- +1
- 02:41:39 [pchampin]
- { "@context": ["http://schema.org/", { "@direction": null }], "tag:p": { "@value": "foo", "@language": "en", "@direction": "ltr" } }
- 02:41:49 [manu]
- scribe: manu
- 02:42:03 [manu]
- Discussion around use of @direction and how it affects JSON-LD 1.0 processors.
- 02:43:15 [manu]
- Seems that there is an issue wrt. the use of @vocab and @direction... processors are choking.
- 02:44:01 [manu]
- A bug exists in 1.0 and 1.1 that doesn't flag the use of @direction and @vocab.
- 02:44:07 [azaroth]
- Issue created: https://github.com/w3c/json-ld-syntax/issues/259
- 02:44:45 [manu]
- Current 1.0 processors are going to ignore use of @direction in various places.
- 02:47:17 [pchampin]
- {"@version": null} :-D
- 02:52:01 [manu]
- rob: Moving on to whether or terms can start with @ symbol.
- 02:52:26 [manu]
- rob: Currently, the spec is not clear wrt. SHOULD NOT vs. MUST NOT.
- 02:52:59 [manu]
- bigbluehat: This is why HTML is not versioned.
- 02:53:25 [manu]
- 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 [manu]
- 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 [manu]
- 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 [manu]
- bigbluehat: I'd suggest you use a switching mechanism in processor... nuclear option is to use 1.1.
- 02:56:21 [manu]
- bigbluehat: If I point towards the past... I provide HTML5 document to HTML 3 processor, you don't lose data
- 02:56:36 [manu]
- bigbluehat: If you give @version to 1.0 processor, it explodes.
- 03:04:14 [pchampin]
- q+
- 03:04:39 [pchampin]
- q-
- 03:05:03 [manu]
- manu: Yes, but the only consumers are schema.org and they'll just do 1.1.
- 03:05:10 [gkellogg]
- q?
- 03:05:39 [manu]
- bigbluehat: yes, the evergreen browser argument
- 03:05:42 [ivan]
- q+
- 03:05:58 [manu]
- pchampin: Changing 1.0 parsers, if they don't fail on 1.1 parsers, they'll break on other things
- 03:06:10 [manu]
- q+ to mention feature detection/upgrades.
- 03:06:42 [bigbluehat]
- Feature Detection issue https://github.com/w3c/json-ld-syntax/issues/33
- 03:08:04 [manu]
- 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 [azaroth]
- ack ivan
- 03:09:16 [manu]
- 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 [gkellogg]
- q+
- 03:09:33 [manu]
- 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 [azaroth]
- q?
- 03:10:02 [azaroth]
- q+ to note lunch :)
- 03:10:12 [ssstolk]
- q+
- 03:10:55 [azaroth]
- ack manu
- 03:10:55 [Zakim]
- manu, you wanted to mention feature detection/upgrades.
- 03:10:55 [manu]
- 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 [bigbluehat]
- manu: so. the original `@version` proposal was a list of features
- 03:11:22 [bigbluehat]
- ...so if you were to process this document, you must support those features
- 03:11:32 [bigbluehat]
- ...if a processor can't support those, then it just blows up
- 03:11:40 [bigbluehat]
- ...and 1.1 was just an alias for a bundle of features
- 03:11:49 [bigbluehat]
- ...the issue we saw was that there might be a feature...well...
- 03:11:58 [bigbluehat]
- ...one, announcing them doesn't mean you'll be using them
- 03:12:14 [bigbluehat]
- ...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 [bigbluehat]
- ...so, the feature detection works best when it's also BC friendly
- 03:12:33 [bigbluehat]
- ...and that turns out to be rather hard
- 03:12:48 [bigbluehat]
- ...we'd have to go through each feature and determine how detectable they are
- 03:12:57 [bigbluehat]
- ...but the reason against that is that it's a huge amount of spec text
- 03:13:09 [bigbluehat]
- ...and we weren't sure that every new feature weren't able to figure those out
- 03:13:26 [bigbluehat]
- ...and they might determined it differently
- 03:13:35 [bigbluehat]
- ...which is why we were ultimately in favor of 1.1
- 03:13:48 [bigbluehat]
- ivan: so does that mean if we go into continuous development
- 03:13:53 [bigbluehat]
- manu: ...yeah. I'm against that also
- 03:14:08 [bigbluehat]
- ...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 [pchampin]
- q+
- 03:14:18 [azaroth]
- q?
- 03:14:27 [bigbluehat]
- ivan: k...but if we keep shipping, then we'd just keep shipping these version number things
- 03:14:38 [bigbluehat]
- manu: yeah...but that gets complicated again
- 03:14:53 [bigbluehat]
- ...and if you look at HTML5, feature detection is insane
- 03:14:54 [azaroth]
- ack gkellogg
- 03:15:39 [bigbluehat]
- ...the earlier issues were about feature announcement not detection
- 03:15:55 [bigbluehat]
- gkellogg: the point of 1.1 was not so we'd have a 1.2
- 03:16:02 [bigbluehat]
- ...it was so we'd be locking things down
- 03:16:11 [bigbluehat]
- ...and that's principally done in context processing
- 03:16:19 [bigbluehat]
- ...and we did not do that properly in 1.0
- 03:17:01 [bigbluehat]
- ...so, virtually, I'd say 90% of features are discovered in `@context` processing
- 03:17:06 [manu]
- 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 [bigbluehat]
- ...the others show up in expansion
- 03:17:27 [azaroth]
- q?
- 03:17:27 [manu]
- gkellogg: We do look for those in 1.1 mode and 1.0 mode... frame processing mode...
- 03:18:00 [manu]
- 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 [manu]
- ivan: If we had it today, @direction wouldn't be detected in @context.
- 03:18:22 [manu]
- gkellogg: If we had it in the context it would be.
- 03:18:43 [manu]
- 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 [manu]
- gkellogg: Anything that looks like a keyword and the processor doesn't understand it, it should abort.
- 03:21:05 [manu]
- gkellogg: I disagree w/ manu, I think we can do feature detection.
- 03:21:26 [manu]
- manu: I don't think I said we'd use 1.1 when doing JSON-LD 5.0
- 03:21:42 [manu]
- ivan: isn't this an issue for stream processor?
- 03:21:43 [azaroth]
- ack azaroth
- 03:21:43 [Zakim]
- azaroth, you wanted to note lunch :)
- 03:21:56 [manu]
- gkellogg: Well, you could throw an error if you hit something...
- 03:22:00 [pchampin]
- q-
- 03:22:06 [manu]
- gkellogg: I think we'd be in a better position if we don't use @version.
- 03:22:27 [azaroth]
- ack ssstolk
- 03:22:33 [manu]
- rob: We need to break for lunch soon.
- 03:23:03 [manu]
- 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 [manu]
- 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 [manu]
- 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 [manu]
- gkellogg: In some cases, in order to get behavior, you should be in validation mode.
- 03:25:28 [manu]
- 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 [manu]
- 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 [manu]
- 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]
- azaroth has joined #json-ld
- 03:36:07 [azaroth]
- azaroth has joined #json-ld
- 03:42:15 [simonstey]
- simonstey has joined #json-ld
- 03:51:19 [simonstey]
- present+
- 03:55:18 [azaroth]
- azaroth has joined #json-ld
- 04:01:04 [azaroth__]
- azaroth__ has joined #json-ld
- 04:04:14 [azaroth]
- --> #wot
- 04:13:07 [ivan]
- ivan has joined #json-ld
- 04:19:22 [pchampin]
- pchampin has joined #json-ld
- 04:26:43 [ivan]
- ivan has joined #json-ld
- 04:41:49 [gkellogg_]
- gkellogg_ has joined #json-ld
- 04:47:30 [addison]
- addison has joined #json-ld
- 04:59:39 [azaroth]
- azaroth has joined #json-ld
- 05:00:49 [azaroth_]
- azaroth_ has joined #json-ld
- 05:01:20 [ivan]
- ivan has joined #json-ld
- 05:01:40 [addison_]
- addison_ has joined #json-ld
- 05:02:01 [ssstolk]
- ssstolk has joined #json-ld
- 05:02:12 [ivan]
- Topic: I18N
- 05:02:48 [Bert]
- Bert has joined #json-ld
- 05:02:48 [chaals]
- chaals has joined #json-ld
- 05:02:53 [Bert]
- present+
- 05:02:58 [chaals]
- present+
- 05:02:58 [manu]
- scribe: manu
- 05:02:59 [r12a]
- r12a has joined #json-ld
- 05:02:59 [ivan]
- guests+ dan, chaals, addison, r12a, hadley, danbri
- 05:03:02 [hadleybeeman]
- present+
- 05:03:20 [ivan]
- scribejs, set hadleybeeman Hadley Beeman
- 05:03:35 [ivan]
- scribejs, set r12a Richard Ishida
- 05:03:48 [ivan]
- scribejs, set chaals Charles Neville
- 05:03:57 [burn]
- burn has joined #json-ld
- 05:04:08 [chaals]
- scribejs, set chaals Chaals Nevile
- 05:04:10 [burn]
- present+ Dan_Burnett
- 05:04:18 [manu]
- 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]
- DavidClarke has joined #json-ld
- 05:04:57 [manu]
- r12a: We move the upper stories of the Eiffel tower first :)
- 05:05:14 [r12a]
- s/r21a/aphillips/
- 05:05:20 [r12a]
- s/r12a/aphillips/
- 05:05:43 [DavidClarke]
- present+
- 05:05:44 [manu]
- 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 [ivan]
- scribejs, addison_ Addison Phillips
- 05:06:00 [manu]
- 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 [ivan]
- scribejs, set addison_ Addison Phillips
- 05:06:16 [manu]
- azaroth_: One question that would be good to answer, why isn't language sufficient to do this?
- 05:06:27 [ivan]
- guests+ Bert
- 05:06:28 [chaals]
- q+ to talk language
- 05:06:31 [manu]
- azaroth_: Why can't we just say English is ltr, arabic is rtl, and be done...
- 05:07:03 [manu]
- 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 [chaals]
- present+ sangwhan
- 05:08:06 [ivan]
- q+
- 05:08:16 [r12a]
- https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags
- 05:08:18 [manu]
- 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 [azaroth_]
- ack chaals
- 05:08:20 [Zakim]
- chaals, you wanted to talk language
- 05:08:48 [burn]
- q?
- 05:08:53 [manu]
- 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 [manu]
- r12a: No, not true by a long shot.
- 05:09:15 [azaroth_]
- s/depict/detect is azeri/
- 05:09:17 [manu]
- chaals: RDF doesn't understand ar-kw ar-?? is all arabic
- 05:09:34 [manu]
- r12a: And new subtags are added all the time...
- 05:09:41 [azaroth_]
- q?
- 05:09:51 [manu]
- chaals: You'd have to parse RDF language tags to get this partial solution
- 05:09:55 [manu]
- q+ danbri
- 05:09:58 [azaroth_]
- q+ sanders
- 05:10:19 [manu]
- 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 [bigbluehat]
- https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags
- 05:10:58 [hadleybeeman]
- q?
- 05:11:36 [azaroth_]
- ack ivan
- 05:11:39 [manu]
- 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 [manu]
- 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 [manu]
- ivan: metadata only on the one string.
- 05:12:46 [manu]
- ivan: When yo uhave mixed text, we can't do that.
- 05:12:48 [azaroth]
- q?
- 05:13:34 [azaroth]
- ack danbri
- 05:13:36 [manu]
- 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 [chaals]
- q+ to follow the subtopic of what breaks if we make the proposed change
- 05:14:18 [manu]
- 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 [manu]
- 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 [ivan]
- q?
- 05:15:50 [manu]
- 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 [ivan]
- q+
- 05:16:03 [manu]
- q+ to ask why this wasn't handled in BCP47?
- 05:16:28 [manu]
- aphillips: If you are doing complex matching, you need application logic.
- 05:16:46 [azaroth]
- ack sanders
- 05:16:53 [manu]
- danbri: We don't need to address fancy SPARQL query.
- 05:17:47 [addison_]
- q?
- 05:18:23 [manu]
- 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 [addison_]
- q+
- 05:18:50 [azaroth]
- ack chaals
- 05:18:50 [Zakim]
- chaals, you wanted to follow the subtopic of what breaks if we make the proposed change
- 05:19:04 [manu]
- chaals: If we follow this plan, what breaks?
- 05:19:21 [manu]
- ivan: What's the plan? Add syntax for @direction and add a new property
- 05:20:14 [azaroth]
- q?
- 05:20:59 [chaals]
- -> https://w3c.github.io/rdf-dir-literal/#json-ld the proposed json-ld syntax
- 05:21:46 [chaals]
- q+ danbri
- 05:21:52 [manu]
- Group looks at directions in rdf-dir-literal document.
- 05:22:55 [chaals]
- 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]
- danbri has joined #json-ld
- 05:23:18 [bigbluehat]
- q?
- 05:23:19 [manu]
- 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 [azaroth]
- ack ivan
- 05:23:28 [manu]
- gkellogg: We also discussed that this was a transitional solution.
- 05:24:04 [danbri]
- 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 [manu]
- 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 [manu]
- 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 [azaroth]
- ack manu
- 05:25:24 [Zakim]
- manu, you wanted to ask why this wasn't handled in BCP47?
- 05:25:25 [manu]
- ivan: Adding the feature is easy, what happens to the process is not a big deal....
- 05:25:48 [chaals]
- manu: I really pushed to fix this, for verifiable credentials to be able to move on...
- 05:25:50 [ivan]
- scribe+ chaals
- 05:26:16 [chaals]
- … 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 [azaroth]
- q+ to question the damage of punning properties (equivalent to new datatype) vs -x BCP extension
- 05:26:19 [gkellogg]
- q?
- 05:26:31 [chaals]
- … seems like language tag does 95% of what we want, a lot of times.
- 05:26:53 [chaals]
- … so it is true that people extract some text direction out of the language tag
- 05:27:03 [chaals]
- addison: mostly right now it isn't used…
- 05:27:25 [chaals]
- … most people without a base direction appy the unicode algorithm.
- 05:27:35 [azaroth]
- q?
- 05:28:27 [chaals]
- chaals: anecdata suggests that in practice, people are really implementing stuff withthe language tag and accept that as generally good enough for customers.
- 05:29:00 [chaals]
- manu: There is a reality on the ground that people are using the lang tag. All of these specs getting changed might not be as good as working out how to do this through teh lang tag.
- 05:29:10 [chaals]
- q+ to argue that requiring lang tag parsing is also a big change.
- 05:29:16 [r12a]
- q+
- 05:29:29 [chaals]
- … we could deal with it in the lang tag and not have to change the RDF layer
- 05:29:31 [bigbluehat]
- the mentioned list of specs https://w3c.github.io/rdf-dir-literal/draft-charter.html#normative
- 05:29:38 [azaroth]
- ack addison_
- 05:30:02 [chaals]
- addison_: One thing is that by design implemnentations don't need to know about the content of the language tag - and most of them don't.
- 05:30:13 [chaals]
- … there is a massive number of subtags.
- 05:32:13 [manu]
- aphillips: One of the things I mentioned earlier, by design, implementations don't need to know about subtags/language tags... we can maybe smuggle serialization schemes... the direction metadata doesn't belong in the language tag, it's semiorthogonal not totally unrelated, separate piece of data, I'll admit that people have struggled... we failed to provide a mechanism to do this, we should have had this conversation before the paint was dry.
- 05:32:14 [chaals]
- … we have looked, in https://w3c.github.io/rdf-dir-literal at ways to "smuggle" the information metadata in via the lanugage tag. It is semi-orthogonal, being a separate bit of data, that we have to be able to serialise and deserialise. There are a lot of places we suffer because we haven't yet managed to solve the problem, since we didn't do it from the start.
- 05:32:49 [r12a]
- r12a's slides start here: https://www.w3.org/International/talks/1810-paris/#metadata
- 05:33:15 [manu]
- aphillips: People who have data catalogs who have base direction metadata, when people have this affordance, it helps to be able to do this... does it work a lot of the time, yes, but corner cases are really not that unusual...
- 05:33:15 [chaals]
- … people with data catalogues who have the metadata have an easy time if they can set the direction directly, Carrying around lists of subtag matching works a lot of the time but is pretty ugly, and the corner cases are not that unusual.
- 05:34:02 [chaals]
- … we launched a site in an RTL language, and hit a pile of bugs. I don't always have convenient mechanisms to manage this, so I am interested in a way to provide direction metadata in JSON-LD
- 05:34:08 [manu]
- aphillips: We launched our first rtl website, we have a bunch of bidi issues, don't always have convenient mechanisms, interested in providing a way of providing direction metadata.
- 05:34:51 [manu]
- aphillips: Where I'm headed to here, I am not a purist, if we had an impure serialization scheme that had greater compat, that wouldn't be bad...
- 05:35:30 [ssstolk]
- q+
- 05:35:51 [manu]
- aphillips: Talking w/ RDF community, we're creating an interesting hack, doesn't speak to extensibility... don't know if it's a hack... I'd be open to a serialization, looks hacky relative to other alternatives... maybe we can be compatible w/ existing implementation things.
- 05:35:59 [azaroth]
- ack danbri
- 05:35:59 [Zakim]
- danbri, you wanted 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:36:33 [manu]
- danbri: I liked the idea of doing something in JSON-LD... if we could backport for 1.0, we could get something happening in 1.0, Google might get involved.
- 05:36:58 [manu]
- danbri: We've encouraged people do to good solid JSON-LD 1.0 files, there are millions and millions of this....
- 05:37:36 [azaroth]
- q?
- 05:37:43 [azaroth]
- ack azaroth
- 05:37:43 [Zakim]
- azaroth, you wanted to question the damage of punning properties (equivalent to new datatype) vs -x BCP extension
- 05:37:52 [manu]
- danbri: The smallest little thing we can do is important, if we can do some surface hackery, we can parse this stuff...
- 05:38:00 [manu]
- gkellogg: Yes, some transitional mechanism.
- 05:38:19 [manu]
- ivan: We are having a discussion about versioning discussion...
- 05:38:36 [manu]
- gkellogg: parameterize RDF algorithms stuff...
- 05:38:52 [manu]
- danbri: Parser being invoked w/ arguments, people run RDFa parser in certain mode.
- 05:39:28 [manu]
- azaroth: There are two separate questions... the first one, do we feel comfortable adding @direction to JSON-LD for @value objects regardless of how it transforms to RDF.
- 05:39:37 [gkellogg]
- q+
- 05:40:27 [manu]
- azaroth: There are things that don't round trip in JSON-LD, such as indexes, there is precendent for non-roundtrippable stuff in JSON-LD... if cost to RDF layer is high, we can defer the serialization through into RDF... the proposal is 1) do we want to do this, to 2) how do we want to do this.
- 05:40:38 [azaroth]
- q?
- 05:40:40 [azaroth]
- ack chaals
- 05:40:40 [Zakim]
- chaals, you wanted to argue that requiring lang tag parsing is also a big change.
- 05:41:00 [manu]
- chaals: I think we want to do this, happy to give up round trippability... what's going to break?
- 05:41:23 [manu]
- chaals: If that's a fast path, this is a good solution.
- 05:41:43 [manu]
- chaals: Forcing things that don't parse language to parse language, that's a big ecosystem thing.
- 05:41:45 [azaroth]
- q+ to respond to what breaks is at different levels, surface syntax and ontology, thus the cost is different for different audiences
- 05:41:58 [azaroth]
- ack r12a
- 05:43:16 [chaals]
- manu: I think the vast majority of appications don't pay attention to the language tags, or direction.
- 05:43:37 [chaals]
- ivan: In browsers, they don't establish direction with language they do it with direction metadata.
- 05:43:47 [addison_]
- <p dir=rtl>arabic here</p>
- 05:45:17 [azaroth]
- ack ssstolk
- 05:45:49 [r12a]
- https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags
- 05:47:46 [manu]
- r12a: The normal way of detecting language is to look at first strong character heuristics, for most things in strings, that's the way to do it... far more efficient to look at first character... that works for 95% of time time, for the other 5%, that's the solution we're looking for, not having language, not having direction, and when direction on character is wrong...
- 05:48:08 [manu]
- manu: I just wanted to make sure we are making an educated decision.
- 05:49:17 [manu]
- aphillips: I think the right thing to have done is split the two -- language and dir must be separated.
- 05:49:24 [manu]
- r12a: Yes, they're not doing the same thing
- 05:49:54 [manu]
- sander: Pinpoint something wrt RDF - our company uses multiple language tags to discuss the same term, we find it's difficult to find proper name for same term.
- 05:50:09 [manu]
- q+ to note that it's not clear that lang and dir were designed to be separate.
- 05:50:32 [manu]
- sander: We would be more reluctant if we adopt this that this is a different language encoding to ...
- 05:51:33 [manu]
- ivan: If you look at this thing in RDF version, if there is no @direction, it maps against a literal and language tag... it's some bnode with properties, it's very different.
- 05:52:15 [manu]
- sander: I wanted to point out that if capturing such information would require another pattern, then such adoption for orgs to adopt direction, if that causes structural thing, that would hinder even looking for these things.
- 05:53:21 [azaroth]
- ack gkellogg
- 05:53:24 [manu]
- sander: smuggling direction in language might help adoption because it's easier to do... let's not make this have additional barriers.
- 05:54:31 [danbri_]
- danbri_ has joined #json-ld
- 05:54:45 [manu]
- gkellogg: To clarify, are we done at 3?
- 05:55:11 [manu]
- azaroth: This is something we want to do...
- 05:56:18 [manu]
- gkellogg: We get together we have an hour, we do the same discussion, we should put a stake in the ground. Something is better than nothing.
- 05:56:22 [rubensworks]
- rubensworks has joined #json-ld
- 05:56:53 [danbri_]
- q+
- 05:56:57 [azaroth]
- ack azaroth
- 05:56:57 [Zakim]
- azaroth, you wanted to respond to what breaks is at different levels, surface syntax and ontology, thus the cost is different for different audiences
- 05:57:00 [bigbluehat]
- q+ danbri_
- 05:57:14 [rubensworks]
- present+
- 05:57:16 [manu]
- manu: I'm committed and convinced to do @direction
- 05:57:19 [manu]
- ack manu
- 05:57:19 [Zakim]
- manu, you wanted to note that it's not clear that lang and dir were designed to be separate.
- 05:57:32 [manu]
- azaroth: Is it possible for you to be back after break, danbri?
- 05:57:43 [azaroth]
- q?
- 05:57:45 [azaroth]
- ack danbri_
- 05:57:47 [ivan]
- scribejs, set danbri Dan Brickley
- 05:57:54 [ivan]
- guests+ danbri
- 05:58:30 [manu]
- danbri_: What about the future? When you have arabic, french, in Japanese?
- 05:59:05 [manu]
- danbri_: Are we defining something where future direction happens...?
- 05:59:46 [azaroth]
- q?
- 06:00:00 [manu]
- chaals: What about text orientation and stuff... LTR and RTL...
- 06:00:21 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html addison_
- 06:00:56 [manu]
- aphillips: There is a high degree of confidence on number of text directions...
- 06:01:01 [manu]
- rrsagent, draft minutes
- 06:01:01 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html manu
- 06:01:27 [azaroth]
- azaroth has joined #json-ld
- 06:02:20 [chaals1]
- chaals1 has joined #json-ld
- 06:25:04 [addison]
- addison has joined #json-ld
- 06:32:54 [azaroth]
- azaroth has joined #json-ld
- 06:33:02 [jc]
- jc has joined #json-ld
- 06:33:13 [azaroth]
- Restarting ...
- 06:33:44 [azaroth]
- scribenick: bigbluehat
- 06:33:44 [bigbluehat]
- scribe+ bigbluehat
- 06:34:03 [bigbluehat]
- azaroth: on the Agenda is continue until exhaustion
- 06:34:15 [bigbluehat]
- ...in favor of progress
- 06:34:27 [bigbluehat]
- ...I think that is contentious to add the surface syntax
- 06:34:36 [bigbluehat]
- ...so reopen that original issue
- 06:34:50 [tung]
- tung has joined #json-ld
- 06:34:51 [bigbluehat]
- ...and then look at RDF round tripping *after* that's resolved
- 06:34:58 [bigbluehat]
- ...the worst scenario is to go to CR with no solution
- 06:35:41 [bigbluehat]
- ...it is better to go CR with `@direction` and without a mapping into RDF, than to not put in `@direction`
- 06:35:46 [bigbluehat]
- gkellogg: curious about danbri's thoughts
- 06:36:13 [bigbluehat]
- danbri: that's up to Google (Bing, etc), but we can encourage users of Schema.org to publish it
- 06:36:13 [azaroth]
- (better to also have consensus about the RDF transitional reflection, but that seems more complicated)
- 06:36:20 [bigbluehat]
- ...but can't promise SEO bots will consume it
- 06:36:42 [bigbluehat]
- ivan: if I put in a `@direction` into my web site data, what happens
- 06:37:00 [azaroth]
- s/@direction/@language/
- 06:37:23 [bigbluehat]
- danbri: we certainly have the notion of languages of pages, etc.
- 06:37:56 [jc]
- jc has joined #json-ld
- 06:38:13 [bigbluehat]
- ...but the more narrow `@language` usage would be up to the various products/consumers of that data
- 06:38:16 [bigbluehat]
- ...and I can't speak for what they do
- 06:38:34 [addison_]
- addison_ has joined #json-ld
- 06:38:44 [bigbluehat]
- ...I think it's likely that we're not doing a great job with `@language`--let alone `@direction`, etc.
- 06:38:49 [addison_]
- q?
- 06:38:56 [gkellogg]
- q+
- 06:39:05 [bigbluehat]
- ...so I don't think our tooling will catch fire, etc.
- 06:39:14 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html addison_
- 06:39:26 [azaroth]
- ack gkellogg
- 06:39:31 [bigbluehat]
- ...it would be nice if there were an appendix or something that said even if you're publishing in 1.0, that you can still put `@direction` in and hope for the best
- 06:39:43 [bigbluehat]
- gkellogg: there have been some calls in Schema.org to add some properties to say
- 06:39:45 [addison_]
- present+ addison
- 06:39:59 [bigbluehat]
- ...things like breadcrumbs might make use of the `@list` capability
- 06:40:04 [bigbluehat]
- ...or strings that used a map structure
- 06:40:12 [bigbluehat]
- ...where there would be a `@context` to understand those
- 06:40:26 [bigbluehat]
- ...whereas at Google they're just checking directly
- 06:40:47 [bigbluehat]
- ...might you consider a similar pattern for `@direction`
- 06:41:10 [bigbluehat]
- danbri: I think you're designing hacks for a system neither of us know much about :)
- 06:41:36 [bigbluehat]
- azaroth: let's project some examples
- 06:41:54 [bigbluehat]
- danbri: I was thinking whatever Voodoo you work up--so in 1.1 it's these little `@` things...
- 06:42:06 [bigbluehat]
- gkellogg: so, yes, we have `@language` and soon, we think, `@direction`
- 06:42:21 [bigbluehat]
- ...I can set an `@language` for the whole document or a certain object
- 06:42:27 [danbri]
- danbri has joined #json-ld
- 06:42:34 [bigbluehat]
- ...and when it gets expanded, you have that language data as well as the value
- 06:42:58 [bigbluehat]
- danbri: so each publishing web site would make use of its own context?
- 06:44:03 [bigbluehat]
- bigbluehat: let's make sure we're all talking using the same terms
- 06:44:10 [bigbluehat]
- ...I don't we're all sure what expanded form is, etc.
- 06:44:24 [bigbluehat]
- azaroth: [projects some examples]
- 06:45:20 [danbri]
- for examples of google's use of json-ld (and schema.org), see Search Gallery at https://developers.google.com/search/docs/guides/search-gallery
- 06:45:23 [bigbluehat]
- manu: so I feel we're overusing an unbuilt feature
- 06:45:37 [bigbluehat]
- ...how often to we expect people to use the `@direction` feature actually?
- 06:45:39 [bigbluehat]
- q+
- 06:46:04 [bigbluehat]
- ...most authors won't want to grow to great pains to express it
- 06:46:11 [bigbluehat]
- addison_: no, but most machines written to care will
- 06:46:18 [manu]
- q+ to are we just talking about schema.org?
- 06:46:22 [bigbluehat]
- ...so people with direction metadata will want to consistently use it all over the place
- 06:46:37 [manu]
- q+ to wonder if we're talking about machine use cases or human use cases?
- 06:46:46 [azaroth]
- ack bigbluehat
- 06:49:29 [gkellogg]
- scribe+
- 06:49:45 [gkellogg]
- danbri: Can’t we just use the dir attribute on a script tag?
- 06:49:48 [manu]
- danbri: You can pick it up from the HTML dir element...
- 06:49:52 [gkellogg]
- bigbluehat: No, we’re not allowed to do that.
- 06:50:05 [manu]
- bigbluehat: You can send it into processing algorithms for JSON-LD...
- 06:50:22 [manu]
- ivan: We looked at this, HTML5 spec says to not use lang for script tags.
- 06:50:54 [bigbluehat]
- danbri: https://html.spec.whatwg.org/multipage/scripting.html#data-block
- 06:51:41 [pchampin]
- q+
- 06:52:12 [jc]
- jc has joined #json-ld
- 06:53:33 [bigbluehat]
- danbri: is there a way to do this at the top of the file?
- 06:53:36 [bigbluehat]
- ivan: no
- 06:53:47 [bigbluehat]
- gkellogg: you can at the top of the file for `@language`
- 06:53:56 [bigbluehat]
- ...and presumably we would for `@direction`
- 06:54:05 [bigbluehat]
- ivan: so, yes, it could be there, and on each value
- 06:54:08 [pchampin]
- q-
- 06:54:25 [bigbluehat]
- ...it is an open question whether the container mapping thing would also be used for language direction
- 06:54:46 [bigbluehat]
- ...basically, yesterday's proposal was to mimic `@language`, but for the `@direction` data
- 06:55:17 [bigbluehat]
- bigbluehat: clearer? or worse?
- 06:55:27 [bigbluehat]
- danbri: but what if context's aren't used?
- 06:55:28 [bigbluehat]
- q+
- 06:55:43 [bigbluehat]
- ack manu
- 06:55:43 [Zakim]
- manu, you wanted to are we just talking about schema.org? and to wonder if we're talking about machine use cases or human use cases?
- 06:55:46 [azaroth]
- q?
- 06:56:12 [danbri]
- eg https://gist.github.com/danbri/9627452ec7dcbe63af9cb5a631acfdf8#file-gistfile1-txt
- 06:56:54 [bigbluehat]
- manu: so you'd just use `@language` and `@value` directly as an object for the value of the property--i.e. a value object
- 06:57:01 [bigbluehat]
- danbri: so, here's an example we've been playing with at Google
- 06:57:17 [bigbluehat]
- ...we don't want to do this on every field--as you can see it'd be painful and verbose
- 06:57:49 [bigbluehat]
- gkellogg: yeah, we would let you set for the whole document--as with `@language`
- 06:58:28 [bigbluehat]
- manu: I feel like we're handing people a foot gun
- 06:58:36 [bigbluehat]
- ...everything would become ltr or rtl--even if it's not supposed to
- 06:58:51 [azaroth]
- q?
- 06:58:56 [azaroth]
- ack bigbluehat
- 06:59:10 [bigbluehat]
- gkellogg: well, it depends on how they visualize the output to know if they've done it wrong
- 06:59:16 [bigbluehat]
- manu: people don't visualize it
- 06:59:41 [bigbluehat]
- bigbluehat: they just put the JSON into text areas and call it done
- 06:59:56 [bigbluehat]
- manu: yeah...most of them don't even care about `@language`
- 07:00:07 [bigbluehat]
- danbri: so do it only down at the property level
- 07:00:14 [bigbluehat]
- addison_: I can see doing it there
- 07:00:17 [jc]
- jc has joined #json-ld
- 07:00:31 [bigbluehat]
- danbri: would it make sense to have it in the schema languages?
- 07:00:37 [bigbluehat]
- ...like certainly fields are "directable"?
- 07:00:54 [bigbluehat]
- ...so gsin's or isbn's are not directable or language-able
- 07:01:01 [bigbluehat]
- addison_: isbn's are a great example
- 07:01:09 [bigbluehat]
- ...they have to be a string, includes letters, hyphens, etc.
- 07:01:13 [bigbluehat]
- ...but it's not in a language
- 07:01:17 [bigbluehat]
- ...it's a string literal
- 07:01:24 [bigbluehat]
- ...and the world is few of these
- 07:01:34 [bigbluehat]
- ...but it's also full of language-bearing strings which have both language and direction
- 07:01:34 [gkellogg]
- q?
- 07:01:37 [gkellogg]
- q+
- 07:01:52 [bigbluehat]
- ...in some cases that can be inferred, but in some cases we can't
- 07:02:06 [bigbluehat]
- ...so we do have direction fields in our databases to track that
- 07:02:19 [bigbluehat]
- manu: so, one option is to allow `@direction` at the top and have it cascade to the entire document
- 07:02:29 [bigbluehat]
- ...the other extreme/option is to put it on only the values
- 07:02:47 [bigbluehat]
- q+
- 07:02:55 [bigbluehat]
- q-
- 07:03:15 [bigbluehat]
- ivan: so it is up to Schema.org to decide if they want to promote `@direction` at the top
- 07:03:22 [bigbluehat]
- ...we are here talking about the standard
- 07:03:33 [bigbluehat]
- ...and I don't see why we would disallow this
- 07:03:34 [bigbluehat]
- q+
- 07:04:04 [bigbluehat]
- addison_: the reason you do this with `@language` is because you don't want to repeat it
- 07:04:15 [azaroth]
- ack gkellogg
- 07:04:22 [bigbluehat]
- ivan: the same applies to `@direction`
- 07:04:41 [bigbluehat]
- gkellogg: we have various things to apply `@language` across the whole document
- 07:04:50 [bigbluehat]
- ...I can say that ISBN is no language
- 07:04:58 [bigbluehat]
- ...by setting `@language: null` on just that value
- 07:04:59 [manu]
- q+ to wonder how often @direction is used in data today alongside language...
- 07:05:19 [bigbluehat]
- ...for symmetries sake it would be odd for us to do this only for `@language`, but not `@direction`
- 07:05:44 [bigbluehat]
- ...even though we might not have obvious use cases, there is an orthogonality argument to make to do it for the whole document
- 07:05:51 [bigbluehat]
- ivan: I agree
- 07:05:54 [bigbluehat]
- addison_: I agree
- 07:06:17 [bigbluehat]
- gkellogg: something I can see us doing is that if there's a default `@direction`, then it could be limited to only things that bear a `@language`
- 07:06:46 [bigbluehat]
- ivan: no, ISBN is a good example
- 07:06:52 [bigbluehat]
- ...they always go "rtl"
- 07:07:02 [bigbluehat]
- addison_: MAC addresses are a great example
- 07:07:12 [bigbluehat]
- ...they draw backwards if they flow the wrong way
- 07:07:44 [bigbluehat]
- gkellogg: so, we should do this in all the same places we allow `@language`
- 07:07:56 [bigbluehat]
- group: [general positive responses]
- 07:08:16 [bigbluehat]
- gkellogg: I presume it doesn't make since to have `@direction` maps?
- 07:08:23 [bigbluehat]
- addison_: `@language` maps are very useful
- 07:08:30 [bigbluehat]
- ...the question then is how to do both if you use `@direction`
- 07:08:57 [bigbluehat]
- gkellogg: we could do nested objects inside nested objects
- 07:08:59 [azaroth]
- q?
- 07:09:01 [bigbluehat]
- group: [growns]
- 07:09:25 [bigbluehat]
- tung: so we define only the language, and guess the direction?
- 07:09:29 [bigbluehat]
- gkellogg: you could leave the direction off
- 07:09:33 [bigbluehat]
- ...you could provide both
- 07:09:40 [bigbluehat]
- ...or the string could just use the default direction
- 07:10:04 [bigbluehat]
- tung: if the user provides a direction, but if the user does not state a direction it falls back to language?
- 07:10:15 [bigbluehat]
- addison_: the language map is the space in which you'd define a language
- 07:10:20 [bigbluehat]
- ...but on each value
- 07:11:15 [bigbluehat]
- tung: what about vertical text?
- 07:11:19 [azaroth]
- ack bigbluehat
- 07:11:27 [azaroth]
- ack manu
- 07:11:27 [Zakim]
- manu, you wanted to wonder how often @direction is used in data today alongside language...
- 07:11:35 [azaroth]
- q+ for resolutions
- 07:11:44 [bigbluehat]
- addison_: vertical text is a presentational concern
- 07:11:51 [bigbluehat]
- manu: I think we keep breaking our own principles here
- 07:12:06 [manu]
- q-q_
- 07:12:08 [manu]
- q-
- 07:12:13 [bigbluehat]
- ...now we're saying we're using language for text direction when it's not available?
- 07:12:19 [bigbluehat]
- addison_: they're not completely independent
- 07:12:19 [azaroth]
- ack azaroth
- 07:12:19 [Zakim]
- azaroth, you wanted to discuss resolutions
- 07:12:37 [bigbluehat]
- manu: yeah...so the fact that this was thoroughly confusing to a bunch of developers...
- 07:13:09 [bigbluehat]
- ...the stuff presented earlier about not guessing direction from language...but now we are
- 07:13:49 [bigbluehat]
- david_clarke: Yiddish can be in Romain characters or Hebrew characters
- 07:14:14 [bigbluehat]
- ...so declaring the direction is still important
- 07:14:16 [bigbluehat]
- q+
- 07:14:39 [bigbluehat]
- manu: page-wide dir on HTML was maybe a mistake
- 07:14:54 [bigbluehat]
- addison_: no, there's a reason to have it on the outside of the container for a bunch of reasons
- 07:15:12 [bigbluehat]
- ...there is some linkage between language and direction
- 07:15:29 [bigbluehat]
- ...and what we want is to give people the things they need to reach beyond what language provides
- 07:15:41 [bigbluehat]
- ...if you ever watch folks attempting to develop or write this stuff, it's really really hard
- 07:15:53 [bigbluehat]
- ...we're trying to provide enough affordance to take a string out of a page and have it present properly
- 07:16:00 [bigbluehat]
- ...without having to introspect, etc.
- 07:16:22 [bigbluehat]
- ...we'd like for folks to be able to express their data in all the various standards without having to rewrite all the things
- 07:16:32 [bigbluehat]
- ...that's why having direction is important here
- 07:16:40 [jc]
- jc has joined #json-ld
- 07:16:44 [bigbluehat]
- ...because it handles all the other bits beyond the text--bullet points, etc.
- 07:16:49 [azaroth]
- ack bigbluehat
- 07:16:50 [bigbluehat]
- ...works in html, etc.
- 07:18:25 [azaroth]
- PROPOSAL: (1/*) We add @direction as a keyword to the JSON-LD Syntax to assert the base text direction of a literal string
- 07:18:37 [manu]
- +1
- 07:18:41 [gkellogg]
- +1
- 07:18:42 [azaroth]
- +1
- 07:18:42 [bigbluehat]
- bigbluehat: it's really similar to RDFa using a document level `dir` for all the things
- 07:18:48 [bigbluehat]
- ...and being overridden elsewhere
- 07:18:49 [bigbluehat]
- +1
- 07:18:50 [simonstey]
- +1
- 07:18:51 [ivan]
- +1
- 07:18:52 [danbri]
- danbri has joined #json-ld
- 07:18:53 [pchampin]
- +1
- 07:18:59 [danbri]
- +1
- 07:19:02 [azaroth]
- RESOLUTION: (1/*) We add @direction as a keyword to the JSON-LD Syntax to assert the base text direction of a literal string
- 07:19:24 [jc]
- jc has joined #json-ld
- 07:19:52 [azaroth]
- PROPOSAL: (2/*) @direction is legal as part of a value object in the json-ld internal model but may not be used if @type is present
- 07:20:01 [manu]
- +1
- 07:20:02 [pchampin]
- +1
- 07:20:02 [azaroth]
- +1
- 07:20:08 [bigbluehat]
- +1
- 07:20:09 [ivan]
- +1
- 07:20:09 [gkellogg]
- +1
- 07:20:13 [simonstey]
- +1
- 07:20:30 [azaroth]
- RESOLVED: (2/*) @direction is legal as part of a value object in the json-ld internal model but may not be used if @type is present
- 07:20:59 [bigbluehat]
- tung: why no `@direction` with `@type`?
- 07:21:11 [bigbluehat]
- gkellogg: because you can't have `@language` with `@type`
- 07:21:48 [bigbluehat]
- tung: but what if the `@type` has a language?
- 07:22:31 [bigbluehat]
- gkellogg: that's a different case
- 07:24:07 [bigbluehat]
- tung: can we use a class to define language?
- 07:24:14 [bigbluehat]
- gkellogg: that was considered
- 07:24:20 [azaroth]
- PROPOSAL: (3/*) @direction is legal in an expanded term definition if you could have used @language in that definition and applies to all values of that term in the same way as @language
- 07:24:30 [bigbluehat]
- azaroth: I think we're back in solution space, and should get back to resolutions
- 07:24:35 [jc]
- jc has joined #json-ld
- 07:24:41 [gkellogg]
- +1
- 07:24:44 [manu]
- +1
- 07:24:45 [bigbluehat]
- +1
- 07:24:48 [pchampin]
- +1
- 07:24:50 [ivan]
- +1
- 07:24:52 [azaroth]
- eg: {"label": {"@id": "rdfs:label", "@direction": "rtl"}}
- 07:25:00 [ivan]
- q+
- 07:25:22 [azaroth]
- ack ivan
- 07:25:33 [azaroth]
- RESOLVED: (3/*) @direction is legal in an expanded term definition if you could have used @language in that definition and applies to all values of that term in the same way as @language
- 07:28:11 [azaroth]
- PROPOSAL: (4/*) The value space of @direction is one of "ltr" and "rtl" ("auto" would have been the same as not asserting the keyword)
- 07:28:13 [azaroth]
- +1
- 07:28:14 [gkellogg]
- +1
- 07:28:15 [ivan]
- +1
- 07:28:17 [simonstey]
- +1
- 07:28:18 [manu]
- +1
- 07:28:20 [bigbluehat]
- +1
- 07:28:20 [pchampin]
- +1
- 07:28:25 [azaroth]
- RESOLVED: (4/*) The value space of @direction is one of "ltr" and "rtl" ("auto" would have been the same as not asserting the keyword)
- 07:28:25 [ivan]
- present+ simonstey
- 07:28:45 [bigbluehat]
- guest+ david_clarke
- 07:28:57 [bigbluehat]
- scribejs, set david_clarke to David Clarke
- 07:29:17 [azaroth]
- PROPOSAL: (5/*) We expand the possible values of language maps to be either a string (as per today) or a value object with direction and without language or type
- 07:29:19 [azaroth]
- +1
- 07:29:20 [gkellogg]
- +1
- 07:29:21 [pchampin]
- +1
- 07:29:21 [ivan]
- +1
- 07:29:23 [bigbluehat]
- +1
- 07:29:25 [manu]
- +1
- 07:29:42 [azaroth]
- eg: {"en": {"@value": "Rob", "@direction": "ltr"}}
- 07:30:00 [azaroth]
- RESOLVED: (5/*) We expand the possible values of language maps to be either a string (as per today) or a value object with direction and without language or type
- 07:32:50 [azaroth]
- PROPOSAL: (6/*) @direction can be present in a context node, and sets in the active context that the default direction for all string literals
- 07:32:52 [azaroth]
- +1
- 07:32:57 [gkellogg]
- +1
- 07:32:58 [ivan]
- +1
- 07:33:00 [manu]
- +1
- 07:33:01 [simonstey]
- +1
- 07:33:06 [bigbluehat]
- +
- 07:33:06 [pchampin]
- +1
- 07:33:09 [bigbluehat]
- +1
- 07:33:14 [azaroth]
- RESOLVED: (6/*) @direction can be present in a context node, and sets in the active context that the default direction for all string literals
- 07:33:52 [azaroth]
- PROPOSAL: WG agrees that @container: @direction is not a useful feature for JSON-LD 1.1 (unlike @container: @language)
- 07:33:53 [azaroth]
- +1
- 07:33:57 [manu]
- +1
- 07:33:58 [danbri]
- +1
- 07:34:02 [pchampin]
- +1
- 07:34:02 [bigbluehat]
- +1
- 07:34:07 [simonstey]
- +1
- 07:34:21 [azaroth]
- s|WG| (7/*) WG|
- 07:34:48 [azaroth]
- RESOLVED: (7/*) WG agrees that `@container: @direction` is not a useful feature for JSON-LD 1.1 (unlike `@container: @language`)
- 07:34:58 [ivan]
- +1
- 07:37:14 [azaroth]
- SUBTOPIC: Versioning issues
- 07:37:59 [danbri]
- https://w3.org/2018/03/jsonld-wg-charter.html "All changes must preserve backward compatibility for JSON-LD 1.0 documents. This means that, when processing existing JSON-LD documents, JSON-LD 1.1 processors generate the same expanded output, unless that output is subject to errata in JSON-LD 1.0 or is otherwise an unspecified implementation detail."
- 07:38:20 [bigbluehat]
- manu: who will this cost?
- 07:38:32 [bigbluehat]
- ...when they upgrade
- 07:38:44 [azaroth]
- q?
- 07:39:52 [bigbluehat]
- danbri: I don't think our processor do language...or value object or whatever...processing
- 07:40:08 [bigbluehat]
- gkellogg: so, your developers are happy, but folks who use the JSON-LD labeled tooling, will get a different result
- 07:40:27 [bigbluehat]
- ...and for those you'd have to say `@version: 1.1`
- 07:41:35 [bigbluehat]
- danbri: we've felt at Google and Schema.org for a long time that JSON-LD 1.0 had finally gotten good momentum
- 07:41:40 [bigbluehat]
- ...and then the 1.1 work showed up
- 07:41:53 [bigbluehat]
- ...and that's why we pushed against it a bit
- 07:42:02 [bigbluehat]
- ...and you all are deep into the `@context` space
- 07:42:32 [bigbluehat]
- ...but we've known from the start that the public Web JSON-LD space was actually processed differently
- 07:42:36 [bigbluehat]
- ...and without the `@context`
- 07:43:04 [bigbluehat]
- ...the promise made by the WG that the new parsers would still successfully parse the old JSON-LD
- 07:43:07 [bigbluehat]
- ...is that still true?
- 07:43:09 [bigbluehat]
- group: yes
- 07:43:16 [manu]
- q+ to suggest a compromise.
- 07:43:26 [bigbluehat]
- azaroth: but we should probably talk about version triggering...as that's goes a bit farther
- 07:44:05 [bigbluehat]
- ...to opt-in to the new features, you have to include `@version: 1.1`
- 07:44:19 [bigbluehat]
- ...and if you do, that in a context, the old processors--using the `@context` file--will choke
- 07:44:49 [bigbluehat]
- danbri: most of the others (Bing, etc) aren't doing JSON-LD processing using the `@context`
- 07:44:56 [bigbluehat]
- ...and we aren't either
- 07:44:59 [azaroth]
- ack manu
- 07:44:59 [Zakim]
- manu, you wanted to suggest a compromise.
- 07:44:59 [bigbluehat]
- ...so who does this break?
- 07:45:16 [bigbluehat]
- azaroth: those folks processing schema.org based data with JSON-LD 1.0 processors
- 07:45:32 [bigbluehat]
- manu: so, what we could do is use the current versioning mechanism
- 07:45:42 [bigbluehat]
- ...but schema.org could promise to not upgrade for 2-3 years
- 07:45:53 [bigbluehat]
- ...but still encourage folks to use the `@language` and `@direction` stuff now
- 07:46:31 [bigbluehat]
- danbri: or we could do the opposite and put 1.1 in the context--and see who cries?
- 07:47:06 [bigbluehat]
- gkellogg: so the way this works is a 1.0 processor is supposed to die when it sees the `@version: 1.1`, so it doesn't consume the wrong data
- 07:47:31 [manu]
- q+ to note that I never got around to my compromise proposal :)
- 07:47:36 [bigbluehat]
- azaroth: right, and some of those features can allow spoofing of terms...which could have security concerns--depending on what that data is used for
- 07:47:46 [bigbluehat]
- ack manu
- 07:47:46 [Zakim]
- manu, you wanted to note that I never got around to my compromise proposal :)
- 07:47:49 [azaroth]
- ack manu
- 07:48:07 [bigbluehat]
- manu: so the compromise proposal is to signal with the `@version: 1.1
- 07:48:23 [bigbluehat]
- ...but what we could do also is that any 1.1 processor could do feature detection
- 07:48:38 [bigbluehat]
- ...i.e. choose to upgrade for other reasons than just the `@version: 1.1`
- 07:48:45 [bigbluehat]
- gkellogg: so no need for the version announcement?
- 07:48:49 [bigbluehat]
- manu: I think it should still be there
- 07:49:02 [bigbluehat]
- gkellogg: so I've come to feel that the `@version` announcement is such a big bearier
- 07:49:06 [bigbluehat]
- ...that people will avoid it
- 07:49:24 [bigbluehat]
- manu: so over time if we see that the `@version` isn't being used, then we can take it out of the spec
- 07:49:30 [bigbluehat]
- ...so it may go away in a future JSON-LD
- 07:49:43 [bigbluehat]
- gkellogg: so Schema.org could avoid `@version`?
- 07:49:53 [pchampin]
- q+
- 07:49:57 [bigbluehat]
- manu: yes, they can use `@direction` now and that could trigger the upgraded processing
- 07:49:57 [azaroth]
- q+
- 07:50:37 [azaroth]
- ack pchampin
- 07:50:40 [bigbluehat]
- danbri: what I tried to get across last year was that there is JSON-LD "stuff" that isn't intended currently to be processed as JSON-LD
- 07:51:14 [bigbluehat]
- ...and there are other concerns arising elsewhere...and I'm sorry I've not been involved more to help you avoid these...but they still need addressing
- 07:51:32 [bigbluehat]
- pchampin: things will still break...just later...so the `@version` could be avoided
- 07:51:42 [bigbluehat]
- ...but we can recommend avoidance of other items also
- 07:51:50 [azaroth]
- q?
- 07:52:12 [bigbluehat]
- q+
- 07:52:13 [azaroth]
- ack azaroth
- 07:52:47 [bigbluehat]
- azaroth: so if you are concerned that there are 1.1 features that you MUST have processed, then you signal with `@version`
- 07:53:01 [bigbluehat]
- ...otherwise, you just let the processor figure it out from the stuff in the document
- 07:53:13 [manu]
- q+
- 07:53:21 [bigbluehat]
- ...if you have scoped properties or whatever in your context, but your document doesn't use them...then things would be fine
- 07:53:43 [bigbluehat]
- ivan: we have a close dependency right now
- 07:53:57 [bigbluehat]
- ...which is the publication manifest and we're at the end...and we had our story with i18n exactly for this reason
- 07:54:07 [bigbluehat]
- ...with these resolutions, I would have to add `@direction` to the manifest
- 07:54:19 [bigbluehat]
- ...that manifest is built up from schema.org for most of it's vocabulary
- 07:54:26 [bigbluehat]
- ...and adds a few more that we need that schema.org doesn't have
- 07:54:40 [bigbluehat]
- ...so what happens if I produce a book and don't put `@version` in it?
- 07:54:45 [chaals]
- chaals has joined #json-ld
- 07:54:49 [pchampin]
- q+ to answer ivan
- 07:55:25 [bigbluehat]
- ...google or bing or whoever processes it
- 07:55:41 [bigbluehat]
- danbri: we don't have a common code base...so we have no idea how these things are processed
- 07:55:52 [azaroth]
- ack bigbluehat
- 07:56:14 [manu]
- bigbluehat: Rob, the chances that you have that playground up w/ @version? Oh, there it is.... no it isn't.
- 07:56:57 [manu]
- bigbluehat: This is what the Publishing WG could do... define it as a term... "direction" set to "@direction"
- 07:57:11 [manu]
- gkellogg: I think schema.org has a 'direction' term?
- 07:57:44 [manu]
- bigbluehat: and you can't do, in context, @direction: direction?...
- 07:57:58 [manu]
- Group works through example on JSON-LD Playground...
- 07:58:37 [manu]
- bigbluehat: A v1.0 processor is going to choke, whatever we do.
- 07:58:45 [manu]
- danbri: What if we do an errata?
- 07:59:53 [bigbluehat]
- bigbluehat: yes. errata could work
- 08:00:05 [bigbluehat]
- ...main thing is getting people to support it so it doesn't choke
- 08:00:25 [manu]
- bigbluehat: The bulk of JSON-LD code is out of this code base, could "fix" it... could put it in 1.1.
- 08:00:35 [bigbluehat]
- manu: ivan just have Publishing WG use 1.1
- 08:00:45 [manu]
- q+
- 08:00:55 [manu]
- q- later
- 08:01:25 [manu]
- ivan: If we introduce @direction...
- 08:01:28 [manu]
- gkellogg: 1.0 will die
- 08:01:43 [azaroth]
- q?
- 08:01:57 [manu]
- ivan and gkellogg brawl! Chairs thrown, walls torn apart! :P
- 08:02:46 [manu]
- bigbluehat: We have stuff that have multiple languages, multiple directions... contents beyond are english... we need a way to do both, in our data, we'd ship @direction and use something in @context.
- 08:02:56 [manu]
- gkellogg: You don't need @version...
- 08:03:06 [manu]
- bigbluehat: I don't want other JSON-LD processors to break.
- 08:03:38 [azaroth]
- ack pchampin
- 08:03:38 [Zakim]
- pchampin, you wanted to answer ivan
- 08:03:38 [manu]
- ivan: If we find a way where we are not required to use @version... we have an option to use that, but a lot of data that used that stuff, it wouldn't use it anyway... we do redefine @direction to direction.
- 08:04:01 [danbri]
- java https://github.com/jsonld-java/jsonld-java , rdfjs https://github.com/rdfjs-base/parser-jsonld , php https://github.com/lanthaler/JsonLD , dotNet https://github.com/linked-data-dotnet/json-ld.net ... do we know which of these toolkits are likely to be upgraded? is there a test harness that can run them and see if they all barf on @direction ?
- 08:04:56 [manu]
- pchampin: The difference between the expressivity using context and data -- the benefits of the compromise is that you can publish a context that is not using any 1.1 feature... such as schema.org and still use 1.1 features in the data... yes, 1.0 processors will choke on the data, but they won't die on the context.
- 08:05:03 [azaroth]
- ack manu
- 08:05:18 [bigbluehat]
- manu: that's the exact point I wanted to make
- 08:05:39 [bigbluehat]
- ...if make the `@version` mandatory
- 08:05:40 [danbri]
- q+ to ask plans for media type; what happens to <script type="application/ld+json"> ?
- 08:06:14 [bigbluehat]
- ...then you can force it into 1.1 mode
- 08:06:19 [bigbluehat]
- ...but at the cost of the current processors
- 08:06:33 [bigbluehat]
- ...but we should leave it around until we know we can take it out and still accomplish the same goal
- 08:07:18 [manu]
- ivan: Is it possible to express the choice as a feature at risk?
- 08:07:56 [bigbluehat]
- ack danbri
- 08:07:56 [Zakim]
- danbri, you wanted to ask plans for media type; what happens to <script type="application/ld+json"> ?
- 08:08:01 [manu]
- scribe: manu
- 08:08:05 [gkellogg]
- q?
- 08:08:36 [manu]
- danbri: For the case where the JSON-LD is in the web page, late in the 1.0 process, Gregg helped spec the script tag, application/ld+json... what happens w/ the new version iterations.
- 08:09:25 [manu]
- bigbluehat: all version detection happens in body, the new version could get a new media type... it could... or a nother parameter to the media type.
- 08:10:18 [manu]
- bigbluehat: in that case, SEO bots could distinguish/care... devs could be told, to opt in, add semicolon v=2.
- 08:10:30 [manu]
- bigbluehat: different way to signal that...
- 08:10:44 [manu]
- danbri: Can we put some wiggle room in so future groups can do stuff?
- 08:10:57 [manu]
- q+ to push back against features that we're not going to use, this sounds like it can be done later.
- 08:11:15 [manu]
- azaroth: Yes, we can do this effectively for free.
- 08:11:35 [manu]
- bigbluehat: That's not an insane thing to say, as long as we have enough access to know media type expressed falls back.
- 08:11:35 [manu]
- q-
- 08:12:22 [azaroth]
- PROPOSAL: Mark the requirement for @version at-risk for CR, with the intent to make it optional to include but mandatory to process if present, allowing systems that want to require a particular processing mode to do so, without preventing feature detection based systems to upgrade over time and as needed
- 08:12:29 [azaroth]
- +1
- 08:13:43 [manu]
- +1
- 08:13:44 [gkellogg]
- +1
- 08:13:45 [bigbluehat]
- +1
- 08:13:45 [rubensworks]
- +1
- 08:13:46 [pchampin]
- +1
- 08:13:55 [ivan]
- +1
- 08:14:07 [azaroth]
- RESOLVED: Mark the requirement for @version at-risk for CR, with the intent to make it optional to include but mandatory to process if present, allowing systems that want to require a particular processing mode to do so, without preventing feature detection based systems to upgrade over time and as needed
- 08:15:08 [manu]
- ivan: We'll need to be very clear about how they're going to detect features, most likley in the text...
- 08:15:20 [manu]
- gkellogg: It's worth running this by Ralph and getting some thoughts.
- 08:16:43 [manu]
- bigbluehat: I'd like to talk about media type parameter, to signal that the content is JSON-LD 1.1... when does schema.org encourage its community to do that?
- 08:16:45 [manu]
- q?
- 08:16:48 [manu]
- q+
- 08:16:50 [azaroth]
- q+ to -1
- 08:17:03 [manu]
- q+ to -1 too, too many signaling mechanisms
- 08:17:49 [manu]
- danbri: The companies build what they build... we can encourage people to look at it... JSON-LD, for a long time Google was using it... Microsoft picked it up, facebook... wobbly for us to say preferred format JSON-LD... we're a project about schemas...
- 08:18:01 [manu]
- gkellogg: My feeling is that SEO community has moved over to JSON-LD...
- 08:18:09 [azaroth]
- ack manu
- 08:18:09 [Zakim]
- manu, you wanted to -1 too, too many signaling mechanisms
- 08:18:10 [manu]
- danbri: large part was Google picking it up.
- 08:18:11 [manu]
- q?
- 08:18:22 [bigbluehat]
- manu: having an extra signalling mech complicates things
- 08:18:24 [azaroth]
- ack azaroth
- 08:18:24 [Zakim]
- azaroth, you wanted to -1
- 08:19:32 [manu]
- gkellogg: I think this makes script tags ugly and error prone
- 08:19:35 [bigbluehat]
- gkellogg: there could be other stuff in the media type to signal processing mode
- 08:20:09 [manu]
- bigbluehat: The only way it would add value is if there is a declaration if people are using features, put it in safe box, people start consuming it.
- 08:20:26 [azaroth]
- q?
- 08:20:29 [manu]
- bigbluehat: this is not an evolutionary choice to start over... whereas other feature... DINNER!
- 08:20:31 [azaroth]
- TOPIC: Dinner :)
- 08:20:38 [bigbluehat]
- Option 1 - ~27 min walk (or 19 min bus) https://g.page/hotarunishijin
- 08:20:38 [bigbluehat]
- Option 2 - ~11 min walk https://goo.gl/maps/CSAS9oEXMddekJom7
- 08:22:34 [ivan]
- rrsagent, draft minutes
- 08:22:34 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html ivan
- 08:22:34 [ivan]
- zakim, bye
- 08:22:34 [ivan]
- rrsagent, bye
- 08:22:34 [RRSAgent]
- I see 1 open action item saved in https://www.w3.org/2019/09/19-json-ld-actions.rdf :
- 08:22:34 [RRSAgent]
- ACTION: gkellogg to write a couple paragraphs + example(s) for explaining expanded form and its use [1]
- 08:22:34 [RRSAgent]
- recorded in https://www.w3.org/2019/09/19-json-ld-irc#T01-30-48
- 08:22:34 [Zakim]
- leaving. As of this point the attendees have been gkellogg, bigbluehat, pchampin, ivan, dlehn, manu, simonstey, Bert, chaals, hadleybeeman, Dan_Burnett, DavidClarke, sangwhan,
- 08:22:34 [Zakim]
- Zakim has left #json-ld
- 08:22:38 [Zakim]
- ... rubensworks, addison
- 23:35:44 [RRSAgent]
- RRSAgent has joined #json-ld
- 23:35:44 [RRSAgent]
- logging to https://www.w3.org/2019/09/19-json-ld-irc
- 23:35:45 [ivan]
- rrsagent, set log public
- 23:35:45 [ivan]
- rrsagent, this meeting spans midnight
- 23:35:45 [ivan]
- Meeting: JSON-LD Working Group F2F in Fukuoka — Second day
- 23:35:45 [ivan]
- Date: 2019-09-20
- 23:35:45 [ivan]
- Agenda: http://tinyurl.com/y34nfpfg
- 23:35:46 [ivan]
- Regrets+
- 23:35:46 [ivan]
- Chair: azaroth, bigbluehat
- 23:48:24 [gkellogg]
- present+
- 23:48:27 [ivan]
- present+
- 23:48:28 [azaroth]
- present+
- 23:51:18 [azaroth]
- azaroth has joined #json-ld
- 23:55:14 [pchampin]
- pchampin has joined #json-ld
- 23:58:19 [dlehn]
- present+
- 23:58:46 [pchampin]
- present+
- 00:04:47 [Ralph]
- Ralph has joined #json-ld
- 00:05:40 [ivan]
- guests+ Ralph
- 00:08:16 [ivan]
- scribejs, set Ralph Ralph Swick
- 00:10:40 [tung]
- tung has joined #json-ld
- 00:12:03 [bigbluehat]
- present+
- 00:12:19 [azaroth]
- scribenick: azaroth
- 00:12:29 [azaroth]
- TOPIC: Discussions with Ralph
- 00:12:46 [ivan]
- scribejs, set tpk Duy-Tung Luu
- 00:12:54 [ivan]
- guests+ tpk
- 00:13:24 [azaroth]
- SUBTOPIC: Version announcement to version detection
- 00:13:27 [bigbluehat]
- yesterday's minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-19-json-ld
- 00:13:51 [azaroth]
- [Various non json-ld issues about w3c irc infrastructure]
- 00:15:02 [azaroth]
- bigbluehat: New feature to be added. Previously had rejected @direction for language, as expected to be solved in RDF
- 00:15:28 [azaroth]
- ... came back in the weds breakout session, that without the RDF momentum, that JSON-LD should fix it for ourselves plus specs dependent on us
- 00:16:20 [azaroth]
- ... WG is fine with doing this. Brings up the issue of versioning. Adding `@version` will intentionally make processors choke
- 00:16:47 [azaroth]
- ... want to make some features that don't make incompatible changes available
- 00:16:56 [azaroth]
- Ralph: What happens now?
- 00:17:13 [ivan]
- present+ manu
- 00:17:23 [azaroth]
- gkellogg: With a default vocab, it gets treated as a relative URI to the vocab. So it gets used, but not in the way anyone would expect
- 00:18:05 [azaroth]
- [disagreement about when things fail]
- 00:19:59 [azaroth]
- ... if you use @direction when it's mapped, then it won't work in a value object but will work elsewhere
- 00:20:15 [azaroth]
- ... if you use it when it isn't mapped, then it is ignored
- 00:20:44 [azaroth]
- gkellogg: in the schema.org case, they set @vocab and would only use @direction in a value object, thinking that processors will do feature detection
- 00:21:08 [azaroth]
- ... it would fail without the processor, due to @vocab
- 00:21:36 [azaroth]
- bigbluehat: ActivityPub also would benefit from this and use @vocab
- 00:22:05 [azaroth]
- ... postel's law discussions about how to get there with as much as possible
- 00:22:19 [chaals]
- chaals has joined #json-ld
- 00:22:30 [azaroth]
- ... concerns about whether this would actually get to where we want to
- 00:22:42 [azaroth]
- gkellogg: We've identified where in the API it has effects
- 00:22:59 [azaroth]
- ... the feature detection mode, the processor would start off in 1.0 mode. It would see 1.1 at some point and switch to 1.1 mode
- 00:23:26 [azaroth]
- ... to use a 1.1 feature, you MUST have @version 1.1 in the context, today. Doesn't have to be the first context, just one of them
- 00:23:36 [pchampin]
- q+
- 00:23:48 [azaroth]
- ... the proposal is to facilitate the use of 1.1 features is it reasonable to not do that
- 00:24:03 [azaroth]
- ... to switch to 1.1 when you're using something that you detect as being part of 1.1. A lazy evaluation
- 00:24:23 [azaroth]
- ... a 1.1 processor will be fine
- 00:24:50 [manu]
- present+
- 00:24:50 [pchampin]
- q-
- 00:24:59 [azaroth]
- ... the issue is for 1.0 processors. We didn't lock down things in 1.0, so it might ignore things in the context that would change the interpretation of the data
- 00:25:17 [azaroth]
- ... one of the things is an id map, keys are ids values are objects for the uris.
- 00:25:27 [azaroth]
- ... a 1.0 processor would just think it was another object with strange properties
- 00:25:36 [azaroth]
- ... could get very very different interpretation of the same document
- 00:25:51 [pchampin]
- q+
- 00:25:51 [azaroth]
- ... if a publisher of a context is concerned about that, then use `@version` announcement
- 00:26:14 [bigbluehat]
- ack pchampin
- 00:26:19 [azaroth]
- ... but might have some reasons to not do that, if you don't worry too much about the interpretation
- 00:26:43 [azaroth]
- pchampin: One idea - we have an extensive test suite. Could try to run the 1.1 tests on a 1.0 processor and see which ones fail or not
- 00:26:47 [bigbluehat]
- +1
- 00:26:59 [azaroth]
- ... could compare the graphs and thus identify the features that really break things or not
- 00:27:06 [azaroth]
- ... then discuss in best practices document
- 00:27:22 [azaroth]
- ... as to which features should really have `@version`
- 00:27:34 [azaroth]
- Ralph: Good to know what "break" means
- 00:27:48 [pchampin]
- +1
- 00:27:52 [azaroth]
- ... if you get an object you can't interpret, but all the other things are fine, that's less risky than if you interpret something wrong but don't know
- 00:28:07 [azaroth]
- gkellogg: There'd be no legit 1.0 data that tried to use lists of lists
- 00:28:17 [azaroth]
- ... it would be useful to see what a 1.0 processor would do
- 00:28:32 [azaroth]
- ... we have the tests, we can have versions of the tests that don't announce 1.1 and see what happens
- 00:28:54 [azaroth]
- Ralph: @version says you must not interpret this using 1.0 rules
- 00:28:59 [dlehn]
- list of lists had explicit error in 1.0 jsonld.js
- 00:29:03 [azaroth]
- bigbluehat: I think there's consensus to do this moving forward
- 00:29:39 [azaroth]
- gkellogg: blanket statement that publishers use version announcement, with warnings for features of what happens if you don't do announcements
- 00:29:45 [manu]
- rrsagent, draft minutes
- 00:29:45 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html manu
- 00:29:49 [pchampin]
- q+
- 00:29:58 [azaroth]
- Ralph: two cases, different results but new objects aren't understood.
- 00:30:14 [azaroth]
- gkellogg: set of okay results and others that are crazy
- 00:30:16 [azaroth]
- q?
- 00:31:06 [azaroth]
- ivan: During transition phase we have a problem. Until schema.org processors upgrade, any json-ld data for schema.org that uses direction will fail
- 00:31:13 [bigbluehat]
- q?
- 00:31:44 [azaroth]
- tpk: incompatibility not necessarily a feature, could be a logical error between interaction of features
- 00:31:59 [azaroth]
- ... hard to anticipate all the tests needed
- 00:32:06 [manu]
- +1 I'm also concerned about combinatorial issues w/ feature detection
- 00:32:08 [bigbluehat]
- ack pchampin
- 00:32:47 [azaroth]
- pchampin: For proposal for warnings in the spec when dangerous features are used without @version, sounds like a good idea but also the bnode @vocab warning for activitystreams
- 00:32:52 [azaroth]
- ... should be cautious about things
- 00:33:02 [azaroth]
- gkellogg: that was when we deprecated behavior that we didn't think was used
- 00:33:14 [azaroth]
- ... not because of the spec, just the way my implementation interpretted it
- 00:33:42 [azaroth]
- bigbluehat: One thing that came up yesterday was that the processors aren't mostly json-ld processors anyway
- 00:33:47 [azaroth]
- ... they won't care
- 00:34:06 [azaroth]
- ... only people that we're hurting are json-ld processors
- 00:34:14 [azaroth]
- ... hard time making the case
- 00:34:37 [azaroth]
- ... it's no issue for non json-ld processors of the data
- 00:35:01 [azaroth]
- ... it's now in lighthouse, which is a json-ld processor for real though
- 00:35:24 [azaroth]
- [SDTT]
- 00:35:30 [azaroth]
- gkellogg: SDTT isn't a validator
- 00:35:42 [azaroth]
- ivan: True but it reflects as much as is known about what schema.org processors do
- 00:36:37 [azaroth]
- ... this construct which is valid JSON-LD isn't processed correctly, for value objects
- 00:36:57 [azaroth]
- bigbluehat: We heard danbri say that they would be happy to promote it, but that's all that they can do
- 00:37:05 [bigbluehat]
- q?
- 00:37:14 [azaroth]
- pchampin: Shouldn't break things that currently work ... including things that don't work
- 00:37:21 [azaroth]
- [laughter]
- 00:37:33 [azaroth]
- gkellogg: SDTT isn't a metric for judging brokenness
- 00:37:51 [azaroth]
- ... people complain about why SDTT complains about stuff that the linter is fine with
- 00:38:17 [azaroth]
- ivan: schema.org is already broken for value objects regardless of what we do here
- 00:38:30 [azaroth]
- bigbluehat: Website owners just want it to show up in the search index
- 00:38:43 [azaroth]
- gkellogg: that it doesn't work in SDTT doesn't mean it won't work in the inde
- 00:38:44 [azaroth]
- x
- 00:39:18 [azaroth]
- Ralph: Still the closest we have. On the principle of making sdtt doing something worse isn't wise, we shouldn't do it, but it already doesn't do it so it's no worse
- 00:40:35 [azaroth]
- [playing with sdtt]
- 00:41:11 [azaroth]
- [accepts https:// and http:// schema.org / or not / ]
- 00:41:17 [azaroth]
- q?
- 00:42:21 [azaroth]
- ivan: one thing for presence of director was a question came up. That version is not required would be put into CR as "at risk"
- 00:42:32 [azaroth]
- ... during implementation if we find feature detection to be too hard, ...
- 00:42:40 [azaroth]
- ralph: or a lot of documents would be broken
- 00:42:53 [azaroth]
- ivan: yes, then changing behavior in CR would be acceptable
- 00:43:07 [azaroth]
- bigbluehat: danbri said we don't look at the context
- 00:43:16 [azaroth]
- ... they don't process it
- 00:43:50 [bigbluehat]
- s/we/SEO bots/
- 00:44:06 [bigbluehat]
- scribe+ bigbluehat
- 00:44:26 [bigbluehat]
- azaroth: is it OK to mark something as "at risk" to note that something has changed--and not that it's something we want to have taken out
- 00:44:42 [bigbluehat]
- ...for example, if it turns out that some things are possible and some other things are really hard
- 00:44:53 [bigbluehat]
- ...then we might change how the warnings/errors work for those
- 00:45:15 [bigbluehat]
- Ralph: so your proposal is that there will be feature detection
- 00:45:22 [bigbluehat]
- ...and what's at risk is that you may require `@version`
- 00:45:26 [gkellogg]
- q+
- 00:45:51 [azaroth]
- gkellogg: Possible middle ground too.
- 00:45:53 [bigbluehat]
- ...your proposal is to make `@version`possible, and you're marking the requirement of it as at risk
- 00:46:11 [azaroth]
- Ralph: Can clarify in the document that things are at risk as to being available without @version
- 00:46:25 [azaroth]
- ... two categories of features ... ones that are turned on without @version which is at risk, and those that require @version
- 00:47:06 [azaroth]
- SUBTOPIC: direction part 3 ... RDF
- 00:47:38 [azaroth]
- ivan: what we agreed yesterday is the syntax. We will have direction in json-ld. Within json-ld world it just works
- 00:47:47 [azaroth]
- ... however, the question is if we generate RDF, what do we do?
- 00:48:05 [azaroth]
- ralph: can we be more precise about "generate RDF"?
- 00:48:19 [azaroth]
- ivan: Produce an RDF graph with a literal with a direction
- 00:49:02 [azaroth]
- ... then one approach is that the processor has two api run-time options. One option is to say forget it. It would just disappear and generate a traditional language literal
- 00:49:32 [azaroth]
- ... the other is to define new RDF terms for language and direction, where instead of a literal it's a blank node
- 00:49:41 [azaroth]
- ... a kind of skos-xl like structure for literals
- 00:49:51 [azaroth]
- ... the positive aspect of the structure is that it round trips through the graph
- 00:49:54 [azaroth]
- ... the information isn't lost
- 00:50:04 [bigbluehat]
- q?
- 00:50:19 [azaroth]
- ... the negative aspect is if RDF data goes this way, we create a parallel universe for language+direction literals
- 00:50:27 [azaroth]
- ... json-ld users can pick which way they want
- 00:50:30 [azaroth]
- ... but what's the default
- 00:50:41 [azaroth]
- ... don't have an answer, perhaps via a coin flip
- 00:51:01 [azaroth]
- ... that's where we are
- 00:51:18 [azaroth]
- ivan: there are other possibilities for how to reflect into RDF
- 00:51:24 [azaroth]
- ... could also be a new datatype
- 00:51:29 [azaroth]
- ... there's always a parallel universe
- 00:51:57 [azaroth]
- [looks at rdf literals and base direction doc]
- 00:52:41 [azaroth]
- ... question is whether there's a problem to define two new terms in rdf: namespace
- 00:52:47 [azaroth]
- q+
- 00:52:52 [pchampin]
- q+
- 00:52:58 [azaroth]
- ralph: comfortable with the processor option
- 00:53:14 [azaroth]
- gkellogg: there are options for other things, though most people use default
- 00:53:17 [bigbluehat]
- ack gkellogg
- 00:53:31 [azaroth]
- gkellogg: Not acceptable to not round trip. Should do something that preserves it.
- 00:53:38 [Ralph]
- s/comfortable/?you are already comfortable
- 00:54:17 [azaroth]
- ... lots of discussion. Future group would be expected to replace or endorse the structure. A processor option would let the future processor adapt
- 00:54:25 [azaroth]
- ... can't keep it entirely in the JSON-LD domain
- 00:54:28 [bigbluehat]
- ack azaroth
- 00:54:37 [manu]
- q+ to -1 intermediate structure... we should try to solve the problem the right way... use JSON-LD as a forcing function, even if it doesn't round trip, even if it's not RDF as it's known today.
- 00:54:44 [bigbluehat]
- azaroth: I generally agree. two comments, though
- 00:54:45 [pchampin]
- q-
- 00:55:00 [bigbluehat]
- ...for CR, if we mark it at risk, and it turns out that....
- 00:55:02 [bigbluehat]
- ivan: mark what?
- 00:55:07 [bigbluehat]
- azaroth: well...whatever we define here
- 00:55:18 [bigbluehat]
- ...and at implementation phase it turns out there's push back against the structured approach
- 00:55:27 [bigbluehat]
- ...because it results in an "always punning" scenario
- 00:55:40 [bigbluehat]
- ...and if, like us, you don't have punning as an option
- 00:55:48 [bigbluehat]
- ...then the language tag approach would be preferred
- 00:55:58 [bigbluehat]
- ...which would be my personal preference
- 00:56:08 [bigbluehat]
- ...because it puts things in an expected place
- 00:56:18 [ivan]
- q+
- 00:56:19 [bigbluehat]
- ...the SPARQL queries already have to search for "en-*"
- 00:56:25 [bigbluehat]
- ...there are of course other cons
- 00:56:40 [bigbluehat]
- ...but if it turns out that during implementation that the structured approach is not the best default
- 00:56:43 [pchampin]
- q+
- 00:56:52 [bigbluehat]
- ...do we have to go back through CR in order to change that default?
- 00:57:19 [bigbluehat]
- gkellogg: the i18n seemed to strongly object to the use (well..."hacking") of the language tag
- 00:57:29 [bigbluehat]
- ivan: I'd even expect them to formally object to that solution
- 00:57:43 [bigbluehat]
- ...at this point I don't think it's a choice
- 00:57:56 [manu]
- ack manu
- 00:57:56 [Zakim]
- manu, you wanted to -1 intermediate structure... we should try to solve the problem the right way... use JSON-LD as a forcing function, even if it doesn't round trip, even if it's
- 00:57:59 [Zakim]
- ... not RDF as it's known today.
- 00:57:59 [bigbluehat]
- azaroth: addision did say he'd rather have it in the language string than to not keep it at all
- 00:58:18 [azaroth]
- manu: I don't think the structure solves things. We haven't had this for a long time.
- 00:58:24 [azaroth]
- Ralph: And getting objections as a result
- 00:58:55 [azaroth]
- manu: Yes. We should be careful to do this right. It's a half way solution that introduces problems. We should do the thing that we think is the final solution
- 00:59:09 [azaroth]
- .. we can be a forcing function. By default it's dropped, it doesn't impact them if you don't want it
- 00:59:11 [azaroth]
- ... so opt in
- 00:59:43 [ivan]
- q?
- 00:59:45 [azaroth]
- ... what it looks like in RDF - I agree that the i18n folks dont' want it in the tag - but there could be a ^direction
- 00:59:57 [azaroth]
- ... of the options I've seen that looks the cleanest
- 01:00:05 [azaroth]
- ... don't have to upgrade infrastructure now until it's implemented
- 01:00:14 [azaroth]
- ... BCP47 doesn't have a caret in any language
- 01:00:20 [azaroth]
- ... so a clean token to split the string on
- 01:00:34 [azaroth]
- ... if that's the final option, then we should force it in that direction
- 01:00:36 [bigbluehat]
- ack ivan
- 01:00:42 [gkellogg]
- q+ to respond to manu
- 01:00:43 [azaroth]
- ivan: Am fine with opt in
- 01:00:53 [azaroth]
- ... but opt in should mean generate something in RDF which is valid today
- 01:01:05 [azaroth]
- ... generating invalid RDF is unusable anyway
- 01:01:26 [azaroth]
- ... no idea wht the community will come to a solution, if ever, but something that no processor will accept today is useless
- 01:01:37 [azaroth]
- ... caret means we create another syntax
- 01:01:52 [azaroth]
- ... could have created something with a string and lots of carets bla bla :)
- 01:02:01 [azaroth]
- ... won't have it today, might not ever
- 01:02:23 [manu]
- q+ there is another option....
- 01:02:26 [azaroth]
- ... so generating it is pointless. Only one that's valid is the structure
- 01:02:27 [azaroth]
- q+
- 01:02:46 [manu]
- q+
- 01:02:49 [bigbluehat]
- ack pchampin
- 01:02:50 [manu]
- zakim, close the queue
- 01:02:50 [Zakim]
- ok, manu, the speaker queue is closed
- 01:03:01 [ivan]
- ack pchampin
- 01:03:18 [azaroth]
- pchampin: If we go the way of an option, we should consider the equivalent for rdf to json-ld
- 01:03:28 [bigbluehat]
- ack gkellogg
- 01:03:28 [Zakim]
- gkellogg, you wanted to respond to manu
- 01:03:29 [azaroth]
- ... that might be none trivial for an intermediate node solution
- 01:03:58 [azaroth]
- gkellogg: to manu's point, the algorithms to make a dataset rather than nquads serialization, adding a direction is something a dataset would need to store
- 01:04:04 [azaroth]
- ... we have uris bnodes and literals
- 01:04:11 [azaroth]
- ... only if language tagged can they have a language
- 01:04:29 [ivan]
- guests+ fantasai
- 01:04:29 [azaroth]
- ... literal would have a direction and a language ... youve added a column in a store
- 01:04:37 [azaroth]
- ... an rdf WG might decide to do that
- 01:04:48 [manu]
- q+ to note that we can have multiple options
- 01:04:49 [bigbluehat]
- ack Ralph
- 01:04:50 [azaroth]
- ... deafening silence was the reaction from the community
- 01:04:58 [azaroth]
- Ralph: strong +1 to opt in
- 01:05:06 [azaroth]
- ... default should be to break the fewest tools
- 01:05:17 [azaroth]
- ... option to do something better is most useful if the better is something that tools can work with
- 01:05:22 [azaroth]
- ... suggests some choices
- 01:05:24 [manu]
- q+ to note that we have done this before, pushed RDF to do new things via JSON-LD.
- 01:05:29 [manu]
- q?
- 01:05:53 [azaroth]
- ... don't know how it works now but could have non binary option, and in 1.2 could then have a 3 or 4 value option with different syntaxes
- 01:06:02 [azaroth]
- ... urge to do something useful to existing tools
- 01:06:03 [bigbluehat]
- ack azaroth
- 01:07:02 [bigbluehat]
- ack manu
- 01:07:20 [azaroth]
- manu: What goes along with the option could be a function to decide what to output
- 01:07:29 [azaroth]
- ... e.g. RDF in some format
- 01:07:50 [azaroth]
- ... if you want new triples then great. BUt it lets the community to decide how to output it so they can integrate with different toolsets
- 01:07:57 [azaroth]
- ... no clear solution that meets all the requiremetns
- 01:08:08 [azaroth]
- ... if the solution is new triples, we have no interest in implementing it
- 01:08:21 [azaroth]
- ... don't have a strong requirement to do that, so would just wait until the problem has a final solution
- 01:08:49 [azaroth]
- ... also to note that the argument of existing ecosystem not doing this is invoked a lot. Invoked in 1.0 but we defined various things and they were pulled into 1.1
- 01:09:16 [azaroth]
- ... arguing this is not the state of the world today can be valid, but can't push the ecosystem forward
- 01:09:20 [Ralph]
- [so if Manu has no strong requorement at the moment, having infinite extensibility with a function call-out seems way overblown]
- 01:09:42 [azaroth]
- ... concerned by implementation complexity. People saying they can't implement a 1.1 processor
- 01:09:51 [azaroth]
- ... everytime they look at the spec they see a massive set of features
- 01:10:09 [azaroth]
- ... looks like it will cost a lot of money so they pick and choose a small set and pay attention to the things they think are important
- 01:10:33 [bigbluehat]
- PROPOSAL: do not, by default, handle `@direction` expression in `toRDF` (or `fromRDF`)
- 01:10:44 [azaroth]
- ... every new feature makes it worse -- too many options and we make it very difficult.
- 01:11:12 [manu]
- +1
- 01:11:30 [azaroth]
- Clarification - the default option for toRDF is to drop it
- 01:11:39 [bigbluehat]
- +1
- 01:11:42 [ivan]
- +1
- 01:11:44 [azaroth]
- ... a future proposal will add in more options
- 01:11:48 [pchampin]
- +0.5
- 01:11:48 [azaroth]
- +1
- 01:12:40 [gkellogg]
- +0.1
- 01:13:05 [bigbluehat]
- RESOLVED: do not, by default, handle `@direction` expression in `toRDF` (or `fromRDF`)
- 01:14:15 [azaroth]
- [bringing fantasai up to speed on @direction]
- 01:16:43 [azaroth]
- azaroth: from before -- data type is also a valid option that solves the objectproperty / dataproperty distinction in OWL
- 01:17:43 [azaroth]
- TOPIC: Future of JSON-LD WG in proposed new process
- 01:18:01 [fantasai]
- fantasai has joined #json-ld
- 01:18:05 [azaroth]
- fantasai: Any questions about hte process?
- 01:18:08 [fantasai]
- r=fantasai on @direction :)
- 01:18:27 [azaroth]
- gkellogg: About CR, if we drop out of CR we can publish WG drafts, but we can also iterate in CR?
- 01:18:53 [azaroth]
- fantasai: CSS iterates within CR, it just takes longer. Right now CSS has the drafts we post to TR, and editors drafts
- 01:19:17 [azaroth]
- ... publishing to the TR page takes some process, up to 4 weeks, has gotten better but got as far as 3 months in the past
- 01:19:25 [azaroth]
- ... still can't publish every week
- 01:19:39 [azaroth]
- ... editors draft is up to date, TR gets published every 6+ months
- 01:19:50 [azaroth]
- ... meaning people look at the drafts not TR, which is supposed to be a scratch space
- 01:20:12 [azaroth]
- ... allow publication on the site ... it's not regressing, not adding brand new features, just fixing the issues that are being reported
- 01:20:39 [jc]
- jc has joined #json-ld
- 01:20:49 [azaroth]
- ... it will be part of the next CR. So publish to the TR/ URL, and make a distinction between WG updates and the snapshot CR that have had directors' approval and trigger patent exclusion
- 01:20:52 [bigbluehat]
- q?
- 01:20:56 [azaroth]
- ivan: How to decide which to choose?
- 01:21:08 [azaroth]
- fantasai: Lawyers don't like looking at things too foten
- 01:21:12 [azaroth]
- s/foten/often/
- 01:21:22 [azaroth]
- fantasai: 6-24 months should be publishing a snapshot
- 01:21:28 [azaroth]
- ... up to the WG as to exactly when
- 01:21:40 [azaroth]
- ... some CRs don't get a lot of changes.
- 01:21:48 [azaroth]
- ... 6-24 from any substantive change
- 01:21:59 [azaroth]
- ivan: when will it come into effect?
- 01:22:11 [azaroth]
- fantasai: will take effect Q2 of 2020, or so
- 01:22:28 [azaroth]
- ralph: You asked when will there be process 2020, and elika guesses Q2
- 01:22:38 [azaroth]
- ivan: we're chartered until June
- 01:22:49 [azaroth]
- fantasai: If you don't get to TR and get an extension...
- 01:23:00 [azaroth]
- ... we get rechartered every two years as well
- 01:23:13 [azaroth]
- ... for what changes, nothing unless you want to update more frequently
- 01:23:48 [azaroth]
- ivan: for us, what is interesting, our current charter goes until june. We'll have no problem getting to REC (apart from @direction) by then
- 01:23:53 [azaroth]
- ... the question is what to do after that
- 01:23:59 [jc]
- jc has joined #json-ld
- 01:24:18 [Ralph]
- s/You asked when will there be process 2020/the question you just asked Elika is "when will there be process 2020?"
- 01:24:20 [azaroth]
- ... the recommendation we might suppose we have 1 or 2 more features that the community wants to add . Not to redo the whole thing
- 01:24:31 [azaroth]
- ... we thought everything was good until yesterday until @direction came along
- 01:24:47 [azaroth]
- ... in a year from now we have a rec published, but there's a new feature ... today we have to recharter from A-Z
- 01:24:53 [azaroth]
- ... is that easier? And if so how?
- 01:25:29 [azaroth]
- fantasai: Proposal to allow non-feature addition changes. Annotate the errata inline. Call for review. Don't have to drag the whole thing through CR
- 01:25:30 [bigbluehat]
- q?
- 01:25:31 [azaroth]
- q+ re WG
- 01:25:37 [azaroth]
- zakim, open the queue
- 01:25:37 [Zakim]
- ok, azaroth, the speaker queue is open
- 01:25:38 [azaroth]
- q+ re WG
- 01:26:02 [azaroth]
- fantasai: good to have recs spawn other recs without the whole dance, just start at CR
- 01:26:11 [azaroth]
- ... shortcut around a lot of the process for the feature addition
- 01:26:16 [azaroth]
- ... to publish a .1 release or whatever
- 01:26:18 [bigbluehat]
- q+
- 01:26:20 [azaroth]
- ... that's the feedback at tpac
- 01:26:58 [azaroth]
- ... don't have a clear answer as to which option to do that. Could use errata system for feature additions, or could make it easier to republish with a new feature with a shorter process
- 01:27:05 [azaroth]
- ... still need to recharter
- 01:27:09 [azaroth]
- ... as need a WG
- 01:27:25 [azaroth]
- ivan: How to recharter then? If we recharter in a year?
- 01:27:41 [azaroth]
- ... if there's nothing else happening, then is it a valid charter?
- 01:27:52 [azaroth]
- fantasai: Don't think anything defines what is a valid charter
- 01:28:00 [azaroth]
- ... if that's the kind of charter we want to have, we can discuss that
- 01:28:11 [azaroth]
- ... could wait until there are feature requests coming in
- 01:28:21 [azaroth]
- ivan: charters take 3 or 4 months today.
- 01:28:45 [azaroth]
- ... have to announce to AC, give them a month, then we do the charter, then to vote which is 6 weeks ... so minimum of 2.5 months
- 01:29:03 [azaroth]
- ... we want to add one feature, say direction, so 3 months for administration of a very short wg
- 01:29:09 [manu]
- q+ for the other alternative...
- 01:29:13 [bigbluehat]
- ack azaroth
- 01:29:13 [Zakim]
- azaroth, you wanted to discuss WG
- 01:29:32 [manu]
- q+ to say that there is another alternative... which is a maintenance WG, which defers much of its decisions to a CG.
- 01:29:35 [gkellogg]
- q+ to ask about process for registray/namespace documents
- 01:30:08 [azaroth]
- ivan: would the AC accept a maintenance WG that sat around for a long time. I think the XML group did that, and the AC said no close them
- 01:30:22 [bigbluehat]
- ack bigbluehat
- 01:30:24 [azaroth]
- ... now with this process we bring back dormant WGs
- 01:31:22 [azaroth]
- bigbluehat: With JSON-LD we have parallel CG / WGs. The CG will reboot to take up work that we don't do. If the process is easier to get from CG to WG for maintenance, that could more easily get a charter, they could prep the errata and have the shorter charter
- 01:31:37 [azaroth]
- ... here's our errata from the last year, boot up the WG, get the official okay and then shut down again
- 01:31:48 [azaroth]
- ... prefer the maintenance WG thing as lots of administration
- 01:32:03 [azaroth]
- ... sends the wrong signals ... news goes out that XML is closed at the w3c
- 01:32:33 [azaroth]
- ... other WGs like annotation. Shipped and people came up and said "is everything okay? the WG closed?!"
- 01:32:52 [azaroth]
- fantasai: "concluded" rather than "closed" in the press release?
- 01:32:58 [azaroth]
- ... satisfied the charter
- 01:33:02 [azaroth]
- ivan: Maintenance issue stands
- 01:33:16 [azaroth]
- bigbluehat: undulating CG /WG thing would get old fast for administration
- 01:33:34 [azaroth]
- gkellogg: a better relationship for the sine wave
- 01:33:40 [ivan]
- q?
- 01:33:52 [azaroth]
- Ralph: Ivan made a good point. Pendulum has swung back and forth
- 01:34:02 [azaroth]
- ... now we realize we need CSS WG for ever
- 01:34:16 [bigbluehat]
- ack manu
- 01:34:16 [Zakim]
- manu, you wanted to discuss the other alternative... and to say that there is another alternative... which is a maintenance WG, which defers much of its decisions to a CG.
- 01:34:29 [azaroth]
- manu: VC WG in discussion about maintenance mode
- 01:34:52 [azaroth]
- ... credentials CG, and VC WG. WG has declared success, going into maintenance mode. Continuation of the IPR policy
- 01:34:57 [azaroth]
- ... new features in CG won't have IPR
- 01:35:22 [azaroth]
- ... so talking about VCWG defers all decision making to the CCG. they continue to iterate and discuss. Once it's ready they feed the features back to the WG
- 01:35:29 [azaroth]
- ... staff contact goes down to 0.05 or whatever
- 01:35:38 [azaroth]
- ... only thing is that chairs can veto things that come in
- 01:36:03 [azaroth]
- ... but did not want members with lots of additions to be able to short circuit it
- 01:36:12 [azaroth]
- ... don't want to say closed, but also doesn't take up resources
- 01:36:19 [azaroth]
- ... helps the community keep the spec current
- 01:36:37 [azaroth]
- ... bugs and errata could be fixed, new features with the new process would be good
- 01:36:45 [azaroth]
- ... would that model work for JSON-LD ?
- 01:37:05 [azaroth]
- ... concern is addition of new features to the point where only a few people can ever implement it
- 01:37:14 [azaroth]
- fantasai: not a question for my time on the AB
- 01:37:19 [azaroth]
- ... working on streamlining the process for WGs
- 01:37:28 [azaroth]
- ... putting errata in is a lot of work
- 01:37:37 [azaroth]
- ... but chartering hasn't come up, but seems like a problem
- 01:37:45 [azaroth]
- ... some kind of maintenance status charter is appropriate
- 01:37:59 [azaroth]
- ... minor feature is interesting one. How to decide if something is minor
- 01:38:20 [bigbluehat]
- q?
- 01:38:21 [azaroth]
- ... a maintenance WG process?
- 01:38:27 [azaroth]
- Ralph: Lowercase p process issue
- 01:38:42 [azaroth]
- ... CSS is constant, other groups don't know when the next big thing is coming
- 01:39:04 [azaroth]
- fantasai: Charter to do maintenance rather than adding new features without a recharter / amendment
- 01:39:05 [danbri]
- danbri has joined #json-ld
- 01:39:16 [azaroth]
- ... if new features come in that are good ideas you amend the charter for specific features
- 01:39:25 [azaroth]
- Ralph: have the machinery but not necessarily the will to do this
- 01:39:56 [azaroth]
- fantasai: Either about Process or just communication. Not charter maintenance groups to do new work, without amendment and review
- 01:40:17 [bigbluehat]
- ack gkellogg
- 01:40:17 [Zakim]
- gkellogg, you wanted to ask about process for registray/namespace documents
- 01:40:18 [azaroth]
- ... that might be acceptable
- 01:40:53 [azaroth]
- gkellogg: an issue we dealt with, the DID wg did. Work starts in the CG, WG elects to take it as input. Lots of technical aspects. COmmit history, open issues to transfer etc
- 01:40:58 [azaroth]
- ... policies and tooling would be good
- 01:41:27 [azaroth]
- ... to the CG, JSON-LD was at a point where we gathered a backlog of features but no way to get to WG without the CG writing a big spec
- 01:41:34 [azaroth]
- ... makes the 1.1 update feel like a BIG update
- 01:41:46 [azaroth]
- ... if CSS was only updated every 5 years, it would overwhelm the community too
- 01:41:55 [azaroth]
- ... an official relationship between CG and WG for that purpose
- 01:42:05 [azaroth]
- ... of new features
- 01:42:24 [azaroth]
- ... Registries. They're a different process ... they live in TR?
- 01:42:26 [azaroth]
- fantasai: yes
- 01:42:43 [azaroth]
- gkellogg: Similar to namespace documents. rdf ontology lives in ns/
- 01:43:03 [azaroth]
- ... groups keep documents there. Should we start using something else for namespaces?
- 01:43:12 [azaroth]
- fantasai: Had a number of groups asking for registries
- 01:43:19 [azaroth]
- ... they have some normative status
- 01:43:35 [azaroth]
- ... they work around it by going through the whole REC track process but then updates are very painful
- 01:43:49 [azaroth]
- ... in a lot of cases if there's no IPR, then some go to notes
- 01:43:52 [azaroth]
- ... then we update when we want
- 01:44:00 [azaroth]
- ... others don't know, so just put it in a wiki
- 01:44:22 [azaroth]
- ... in terms of groups that need IPR, then it needs the rec process.
- 01:44:44 [azaroth]
- ... making it easier to edit will make it faster, but at least 70 days for anything for exclusions and ip review
- 01:44:52 [azaroth]
- ... so 2-3 months at least
- 01:45:21 [azaroth]
- ... for things that need more frequent updates, no restriction on notes at all. Registry needs a little bit more official
- 01:45:40 [azaroth]
- ... can't change the process, can't change the columns, can only add new entries in the table
- 01:45:48 [azaroth]
- ... sometimes just collision management
- 01:45:55 [azaroth]
- ... othertimes it needs to be validated
- 01:46:02 [azaroth]
- ... e.g. to detect duplicates
- 01:46:23 [azaroth]
- ... Process is that you can edit what you want, so long as it follows the process defined in the registry
- 01:46:25 [bigbluehat]
- q?
- 01:46:35 [azaroth]
- gkellogg: impelemtnation reports are there to get CR
- 01:46:46 [azaroth]
- ... other people want to be part of the report later
- 01:46:57 [azaroth]
- bigbluehat: good for community
- 01:47:04 [azaroth]
- gkellogg: linked from the spec
- 01:47:15 [azaroth]
- fantasai: not really a registry?
- 01:47:22 [azaroth]
- gkellogg: test suite fixes
- 01:47:25 [bigbluehat]
- ack Ralph
- 01:47:38 [azaroth]
- Ralph: incentive to implement in CR too
- 01:48:02 [azaroth]
- ... new TR class called registry is bikeshedding. The feature this new class of docs has is that it must come with a maintenance policy for how to add things
- 01:48:09 [azaroth]
- ... a WG note can come with an update policy
- 01:48:38 [azaroth]
- ... this is the registry of names for this thing. Lost that battle, because people add semantics to Note that it's a low class thing
- 01:48:49 [azaroth]
- ... people wanted another name for it
- 01:48:57 [azaroth]
- fantasai: there's a bit more process on it
- 01:49:13 [azaroth]
- ... can only be updated by the WG. WG doesn't necessarily want o maintain the registry
- 01:49:26 [azaroth]
- ... separate process in order to delegate the maintenance to a CG or the team or something else
- 01:49:46 [azaroth]
- ... as long as they follow the rules, it gets updated on TR without a WG
- 01:50:08 [azaroth]
- Ralph: argued that if the WG stops, the team gets to update notes, which they could delegate to someone else
- 01:50:09 [bigbluehat]
- q?
- 01:51:04 [azaroth]
- Ralph: CG transitions. Good to have best practices. JSON-LD started as a WG, then CG, then a WG.
- 01:51:17 [azaroth]
- ... annotation didn't start with a WG.
- 01:51:29 [azaroth]
- ... write down what worked and what didn't as you've been through it twice
- 01:51:40 [azaroth]
- ... don't understand it well enough to do it in Process
- 01:51:57 [azaroth]
- fantasai: send it to the process list
- 01:52:22 [azaroth]
- bigbluehat: happy about the registry process
- 01:52:38 [azaroth]
- Ralph: asked tag to write design templates a while ago. They punted to process CG.
- 01:52:42 [fantasai]
- https://lists.w3.org/Archives/Public/public-w3process/
- 01:53:18 [azaroth]
- TOPIC: break
- 02:03:40 [fantasai]
- Thanks everyone!
- 02:26:31 [gkellogg]
- scribe+
- 02:26:35 [tung]
- tung has joined #json-ld
- 02:26:38 [ivan]
- ivan has joined #json-ld
- 02:27:40 [azaroth]
- TOPIC: Direction ... part 4
- 02:29:26 [ivan]
- q+
- 02:29:37 [gkellogg]
- azaroth: We agreed in the AM that we want a processor option, which defaults to drop the direction.
- 02:30:38 [azaroth]
- ack ivan
- 02:31:01 [ivan]
- -> https://w3c.github.io/rdf-dir-literal/#datatype-family a viable option, too
- 02:31:28 [gkellogg]
- ivan: The datatype version (familiy of language datatypes) is one of the options I enumerated.
- 02:32:22 [gkellogg]
- 2.1.2.1.2 createa an ugly but valid datatype to describe language and direction #XX_YY.
- 02:32:58 [bigbluehat]
- q+
- 02:32:59 [gkellogg]
- s/2.1.2.1.2/… 2.1.2.1.2/
- 02:33:00 [pchampin]
- q+
- 02:33:31 [gkellogg]
- ivan: This wouldn’t be used in JSON-LD, but in the resulting quad.
- 02:33:56 [azaroth]
- q+
- 02:33:59 [gkellogg]
- … I know think this should be one option, and the other comound document
- 02:34:15 [bigbluehat]
- ack bigbluehat
- 02:35:07 [gkellogg]
- bigbluehat: This is adding switching in from/to RDF algorithms. 1.0 did not actually have API entrypoints for this.
- 02:35:54 [gkellogg]
- … We could lower the bar for implementations by moving them into a separate interrace.
- 02:36:00 [gkellogg]
- q+
- 02:36:14 [bigbluehat]
- ack pchampin
- 02:36:40 [gkellogg]
- q-
- 02:37:13 [gkellogg]
- pchampin: I advocate the datatype solution over the compound node.
- 02:37:31 [gkellogg]
- … The opt-in/out options would be different, but they would still be literals.
- 02:37:45 [gkellogg]
- … In SPARQL, STR(literal) still gives you the expected results.
- 02:38:14 [gkellogg]
- … Detecting these in the to/from algorithm would be easier and fewer corner-cases.
- 02:39:02 [gkellogg]
- … On the semantics side, I think the DT solution makes it easy to define semantic interopration with existing language tags (intersecting value spaces).
- 02:39:33 [gkellogg]
- … You could make interaction with existing lang-tagged strings smoother than as considering them as two different spieces of literals.
- 02:40:26 [gkellogg]
- ivan: We’re talking about 2.1.2.1.2 in the document.
- 02:40:58 [pchampin]
- https://w3c.github.io/rdf-dir-literal/#datatype-family
- 02:41:02 [gkellogg]
- azaroth: I wanted to disuss 2.1.1.2.
- 02:41:38 [gkellogg]
- … I think we could subclass rdf:langString to create rtl/ltr versions of that sub-type.
- 02:42:25 [gkellogg]
- … Guess not, given RDF spec.
- 02:43:16 [azaroth]
- q?
- 02:43:19 [azaroth]
- ack azaroth
- 02:46:16 [pchampin]
- q+
- 02:46:42 [gkellogg]
- ack pchampin
- 02:47:35 [gkellogg]
- pchampin: I agree with gkellogg that the option in fromRdf might sound strange, but the message might not be clear. If there’s no option, we bake in the processing, and close the door for other possible options.
- 02:48:40 [bigbluehat]
- section references come from https://w3c.github.io/rdf-dir-literal/#compound-literal
- 02:49:10 [bigbluehat]
- q?
- 02:49:14 [bigbluehat]
- q+
- 02:49:21 [azaroth]
- PROPOSAL: Add a parameter option to the API function toRDF, with three possible values: null or absent (do not process, the default), datatype (reflect to a datatype per 2.1.2.1.2) and bnode (reflect to a bnode structure per 2.1.4)
- 02:49:23 [azaroth]
- +1
- 02:49:24 [bigbluehat]
- +1
- 02:49:24 [gkellogg]
- +1
- 02:49:24 [ivan]
- +1
- 02:49:32 [pchampin]
- +1
- 02:49:59 [azaroth]
- RESOLVED: Add a parameter option to the API function toRDF, with three possible values: null or absent (do not process, the default), datatype (reflect to a datatype per 2.1.2.1.2) and bnode (reflect to a bnode structure per 2.1.4)
- 02:51:24 [azaroth_]
- azaroth_ has joined #json-ld
- 02:52:30 [gkellogg]
- bigbluehat: What if you have both bnodes and datatypes in an input? Could we convert them?
- 02:54:12 [azaroth_]
- PROPOSAL: Add a value to the options parameter to the API function fromRDF, with the above three options plus "any" which will convert either datatype or bnode as discovered in the data
- 02:54:14 [azaroth_]
- +1
- 02:54:15 [ivan]
- +1
- 02:54:16 [bigbluehat]
- +1
- 02:54:16 [gkellogg]
- +1
- 02:55:22 [bigbluehat]
- q-
- 02:55:23 [bigbluehat]
- q+
- 02:55:28 [pchampin]
- q+
- 02:55:34 [bigbluehat]
- q-
- 02:55:48 [gkellogg]
- For example `preserveDirection: enum(null, dt, combo, any)
- 02:56:17 [bigbluehat]
- ack pchampin
- 02:56:36 [azaroth_]
- RESOLVED: Add a value to the options parameter to the API function fromRDF, with the above three options plus "any" which will convert via any conversion function available as discovered in the data
- 02:56:44 [azaroth_]
- s/RESOLVED/PROPOSAL/
- 02:56:53 [gkellogg]
- pchampin: I see this as an extension point, some may have more than two.
- 02:57:30 [ivan]
- +1
- 02:57:44 [bigbluehat]
- +1
- 02:57:44 [gkellogg]
- +1
- 02:57:49 [bigbluehat]
- q+
- 02:58:03 [azaroth_]
- +1
- 02:58:29 [pchampin]
- +1
- 02:58:34 [azaroth_]
- RESOLVED: Add a value to the options parameter to the API function fromRDF, with the above three options plus "any" which will convert via any conversion function available as discovered in the data
- 03:00:06 [gkellogg]
- bigbluehat: Can we partition the RDF API?
- 03:00:10 [gkellogg]
- q+
- 03:00:14 [gkellogg]
- ack
- 03:00:23 [gkellogg]
- ack bigbluehat
- 03:00:30 [ivan]
- Topic: fromRDF/toRDF status
- 03:00:48 [gkellogg]
- bigbluehat: These are different types of things which may be a barrior to implementation.
- 03:01:03 [azaroth_]
- q+
- 03:01:48 [gkellogg]
- pchampin: posts comic about HTTP range-14 being a challenging issue.
- 03:01:59 [ivan]
- q+
- 03:01:59 [azaroth_]
- ack gkellogg
- 03:03:10 [gkellogg]
- bigbluehat: We may loose because of RDF, and may gain market share because we insist on RDF
- 03:03:44 [azaroth]
- q?
- 03:04:38 [pchampin]
- q+
- 03:04:46 [gkellogg]
- bigbluehat: The context fetching is also a controversial requirement.
- 03:05:41 [azaroth]
- ack azaroth
- 03:06:24 [gkellogg]
- azaroth: I’m a -1; I understand the intent, but the audience is not those that will actually read the spec.
- 03:06:54 [gkellogg]
- bigbluehat: This revision makes more claims of RDF than 1.0 did, and people are comenting that this is a shift.
- 03:07:16 [gkellogg]
- azaroth: People said they liked to see the addition that RDF is not needed.
- 03:07:25 [azaroth]
- q?
- 03:07:29 [azaroth]
- ack ivan
- 03:08:23 [gkellogg]
- ivan: To be process oriented, we declared feature freeze and are close to CR raising an issue that is inappropriate. If we go done this line, it resets us by some amount of time, and are going against our charter.
- 03:08:50 [gkellogg]
- … direction was already an issue, so was within the feature set.
- 03:08:50 [azaroth]
- q?
- 03:09:06 [azaroth]
- ack Ralph
- 03:09:07 [gkellogg]
- … Unless this is purely editorial, I’m against it.
- 03:09:28 [bigbluehat]
- q+
- 03:09:49 [gkellogg]
- Ralph: I don’t know if it’s editorial, but if you considered that it didn’t violate it, other groups have said things like “conformling level 1, 2, etc proessors”.
- 03:10:02 [gkellogg]
- … This allows people to subset better.
- 03:10:14 [azaroth]
- ack pchampin
- 03:10:19 [gkellogg]
- … The partition excercise might be instrucive.
- 03:10:36 [azaroth]
- q+ to compare html processor levels and result
- 03:11:20 [gkellogg]
- pchampin: It reminded me of manu’s comments before the break about the spec being quite complex and frightening. gkellogg said that some implementations might not flatten or frame. Maybe what you should say you need at the core is Compaction and Expasion, and the rest could be skipped.
- 03:11:26 [azaroth]
- ack bigbluehat
- 03:11:32 [gkellogg]
- … THis might make it less frightening.
- 03:11:50 [gkellogg]
- bigbluehat: That’s the core of what I’d like to say; i’d like to reduce the core of what people need to do
- 03:11:52 [gkellogg]
- q+
- 03:12:25 [gkellogg]
- … I’d like to do something with some core stuff, no fetching, HTML parsing, etc.
- 03:13:22 [azaroth]
- ack azaroth
- 03:13:22 [Zakim]
- azaroth, you wanted to compare html processor levels and result
- 03:13:32 [gkellogg]
- ivan: It’s not normative or non-normative, they must be implemented in that way.
- 03:14:41 [gkellogg]
- azaroth: We already discussed proessor levels, we put them in, they were hated, we took them out.
- 03:15:11 [azaroth]
- q?
- 03:15:14 [gkellogg]
- … I’m in support of adding introductory prose to say that you don’t need to implement everything. If you implement something, you must do it this way.
- 03:15:15 [azaroth]
- ack gkellogg
- 03:15:23 [manu]
- q+ to provide a real world scenario where this would be helpful
- 03:16:01 [bigbluehat]
- q+
- 03:16:36 [pchampin]
- q+
- 03:16:42 [azaroth]
- q+ to close the queue :)
- 03:16:52 [bigbluehat]
- Zakim, close the queue
- 03:16:52 [Zakim]
- ok, bigbluehat, the speaker queue is closed
- 03:17:55 [azaroth]
- ack manu
- 03:17:55 [Zakim]
- manu, you wanted to provide a real world scenario where this would be helpful
- 03:18:23 [gkellogg]
- manu: We’re having a discussion with an implementer who thought they needed to implement everything.
- 03:18:56 [gkellogg]
- … IN the C++ implementation, they only need to implement expansion/toRdf (and c14n). THose two aren’t hard, but trying to do the whole spec was daunting.
- 03:19:36 [gkellogg]
- … I agree with gkellogg that it might be difficult to break out into layers.
- 03:19:58 [gkellogg]
- … The counter argument is that it would be nice to know if you have afullly conformant 1.1 processor.
- 03:20:44 [azaroth]
- ack bigbluehat
- 03:20:58 [pchampin]
- q-
- 03:21:51 [gkellogg]
- bigbluehat: This is marketing, there is a way that this can be accomplished, and encourage people to get into JSON-LD piece by piece.
- 03:22:36 [gkellogg]
- ivan: we have a conformance section.
- 03:22:44 [azaroth]
- ack azaroth
- 03:22:44 [Zakim]
- azaroth, you wanted to close the queue :)
- 03:23:31 [gkellogg]
- azaroth: There is text in the document about processor classes already (conformance). It would be months of work to do anything else.
- 03:24:20 [gkellogg]
- bigbluehat: We signal that it’s hard because you must have something that gets and retrieves stuff.
- 03:25:29 [azaroth]
- TOPIC: Break for lunch
- 03:25:55 [ivan]
- rrsagent, draft minutes
- 03:25:55 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html ivan
- 03:26:25 [azaroth]
- azaroth has joined #json-ld
- 03:49:55 [Ralph_]
- Ralph_ has joined #json-ld
- 03:50:12 [simonstey]
- simonstey has joined #json-ld
- 03:50:35 [simonstey]
- present+
- 03:57:09 [Ralph]
- Ralph has joined #json-ld
- 04:02:21 [Ralph_]
- Ralph_ has joined #json-ld
- 04:09:58 [azaroth]
- azaroth has joined #json-ld
- 04:10:04 [azaroth]
- azaroth has joined #json-ld
- 04:11:00 [ivan]
- ivan has joined #json-ld
- 04:16:23 [ivan]
- ivan has joined #json-ld
- 04:17:32 [azaroth]
- TOPIC: Issue #153, @prefix and keyword aliases
- 04:17:41 [ivan]
- present+ simonstey
- 04:17:46 [ivan]
- present+ dlehn
- 04:18:42 [azaroth]
- s/@prefix/`@prefix`/
- 04:18:56 [azaroth]
- s/#153/json-ld-api#153/
- 04:19:38 [ivan]
- -> https://github.com/w3c/json-ld-api/issues/153 API #153
- 04:24:21 [bigbluehat]
- azaroth: time to summarize for the minutes
- 04:24:26 [bigbluehat]
- ...we accept that issue 153 is an issue
- 04:24:32 [bigbluehat]
- gkellogg: a bug
- 04:24:35 [bigbluehat]
- azaroth: true. a bug
- 04:24:55 [bigbluehat]
- ...it should not in fact generate `@idfoo`
- 04:25:08 [bigbluehat]
- gkellogg: it should treat `id:foo` as an IRI
- 04:25:16 [bigbluehat]
- ...so the result of expanding should be `id:foo`
- 04:26:41 [azaroth]
- PROPOSAL: When encountering a term in the form of a compact IRI for which the prefix would expand to a keyword, do not expand the term
- 04:27:08 [bigbluehat]
- azaroth: so if there was an `@vocab` it would expand to that value + `id:foo`?
- 04:27:20 [azaroth]
- +1
- 04:27:25 [pchampin]
- +1
- 04:27:28 [bigbluehat]
- gkellogg: it won't be expanded as a relative URI because of the colon
- 04:27:28 [gkellogg]
- +1
- 04:27:29 [bigbluehat]
- +1
- 04:27:30 [simonstey]
- +1
- 04:27:38 [azaroth]
- RESOLVED: When encountering a term in the form of a compact IRI for which the prefix would expand to a keyword, do not expand the term
- 04:28:02 [bigbluehat]
- bigbluehat has changed the topic to: Meeting Agenda 2019-09-20: http://tinyurl.com/y34nfpfg
- 04:28:29 [bigbluehat]
- gkellogg: if there is an `id` term that's legit, and I see `@prefix: false`
- 04:28:55 [bigbluehat]
- ...it won't expand that because prefix is false
- 04:29:44 [azaroth]
- ACTION: gkellogg to determine if `@prefix: false` will prevent the term from being used in expanding IRIs, and file an issue if it does
- 04:30:17 [bigbluehat]
- gkellogg: there's another issue about changing SHOULD's to MUST's for things that look like keywords
- 04:30:31 [azaroth]
- TOPIC: json-ld-syntax #260 -- Can terms start with an `@`
- 04:31:34 [ivan]
- -> https://github.com/w3c/json-ld-syntax/issues/260 Issue Syntax#260
- 04:31:55 [bigbluehat]
- gkellogg: what we're most worried about is other specs using `@` and we want them to be compatible with us
- 04:36:00 [bigbluehat]
- ...but at this point hopefully everyone's aware of our use of `@`
- 04:36:14 [bigbluehat]
- manu: what does changing it to MUST NOT buy us?
- 04:37:19 [bigbluehat]
- gkellogg: it means that if we add things like `@direction` in the future, the processors would choke on the new term but they also wouldn't try to turn it into a URI
- 04:37:23 [bigbluehat]
- Zakim, open the queue
- 04:37:23 [Zakim]
- ok, bigbluehat, the speaker queue is open
- 04:37:44 [azaroth]
- ack ralph
- 04:37:57 [azaroth]
- q+ to ask about new information to reopen
- 04:38:00 [bigbluehat]
- q+
- 04:38:37 [azaroth]
- ack azaroth
- 04:38:37 [Zakim]
- azaroth, you wanted to ask about new information to reopen
- 04:38:50 [tung]
- tung has joined #json-ld
- 04:39:01 [bigbluehat]
- Ralph: so, could you just say SHOULD NOT?
- 04:39:03 [bigbluehat]
- azaroth: it does
- 04:39:11 [bigbluehat]
- Ralph: ah, so you are leaving this open for future compatibility
- 04:39:22 [bigbluehat]
- gkellogg: and I think `@direction` is an example of why we want this
- 04:39:48 [bigbluehat]
- azaroth: there was an earlier issue which we closed about this
- 04:40:00 [bigbluehat]
- ...and it was mentioned that if we found new info we might reopen it
- 04:40:05 [bigbluehat]
- ...this seems like new infromation
- 04:40:21 [bigbluehat]
- gkellogg: so, some future `@direction` type thing could be setup to just disappear
- 04:40:33 [bigbluehat]
- azaroth: or attempt to turn into a crazy relative IRI
- 04:40:36 [azaroth]
- ack bigbluehat
- 04:41:26 [bigbluehat]
- bigbluehat: so, as long as we just ignore the new values when processing--and don't choke--that should leave the door open to the future without tripping up old clients
- 04:42:02 [bigbluehat]
- gkellogg: authors should not use these keywords, but processors must ignore them
- 04:42:21 [manu]
- scribe: manu
- 04:42:24 [bigbluehat]
- ...but with a warning
- 04:44:06 [azaroth]
- PROPOSAL: Reopen w3c/json-ld-syntax#16 and require processors to ignore terms beginning with @ that are not defined keywords
- 04:44:08 [gkellogg]
- +1
- 04:44:08 [manu]
- +1
- 04:44:09 [azaroth]
- +1
- 04:44:16 [bigbluehat]
- +1
- 04:44:16 [simonstey]
- +1
- 04:44:17 [pchampin]
- +1
- 04:44:17 [ivan]
- +1
- 04:44:24 [azaroth]
- RESOLVED: Reopen w3c/json-ld-syntax#16 and require processors to ignore terms beginning with @ that are not defined keywords
- 04:44:44 [ivan]
- -> https://github.com/w3c/json-ld-syntax/issues/16 Issue syntax#16
- 04:45:27 [manu]
- azaroth: Have we made this clear, it's resolved?
- 04:45:36 [manu]
- gkellogg: Yes, the editors need to do their thing now.
- 04:46:04 [manu]
- azaroth: so we'll close #260 in favor of opening #16.
- 04:46:53 [azaroth]
- TOPIC: w3c/json-ld-syntax#259 - @vocab and keywords
- 04:48:25 [manu]
- azaroth: propose that we can close #259, is this errata to JSON-LD 1.0?
- 04:48:35 [manu]
- gkellogg: it's not
- 04:48:55 [manu]
- azaroth: Ok, this will remain a bug with 1.0 processors, they should update and do the 1.1 process for this particular feature.
- 04:49:45 [azaroth]
- PROPOSAL: Close w3c/json-ld-syntax#259 as we can't fix 1.0, and 1.1 will be solved by newly reopened #16
- 04:49:47 [azaroth]
- +1
- 04:49:49 [ivan]
- +1
- 04:49:50 [manu]
- +1
- 04:49:56 [pchampin]
- +1
- 04:50:01 [simonstey]
- +1
- 04:50:05 [gkellogg]
- +1
- 04:50:09 [bigbluehat]
- +1
- 04:50:16 [azaroth]
- RESOLVED: Close w3c/json-ld-syntax#259 as we can't fix 1.0, and 1.1 will be solved by newly reopened #16
- 04:50:58 [azaroth]
- TOPIC: w3c/json-ld-syntax#257 typed values
- 04:51:00 [manu]
- azaroth: Moving on to #257...
- 04:51:27 [ivan]
- -> https://github.com/w3c/json-ld-syntax/issues/257 issue syntax#257
- 04:51:36 [manu]
- bigbluehat: It's probably reducible to an editorial thing in a best practices document.
- 04:53:07 [manu]
- bigbluehat: People are going to get confused when they do type coercion and they're getting booleans that are typed as xsd:datetime... I'd love to see, when we recharter to fix bugs, I don't expect this is a JSON-LD proper problem... I'd like an extra spec that goes and checks these things.
- 04:53:13 [manu]
- gkellogg: If you run it through a linter...
- 04:53:39 [manu]
- bigbluehat: This is an acceptable way to do it via our specs, it looks wrong, but validation is not JSON-LD's problem, but we didn't take that on.
- 04:53:40 [azaroth]
- q?
- 04:53:51 [manu]
- ivan: RDF doesn't do those things either, you can have values w/ datatypes, which is wrong.
- 04:53:57 [manu]
- bigbluehat: so, you can say it's best practices stuff
- 04:54:05 [azaroth]
- q+
- 04:54:23 [pchampin]
- q+
- 04:54:27 [manu]
- bigbluehat: The CG could address this, these are the kinds of things that we need to address w/ the community
- 04:54:46 [manu]
- gkellogg: A different example, instead of a string it's an xsd:datetime, that's valid -
- 04:55:29 [manu]
- bigbluehat: When people have an expectation of JSON-LD, and it's one thing, and it turns out to not be that one thing... we need to build bridges towards validation.
- 04:55:46 [azaroth]
- ack azaroth
- 04:56:45 [manu]
- azaroth: If you push this through to RDF, you'll get the right thing back out.
- 04:57:00 [manu]
- gkellogg: well, if it's xsd:string, you will get that, but if it's "boolean" you will.
- 04:57:50 [azaroth]
- ack pchampin
- 04:57:54 [manu]
- gkellogg: another thing that could happen, is when you expand, ignored if it's an array or object... it could be ignored for numbers... you don't know, could be decimal/double.
- 04:58:39 [manu]
- pchampin: JSON-LD has support for more datatypes than RDF... it's better, the fact that it doesn't support other datatypes can be argued by the fact that it's open... xsd:datatypes...
- 04:59:15 [manu]
- azaroth: We should transfer this issue to best practices...
- 05:00:13 [manu]
- bigbluehat: my confusion is about expanded form vs. compact
- 05:00:27 [manu]
- bigbluehat: if name had ex: in front of it, it wouldn't show up...
- 05:00:30 [azaroth]
- PROPOSAL: Transfer w3c/json-ld-syntax#257 to best practices document
- 05:00:31 [manu]
- gkellogg: no, it would show up, it's an IRI
- 05:00:32 [azaroth]
- +1
- 05:00:44 [gkellogg]
- +1
- 05:01:02 [bigbluehat]
- +1
- 05:01:04 [simonstey]
- +1
- 05:01:04 [manu]
- manu: +1
- 05:01:20 [pchampin]
- +1
- 05:01:21 [ivan]
- +1
- 05:01:23 [azaroth]
- RESOLVED: Transfer w3c/json-ld-syntax#257 to best practices document
- 05:01:40 [manu]
- bigbluehat: if if if if if
- 05:02:30 [bigbluehat]
- {"name": true}
- 05:02:42 [manu]
- bigbluehat: That doesn't survive
- 05:02:57 [manu]
- gkellogg: The later one isn't absolute IRI... the previous is
- 05:03:21 [azaroth]
- q?
- 05:03:48 [manu]
- gkellogg: This might be why manu keeps saying compact IRIs were a mistake
- 05:04:08 [manu]
- bigbluehat: It means you have a bit of a rosetta stone w/ @context.
- 05:04:23 [manu]
- azaroth: That's all of the open issues, except for the loads of editorial issues.
- 05:04:54 [manu]
- azaroth: The framing stuff has no more issues either.
- 05:07:42 [bigbluehat]
- Topic: w3c/json-ld-syntax#108
- 05:08:00 [bigbluehat]
- manu: this is an awareness opportunity
- 05:08:17 [bigbluehat]
- azaroth: so from our side, we've pointed to DocumentLoader as the thing that makes the loading stuff work
- 05:08:29 [bigbluehat]
- ...whatever the format, type, etc of the IRI
- 05:09:03 [bigbluehat]
- ...this is deferred to a future version because we don't know if more data will be needed at the JSON-LD document level to express this
- 05:09:05 [manu]
- azaroth: What we said is that document loaders should do whatever they can ... hashlink or ipfs or something else that enables content integrity. We added @import for future version, if there is interest in putting data into instance graphs/contexts... this particular thing needs a particular SRI value or other, we have a slot that we can provide stuff in @import so you can add something.
- 05:09:39 [manu]
- azaroth: The use cases fulfilled by document loader process, if there is need to support this in the future, we want to have support and have support.
- 05:09:40 [bigbluehat]
- q?
- 05:09:55 [bigbluehat]
- manu: the thing I don't know is anyone circling a solution?
- 05:10:08 [bigbluehat]
- ...we're strongly pushing the hashlink spec as an option for DID and VCWG stuff
- 05:10:20 [bigbluehat]
- ...for VC's bad things happen if your context changes
- 05:10:28 [bigbluehat]
- ...and in our specs, we make the promise that this context will never change
- 05:10:37 [bigbluehat]
- ...so you download it and put it into your code
- 05:10:42 [bigbluehat]
- ...but that doesn't address extensions
- 05:10:47 [bigbluehat]
- ...which need something like hashlink
- 05:10:47 [bigbluehat]
- q+
- 05:11:24 [bigbluehat]
- manu: all you can do with SRI is to find out you got something you didn't want
- 05:11:41 [bigbluehat]
- ...and it requires infrastructure to be setup, etc.
- 05:11:45 [bigbluehat]
- ...there are two parts of this
- 05:11:58 [bigbluehat]
- ...in the future we'd like to settle on hashlink as the primary way--in our communities
- 05:12:25 [ivan]
- guests+ danbri
- 05:12:26 [azaroth]
- ack bigbluehat
- 05:13:37 [danbri]
- danbri has joined #json-ld
- 05:13:56 [chaals]
- chaals has joined #json-ld
- 05:18:25 [azaroth_]
- azaroth_ has joined #json-ld
- 05:20:10 [chaals]
- chaals has joined #json-ld
- 05:20:11 [bigbluehat]
- manu: [demoing hashlink]
- 05:24:02 [pchampin]
- q+
- 05:27:17 [azaroth_]
- ack pchampin
- 05:27:21 [gkellogg]
- q+
- 05:28:29 [azaroth_]
- ack gkellogg
- 05:29:15 [azaroth_]
- q+ re rfc7089
- 05:29:36 [azaroth]
- ack azaroth
- 05:29:36 [Zakim]
- azaroth_, you wanted to discuss rfc7089
- 05:30:04 [danbri]
- manu, is there a github repo for the conversation you mentioned with J Yasskin?
- 05:31:14 [chaals]
- chaals has joined #json-ld
- 05:31:53 [bigbluehat]
- q+
- 05:32:14 [azaroth]
- ack bigbluehat
- 05:33:02 [azaroth]
- TOPIC: CR status and timeline
- 05:35:22 [azaroth]
- TOPIC: Attribution
- 05:35:39 [chaals]
- chaals has joined #json-ld
- 05:35:45 [gkellogg]
- q+
- 05:35:48 [azaroth]
- ack gkellogg
- 05:42:59 [bigbluehat]
- group: [discussing how best to give credit where due in the specs]
- 05:43:49 [bigbluehat]
- gkellogg: I think we should add dlongley
- 05:43:59 [bigbluehat]
- ...to all the 1.1 specs
- 05:44:06 [gkellogg]
- https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords
- 05:44:21 [bigbluehat]
- ...we should add him in position 3 on Syntax after pchampin
- 05:44:27 [bigbluehat]
- ...to both v1.0 and v1.1
- 05:44:55 [bigbluehat]
- ...in both versions of the API spec, we'd add dlongley in position 2
- 05:45:09 [bigbluehat]
- ...and in Framing, dlongley would be in position 1
- 05:45:24 [bigbluehat]
- ...and he'd be removed as a "former editor" section
- 05:45:56 [bigbluehat]
- ...and we should look back through commit amounts to consider afresh our list of additional editors
- 05:46:13 [azaroth]
- q?
- 05:46:51 [bigbluehat]
- ...and maybe we should add pchampin to the API spec
- 05:47:29 [bigbluehat]
- pchampin: yeah, I did add the folding, but I'd be happy to complete it since we recently decided to do it
- 05:47:39 [bigbluehat]
- ...and the ordering on API sounds fine
- 05:48:15 [chaals]
- chaals has joined #json-ld
- 05:48:25 [bigbluehat]
- gkellogg: and we should remove editors from acknowledgements and remix that as needed
- 05:49:44 [manu]
- q+ for CBOR-LD
- 05:50:00 [bigbluehat]
- ack manu
- 05:50:00 [Zakim]
- manu, you wanted to discuss CBOR-LD
- 05:50:07 [bigbluehat]
- bigbluehat: we could also move some of this note work into the CG
- 05:50:13 [bigbluehat]
- ...just so we don't over promise or underdeliver
- 05:50:20 [bigbluehat]
- manu: we do have folks interested in CBOR-LD
- 05:50:32 [bigbluehat]
- ...and we've been digging into how to minimize it/simplify the storage
- 05:50:38 [bigbluehat]
- ...and we've gotten URIs into single byte storage
- 05:50:45 [bigbluehat]
- ...it's fantastically efficient when you do that
- 05:50:56 [bigbluehat]
- ...so you can get the document way smaller than even with gzip, etc.
- 05:51:10 [bigbluehat]
- danbri: so, we could do this with schema.org's context file?
- 05:51:14 [bigbluehat]
- manu: yeah, it would work great for that
- 05:51:29 [bigbluehat]
- ...the other amazing thing with CBOR-LD, if you do data normalization
- 05:51:48 [bigbluehat]
- ...you can do a binary comparison
- 05:51:51 [bigbluehat]
- ...via templates
- 05:51:52 [danbri]
- on schema.org size, "The core vocabulary currently consists of 614 Types, 905 Properties, and 114 Enumeration values." --https://schema.org/docs/schemas.html (plus a few more in https://pending.schema.org )
- 05:52:14 [bigbluehat]
- gkellogg: as long as you avoid blank nodes?
- 05:52:36 [bigbluehat]
- manu: ...yes...and if you do this well, it's way more compact than any linked data representation currently in use
- 05:52:42 [bigbluehat]
- ...and it doesn't need to be base64'd
- 05:52:49 [bigbluehat]
- ...and you don't need JSON Schema on it
- 05:52:53 [bigbluehat]
- ...and you can sign it
- 05:52:59 [bigbluehat]
- ...there's some really interesting stuff there
- 05:53:11 [bigbluehat]
- ...people processing an enormous amount of data can benefit
- 05:53:20 [bigbluehat]
- q?
- 05:53:26 [bigbluehat]
- ...and super tiny stuff benefits as well
- 05:53:56 [bigbluehat]
- pchampin: I did contact a few people in the WoT WG
- 05:54:09 [bigbluehat]
- ...and they sent me to someone else in the JSON-LD WG who's also in the WoT WG
- 05:54:15 [bigbluehat]
- ...and he's OK to contribute to a Note
- 05:54:24 [azaroth]
- Viktor Charpenay
- 05:54:29 [bigbluehat]
- ...some of this work he's shown in the W3C is very similar to what manu mentioned
- 05:54:36 [pchampin]
- s/Viktor/Victor/
- 05:54:38 [bigbluehat]
- ...much of it around compact IRI's in CBOR
- 05:54:50 [bigbluehat]
- ...so I have a call setup with him next monday
- 05:54:55 [manu]
- scribe: manu
- 05:55:47 [manu]
- azaroth: Are we done w/ agenda setting? CR status timeline.... when do we finish the work, what do we do after, what happens in june if we do rechartering
- 05:55:55 [pchampin]
- s/in the WoT WG/in a WoT project that we are starting/
- 05:56:14 [manu]
- bigbluehat: is there anything you want to discuss, danbri?
- 05:56:49 [manu]
- danbri: It would be nice if JSON-LD has a document format ... we wanted lots of documents and the format... not to implement a processor.
- 05:57:06 [manu]
- bigbluehat: Are there any explicit asks for us to build that bridge?
- 05:57:37 [gkellogg]
- q+
- 05:58:11 [bigbluehat]
- manu: so, the VC WG and DID WG's have basically said, you don't need to do JSON-LD processing
- 05:58:22 [bigbluehat]
- ...all you need to do is JSON processing focused on a few keys/things mentioned in the spec
- 05:58:47 [bigbluehat]
- danbri: can you say that some but not all profiles
- 05:58:52 [azaroth]
- ack gkellogg
- 05:59:02 [bigbluehat]
- ...and there's some history with the CSV WG
- 05:59:16 [bigbluehat]
- gkellogg: there is a range of groups attempting to solve for this though
- 05:59:46 [bigbluehat]
- ...you can require the context URL...or a specific context file
- 06:00:02 [bigbluehat]
- ...schema.org's a bit more elaborate than most of these though
- 06:00:08 [bigbluehat]
- ...but the solution's the same or similar
- 06:00:17 [bigbluehat]
- ...you state the place in the `@context` space where it must go
- 06:00:29 [bigbluehat]
- danbri: we want to be full fruited JSON-LD or whatever
- 06:00:36 [bigbluehat]
- ...and we've done this a bit with Wiki Data for instance
- 06:00:46 [bigbluehat]
- ...so you start with a schema:Person...and then describe more
- 06:00:58 [bigbluehat]
- ...the point being that any use of the JSON-LD context implies...
- 06:01:06 [bigbluehat]
- gkellogg: you just require the `@context` include schema.org
- 06:01:25 [bigbluehat]
- ...but if you don't actually use the context, then you miss out on the extensibility points
- 06:01:28 [bigbluehat]
- q+ danbri
- 06:01:37 [bigbluehat]
- ...but you still wouldn't depend on processing the context
- 06:01:51 [manu]
- q+ to note that I think this will work really well for schema.org
- 06:01:55 [bigbluehat]
- ...I'm agreeing with manu that what schema.org wants to do is very much like all the other groups wants to do
- 06:02:08 [manu]
- q+ to say that we didn't have RDF-heavy folks in the VC or DID WGs.
- 06:02:14 [bigbluehat]
- ...and what we really need is some best practices for JSON-LD in "pure" JSON processing contexts
- 06:02:29 [azaroth]
- ack danbri
- 06:02:33 [bigbluehat]
- danbri: it's tricky because we want to be able to be mixed with other vocabs
- 06:02:39 [bigbluehat]
- manu: yeah, you get that with this approach
- 06:02:46 [azaroth]
- ack manu
- 06:02:46 [Zakim]
- manu, you wanted to note that I think this will work really well for schema.org and to say that we didn't have RDF-heavy folks in the VC or DID WGs.
- 06:02:55 [bigbluehat]
- ...you just have to be sure the schema.org is in there somewhere
- 06:02:57 [azaroth]
- zakim, close the queue
- 06:02:57 [Zakim]
- ok, azaroth, the speaker queue is closed
- 06:03:28 [bigbluehat]
- ivan: loads of groups are doing this
- 06:03:39 [bigbluehat]
- ...and in publishing's case we're using schema.org explicitly
- 06:03:57 [bigbluehat]
- ...and we also describe if the only thing you want to do is push it into schema.org, then we make sure you know where that edge is
- 06:04:09 [bigbluehat]
- ...if you want to do more complex stuff, then you might make it harder to process
- 06:04:14 [bigbluehat]
- ...but the basics usually get picked up
- 06:04:19 [bigbluehat]
- q+
- 06:04:30 [azaroth]
- the IIIF docs: https://iiif.io/api/presentation/3.0/#46-linked-data-context-and-extensions
- 06:04:30 [bigbluehat]
- ...we call it a fixed shape
- 06:04:35 [bigbluehat]
- ...tnx to bigbluehat
- 06:04:50 [bigbluehat]
- ...but you are right that it is not documented
- 06:04:54 [bigbluehat]
- ...and it's on us to do that
- 06:04:59 [bigbluehat]
- danbri: that would be very helpful
- 06:05:23 [bigbluehat]
- manu: I'm wondering if it's a different conformance class
- 06:05:25 [bigbluehat]
- danbri: that would be nice
- 06:05:41 [bigbluehat]
- gkellogg: or at least a way to describe that there is additional restrictions
- 06:06:20 [bigbluehat]
- ivan: what happens if you want a specific shape of JSON
- 06:06:25 [bigbluehat]
- ...that can be used for JSON-LD
- 06:06:27 [bigbluehat]
- ...for the LD fans
- 06:06:36 [pchampin]
- we already have a little of that in the `@protected` section
- 06:06:36 [danbri]
- q+
- 06:07:00 [pchampin]
- but this could do with more details
- 06:07:44 [bigbluehat]
- danbri: many of these won't ever got get contexts from anywhere
- 06:07:54 [bigbluehat]
- manu: this approach allows exactly that
- 06:08:02 [ivan]
- rrsagent, draft minutes
- 06:08:02 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html ivan
- 06:08:09 [azaroth]
- azaroth has joined #json-ld
- 06:08:25 [bigbluehat]
- gkellogg: so one thing I might suggest is that now that we've added this HTML => JSON-LD linkage via rel="alternate" in the HTTP header
- 06:08:34 [bigbluehat]
- ...then you could call that requirement out lots of places
- 06:08:47 [bigbluehat]
- danbri: so it would just be a free form chunk of text explaining it
- 06:08:58 [bigbluehat]
- gkellogg: so best practices might spell out how you could do all that
- 06:09:11 [bigbluehat]
- ...this application requires a specific shape
- 06:09:26 [bigbluehat]
- ...so no further contexts would be processed
- 06:09:38 [danbri]
- possibly nearby: https://www.w3.org/2017/dxwg/wiki/Main_Page#Profiles
- 06:09:43 [bigbluehat]
- ...but you'd still get the date from the one you want-- and require it matches the shape
- 06:26:56 [azaroth]
- azaroth has joined #json-ld
- 06:36:15 [azaroth]
- azaroth has joined #json-ld
- 06:41:56 [tung]
- tung has joined #json-ld
- 06:48:54 [ivan]
- ivan has joined #json-ld
- 06:52:24 [tung]
- tung has joined #json-ld
- 06:52:31 [azaroth]
- TOPIC: CR
- 07:00:06 [azaroth_]
- azaroth_ has joined #json-ld
- 07:00:45 [azaroth]
- CR prereqs
- 07:00:58 [azaroth]
- Privacy and I18n are good
- 07:01:12 [azaroth]
- Not heard from a11y or security at all, but have pinged several times
- 07:01:17 [tung_]
- tung_ has joined #json-ld
- 07:01:25 [azaroth]
- question about IANA registration of profiles as to when they are required
- 07:01:31 [azaroth]
- have asked PLH about Process details
- 07:01:38 [azaroth]
- No formal objections
- 07:01:45 [bigbluehat]
- a11y review request URL https://lists.w3.org/Archives/Public/public-apa/2019Sep/0025.html
- 07:02:26 [gkellogg_]
- gkellogg_ has joined #json-ld
- 07:02:41 [azaroth]
- features at risk
- 07:02:56 [azaroth]
- defined one today
- 07:03:02 [azaroth]
- currently?
- 07:03:34 [azaroth]
- tried to use it incorrectly
- 07:03:38 [azaroth]
- gkellogg: Framing has one
- 07:03:47 [azaroth]
- ivan: will need a list
- 07:03:55 [azaroth]
- ... patent disclosures - no problem
- 07:04:15 [azaroth]
- gkellogg: json canonicalization scheme -- should keep it
- 07:04:23 [azaroth]
- ivan: implementation information
- 07:04:35 [azaroth]
- ... document exactly what our exit criteria are
- 07:04:44 [azaroth]
- ... what do we expect and how to document it
- 07:04:59 [azaroth]
- ... do we have that?
- 07:05:01 [azaroth]
- azaroth: no
- 07:05:05 [azaroth]
- ivan: a good time to define that
- 07:05:15 [azaroth]
- ... clearly described, in a separate document
- 07:05:21 [azaroth]
- ... should discuss it
- 07:05:32 [azaroth]
- ... have example for evaluation form etc. from gregg
- 07:05:49 [azaroth]
- ... dates are up to us
- 07:06:00 [azaroth]
- azaroth: baseline
- 07:07:01 [manu]
- scribe: manu
- 07:07:28 [manu]
- ivan: What was official exit criteria for VCWG?
- 07:07:40 [azaroth]
- azaroth: is there any advantage to having a higher barrier to exit CR than the minimum
- 07:08:06 [manu]
- manu: two independent implementations of each feature, where each feature is defined by a unit test.
- 07:08:10 [manu]
- ivan: What do we test?
- 07:08:26 [manu]
- gkellogg: Every feature, essentially.
- 07:08:38 [manu]
- gkellogg: Many tests will test the same feature
- 07:08:56 [manu]
- gkellogg: for example, testing framing also tests expansion.
- 07:09:08 [manu]
- ivan: The reason I'm saying this is because I can't put this together myself... I need all this text.
- 07:09:10 [pchampin]
- q+
- 07:09:16 [azaroth]
- zakim, open the queue
- 07:09:16 [Zakim]
- ok, azaroth, the speaker queue is open
- 07:09:20 [azaroth]
- q+ pchampin
- 07:09:21 [manu]
- ivan: We will have a proper description on 1.0 vs 1.1 in the testing.
- 07:09:27 [manu]
- gkellogg: We mark every 1.1 test as 1.1
- 07:09:44 [manu]
- ivan: I need a clear description of all of this.
- 07:09:46 [azaroth]
- ack pchampin
- 07:09:48 [manu]
- gkellogg: My report to you will have that in there.
- 07:10:31 [manu]
- pchampin: I don't remember how we find the conformance criteria for RDF 1.1, but in the meantime a CG has maintained that test suite... my question is - what if the test suite continues evolving and new tests fails for implementations that did conform at some time?
- 07:11:07 [manu]
- gkellogg: once we've created a recommendation, something may fail that doesn't take the relevant spec out of rec... that's history.
- 07:11:33 [manu]
- gkellogg: if the intent of adding those tests after the fact is to support the community in curating the spec and their own implementations... if there are issues that they reveal, it's an errata.
- 07:11:49 [manu]
- gkellogg: Eratta can be marked inline now... well, soon... 2020 process update.
- 07:12:03 [manu]
- gkellogg: By the time we need to add errata, it'll be ready
- 07:12:30 [manu]
- ivan: No advantage in terms of process, but obviously if we go beyond what's minimally required... can we say that we need 3 implementations for each feature?
- 07:12:45 [manu]
- ivan: Or, we'll need 2 impls for each feature and at least 1 complete implementation.
- 07:12:52 [manu]
- gkellogg: Why do we want to impose those requirements?
- 07:13:11 [manu]
- ivan: because we are HARDCORE!!!! *throws chair across room*
- 07:13:23 [pchampin]
- that would send the wrong signal, wrt what we discussed this morning: it is ok to be only partially compliant
- 07:13:43 [manu]
- gkellogg: We know we can meet that bar, by why set it higher than necessary?
- 07:14:06 [manu]
- ivan: If we say, look - this has been implemented by 3-4 independent implementations...
- 07:14:11 [manu]
- gkellogg: I'm not sure we want to say that..
- 07:14:25 [manu]
- ivan: If we say that to the outside world... 15 implementations, all complete.. it makes the case way stronger.
- 07:15:00 [manu]
- ivan: Only two... that's the other end of the spectrum.
- 07:15:36 [manu]
- gkellogg: If we can get the Go, Java, and C++ folks... maybe Rust...
- 07:16:08 [manu]
- ivan: pchampin might do that
- 07:16:13 [manu]
- pchampin: uuuummmmmmmm...
- 07:16:31 [manu]
- ivan: Internally, we do try to get the bar higher, don't want to state that officially....
- 07:16:44 [manu]
- ivan: When we get two, we can say we are done... we go to PR, we're done...
- 07:17:10 [manu]
- ivan: On the other hand, we can say -- we know we'll pass, we'll leave CR open, work on CBOR conversion (or whatever) and go to Director when we have 4-5
- 07:17:21 [manu]
- gkellogg: If we can see progress in more implementations, we should wait for them to appear.
- 07:18:09 [manu]
- gkellogg: Yes, I'm doing Ruby, Python, and Javascript... we have to have Java, and we really should have C... and hopefully Go.
- 07:18:17 [azaroth]
- q?
- 07:19:19 [manu]
- ivan: For wide review, do we have a list or feeling wrt. comments that came from outside of the group?
- 07:19:31 [manu]
- gkellogg: We can get that from issue list... have issues come in via email?
- 07:19:50 [manu]
- azaroth: Where would email have come into? I guess public, maybe we can check there.
- 07:22:52 [manu]
- ivan: Dependencies?
- 07:23:02 [manu]
- gkellogg: VCWG and schema.org
- 07:23:19 [manu]
- azaroth: We haven't interacted w/ schema.org, but have talked w/ danbri repeatedly...
- 07:23:29 [manu]
- gkellogg: We said we'd coordinate, we should reach out for comments.
- 07:24:07 [manu]
- ivan: We should send a note considering that we're feature freeze...
- 07:24:17 [azaroth]
- ACTION: azaroth to send email to schema.org CG when final WD pre CR is available for review
- 07:25:23 [manu]
- gkellogg: What about VCWG
- 07:25:32 [manu]
- manu: Charter ends at the end of this month, REC in early Oct.
- 07:25:46 [manu]
- manu: Might want to reach out to DID WG as well
- 07:26:06 [manu]
- ivan: Yes, can do that, reach out to those that exist...
- 07:26:21 [azaroth]
- Also to reference TAG issues
- 07:28:22 [manu]
- ivan: When do we need to send these communications out?
- 07:28:32 [manu]
- gkellogg: several weeks, editorial work should be done by then.
- 07:28:45 [manu]
- ivan: Would help to have all material together 2nd half of October.
- 07:29:01 [azaroth]
- ACTION: azaroth to instead send email to schema earlier
- 07:29:21 [azaroth]
- ACTION: ivan to set up empty wiki page with template for transition request to collect information
- 07:29:28 [manu]
- ivan: Maybe what I could do, if you put an action on me, is a semi empty page on github wiki with headline that can fill in what I know and what is easy to do, as things come in, you put it there, we can send TR by refering to the wiki page.
- 07:29:51 [manu]
- ivan: I will do that some time week.
- 07:30:27 [manu]
- ivan: I think we're...
- 07:30:37 [manu]
- bigbluehat: say it... SAAAAY IT....
- 07:30:40 [manu]
- ivan: done.
- 07:30:55 [manu]
- gkellogg: we need some feature detection stuff... testing for that.
- 07:31:16 [manu]
- azaroth: we should wait to exit CR, then PR, then process train takes it down the track.
- 07:32:35 [manu]
- ivan: When we get from CR to PR, we need to repeat many of these things... update them, we'll have to prove that implementations are done... from that point on, we have to be careful once the document goes to PR, then the only change to document between PR to REC are spelling mistakes.
- 07:33:10 [manu]
- ivan: for those that may not be old timers... from the moment the CR is pubished on... there can be no technical changes on the document.
- 07:34:19 [manu]
- azaroth: if we have a REC in march, we don't want to close the group because we still have other things we want to work on.
- 07:34:38 [manu]
- ivan: No harm in leaving document in CR... maybe something will come up.
- 07:36:20 [manu]
- Topic: Other Work
- 07:36:32 [manu]
- ivan: What about the Primer, CBOR, YAML, Best Practice?
- 07:36:39 [manu]
- azaroth: What are the priorities?
- 07:36:47 [manu]
- gkellogg: Best Practices, we have to have that.
- 07:36:55 [manu]
- gkellogg: Primer is... we should have that.
- 07:36:59 [manu]
- gkellogg: The others are nice to haves.
- 07:37:09 [manu]
- gkellogg: There is a non-overlapping set of people working on those things...
- 07:37:16 [manu]
- ivan: Who may publish it as a CG document.
- 07:37:38 [manu]
- bigbluehat: Can we transition them into a CG?
- 07:37:55 [manu]
- bigbluehat: if we don't publish in time?
- 07:38:15 [manu]
- ivan: If the CG picks up a document that's a NOTE, and puts it outside, no problem.
- 07:38:27 [manu]
- gkellogg: What if we do a maintenance WG?
- 07:38:40 [manu]
- ivan: We maintain the WG, we may copy certain notes... it's all possible.
- 07:39:05 [manu]
- ivan: We want to concentrate on best practices...
- 07:39:32 [manu]
- azaroth: Adam signed up to work on the Best Practices / Primer ...
- 07:39:46 [manu]
- bigbluehat: I signed up for it, but neither Adam nor I have been able to do anything on it.
- 07:40:16 [manu]
- bigbluehat: Depends on if Adam and myself should push this forward, or leave it in CG and push it up...
- 07:40:29 [manu]
- gkellogg: Have the WG publish it, at the same time.
- 07:40:44 [manu]
- bigbluehat: The plan has, and still is, bring over everything in Best Practices document.
- 07:42:16 [manu]
- azaroth: So, we'll try to move Best Practices forward to a NOTE.
- 07:42:36 [manu]
- azaroth: We'll do this when we're in CR.
- 07:43:06 [manu]
- bigbluehat: There were conversations about combining JSON Schema and JSON-LD? Are we going to say something in Best Practices?
- 07:43:25 [manu]
- gkellogg: If we're going to talk about Profiles, then that's where it's appropriate.
- 07:45:30 [manu]
- azaroth: Who is the intended audience for the Best Practices document?
- 07:45:35 [manu]
- gkellogg: Publishers...
- 07:46:01 [manu]
- azaroth: So it should be Publishing Best Practices...
- 07:46:46 [manu]
- bigbluehat: Let's do one document, different sections for Publishers, and Developers.
- 07:47:21 [manu]
- bigbluehat: Should rename to JSON-LD Best Practices
- 07:47:25 [manu]
- rrsagent, draft minutes
- 07:47:25 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html manu
- 07:47:51 [manu]
- bigbluehat: We should have sections for authoring, consuming, publishing...
- 07:49:11 [manu]
- azaroth: Given our velocity, if we were to get through best practices... I expect it will be impossible for us to get to CBOR and YAML.
- 07:49:39 [manu]
- gkellogg: pchampin said he might have someone focused on CBOR...
- 07:49:54 [manu]
- ivan: We'd still have to go through the whole TR process....
- 07:50:00 [manu]
- ivan: CBOR is interesting...
- 07:50:24 [manu]
- bigbluehat: If any of manu's claims are tenable... we might want to recharter to do that.
- 07:50:42 [manu]
- manu denies being a trustworthy source for rechartering criteria.
- 07:51:11 [manu]
- ivan: What we would have to do as a REC, it's not 2 years work...
- 07:51:24 [manu]
- bigbluehat: for the NOTE, it's important that we have a note that we say that are opportunities...
- 07:51:38 [manu]
- bigbluehat: when we come to charter the JSON-LD thing, we can point to the NOTE.
- 07:52:07 [manu]
- ivan: We just discussed this w/ fantasai, depends on what she and Ralph and the others think about that.
- 07:53:19 [manu]
- ivan: Let's be optimistic, by the time we get to rechartering, Process 2020 may be in place...
- 07:53:46 [manu]
- gkellogg: We're not limited to the REC we issue, we could decide to ... as extension/maintenance... that and other closely related tech would remain in scope.
- 07:54:07 [manu]
- azaroth: I'm not convinced that NOTE is more powerful than CG document.
- 07:54:23 [manu]
- bigbluehat: if BP should be a note, CBOR thing should be a note.
- 07:54:29 [manu]
- bigbluehat: It's a signalling opportunity
- 07:54:45 [manu]
- bigbluehat: I'm saying, don't let it drift down to a CG... keep it in the WG>
- 07:55:00 [manu]
- ivan: We're all wildly in agreement, if possible, the CBOR stuff should happen.
- 07:55:20 [manu]
- ivan: When should we think about rechartering?
- 07:55:24 [manu]
- gkellogg: Other than the CBOR stuff?
- 07:55:35 [manu]
- gkellogg: Oh, you mean beside the rechartering for maintenance...
- 07:55:42 [manu]
- bigbluehat: We should do before end of year
- 07:56:20 [jc]
- jc has joined #json-ld
- 07:56:23 [manu]
- ivan: In this case, a bit different, we need 6 weeks for voting period, if we started in Feb... had 3 months, we would have to have some preliminary discussion, put it into voting bin...
- 07:56:30 [manu]
- azaroth: Into AC by ...
- 07:56:33 [manu]
- ivan: mid-April
- 07:56:51 [manu]
- ivan: On other hand, if there is a charter renewal going on... if we run out of Charter, W3M will extend.
- 07:57:15 [ivan]
- rrsagent, draft minutes
- 07:57:15 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/19-json-ld-minutes.html ivan
- 07:57:15 [ivan]
- zakim, bye
- 07:57:15 [ivan]
- rrsagent, bye
- 07:57:15 [RRSAgent]
- I see 4 open action items saved in https://www.w3.org/2019/09/20-json-ld-actions.rdf :
- 07:57:15 [RRSAgent]
- ACTION: gkellogg to determine if `@prefix: false` will prevent the term from being used in expanding IRIs, and file an issue if it does [1]
- 07:57:15 [RRSAgent]
- recorded in https://www.w3.org/2019/09/19-json-ld-irc#T04-29-44
- 07:57:15 [RRSAgent]
- ACTION: azaroth to send email to schema.org CG when final WD pre CR is available for review [2]
- 07:57:15 [RRSAgent]
- recorded in https://www.w3.org/2019/09/19-json-ld-irc#T07-24-17
- 07:57:15 [RRSAgent]
- ACTION: azaroth to instead send email to schema earlier [3]
- 07:57:15 [RRSAgent]
- recorded in https://www.w3.org/2019/09/19-json-ld-irc#T07-29-01
- 07:57:15 [RRSAgent]
- ACTION: ivan to set up empty wiki page with template for transition request to collect information [4]
- 07:57:15 [RRSAgent]
- recorded in https://www.w3.org/2019/09/19-json-ld-irc#T07-29-21
- 07:57:15 [Zakim]
- leaving. As of this point the attendees have been gkellogg, ivan, azaroth, dlehn, pchampin, bigbluehat, manu, simonstey
- 07:57:15 [Zakim]
- Zakim has left #json-ld