<gkellogg> ttps://mit.webex.com/mit/j.php?MTID=m792442d12074490aa495ecaa0df1ff3a

<gkellogg> https://mit.webex.com/mit/j.php?MTID=m792442d12074490aa495ecaa0df1ff3a

<azaroth> We hear you :)

<gkellogg> scribe+ gkellogg

Introductions

<gkellogg> azaroth: I’m Rob, co-chair. Architect at J Paul Getty Trust

<azaroth> scribe+

<azaroth> gkellogg: Gregg Kellogg, chief editor for the spec, and invited expert to the group

<gkellogg> ivan: Ivan Herman, W3C staff contact, mostly in France

<gkellogg> bigbluehat: Benjamin Young, co-chair, work for John Wiley & Sons, Inc.

<ivan> scribejs, set tpk Duy-Tung Luu

<ivan> guests+ tpk

<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.

<gkellogg> … Canton Consulting

<ivan> scribejs, set ssstolk Sanders Tolk

<ivan> guests= ssstolk

<gkellogg> ssstolk: Sanders Stolk, I work for Semmtech.

<ivan> guests+ ssstolk

<ivan> guests+ tpk

<gkellogg> … We’re using LD for our clients to help in infrastructure to share information on buildings from design, building to maintanence.

<gkellogg> … In NL near Schiphol

<gkellogg> azaroth: topic: Review of accomplishments

Review of Accomplishments

<gkellogg> bigbluehat: Virtual click-through slide deck

<gkellogg> azaroth: We’re close to CR. There are three open issues.

<gkellogg> pchampin: Pierre-Antoine Champin, an assoiate professor at Univ. Lyon.

<gkellogg> … I’ve been on the WG for a year. My research is in SemWeb, also in RDF WG

<gkellogg> … Also co-editor of the syntax doc.

<gkellogg> azaroth: Three issues to consider, two this morning.

<gkellogg> bigbluehat: This afternoon, we want to talk about string direction, which may bring in more outside visitors.

<gkellogg> … Its of keen interest to a wide group; we thought it would be solved in RDF, but it may be on our shoulders.

<gkellogg> ivan: Formally speaking, it may be worth adding an explicit issue, or reopening the old issue. #11

<gkellogg> bigbluehat: version triggering is something to consider.

<bigbluehat> scribe+ bigbluehat

<bigbluehat> gkellogg: in most statements we do not include the nulls. one exception is JSON literals

<bigbluehat> ...but null is a valid JSON value, so there are reasons to keep them

<bigbluehat> ...pchampin pointed out a similar situation with strings, but that was an implementation issue

<bigbluehat> ...but it did help us find this

<bigbluehat> ...you can keep the `null` value currently by using the `@type: @json`

<bigbluehat> ...but in other cases we take it out

<bigbluehat> ...so we're at least inconsistent

<bigbluehat> ...it implies that there's some missing algorithm text

<bigbluehat> ...for preserving a key/value with a value of `null`

<bigbluehat> ...there are various options for preserving them

<bigbluehat> ...we could also decide not to

<bigbluehat> ...but I do think we can

<bigbluehat> ...if you expand it, and then re-expand it the `null` goes away...even when using the `@json` value type

<azaroth> issue: https://github.com/w3c/json-ld-syntax/issues/258

<bigbluehat> ...it's an editorial issue once we figure out how we want to handle it

<bigbluehat> ...because it's a lack of clarity

<bigbluehat> ...should be the work of an hour or two

<bigbluehat> azaroth: the question then is should the `null` be treated as a JSON literal null or should we remove the property

<bigbluehat> bigbluehat: Apache CouchDB and MongoDB (iirc) will remove keys set to `null`

<bigbluehat> azaroth: that's what this does in every other case...except the new `@json` type

<bigbluehat> ...I think it's more surprising for the `null` to go away if the type is `@json` than for it to stay around

<bigbluehat> ...but...do we want to still provide a way to remove the key/value?

<bigbluehat> ivan: why would we want to remove key/values?

<bigbluehat> bigbluehat: databases do it

<bigbluehat> azaroth: but this would be full statements

<bigbluehat> gkellogg: so most of the testing I've done was with numeric values and objects

<bigbluehat> bigbluehat: is `null` on it's own a valid JSON value/document?

<bigbluehat> ...what would JSON.parse do?

<bigbluehat> gkellogg: it would keep it

<bigbluehat> pchampin: I'm playing around with the code right now, and gkellogg mentioned that re-expansion would get rid of it

<bigbluehat> ...I added the `@version: 1.1`

<bigbluehat> ...otherwise it doesn't work at all

<bigbluehat> ...and when I do it, it looks like we get an invalid value

<bigbluehat> gkellogg: part of the use of `null` is to eliminate contexts

<bigbluehat> ...you can certainly handle these by setting a 1.1 at the processor level--if the document itself doesn't set it

<azaroth> azaroth tests `JSON.parse("null")` in chrome, and the result is a real null

<bigbluehat> ...but you're right it could be restricted to 1.0-based processing

<bigbluehat> ...so we may need to update tests to use 1.1 mode

<bigbluehat> ...and test with expanded values

<bigbluehat> ...so setting the processing mode is probably the way to do it

<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.

<azaroth> +1

<bigbluehat> +1

<gkellogg> +1

<pchampin> +1

<ivan> +1

RESOLUTION: 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.

<dlehn> +1

<bigbluehat> Subtopic: keyword alias for `@id` and `@type` cannot be singly `@protected`

<bigbluehat> https://github.com/w3c/json-ld-syntax/issues/246

<bigbluehat> azaroth: if you alias `@type` to `type` it can still be a set

<bigbluehat> ...however, using `@protected` on an object-based term definition will not protect the `id` aliasing

<bigbluehat> ...so my proposal is that we change `@protected` to be a legal keyword for keyword aliases

<bigbluehat> gkellogg: does `@protected` protect the `@type` based aliasing?

<bigbluehat> azaroth: [adds more examples to 246]

<bigbluehat> ivan: the examples don't show any reason for the `@protected`

<bigbluehat> azaroth: [fixes examples]

<bigbluehat> azaroth: [reads text from 4.1.5]

<bigbluehat> ...[reads text from 4.3.3]

<bigbluehat> gkellogg: looks like the API is correct

<bigbluehat> azaroth: ah, so they're out of sync

<bigbluehat> gkellogg: we do need more `@protected` text in this API section

<bigbluehat> azaroth: so the syntax fix is editorial

<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`.

<azaroth> +1

<gkellogg> +1

<bigbluehat> +1

<pchampin> +1

<ivan> +1

RESOLUTION: Allow the use of `@protected` as a valid keyword in term definitions which are aliases of keywords or where the term is `@type`

<azaroth> Issue above: https://github.com/w3c/json-ld-syntax/issues/246

<bigbluehat> gkellogg: before we go on to the next issue, there are some visual things maybe we can solve

<bigbluehat> ...I've never liked the green stuff

<bigbluehat> ...for new items

<bigbluehat> ...since we already have some active JS in there

<bigbluehat> ...maybe we can toggle highlight changes in 1.1

<bigbluehat> group: [discusses various CSS related tweaks...decides to leave things as is]

<bigbluehat> gkellogg: but then there's "[Exposed=Window]"

<bigbluehat> ivan: why is that even needed?

<bigbluehat> ...let's just display: none it

<bigbluehat> ...it doesn't apply to us

<bigbluehat> ...since our use of WebIDL is not language specific or browser specific, there's no reason for this exposed window object thing

<bigbluehat> azaroth: there are a few other issues we should chip away at

<bigbluehat> Subtopic: 220 in syntax; move 9.3 and "default object" to framing only?

<bigbluehat> https://github.com/w3c/json-ld-syntax/issues/246

<bigbluehat> gkellogg: so things show up when they've been referenced

<bigbluehat> ...and the terminology here does make this confusing

<bigbluehat> ...we introduce these concepts, because many people who use these don't look at API documents

<bigbluehat> ...the frame is more of a hybrid document of syntax and api

<bigbluehat> ...we might just be being to explicit here

<bigbluehat> ...we even describe a frame object here for that matter...

<bigbluehat> azaroth: this doesn't really add much...and I'd suggest just removing 9.3

<bigbluehat> gkellogg: and there is an earlier reference to framing earlier

<bigbluehat> azaroth: so...yeah

<bigbluehat> gkellogg: and farther down, we introduce expansion, compaction, etc.

<bigbluehat> ...and there's a framed document form

<bigbluehat> bigbluehat: off topic, but I'd love to have expanded form explained earlier

<bigbluehat> ...too big a change right now...but maybe in the primer

<bigbluehat> ivan: it helps me too to think about expanded form

<bigbluehat> gkellogg: but back to this specific issue

<bigbluehat> ivan: right. frames are valid 1.1 documents now

<bigbluehat> ...so the syntax document has to call this out

<bigbluehat> azaroth: right, 5.4. explains it, and you can't understand 5.4 without 9.3

<bigbluehat> gkellogg: this issue can capture why its there

<bigbluehat> Subtopic: regarding expanded form earlier in the doc

<bigbluehat> gkellogg: maybe we just add a new section that talks a bit more about expanded form in the intro

<bigbluehat> ...that highlights that various forms exist and how they work

<bigbluehat> ivan: it's true that these other forms are helpful

<bigbluehat> bigbluehat: do we need an action for this?

<bigbluehat> gkellogg: maybe we can put a basic overview of just expanded form and its use in the intro/basic concepts section

<bigbluehat> ...and then to note that semantically the compacted + expanded are equivalent

<bigbluehat> ...even though syntactically they look different

<bigbluehat> ACTION: gkellogg to write a couple paragraphs + example(s) for explaining expanded form and its use

<bigbluehat> group: [discussing the implementations available and needed]

<bigbluehat> ...primarily C++ and Java need the most attention

<gkellogg> http://drobilla.net/pages/contact.html

<azaroth> {

<azaroth> "@context": {

<azaroth> "@vocab": "https://example.com/",

<azaroth> "schema": "https://schema.org/",

<azaroth> "name": "schema:name"

<azaroth> },

<azaroth> "name": {

<azaroth> "@value": "fish",

<azaroth> "@language": "en",

<azaroth> "@direction": "ltr"

<azaroth> }

<azaroth> }

<pchampin> +1

<pchampin> { "@context": ["http://schema.org/", { "@direction": null }], "tag:p": { "@value": "foo", "@language": "en", "@direction": "ltr" } }

<scribe> scribe: manu

Discussion around use of @direction and how it affects JSON-LD 1.0 processors.

Seems that there is an issue wrt. the use of @vocab and @direction... processors are choking.

A bug exists in 1.0 and 1.1 that doesn't flag the use of @direction and @vocab.

<azaroth> Issue created: https://github.com/w3c/json-ld-syntax/issues/259

Current 1.0 processors are going to ignore use of @direction in various places.

<pchampin> {"@version": null} :-D

rob: Moving on to whether or terms can start with @ symbol.
... Currently, the spec is not clear wrt. SHOULD NOT vs. MUST NOT.

bigbluehat: This is why HTML is not versioned.
... 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.

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.

bigbluehat: When I use a newer processor, I'm aware that it's going to look different... I don't touch old data.
... I'd suggest you use a switching mechanism in processor... nuclear option is to use 1.1.
... If I point towards the past... I provide HTML5 document to HTML 3 processor, you don't lose data
... If you give @version to 1.0 processor, it explodes.

manu: Yes, but the only consumers are schema.org and they'll just do 1.1.

bigbluehat: yes, the evergreen browser argument

pchampin: Changing 1.0 parsers, if they don't fail on 1.1 parsers, they'll break on other things

<bigbluehat> Feature Detection issue https://github.com/w3c/json-ld-syntax/issues/33

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.

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.
... If in a year from now, we add @direction, what do we do -- version 1.1.1 or version 1.2?

<Zakim> manu, you wanted to mention feature detection/upgrades.

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.

<bigbluehat> manu: so. the original `@version` proposal was a list of features

<bigbluehat> ...so if you were to process this document, you must support those features

<bigbluehat> ...if a processor can't support those, then it just blows up

<bigbluehat> ...and 1.1 was just an alias for a bundle of features

<bigbluehat> ...the issue we saw was that there might be a feature...well...

<bigbluehat> ...one, announcing them doesn't mean you'll be using them

<bigbluehat> ...or it might just get forgotten that you've left the "opt-in" around when you ended up not using it after all

<bigbluehat> ...so, the feature detection works best when it's also BC friendly

<bigbluehat> ...and that turns out to be rather hard

<bigbluehat> ...we'd have to go through each feature and determine how detectable they are

<bigbluehat> ...but the reason against that is that it's a huge amount of spec text

<bigbluehat> ...and we weren't sure that every new feature weren't able to figure those out

<bigbluehat> ...and they might determined it differently

<bigbluehat> ...which is why we were ultimately in favor of 1.1

<bigbluehat> ivan: so does that mean if we go into continuous development

<bigbluehat> manu: ...yeah. I'm against that also

<bigbluehat> ...I was opposed to this 1.1 work earlier...the 4 year gap was helpful for the stability of the data and community

<bigbluehat> ivan: k...but if we keep shipping, then we'd just keep shipping these version number things

<bigbluehat> manu: yeah...but that gets complicated again

<bigbluehat> ...and if you look at HTML5, feature detection is insane

<bigbluehat> ...the earlier issues were about feature announcement not detection

<bigbluehat> gkellogg: the point of 1.1 was not so we'd have a 1.2

<bigbluehat> ...it was so we'd be locking things down

<bigbluehat> ...and that's principally done in context processing

<bigbluehat> ...and we did not do that properly in 1.0

<bigbluehat> ...so, virtually, I'd say 90% of features are discovered in `@context` processing

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.

<bigbluehat> ...the others show up in expansion

gkellogg: We do look for those in 1.1 mode and 1.0 mode... frame processing mode...
... 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.

ivan: If we had it today, @direction wouldn't be detected in @context.

gkellogg: If we had it in the context it would be.

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.

gkellogg: Anything that looks like a keyword and the processor doesn't understand it, it should abort.
... I disagree w/ manu, I think we can do feature detection.

manu: I don't think I said we'd use 1.1 when doing JSON-LD 5.0

ivan: isn't this an issue for stream processor?

<Zakim> azaroth, you wanted to note lunch :)

gkellogg: Well, you could throw an error if you hit something...
... I think we'd be in a better position if we don't use @version.

rob: We need to break for lunch soon.

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...
... There is something to be said to an interpreter breaking on a feature it doesn't understand, vs. a feature thing... parser, or implementation...
... Depending on level of confidence, you use one or the other... this is something that people should be aware of anyway.

gkellogg: In some cases, in order to get behavior, you should be in validation mode.

bigbluehat: I want as much of data out of top of page, don't care about reviews, give me what you can give me.

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...

gkellogg: It is using features that are defined in 1.1... if your parser dies, sometimes it helps if you have it all gathered.

<azaroth> --> #wot

I18N

<scribe> scribe: manu

<ivan> guests+ dan, chaals, addison, r12a, hadley, danbri

<ivan> scribejs, set hadleybeeman Hadley Beeman

<ivan> scribejs, set r12a Richard Ishida

<ivan> scribejs, set chaals Charles Neville

<chaals> scribejs, set chaals Chaals Nevile

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.

r12a: We move the upper stories of the Eiffel tower first :)

<aphillips> s/r21a/aphillips/

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.

<ivan> scribejs, addison_ Addison Phillips

aphillips: We are interested in seeing if we can do something at this level, see if we can move this down to RDF level.

<ivan> scribejs, set addison_ Addison Phillips

azaroth_: One question that would be good to answer, why isn't language sufficient to do this?

<ivan> guests+ Bert

azaroth_: Why can't we just say English is ltr, arabic is rtl, and be done...

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.

<r12a> https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags

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.

<Zakim> chaals, you wanted to talk language

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 detect is azeri.

r12a: No, not true by a long shot.

chaals: RDF doesn't understand ar-kw ar-?? is all arabic

r12a: And new subtags are added all the time...

chaals: You'd have to parse RDF language tags to get this partial solution

r12a: There was a point where we thought it would work... the URL that I just posed in IRC is the result of that.

<bigbluehat> https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags

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.

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.
... metadata only on the one string.
... When yo uhave mixed text, we can't do that.

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

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.

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.
... 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.
... If you are doing complex matching, you need application logic.

danbri: We don't need to address fancy SPARQL query.

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.

<Zakim> chaals, you wanted to follow the subtopic of what breaks if we make the proposed change

chaals: If we follow this plan, what breaks?

ivan: What's the plan? Add syntax for @direction and add a new property

<chaals> the proposed json-ld syntax

Group looks at directions in rdf-dir-literal document.

<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

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...

gkellogg: We also discussed that this was a transitional solution.

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.
... 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...

<Zakim> manu, you wanted to ask why this wasn't handled in BCP47?

ivan: Adding the feature is easy, what happens to the process is not a big deal....

<chaals> manu: I really pushed to fix this, for verifiable credentials to be able to move on...

<ivan> scribe+ chaals

<chaals> … we rushed in to getting good ideas on the table. I am going to check whether this is really the right course.

<chaals> … seems like language tag does 95% of what we want, a lot of times.

<chaals> … so it is true that people extract some text direction out of the language tag

<chaals> addison: mostly right now it isn't used…

<chaals> … most people without a base direction appy the unicode algorithm.

<chaals> chaals: anecdata suggests that in practice, people are really implementing stuff withthe language tag and accept that as generally good enough for customers.

<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.

<chaals> … we could deal with it in the lang tag and not have to change the RDF layer

<bigbluehat> the mentioned list of specs https://w3c.github.io/rdf-dir-literal/draft-charter.html#normative

<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.

<chaals> … there is a massive number of subtags.

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.

<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.

<r12a> r12a's slides start here: https://www.w3.org/International/talks/1810-paris/#metadata

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...

<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.

<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

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.
... 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...
... 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.

<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)

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.
... We've encouraged people do to good solid JSON-LD 1.0 files, there are millions and millions of this....

<Zakim> azaroth, you wanted to question the damage of punning properties (equivalent to new datatype) vs -x BCP extension

danbri: The smallest little thing we can do is important, if we can do some surface hackery, we can parse this stuff...

gkellogg: Yes, some transitional mechanism.

ivan: We are having a discussion about versioning discussion...

gkellogg: parameterize RDF algorithms stuff...

danbri: Parser being invoked w/ arguments, people run RDFa parser in certain mode.

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.
... 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.

<Zakim> chaals, you wanted to argue that requiring lang tag parsing is also a big change.

chaals: I think we want to do this, happy to give up round trippability... what's going to break?
... If that's a fast path, this is a good solution.
... Forcing things that don't parse language to parse language, that's a big ecosystem thing.

<chaals> manu: I think the vast majority of appications don't pay attention to the language tags, or direction.

<chaals> ivan: In browsers, they don't establish direction with language they do it with direction metadata.

<addison_> <p dir=rtl>arabic here</p>

<r12a> https://github.com/w3c/string-meta/wiki/Base-direction-and-language-tags

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...

manu: I just wanted to make sure we are making an educated decision.

aphillips: I think the right thing to have done is split the two -- language and dir must be separated.

r12a: Yes, they're not doing the same thing

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.
... We would be more reluctant if we adopt this that this is a different language encoding to ...

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.

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.
... smuggling direction in language might help adoption because it's easier to do... let's not make this have additional barriers.

gkellogg: To clarify, are we done at 3?

azaroth: This is something we want to do...

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.

<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

manu: I'm committed and convinced to do @direction

<Zakim> manu, you wanted to note that it's not clear that lang and dir were designed to be separate.

azaroth: Is it possible for you to be back after break, danbri?

<ivan> scribejs, set danbri Dan Brickley

<ivan> guests+ danbri

danbri_: What about the future? When you have arabic, french, in Japanese?
... Are we defining something where future direction happens...?

chaals: What about text orientation and stuff... LTR and RTL...

aphillips: There is a high degree of confidence on number of text directions...

<azaroth> Restarting ...

<azaroth> scribenick: bigbluehat

scribe+ bigbluehat

azaroth: on the Agenda is continue until exhaustion
... in favor of progress
... I think that is contentious to add the surface syntax
... so reopen that original issue
... and then look at RDF round tripping *after* that's resolved
... the worst scenario is to go to CR with no solution
... it is better to go CR with `@direction` and without a mapping into RDF, than to not put in `@direction`

gkellogg: curious about danbri's thoughts

danbri: that's up to Google (Bing, etc), but we can encourage users of Schema.org to publish it

<azaroth> (better to also have consensus about the RDF transitional reflection, but that seems more complicated)

danbri: but can't promise SEO bots will consume it

ivan: if I put in a `@language` into my web site data, what happens

danbri: we certainly have the notion of languages of pages, etc.
... but the more narrow `@language` usage would be up to the various products/consumers of that data
... and I can't speak for what they do
... I think it's likely that we're not doing a great job with `@language`--let alone `@direction`, etc.
... so I don't think our tooling will catch fire, etc.
... 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

gkellogg: there have been some calls in Schema.org to add some properties to say
... things like breadcrumbs might make use of the `@list` capability
... or strings that used a map structure
... where there would be a `@context` to understand those
... whereas at Google they're just checking directly
... might you consider a similar pattern for `@direction`

danbri: I think you're designing hacks for a system neither of us know much about :)

azaroth: let's project some examples

danbri: I was thinking whatever Voodoo you work up--so in 1.1 it's these little `@` things...

gkellogg: so, yes, we have `@language` and soon, we think, `@direction`
... I can set an `@language` for the whole document or a certain object
... and when it gets expanded, you have that language data as well as the value

danbri: so each publishing web site would make use of its own context?

bigbluehat: let's make sure we're all talking using the same terms
... I don't we're all sure what expanded form is, etc.

azaroth: [projects some examples]

<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

manu: so I feel we're overusing an unbuilt feature
... how often to we expect people to use the `@direction` feature actually?
... most authors won't want to grow to great pains to express it

addison_: no, but most machines written to care will
... so people with direction metadata will want to consistently use it all over the place

<gkellogg> scribe+

<gkellogg> danbri: Can’t we just use the dir attribute on a script tag?

<manu> danbri: You can pick it up from the HTML dir element...

<gkellogg> bigbluehat: No, we’re not allowed to do that.

<manu> bigbluehat: You can send it into processing algorithms for JSON-LD...

<manu> ivan: We looked at this, HTML5 spec says to not use lang for script tags.

danbri: https://html.spec.whatwg.org/multipage/scripting.html#data-block
... is there a way to do this at the top of the file?

ivan: no

gkellogg: you can at the top of the file for `@language`
... and presumably we would for `@direction`

ivan: so, yes, it could be there, and on each value
... it is an open question whether the container mapping thing would also be used for language direction
... basically, yesterday's proposal was to mimic `@language`, but for the `@direction` data

bigbluehat: clearer? or worse?

danbri: but what if context's aren't used?

<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?

<danbri> eg https://gist.github.com/danbri/9627452ec7dcbe63af9cb5a631acfdf8#file-gistfile1-txt

manu: so you'd just use `@language` and `@value` directly as an object for the value of the property--i.e. a value object

danbri: so, here's an example we've been playing with at Google
... we don't want to do this on every field--as you can see it'd be painful and verbose

gkellogg: yeah, we would let you set for the whole document--as with `@language`

manu: I feel like we're handing people a foot gun
... everything would become ltr or rtl--even if it's not supposed to

gkellogg: well, it depends on how they visualize the output to know if they've done it wrong

manu: people don't visualize it

bigbluehat: they just put the JSON into text areas and call it done

manu: yeah...most of them don't even care about `@language`

danbri: so do it only down at the property level

addison_: I can see doing it there

danbri: would it make sense to have it in the schema languages?
... like certainly fields are "directable"?
... so gsin's or isbn's are not directable or language-able

addison_: isbn's are a great example
... they have to be a string, includes letters, hyphens, etc.
... but it's not in a language
... it's a string literal
... and the world is few of these
... but it's also full of language-bearing strings which have both language and direction
... in some cases that can be inferred, but in some cases we can't
... so we do have direction fields in our databases to track that

manu: so, one option is to allow `@direction` at the top and have it cascade to the entire document
... the other extreme/option is to put it on only the values

ivan: so it is up to Schema.org to decide if they want to promote `@direction` at the top
... we are here talking about the standard
... and I don't see why we would disallow this

addison_: the reason you do this with `@language` is because you don't want to repeat it

ivan: the same applies to `@direction`

gkellogg: we have various things to apply `@language` across the whole document
... I can say that ISBN is no language
... by setting `@language: null` on just that value
... for symmetries sake it would be odd for us to do this only for `@language`, but not `@direction`
... even though we might not have obvious use cases, there is an orthogonality argument to make to do it for the whole document

ivan: I agree

addison_: I agree

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`

ivan: no, ISBN is a good example
... they always go "rtl"

addison_: MAC addresses are a great example
... they draw backwards if they flow the wrong way

gkellogg: so, we should do this in all the same places we allow `@language`

group: [general positive responses]

gkellogg: I presume it doesn't make since to have `@direction` maps?

addison_: `@language` maps are very useful
... the question then is how to do both if you use `@direction`

gkellogg: we could do nested objects inside nested objects

group: [growns]

tung: so we define only the language, and guess the direction?

gkellogg: you could leave the direction off
... you could provide both
... or the string could just use the default direction

tung: if the user provides a direction, but if the user does not state a direction it falls back to language?

addison_: the language map is the space in which you'd define a language
... but on each value

tung: what about vertical text?

<Zakim> manu, you wanted to wonder how often @direction is used in data today alongside language...

addison_: vertical text is a presentational concern

manu: I think we keep breaking our own principles here
... now we're saying we're using language for text direction when it's not available?

addison_: they're not completely independent

<Zakim> azaroth, you wanted to discuss resolutions

manu: yeah...so the fact that this was thoroughly confusing to a bunch of developers...
... the stuff presented earlier about not guessing direction from language...but now we are

david_clarke: Yiddish can be in Romain characters or Hebrew characters
... so declaring the direction is still important

manu: page-wide dir on HTML was maybe a mistake

addison_: no, there's a reason to have it on the outside of the container for a bunch of reasons
... there is some linkage between language and direction
... and what we want is to give people the things they need to reach beyond what language provides
... if you ever watch folks attempting to develop or write this stuff, it's really really hard
... we're trying to provide enough affordance to take a string out of a page and have it present properly
... without having to introspect, etc.
... we'd like for folks to be able to express their data in all the various standards without having to rewrite all the things
... that's why having direction is important here
... because it handles all the other bits beyond the text--bullet points, etc.
... works in html, etc.

<azaroth> PROPOSAL: (1/*) We add @direction as a keyword to the JSON-LD Syntax to assert the base text direction of a literal string

<manu> +1

<gkellogg> +1

<azaroth> +1

bigbluehat: it's really similar to RDFa using a document level `dir` for all the things
... and being overridden elsewhere

+1

<simonstey> +1

<ivan> +1

<pchampin> +1

<danbri> +1

RESOLUTION: (1/*) We add @direction as a keyword to the JSON-LD Syntax to assert the base text direction of a literal string

<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

<manu> +1

<pchampin> +1

<azaroth> +1

+1

<ivan> +1

<gkellogg> +1

<simonstey> +1

RESOLUTION: (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

tung: why no `@direction` with `@type`?

gkellogg: because you can't have `@language` with `@type`

tung: but what if the `@type` has a language?

gkellogg: that's a different case

tung: can we use a class to define language?

gkellogg: that was considered

<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

azaroth: I think we're back in solution space, and should get back to resolutions

<gkellogg> +1

<manu> +1

+1

<pchampin> +1

<ivan> +1

<azaroth> eg: {"label": {"@id": "rdfs:label", "@direction": "rtl"}}

RESOLUTION: (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

<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)

<azaroth> +1

<gkellogg> +1

<ivan> +1

<simonstey> +1

<manu> +1

+1

<pchampin> +1

RESOLUTION: (4/*) The value space of @direction is one of "ltr" and "rtl" ("auto" would have been the same as not asserting the keyword)

guest+ david_clarke

scribejs, set david_clarke to David Clarke

<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

<azaroth> +1

<gkellogg> +1

<pchampin> +1

<ivan> +1

+1

<manu> +1

<azaroth> eg: {"en": {"@value": "Rob", "@direction": "ltr"}}

RESOLUTION: (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

<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

<azaroth> +1

<gkellogg> +1

<ivan> +1

<manu> +1

<simonstey> +1

+

<pchampin> +1

+1

RESOLUTION: (6/*) @direction can be present in a context node, and sets in the active context that the default direction for all string literals

<azaroth> PROPOSAL: (7/*) WG agrees that @container: @direction is not a useful feature for JSON-LD 1.1 (unlike @container: @language)

<azaroth> +1

<manu> +1

<danbri> +1

<pchampin> +1

+1

<simonstey> +1

RESOLUTION: (7/*) WG agrees that `@container: @direction` is not a useful feature for JSON-LD 1.1 (unlike `@container: @language`)

<ivan> +1

<azaroth> SUBTOPIC: Versioning issues

<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."

manu: who will this cost?
... when they upgrade

danbri: I don't think our processor do language...or value object or whatever...processing

gkellogg: so, your developers are happy, but folks who use the JSON-LD labeled tooling, will get a different result
... and for those you'd have to say `@version: 1.1`

danbri: we've felt at Google and Schema.org for a long time that JSON-LD 1.0 had finally gotten good momentum
... and then the 1.1 work showed up
... and that's why we pushed against it a bit
... and you all are deep into the `@context` space
... but we've known from the start that the public Web JSON-LD space was actually processed differently
... and without the `@context`
... the promise made by the WG that the new parsers would still successfully parse the old JSON-LD
... is that still true?

group: yes

azaroth: but we should probably talk about version triggering...as that's goes a bit farther
... to opt-in to the new features, you have to include `@version: 1.1`
... and if you do, that in a context, the old processors--using the `@context` file--will choke

danbri: most of the others (Bing, etc) aren't doing JSON-LD processing using the `@context`
... and we aren't either

<Zakim> manu, you wanted to suggest a compromise.

danbri: so who does this break?

azaroth: those folks processing schema.org based data with JSON-LD 1.0 processors

manu: so, what we could do is use the current versioning mechanism
... but schema.org could promise to not upgrade for 2-3 years
... but still encourage folks to use the `@language` and `@direction` stuff now

danbri: or we could do the opposite and put 1.1 in the context--and see who cries?

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

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

<Zakim> manu, you wanted to note that I never got around to my compromise proposal :)

manu: so the compromise proposal is to signal with the `@version: 1.1
... but what we could do also is that any 1.1 processor could do feature detection
... i.e. choose to upgrade for other reasons than just the `@version: 1.1`

gkellogg: so no need for the version announcement?

manu: I think it should still be there

gkellogg: so I've come to feel that the `@version` announcement is such a big bearier
... that people will avoid it

manu: so over time if we see that the `@version` isn't being used, then we can take it out of the spec
... so it may go away in a future JSON-LD

gkellogg: so Schema.org could avoid `@version`?

manu: yes, they can use `@direction` now and that could trigger the upgraded processing

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
... 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

pchampin: things will still break...just later...so the `@version` could be avoided
... but we can recommend avoidance of other items also

azaroth: so if you are concerned that there are 1.1 features that you MUST have processed, then you signal with `@version`
... otherwise, you just let the processor figure it out from the stuff in the document
... if you have scoped properties or whatever in your context, but your document doesn't use them...then things would be fine

ivan: we have a close dependency right now
... which is the publication manifest and we're at the end...and we had our story with i18n exactly for this reason
... with these resolutions, I would have to add `@direction` to the manifest
... that manifest is built up from schema.org for most of it's vocabulary
... and adds a few more that we need that schema.org doesn't have
... so what happens if I produce a book and don't put `@version` in it?
... google or bing or whoever processes it

danbri: we don't have a common code base...so we have no idea how these things are processed

<manu> bigbluehat: Rob, the chances that you have that playground up w/ @version? Oh, there it is.... no it isn't.

<manu> bigbluehat: This is what the Publishing WG could do... define it as a term... "direction" set to "@direction"

<manu> gkellogg: I think schema.org has a 'direction' term?

<manu> bigbluehat: and you can't do, in context, @direction: direction?...

<manu> Group works through example on JSON-LD Playground...

<manu> bigbluehat: A v1.0 processor is going to choke, whatever we do.

<manu> danbri: What if we do an errata?

bigbluehat: yes. errata could work
... main thing is getting people to support it so it doesn't choke

<manu> bigbluehat: The bulk of JSON-LD code is out of this code base, could "fix" it... could put it in 1.1.

manu: ivan just have Publishing WG use 1.1

<manu> ivan: If we introduce @direction...

<manu> gkellogg: 1.0 will die

<manu> ivan and gkellogg brawl! Chairs thrown, walls torn apart! :P

<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.

<manu> gkellogg: You don't need @version...

<manu> bigbluehat: I don't want other JSON-LD processors to break.

<Zakim> pchampin, you wanted to answer ivan

<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.

<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 ?

<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.

manu: that's the exact point I wanted to make
... if make the `@version` mandatory
... then you can force it into 1.1 mode
... but at the cost of the current processors
... but we should leave it around until we know we can take it out and still accomplish the same goal

<manu> ivan: Is it possible to express the choice as a feature at risk?

<Zakim> danbri, you wanted to ask plans for media type; what happens to <script type="application/ld+json"> ?

<manu> scribe: 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.

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.
... in that case, SEO bots could distinguish/care... devs could be told, to opt in, add semicolon v=2.
... different way to signal that...

danbri: Can we put some wiggle room in so future groups can do stuff?

azaroth: Yes, we can do this effectively for free.

bigbluehat: That's not an insane thing to say, as long as we have enough access to know media type expressed falls back.

<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

<azaroth> +1

+1

<gkellogg> +1

<bigbluehat> +1

<rubensworks> +1

<pchampin> +1

<ivan> +1

RESOLUTION: 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

ivan: We'll need to be very clear about how they're going to detect features, most likley in the text...

gkellogg: It's worth running this by Ralph and getting some thoughts.

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?

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...

gkellogg: My feeling is that SEO community has moved over to JSON-LD...

<Zakim> manu, you wanted to -1 too, too many signaling mechanisms

danbri: large part was Google picking it up.

<bigbluehat> manu: having an extra signalling mech complicates things

<Zakim> azaroth, you wanted to -1

gkellogg: I think this makes script tags ugly and error prone

<bigbluehat> gkellogg: there could be other stuff in the media type to signal processing mode

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.
... this is not an evolutionary choice to start over... whereas other feature... DINNER!

Dinner :)

<bigbluehat> Option 1 - ~27 min walk (or 19 min bus) https://g.page/hotarunishijin

<bigbluehat> Option 2 - ~11 min walk https://goo.gl/maps/CSAS9oEXMddekJom7

<ivan> Meeting: JSON-LD Working Group F2F in Fukuoka — Second day

<ivan> Date: 2019-09-20

<ivan> Agenda: http://tinyurl.com/y34nfpfg

<ivan> Chair: azaroth, bigbluehat

<ivan> guests+ Ralph

<ivan> scribejs, set Ralph Ralph Swick

<azaroth> scribenick: azaroth

Discussions with Ralph

<ivan> scribejs, set tpk Duy-Tung Luu

<ivan> guests+ tpk

SUBTOPIC: Version announcement to version detection

<bigbluehat> yesterday's minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-09-19-json-ld

[Various non json-ld issues about w3c irc infrastructure]

bigbluehat: New feature to be added. Previously had rejected @direction for language, as expected to be solved in RDF
... 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
... WG is fine with doing this. Brings up the issue of versioning. Adding `@version` will intentionally make processors choke
... want to make some features that don't make incompatible changes available

Ralph: What happens now?

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

[disagreement about when things fail]

scribe: if you use @direction when it's mapped, then it won't work in a value object but will work elsewhere
... if you use it when it isn't mapped, then it is ignored

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
... it would fail without the processor, due to @vocab

bigbluehat: ActivityPub also would benefit from this and use @vocab
... postel's law discussions about how to get there with as much as possible
... concerns about whether this would actually get to where we want to

gkellogg: We've identified where in the API it has effects
... 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
... 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
... the proposal is to facilitate the use of 1.1 features is it reasonable to not do that
... to switch to 1.1 when you're using something that you detect as being part of 1.1. A lazy evaluation
... a 1.1 processor will be fine
... 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
... one of the things is an id map, keys are ids values are objects for the uris.
... a 1.0 processor would just think it was another object with strange properties
... could get very very different interpretation of the same document
... if a publisher of a context is concerned about that, then use `@version` announcement
... but might have some reasons to not do that, if you don't worry too much about the interpretation

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

<bigbluehat> +1

pchampin: could compare the graphs and thus identify the features that really break things or not
... then discuss in best practices document
... as to which features should really have `@version`

Ralph: Good to know what "break" means

<pchampin> +1

Ralph: 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

gkellogg: There'd be no legit 1.0 data that tried to use lists of lists
... it would be useful to see what a 1.0 processor would do
... we have the tests, we can have versions of the tests that don't announce 1.1 and see what happens

Ralph: @version says you must not interpret this using 1.0 rules

<dlehn> list of lists had explicit error in 1.0 jsonld.js

bigbluehat: I think there's consensus to do this moving forward

gkellogg: blanket statement that publishers use version announcement, with warnings for features of what happens if you don't do announcements

Ralph: two cases, different results but new objects aren't understood.

gkellogg: set of okay results and others that are crazy

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

tpk: incompatibility not necessarily a feature, could be a logical error between interaction of features
... hard to anticipate all the tests needed

<manu> +1 I'm also concerned about combinatorial issues w/ feature detection

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
... should be cautious about things

gkellogg: that was when we deprecated behavior that we didn't think was used
... not because of the spec, just the way my implementation interpretted it

bigbluehat: One thing that came up yesterday was that the processors aren't mostly json-ld processors anyway
... they won't care
... only people that we're hurting are json-ld processors
... hard time making the case
... it's no issue for non json-ld processors of the data
... it's now in lighthouse, which is a json-ld processor for real though

[SDTT]

gkellogg: SDTT isn't a validator

ivan: True but it reflects as much as is known about what schema.org processors do
... this construct which is valid JSON-LD isn't processed correctly, for value objects

bigbluehat: We heard danbri say that they would be happy to promote it, but that's all that they can do

pchampin: Shouldn't break things that currently work ... including things that don't work

[laughter]

gkellogg: SDTT isn't a metric for judging brokenness
... people complain about why SDTT complains about stuff that the linter is fine with

ivan: schema.org is already broken for value objects regardless of what we do here

bigbluehat: Website owners just want it to show up in the search index

gkellogg: that it doesn't work in SDTT doesn't mean it won't work in the inde

x

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

[playing with sdtt]

[accepts https:// and http:// schema.org / or not / ]

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"
... during implementation if we find feature detection to be too hard, ...

ralph: or a lot of documents would be broken

ivan: yes, then changing behavior in CR would be acceptable

bigbluehat: danbri said SEO bots don't look at the context
... they don't process it

<bigbluehat> scribe+ bigbluehat

<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

<bigbluehat> ...for example, if it turns out that some things are possible and some other things are really hard

<bigbluehat> ...then we might change how the warnings/errors work for those

<bigbluehat> Ralph: so your proposal is that there will be feature detection

<bigbluehat> ...and what's at risk is that you may require `@version`

gkellogg: Possible middle ground too.

<bigbluehat> ...your proposal is to make `@version`possible, and you're marking the requirement of it as at risk

Ralph: Can clarify in the document that things are at risk as to being available without @version
... two categories of features ... ones that are turned on without @version which is at risk, and those that require @version

SUBTOPIC: direction part 3 ... RDF

ivan: what we agreed yesterday is the syntax. We will have direction in json-ld. Within json-ld world it just works
... however, the question is if we generate RDF, what do we do?

ralph: can we be more precise about "generate RDF"?

ivan: Produce an RDF graph with a literal with a direction
... 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
... the other is to define new RDF terms for language and direction, where instead of a literal it's a blank node
... a kind of skos-xl like structure for literals
... the positive aspect of the structure is that it round trips through the graph
... the information isn't lost
... the negative aspect is if RDF data goes this way, we create a parallel universe for language+direction literals
... json-ld users can pick which way they want
... but what's the default
... don't have an answer, perhaps via a coin flip
... that's where we are
... there are other possibilities for how to reflect into RDF
... could also be a new datatype
... there's always a parallel universe

[looks at rdf literals and base direction doc]

scribe: question is whether there's a problem to define two new terms in rdf: namespace

ralph: ?you are already comfortable with the processor option

gkellogg: there are options for other things, though most people use default
... Not acceptable to not round trip. Should do something that preserves it.
... lots of discussion. Future group would be expected to replace or endorse the structure. A processor option would let the future processor adapt
... can't keep it entirely in the JSON-LD domain

<bigbluehat> azaroth: I generally agree. two comments, though

<bigbluehat> ...for CR, if we mark it at risk, and it turns out that....

<bigbluehat> ivan: mark what?

<bigbluehat> azaroth: well...whatever we define here

<bigbluehat> ...and at implementation phase it turns out there's push back against the structured approach

<bigbluehat> ...because it results in an "always punning" scenario

<bigbluehat> ...and if, like us, you don't have punning as an option

<bigbluehat> ...then the language tag approach would be preferred

<bigbluehat> ...which would be my personal preference

<bigbluehat> ...because it puts things in an expected place

<bigbluehat> ...the SPARQL queries already have to search for "en-*"

<bigbluehat> ...there are of course other cons

<bigbluehat> ...but if it turns out that during implementation that the structured approach is not the best default

<bigbluehat> ...do we have to go back through CR in order to change that default?

<bigbluehat> gkellogg: the i18n seemed to strongly object to the use (well..."hacking") of the language tag

<bigbluehat> ivan: I'd even expect them to formally object to that solution

<bigbluehat> ...at this point I don't think it's a choice

<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

<bigbluehat> azaroth: addision did say he'd rather have it in the language string than to not keep it at all

manu: I don't think the structure solves things. We haven't had this for a long time.

Ralph: And getting objections as a result

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
... we can be a forcing function. By default it's dropped, it doesn't impact them if you don't want it
... so opt in
... what it looks like in RDF - I agree that the i18n folks dont' want it in the tag - but there could be a ^direction
... of the options I've seen that looks the cleanest
... don't have to upgrade infrastructure now until it's implemented
... BCP47 doesn't have a caret in any language
... so a clean token to split the string on
... if that's the final option, then we should force it in that direction

ivan: Am fine with opt in
... but opt in should mean generate something in RDF which is valid today
... generating invalid RDF is unusable anyway
... no idea wht the community will come to a solution, if ever, but something that no processor will accept today is useless
... caret means we create another syntax
... could have created something with a string and lots of carets bla bla :)
... won't have it today, might not ever
... so generating it is pointless. Only one that's valid is the structure

pchampin: If we go the way of an option, we should consider the equivalent for rdf to json-ld

<Zakim> gkellogg, you wanted to respond to manu

pchampin: that might be none trivial for an intermediate node solution

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
... we have uris bnodes and literals
... only if language tagged can they have a language

<ivan> guests+ fantasai

gkellogg: literal would have a direction and a language ... youve added a column in a store
... an rdf WG might decide to do that
... deafening silence was the reaction from the community

Ralph: strong +1 to opt in
... default should be to break the fewest tools
... option to do something better is most useful if the better is something that tools can work with
... suggests some choices
... 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
... urge to do something useful to existing tools

manu: What goes along with the option could be a function to decide what to output
... e.g. RDF in some format
... 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
... no clear solution that meets all the requiremetns
... if the solution is new triples, we have no interest in implementing it
... don't have a strong requirement to do that, so would just wait until the problem has a final solution
... 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
... arguing this is not the state of the world today can be valid, but can't push the ecosystem forward

<Ralph> [so if Manu has no strong requorement at the moment, having infinite extensibility with a function call-out seems way overblown]

manu: concerned by implementation complexity. People saying they can't implement a 1.1 processor
... everytime they look at the spec they see a massive set of features
... 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

<bigbluehat> PROPOSAL: do not, by default, handle `@direction` expression in `toRDF` (or `fromRDF`)

manu: every new feature makes it worse -- too many options and we make it very difficult.

<manu> +1

Clarification - the default option for toRDF is to drop it

<bigbluehat> +1

<ivan> +1

scribe: a future proposal will add in more options

<pchampin> +0.5

+1

<gkellogg> +0.1

RESOLUTION: do not, by default, handle `@direction` expression in `toRDF` (or `fromRDF`)

[bringing fantasai up to speed on @direction]

azaroth: from before -- data type is also a valid option that solves the objectproperty / dataproperty distinction in OWL

Future of JSON-LD WG in proposed new process

fantasai: Any questions about hte process?

<fantasai> r=fantasai on @direction :)

gkellogg: About CR, if we drop out of CR we can publish WG drafts, but we can also iterate in CR?

fantasai: CSS iterates within CR, it just takes longer. Right now CSS has the drafts we post to TR, and editors drafts
... 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
... still can't publish every week
... editors draft is up to date, TR gets published every 6+ months
... meaning people look at the drafts not TR, which is supposed to be a scratch space
... allow publication on the site ... it's not regressing, not adding brand new features, just fixing the issues that are being reported
... 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

ivan: How to decide which to choose?

fantasai: Lawyers don't like looking at things too often
... 6-24 months should be publishing a snapshot
... up to the WG as to exactly when
... some CRs don't get a lot of changes.
... 6-24 from any substantive change

ivan: when will it come into effect?

fantasai: will take effect Q2 of 2020, or so

ralph: the question you just asked Elika is "when will there be process 2020?", and elika guesses Q2

ivan: we're chartered until June

fantasai: If you don't get to TR and get an extension...
... we get rechartered every two years as well
... for what changes, nothing unless you want to update more frequently

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
... the question is what to do after that
... the recommendation we might suppose we have 1 or 2 more features that the community wants to add . Not to redo the whole thing
... we thought everything was good until yesterday until @direction came along
... in a year from now we have a rec published, but there's a new feature ... today we have to recharter from A-Z
... is that easier? And if so how?

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
... good to have recs spawn other recs without the whole dance, just start at CR
... shortcut around a lot of the process for the feature addition
... to publish a .1 release or whatever
... that's the feedback at tpac
... 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
... still need to recharter
... as need a WG

ivan: How to recharter then? If we recharter in a year?
... if there's nothing else happening, then is it a valid charter?

fantasai: Don't think anything defines what is a valid charter
... if that's the kind of charter we want to have, we can discuss that
... could wait until there are feature requests coming in

ivan: charters take 3 or 4 months today.
... 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
... we want to add one feature, say direction, so 3 months for administration of a very short wg

<Zakim> azaroth, you wanted to discuss WG

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
... now with this process we bring back dormant WGs

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
... here's our errata from the last year, boot up the WG, get the official okay and then shut down again
... prefer the maintenance WG thing as lots of administration
... sends the wrong signals ... news goes out that XML is closed at the w3c
... other WGs like annotation. Shipped and people came up and said "is everything okay? the WG closed?!"

fantasai: "concluded" rather than "closed" in the press release?
... satisfied the charter

ivan: Maintenance issue stands

bigbluehat: undulating CG /WG thing would get old fast for administration

gkellogg: a better relationship for the sine wave

Ralph: Ivan made a good point. Pendulum has swung back and forth
... now we realize we need CSS WG for ever

<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.

manu: VC WG in discussion about maintenance mode
... credentials CG, and VC WG. WG has declared success, going into maintenance mode. Continuation of the IPR policy

<scribe> ... new features in CG won't have IPR

UNKNOWN_SPEAKER: 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
... staff contact goes down to 0.05 or whatever
... only thing is that chairs can veto things that come in
... but did not want members with lots of additions to be able to short circuit it
... don't want to say closed, but also doesn't take up resources
... helps the community keep the spec current
... bugs and errata could be fixed, new features with the new process would be good
... would that model work for JSON-LD ?
... concern is addition of new features to the point where only a few people can ever implement it

fantasai: not a question for my time on the AB
... working on streamlining the process for WGs
... putting errata in is a lot of work
... but chartering hasn't come up, but seems like a problem
... some kind of maintenance status charter is appropriate
... minor feature is interesting one. How to decide if something is minor
... a maintenance WG process?

Ralph: Lowercase p process issue
... CSS is constant, other groups don't know when the next big thing is coming

fantasai: Charter to do maintenance rather than adding new features without a recharter / amendment
... if new features come in that are good ideas you amend the charter for specific features

Ralph: have the machinery but not necessarily the will to do this

fantasai: Either about Process or just communication. Not charter maintenance groups to do new work, without amendment and review

<Zakim> gkellogg, you wanted to ask about process for registray/namespace documents

fantasai: that might be acceptable

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
... policies and tooling would be good
... 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
... makes the 1.1 update feel like a BIG update
... if CSS was only updated every 5 years, it would overwhelm the community too
... an official relationship between CG and WG for that purpose
... of new features
... Registries. They're a different process ... they live in TR?

fantasai: yes

gkellogg: Similar to namespace documents. rdf ontology lives in ns/
... groups keep documents there. Should we start using something else for namespaces?

fantasai: Had a number of groups asking for registries
... they have some normative status
... they work around it by going through the whole REC track process but then updates are very painful
... in a lot of cases if there's no IPR, then some go to notes
... then we update when we want
... others don't know, so just put it in a wiki
... in terms of groups that need IPR, then it needs the rec process.
... making it easier to edit will make it faster, but at least 70 days for anything for exclusions and ip review
... so 2-3 months at least
... for things that need more frequent updates, no restriction on notes at all. Registry needs a little bit more official
... can't change the process, can't change the columns, can only add new entries in the table
... sometimes just collision management
... othertimes it needs to be validated
... e.g. to detect duplicates
... Process is that you can edit what you want, so long as it follows the process defined in the registry

gkellogg: impelemtnation reports are there to get CR
... other people want to be part of the report later

bigbluehat: good for community

gkellogg: linked from the spec

fantasai: not really a registry?

gkellogg: test suite fixes

Ralph: incentive to implement in CR too

<scribe> ... 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

UNKNOWN_SPEAKER: a WG note can come with an update policy
... 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
... people wanted another name for it

fantasai: there's a bit more process on it
... can only be updated by the WG. WG doesn't necessarily want o maintain the registry
... separate process in order to delegate the maintenance to a CG or the team or something else
... as long as they follow the rules, it gets updated on TR without a WG

Ralph: argued that if the WG stops, the team gets to update notes, which they could delegate to someone else
... CG transitions. Good to have best practices. JSON-LD started as a WG, then CG, then a WG.
... annotation didn't start with a WG.
... write down what worked and what didn't as you've been through it twice
... don't understand it well enough to do it in Process

fantasai: send it to the process list

bigbluehat: happy about the registry process

Ralph: asked tag to write design templates a while ago. They punted to process CG.

<fantasai> https://lists.w3.org/Archives/Public/public-w3process/

break

<fantasai> Thanks everyone!

<gkellogg> scribe+

Direction ... part 4

<gkellogg> azaroth: We agreed in the AM that we want a processor option, which defaults to drop the direction.

<ivan> a viable option, too

<gkellogg> ivan: The datatype version (familiy of language datatypes) is one of the options I enumerated.

<gkellogg> … 2.1.2.1.2 createa an ugly but valid datatype to describe language and direction #XX_YY.

<gkellogg> ivan: This wouldn’t be used in JSON-LD, but in the resulting quad.

<gkellogg> … I know think this should be one option, and the other comound document

<gkellogg> bigbluehat: This is adding switching in from/to RDF algorithms. 1.0 did not actually have API entrypoints for this.

<gkellogg> … We could lower the bar for implementations by moving them into a separate interrace.

<gkellogg> pchampin: I advocate the datatype solution over the compound node.

<gkellogg> … The opt-in/out options would be different, but they would still be literals.

<gkellogg> … In SPARQL, STR(literal) still gives you the expected results.

<gkellogg> … Detecting these in the to/from algorithm would be easier and fewer corner-cases.

<gkellogg> … On the semantics side, I think the DT solution makes it easy to define semantic interopration with existing language tags (intersecting value spaces).

<gkellogg> … You could make interaction with existing lang-tagged strings smoother than as considering them as two different spieces of literals.

<gkellogg> ivan: We’re talking about 2.1.2.1.2 in the document.

<pchampin> https://w3c.github.io/rdf-dir-literal/#datatype-family

<gkellogg> azaroth: I wanted to disuss 2.1.1.2.

<gkellogg> … I think we could subclass rdf:langString to create rtl/ltr versions of that sub-type.

<gkellogg> … Guess not, given RDF spec.

<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.

<bigbluehat> section references come from https://w3c.github.io/rdf-dir-literal/#compound-literal

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)

+1

<bigbluehat> +1

<gkellogg> +1

<ivan> +1

<pchampin> +1

RESOLUTION: 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)

<gkellogg> bigbluehat: What if you have both bnodes and datatypes in an input? Could we convert them?

<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

<azaroth_> +1

<ivan> +1

<bigbluehat> +1

<gkellogg> +1

<gkellogg> For example `preserveDirection: enum(null, dt, combo, any)

<azaroth_> PROPOSAL: 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

<gkellogg> pchampin: I see this as an extension point, some may have more than two.

<ivan> +1

<bigbluehat> +1

<gkellogg> +1

<azaroth_> +1

<pchampin> +1

RESOLUTION: 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

<gkellogg> bigbluehat: Can we partition the RDF API?

<gkellogg> ack

fromRDF/toRDF status

<gkellogg> bigbluehat: These are different types of things which may be a barrior to implementation.

<gkellogg> pchampin: posts comic about HTTP range-14 being a challenging issue.

<gkellogg> bigbluehat: We may loose because of RDF, and may gain market share because we insist on RDF

<gkellogg> bigbluehat: The context fetching is also a controversial requirement.

<gkellogg> azaroth: I’m a -1; I understand the intent, but the audience is not those that will actually read the spec.

<gkellogg> bigbluehat: This revision makes more claims of RDF than 1.0 did, and people are comenting that this is a shift.

<gkellogg> azaroth: People said they liked to see the addition that RDF is not needed.

<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.

<gkellogg> … direction was already an issue, so was within the feature set.

<gkellogg> … Unless this is purely editorial, I’m against it.

<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”.

<gkellogg> … This allows people to subset better.

<gkellogg> … The partition excercise might be instrucive.

<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.

<gkellogg> … THis might make it less frightening.

<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

<gkellogg> … I’d like to do something with some core stuff, no fetching, HTML parsing, etc.

<Zakim> azaroth, you wanted to compare html processor levels and result

<gkellogg> ivan: It’s not normative or non-normative, they must be implemented in that way.

<gkellogg> azaroth: We already discussed proessor levels, we put them in, they were hated, we took them out.

<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.

<Zakim> manu, you wanted to provide a real world scenario where this would be helpful

<gkellogg> manu: We’re having a discussion with an implementer who thought they needed to implement everything.

<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.

<gkellogg> … I agree with gkellogg that it might be difficult to break out into layers.

<gkellogg> … The counter argument is that it would be nice to know if you have afullly conformant 1.1 processor.

<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.

<gkellogg> ivan: we have a conformance section.

<Zakim> azaroth, you wanted to close the queue :)

<gkellogg> azaroth: There is text in the document about processor classes already (conformance). It would be months of work to do anything else.

<gkellogg> bigbluehat: We signal that it’s hard because you must have something that gets and retrieves stuff.

Break for lunch

Issue json-ld-api#153, `@prefix` and keyword aliases

<ivan> API #153

<bigbluehat> azaroth: time to summarize for the minutes

<bigbluehat> ...we accept that issue 153 is an issue

<bigbluehat> gkellogg: a bug

<bigbluehat> azaroth: true. a bug

<bigbluehat> ...it should not in fact generate `@idfoo`

<bigbluehat> gkellogg: it should treat `id:foo` as an IRI

<bigbluehat> ...so the result of expanding should be `id:foo`

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

<bigbluehat> azaroth: so if there was an `@vocab` it would expand to that value + `id:foo`?

+1

<pchampin> +1

<bigbluehat> gkellogg: it won't be expanded as a relative URI because of the colon

<gkellogg> +1

<bigbluehat> +1

<simonstey> +1

RESOLUTION: 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

<bigbluehat> gkellogg: if there is an `id` term that's legit, and I see `@prefix: false`

<bigbluehat> ...it won't expand that because prefix is false

<scribe> ACTION: gkellogg to determine if `@prefix: false` will prevent the term from being used in expanding IRIs, and file an issue if it does

<bigbluehat> gkellogg: there's another issue about changing SHOULD's to MUST's for things that look like keywords

json-ld-syntax #260 -- Can terms start with an `@`

<ivan> Issue Syntax#260

<bigbluehat> gkellogg: what we're most worried about is other specs using `@` and we want them to be compatible with us

<bigbluehat> ...but at this point hopefully everyone's aware of our use of `@`

<bigbluehat> manu: what does changing it to MUST NOT buy us?

<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

<Zakim> azaroth, you wanted to ask about new information to reopen

<bigbluehat> Ralph: so, could you just say SHOULD NOT?

<bigbluehat> azaroth: it does

<bigbluehat> Ralph: ah, so you are leaving this open for future compatibility

<bigbluehat> gkellogg: and I think `@direction` is an example of why we want this

<bigbluehat> azaroth: there was an earlier issue which we closed about this

<bigbluehat> ...and it was mentioned that if we found new info we might reopen it

<bigbluehat> ...this seems like new infromation

<bigbluehat> gkellogg: so, some future `@direction` type thing could be setup to just disappear

<bigbluehat> azaroth: or attempt to turn into a crazy relative IRI

<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

<bigbluehat> gkellogg: authors should not use these keywords, but processors must ignore them

<manu> scribe: manu

<bigbluehat> ...but with a warning

<azaroth> PROPOSAL: Reopen w3c/json-ld-syntax#16 and require processors to ignore terms beginning with @ that are not defined keywords

<gkellogg> +1

+1

<azaroth> +1

<bigbluehat> +1

<simonstey> +1

<pchampin> +1

<ivan> +1

RESOLUTION: Reopen w3c/json-ld-syntax#16 and require processors to ignore terms beginning with @ that are not defined keywords

<ivan> Issue syntax#16

azaroth: Have we made this clear, it's resolved?

gkellogg: Yes, the editors need to do their thing now.

azaroth: so we'll close #260 in favor of opening #16.

w3c/json-ld-syntax#259 - @vocab and keywords

azaroth: propose that we can close #259, is this errata to JSON-LD 1.0?

gkellogg: it's not

azaroth: Ok, this will remain a bug with 1.0 processors, they should update and do the 1.1 process for this particular feature.

<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

<azaroth> +1

<ivan> +1

+1

<pchampin> +1

<simonstey> +1

<gkellogg> +1

<bigbluehat> +1

RESOLUTION: Close w3c/json-ld-syntax#259 as we can't fix 1.0, and 1.1 will be solved by newly reopened #16

w3c/json-ld-syntax#257 typed values

azaroth: Moving on to #257...

<ivan> issue syntax#257

bigbluehat: It's probably reducible to an editorial thing in a best practices document.
... 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.

gkellogg: If you run it through a linter...

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.

ivan: RDF doesn't do those things either, you can have values w/ datatypes, which is wrong.

bigbluehat: so, you can say it's best practices stuff
... The CG could address this, these are the kinds of things that we need to address w/ the community

gkellogg: A different example, instead of a string it's an xsd:datetime, that's valid -

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.

azaroth: If you push this through to RDF, you'll get the right thing back out.

gkellogg: well, if it's xsd:string, you will get that, but if it's "boolean" you will.
... 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.

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...

azaroth: We should transfer this issue to best practices...

bigbluehat: my confusion is about expanded form vs. compact
... if name had ex: in front of it, it wouldn't show up...

<azaroth> PROPOSAL: Transfer w3c/json-ld-syntax#257 to best practices document

gkellogg: no, it would show up, it's an IRI

<azaroth> +1

<gkellogg> +1

<bigbluehat> +1

<simonstey> +1

manu: +1

<pchampin> +1

<ivan> +1

RESOLUTION: Transfer w3c/json-ld-syntax#257 to best practices document

bigbluehat: if if if if if

<bigbluehat> {"name": true}

bigbluehat: That doesn't survive

gkellogg: The later one isn't absolute IRI... the previous is
... This might be why manu keeps saying compact IRIs were a mistake

bigbluehat: It means you have a bit of a rosetta stone w/ @context.

azaroth: That's all of the open issues, except for the loads of editorial issues.
... The framing stuff has no more issues either.

w3c/json-ld-syntax#108

<bigbluehat> manu: this is an awareness opportunity

<bigbluehat> azaroth: so from our side, we've pointed to DocumentLoader as the thing that makes the loading stuff work

<bigbluehat> ...whatever the format, type, etc of the IRI

<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

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.
... 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.

<bigbluehat> manu: the thing I don't know is anyone circling a solution?

<bigbluehat> ...we're strongly pushing the hashlink spec as an option for DID and VCWG stuff

<bigbluehat> ...for VC's bad things happen if your context changes

<bigbluehat> ...and in our specs, we make the promise that this context will never change

<bigbluehat> ...so you download it and put it into your code

<bigbluehat> ...but that doesn't address extensions

<bigbluehat> ...which need something like hashlink

<bigbluehat> manu: all you can do with SRI is to find out you got something you didn't want

<bigbluehat> ...and it requires infrastructure to be setup, etc.

<bigbluehat> ...there are two parts of this

<bigbluehat> ...in the future we'd like to settle on hashlink as the primary way--in our communities

<ivan> guests+ danbri

<bigbluehat> manu: [demoing hashlink]

<Zakim> azaroth_, you wanted to discuss rfc7089

<danbri> manu, is there a github repo for the conversation you mentioned with J Yasskin?

CR status and timeline

Attribution

<bigbluehat> group: [discussing how best to give credit where due in the specs]

<bigbluehat> gkellogg: I think we should add dlongley

<bigbluehat> ...to all the 1.1 specs

<gkellogg> https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords

<bigbluehat> ...we should add him in position 3 on Syntax after pchampin

<bigbluehat> ...to both v1.0 and v1.1

<bigbluehat> ...in both versions of the API spec, we'd add dlongley in position 2

<bigbluehat> ...and in Framing, dlongley would be in position 1

<bigbluehat> ...and he'd be removed as a "former editor" section

<bigbluehat> ...and we should look back through commit amounts to consider afresh our list of additional editors

<bigbluehat> ...and maybe we should add pchampin to the API spec

<bigbluehat> pchampin: yeah, I did add the folding, but I'd be happy to complete it since we recently decided to do it

<bigbluehat> ...and the ordering on API sounds fine

<bigbluehat> gkellogg: and we should remove editors from acknowledgements and remix that as needed

<Zakim> manu, you wanted to discuss CBOR-LD

<bigbluehat> bigbluehat: we could also move some of this note work into the CG

<bigbluehat> ...just so we don't over promise or underdeliver

<bigbluehat> manu: we do have folks interested in CBOR-LD

<bigbluehat> ...and we've been digging into how to minimize it/simplify the storage

<bigbluehat> ...and we've gotten URIs into single byte storage

<bigbluehat> ...it's fantastically efficient when you do that

<bigbluehat> ...so you can get the document way smaller than even with gzip, etc.

<bigbluehat> danbri: so, we could do this with schema.org's context file?

<bigbluehat> manu: yeah, it would work great for that

<bigbluehat> ...the other amazing thing with CBOR-LD, if you do data normalization

<bigbluehat> ...you can do a binary comparison

<bigbluehat> ...via templates

<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)

<bigbluehat> gkellogg: as long as you avoid blank nodes?

<bigbluehat> manu: ...yes...and if you do this well, it's way more compact than any linked data representation currently in use

<bigbluehat> ...and it doesn't need to be base64'd

<bigbluehat> ...and you don't need JSON Schema on it

<bigbluehat> ...and you can sign it

<bigbluehat> ...there's some really interesting stuff there

<bigbluehat> ...people processing an enormous amount of data can benefit

<bigbluehat> ...and super tiny stuff benefits as well

<bigbluehat> pchampin: I did contact a few people in the WoT WG

<bigbluehat> ...and they sent me to someone else in the JSON-LD WG who's also in a WoT project that we are starting

<bigbluehat> ...and he's OK to contribute to a Note

<azaroth> Victor Charpenay

<bigbluehat> ...some of this work he's shown in the W3C is very similar to what manu mentioned

<bigbluehat> ...much of it around compact IRI's in CBOR

<bigbluehat> ...so I have a call setup with him next monday

<scribe> scribe: 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

bigbluehat: is there anything you want to discuss, danbri?

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.

bigbluehat: Are there any explicit asks for us to build that bridge?

<bigbluehat> manu: so, the VC WG and DID WG's have basically said, you don't need to do JSON-LD processing

<bigbluehat> ...all you need to do is JSON processing focused on a few keys/things mentioned in the spec

<bigbluehat> danbri: can you say that some but not all profiles

<bigbluehat> ...and there's some history with the CSV WG

<bigbluehat> gkellogg: there is a range of groups attempting to solve for this though

<bigbluehat> ...you can require the context URL...or a specific context file

<bigbluehat> ...schema.org's a bit more elaborate than most of these though

<bigbluehat> ...but the solution's the same or similar

<bigbluehat> ...you state the place in the `@context` space where it must go

<bigbluehat> danbri: we want to be full fruited JSON-LD or whatever

<bigbluehat> ...and we've done this a bit with Wiki Data for instance

<bigbluehat> ...so you start with a schema:Person...and then describe more

<bigbluehat> ...the point being that any use of the JSON-LD context implies...

<bigbluehat> gkellogg: you just require the `@context` include schema.org

<bigbluehat> ...but if you don't actually use the context, then you miss out on the extensibility points

<bigbluehat> ...but you still wouldn't depend on processing the context

<bigbluehat> ...I'm agreeing with manu that what schema.org wants to do is very much like all the other groups wants to do

<bigbluehat> ...and what we really need is some best practices for JSON-LD in "pure" JSON processing contexts

<bigbluehat> danbri: it's tricky because we want to be able to be mixed with other vocabs

<bigbluehat> manu: yeah, you get that with this approach

<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.

<bigbluehat> ...you just have to be sure the schema.org is in there somewhere

<bigbluehat> ivan: loads of groups are doing this

<bigbluehat> ...and in publishing's case we're using schema.org explicitly

<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

<bigbluehat> ...if you want to do more complex stuff, then you might make it harder to process

<bigbluehat> ...but the basics usually get picked up

<azaroth> the IIIF docs: https://iiif.io/api/presentation/3.0/#46-linked-data-context-and-extensions

<bigbluehat> ...we call it a fixed shape

<bigbluehat> ...tnx to bigbluehat

<bigbluehat> ...but you are right that it is not documented

<bigbluehat> ...and it's on us to do that

<bigbluehat> danbri: that would be very helpful

<bigbluehat> manu: I'm wondering if it's a different conformance class

<bigbluehat> danbri: that would be nice

<bigbluehat> gkellogg: or at least a way to describe that there is additional restrictions

<bigbluehat> ivan: what happens if you want a specific shape of JSON

<bigbluehat> ...that can be used for JSON-LD

<bigbluehat> ...for the LD fans

<pchampin> we already have a little of that in the `@protected` section

<pchampin> but this could do with more details

<bigbluehat> danbri: many of these won't ever got get contexts from anywhere

<bigbluehat> manu: this approach allows exactly that

<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

<bigbluehat> ...then you could call that requirement out lots of places

<bigbluehat> danbri: so it would just be a free form chunk of text explaining it

<bigbluehat> gkellogg: so best practices might spell out how you could do all that

<bigbluehat> ...this application requires a specific shape

<bigbluehat> ...so no further contexts would be processed

<danbri> possibly nearby: https://www.w3.org/2017/dxwg/wiki/Main_Page#Profiles

<bigbluehat> ...but you'd still get the date from the one you want-- and require it matches the shape

CR

<azaroth> CR prereqs

<azaroth> Privacy and I18n are good

<azaroth> Not heard from a11y or security at all, but have pinged several times

<azaroth> question about IANA registration of profiles as to when they are required

<azaroth> have asked PLH about Process details

<azaroth> No formal objections

<bigbluehat> a11y review request URL https://lists.w3.org/Archives/Public/public-apa/2019Sep/0025.html

<azaroth> features at risk

<azaroth> defined one today

<azaroth> currently?

<azaroth> tried to use it incorrectly

<azaroth> gkellogg: Framing has one

<azaroth> ivan: will need a list

<azaroth> ... patent disclosures - no problem

<azaroth> gkellogg: json canonicalization scheme -- should keep it

<azaroth> ivan: implementation information

<azaroth> ... document exactly what our exit criteria are

<azaroth> ... what do we expect and how to document it

<azaroth> ... do we have that?

<azaroth> azaroth: no

<azaroth> ivan: a good time to define that

<azaroth> ... clearly described, in a separate document

<azaroth> ... should discuss it

<azaroth> ... have example for evaluation form etc. from gregg

<azaroth> ... dates are up to us

<azaroth> azaroth: baseline

<scribe> scribe: manu

ivan: What was official exit criteria for VCWG?

<azaroth> azaroth: is there any advantage to having a higher barrier to exit CR than the minimum

manu: two independent implementations of each feature, where each feature is defined by a unit test.

ivan: What do we test?

gkellogg: Every feature, essentially.
... Many tests will test the same feature
... for example, testing framing also tests expansion.

ivan: The reason I'm saying this is because I can't put this together myself... I need all this text.
... We will have a proper description on 1.0 vs 1.1 in the testing.

gkellogg: We mark every 1.1 test as 1.1

ivan: I need a clear description of all of this.

gkellogg: My report to you will have that in there.

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?

gkellogg: once we've created a recommendation, something may fail that doesn't take the relevant spec out of rec... that's history.
... 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.
... Eratta can be marked inline now... well, soon... 2020 process update.
... By the time we need to add errata, it'll be ready

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?
... Or, we'll need 2 impls for each feature and at least 1 complete implementation.

gkellogg: Why do we want to impose those requirements?

ivan: because we are HARDCORE!!!! *throws chair across room*

<pchampin> that would send the wrong signal, wrt what we discussed this morning: it is ok to be only partially compliant

gkellogg: We know we can meet that bar, by why set it higher than necessary?

ivan: If we say, look - this has been implemented by 3-4 independent implementations...

gkellogg: I'm not sure we want to say that..

ivan: If we say that to the outside world... 15 implementations, all complete.. it makes the case way stronger.
... Only two... that's the other end of the spectrum.

gkellogg: If we can get the Go, Java, and C++ folks... maybe Rust...

ivan: pchampin might do that

pchampin: uuuummmmmmmm...

ivan: Internally, we do try to get the bar higher, don't want to state that officially....
... When we get two, we can say we are done... we go to PR, we're done...
... 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

gkellogg: If we can see progress in more implementations, we should wait for them to appear.
... Yes, I'm doing Ruby, Python, and Javascript... we have to have Java, and we really should have C... and hopefully Go.

ivan: For wide review, do we have a list or feeling wrt. comments that came from outside of the group?

gkellogg: We can get that from issue list... have issues come in via email?

azaroth: Where would email have come into? I guess public, maybe we can check there.

ivan: Dependencies?

gkellogg: VCWG and schema.org

azaroth: We haven't interacted w/ schema.org, but have talked w/ danbri repeatedly...

gkellogg: We said we'd coordinate, we should reach out for comments.

ivan: We should send a note considering that we're feature freeze...

<azaroth> ACTION: azaroth to send email to schema.org CG when final WD pre CR is available for review

gkellogg: What about VCWG

manu: Charter ends at the end of this month, REC in early Oct.
... Might want to reach out to DID WG as well

ivan: Yes, can do that, reach out to those that exist...

<azaroth> Also to reference TAG issues

ivan: When do we need to send these communications out?

gkellogg: several weeks, editorial work should be done by then.

ivan: Would help to have all material together 2nd half of October.

<azaroth> ACTION: azaroth to instead send email to schema earlier

<azaroth> ACTION: ivan to set up empty wiki page with template for transition request to collect information

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.
... I will do that some time week.
... I think we're...

bigbluehat: say it... SAAAAY IT....

ivan: done.

gkellogg: we need some feature detection stuff... testing for that.

azaroth: we should wait to exit CR, then PR, then process train takes it down the track.

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.
... 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.

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.

ivan: No harm in leaving document in CR... maybe something will come up.

Other Work

ivan: What about the Primer, CBOR, YAML, Best Practice?

azaroth: What are the priorities?

gkellogg: Best Practices, we have to have that.
... Primer is... we should have that.
... The others are nice to haves.
... There is a non-overlapping set of people working on those things...

ivan: Who may publish it as a CG document.

bigbluehat: Can we transition them into a CG?
... if we don't publish in time?

ivan: If the CG picks up a document that's a NOTE, and puts it outside, no problem.

gkellogg: What if we do a maintenance WG?

ivan: We maintain the WG, we may copy certain notes... it's all possible.
... We want to concentrate on best practices...

azaroth: Adam signed up to work on the Best Practices / Primer ...

bigbluehat: I signed up for it, but neither Adam nor I have been able to do anything on it.
... Depends on if Adam and myself should push this forward, or leave it in CG and push it up...

gkellogg: Have the WG publish it, at the same time.

bigbluehat: The plan has, and still is, bring over everything in Best Practices document.

azaroth: So, we'll try to move Best Practices forward to a NOTE.
... We'll do this when we're in CR.

bigbluehat: There were conversations about combining JSON Schema and JSON-LD? Are we going to say something in Best Practices?

gkellogg: If we're going to talk about Profiles, then that's where it's appropriate.

azaroth: Who is the intended audience for the Best Practices document?

gkellogg: Publishers...

azaroth: So it should be Publishing Best Practices...

bigbluehat: Let's do one document, different sections for Publishers, and Developers.
... Should rename to JSON-LD Best Practices
... We should have sections for authoring, consuming, publishing...

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.

gkellogg: pchampin said he might have someone focused on CBOR...

ivan: We'd still have to go through the whole TR process....
... CBOR is interesting...

bigbluehat: If any of manu's claims are tenable... we might want to recharter to do that.

manu denies being a trustworthy source for rechartering criteria.

ivan: What we would have to do as a REC, it's not 2 years work...

bigbluehat: for the NOTE, it's important that we have a note that we say that are opportunities...
... when we come to charter the JSON-LD thing, we can point to the NOTE.

ivan: We just discussed this w/ fantasai, depends on what she and Ralph and the others think about that.
... Let's be optimistic, by the time we get to rechartering, Process 2020 may be in place...

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.

azaroth: I'm not convinced that NOTE is more powerful than CG document.

bigbluehat: if BP should be a note, CBOR thing should be a note.
... It's a signalling opportunity
... I'm saying, don't let it drift down to a CG... keep it in the WG>

ivan: We're all wildly in agreement, if possible, the CBOR stuff should happen.
... When should we think about rechartering?

gkellogg: Other than the CBOR stuff?
... Oh, you mean beside the rechartering for maintenance...

bigbluehat: We should do before end of year

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...

azaroth: Into AC by ...

ivan: mid-April
... On other hand, if there is a charter renewal going on... if we run out of Charter, W3M will extend.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/J Weily/John Wiley & Sons, Inc./
Succeeded: s/Saunders/Sanders/
Succeeded: s/Shipol/Schiphol/
FAILED: s/r21a/aphillips/
Succeeded: s/r12a/aphillips/
Succeeded: s/depict/detect is azeri/
Succeeded: s/@direction/@language/
Succeeded: s|WG| (7/*) WG|
Succeeded: s/we/SEO bots/
Succeeded: s/comfortable/?you are already comfortable/
Succeeded: s/foten/often/
Succeeded: s/You asked when will there be process 2020/the question you just asked Elika is "when will there be process 2020?"/
Succeeded: s/2.1.2.1.2/… 2.1.2.1.2/
Succeeded: s/RESOLVED/PROPOSAL/
Succeeded: s/@prefix/`@prefix`/
Succeeded: s/#153/json-ld-api#153/
Succeeded: s/Viktor/Victor/
Succeeded: s/in the WoT WG/in a WoT project that we are starting/

WARNING: Replacing list of attendees.
Old list: gkellogg bigbluehat pchampin ivan dlehn manu simonstey Bert chaals hadleybeeman Dan_Burnett DavidClarke sangwhan
New list: gkellogg ivan azaroth dlehn pchampin bigbluehat manu simonstey

Default Present: gkellogg, ivan, azaroth, dlehn, pchampin, bigbluehat, manu, simonstey
Present: gkellogg ivan azaroth dlehn pchampin bigbluehat manu simonstey Bert chaals hadleybeeman Dan_Burnett DavidClarke sangwhan rubensworks addison
Regrets: ivan
Found Scribe: manu
Inferring ScribeNick: manu
Found Scribe: manu
Inferring ScribeNick: manu
Found ScribeNick: bigbluehat
Found Scribe: manu
Inferring ScribeNick: manu
Found ScribeNick: azaroth
Found Scribe: manu
Inferring ScribeNick: manu
Found Scribe: manu
Inferring ScribeNick: manu
Found Scribe: manu
Inferring ScribeNick: manu
ScribeNicks: manu, bigbluehat, azaroth
Agenda: http://tinyurl.com/y34nfpfg
WARNING: Could not parse date.  Unknown month name "09": 2019-09-19
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: azaroth gkellogg ivan

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)