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