06:32:59 <RRSAgent> RRSAgent has joined #json-ld
06:32:59 <RRSAgent> logging to https://www.w3.org/2018/10/25-json-ld-irc
06:33:05 <Zakim> Zakim has joined #json-ld
06:33:10 <azaroth> zakim, this is json-ld
06:33:10 <Zakim> got it, azaroth
06:33:21 <azaroth> rrsagent, draft minutes
06:33:21 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/25-json-ld-minutes.html azaroth
06:33:28 <azaroth> rrsagent, set log public
06:33:42 <azaroth> Meeting: JSON-LD
06:33:51 <azaroth> Date: 2018-10-25
06:34:03 <azaroth> Chair: Rob_Sanderson, Benjamin_Young
06:34:15 <azaroth> Agenda: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#
06:34:23 <azaroth> azaroth has changed the topic to: F2F Agenda: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#
06:37:27 <pchampin> pchampin has joined #json-ld
06:37:31 <ivan> ivan has joined #json-ld
06:37:40 <paul> paul has joined #json-ld
06:37:44 <laudrain> laudrain has joined #json-ld
06:37:57 <ivan> present+
06:38:05 <azaroth> present+ Rob_Sanderson
06:38:19 <leonardr> leonardr has joined #json-ld
06:38:26 <leonardr> present+ Leonard
06:40:44 <laudrain> present+ Luc
06:44:18 <azaroth> scribenick: gkellogg
06:44:25 <bigbluehat> present+ Benjamin_Young
06:44:34 <arln> arln has joined #json-ld
06:44:44 <simonstey> present+
06:44:46 <ivan> present+ gkellogg
06:44:52 <gkellogg> gkellogg has joined #json-ld
06:45:00 <jyrossi> jyrossi has joined #json-ld
06:45:06 <gkellogg> present+ Gregg_Kellogg
06:45:11 <arln> present+
06:45:16 <jyrossi> present+ J-Y _Rossi
06:45:35 <gkellogg> ivan: Ivan Herman, I’m th W3C Staff Contact. I used to be Semantic Web activity lead, but not now.
06:46:09 <gkellogg> azaroth: Rob Sanderson from the J Paul Getty Trust. Co-char with Benjamin. Formerly with annotations.
06:46:24 <pchampin> present+ Pierre-Antoine Champin
06:46:31 <gkellogg> bigbluehat: benjamin Young with Wiely and sons, co-chari.
06:46:57 <azaroth> scribenick: azaroth
06:47:23 <ivan> scribejs, set pchampin Pierre-Antoine Champin
06:47:23 <azaroth> gkellogg: I'm Gregg Kellogg, have been on a number of groups, first was RDFA. Working on JSON-LD 1.0 in RDF 1.1, worked with Ivan on those and for CSV on the Web
06:47:59 <azaroth> ... an underutilized format for representing information in CSV. Co-chair on the JSON-LD CG where we pushed in some new features that we've inherited. Acting as only editor, hopefully can get someone else to come and help
06:48:03 <gkellogg> pchampin: Piere-Antoine Champin: formerly RDF WG, considering joining the group
06:48:04 <azaroth> scribenick: gkellogg
06:48:16 <ivan> scribejs, set jyrossi Jean-Yves Rossi
06:49:31 <ivan> scribejs, set laudrain Luc Audrain
06:49:35 <gkellogg> jyrossi: I’ve discovered the W3C 4 years ago. One of our R/D topics was rules and regulations and looked into RDF to navigate those rules. Different state members; we’ve been investing for the last 2 years arond this topic.
06:50:09 <gkellogg> arin: Antoin Roulin, working in the European legislation mapping.
06:50:38 <gkellogg> laudrain: chair in the machine activites in the W3C. Hear as an observer, for now.
06:50:48 <ivan> scribejs, set arin Antoine Roulin
06:51:18 <gkellogg> leonardr: Leonard Rosenthal at Adobe. I also serve as chair on ?? using JSON-LD. Also, Adobe using JSON-LD.
06:51:34 <laudrain> s/chair in the machine activities/co-chair of the publishing business group
06:51:36 <leonardr> s/??/XMP
06:52:03 <gkellogg> paul: Paul from XML5 forum in Korea, I’ve been in social web working group. I’m interested in introducing JSON-LD to Korean developers. This is my first time to join a F2F.
06:52:24 <bigbluehat> present+ ajs6f
06:52:33 <laudrain> s/chair in the machine activites/co-chair of the publishing business group/
06:52:40 <gkellogg> ajs6f: Adam Soroka from Apache, member of the WG.
06:52:55 <paul> present + paul
06:53:17 <simonstey> simonstey: Simon Steyskal, research scientist at Siemens Austria and also with Vienna University of Economics and Business together with Axel Polleres; prior to this WG I was part of the SHACL WG, ODRL WG and now also part of the Data Privacy Vocabulary CG
06:54:01 <ajs6f> ajs6f has joined #json-ld
06:54:05 <azaroth> agenda link: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#
06:54:11 <ajs6f> present+
06:54:36 <gkellogg> azaroth: We’ve tried to keep the sessions to 90 minutes and then have breaks along with everyone else.
06:54:56 <gkellogg> … We have 2 joint sessions, one from 11:30 with WoT who have slides.
06:55:43 <gkellogg> … The second is from tomorrow from 11:00-12:30 around profiles and content negotiation. There’s a best practice as using the context as a profile in the media type. They have a work item to standardize these things.
06:56:14 <gkellogg> … We’ve tried to front-load the complicated stuff until today, while we’re somewhat fresh.
06:56:36 <gkellogg> … Starting with the RDF issues that will set the stage for the other issues.
06:57:15 <azaroth> guiding principles: https://www.w3.org/2018/json-ld-wg/WorkMode/guiding_principles
06:58:18 <gkellogg> … The guiding principles are “stay on target”, prod/consumption of JSON-LD. Make it easy as possible for a wide-vaviety of developers to understand JSON-LD without having to understand RDF.
06:58:44 <gkellogg> … Require real use cases with actual data.
06:59:08 <gkellogg> … Require two supporters of each use case.
06:59:19 <ivan> present+ danbri
06:59:20 <bigbluehat> s/one from 11:30 with WoT who have slides/one from 15:30 with WoT who have slides/
06:59:48 <gkellogg> danbri: Dan Brickely, work for Google run schema.org project. Complain alot about JSON-LD but love it.
07:00:27 <gkellogg> azaroth: A single WG may bring an issue that thas multiple supporters within that WG.
07:00:37 <gkellogg> … Consistency is good.
07:01:06 <gkellogg> … Usability determined by end-users not developers. The serialized JSON should be as directly usable by users.
07:01:46 <gkellogg> danbri: there are Google engineers who write parsers, I don’t minde making them work. Publishers need to have it easy, becuase they use cookbooks.
07:02:06 <gkellogg> azaroth: there don’t need to be 100 parsers, but 100s of users that make use of it.
07:02:15 <gkellogg> … It should also be easy to produce the JSON.
07:02:32 <gkellogg> … Provide on-ramps. Barrior to entry should be low.
07:02:47 <danbri> danbri has joined #json-ld
07:03:00 <gkellogg> … Define success, not failure. Leave things open.
07:03:09 <gkellogg> … Follow exising standards and best practices.
07:03:45 <gkellogg> … New features should be compatible with the RDF data model. Althought 1.0 has a model which is a super-set, new features should be round-trippable through RDF.
07:03:58 <gkellogg> ajs6f: I don’t think people disagree with that.
07:04:19 <bigbluehat> q?
07:04:26 <gkellogg> azaroth: If we end up in a stalemate, we come back to the principles to try to resolve.
07:04:56 <gkellogg> danbri: I don’t see privacy, can you articulate that.
07:05:12 <gkellogg> ajs6f: It comes from other groups as well, such as WoT.
07:05:18 <azaroth> ACTION: azaroth to add privacy and horizontal review to guiding principles
07:05:25 <bigbluehat> q?
07:05:28 <gkellogg> danbri: I’m concerned about the remote context.
07:06:48 <azaroth> the direction issue: https://github.com/w3c/json-ld-syntax/issues/11
07:06:51 <gkellogg> ivan: It would be worth discussing language/direction issues as discussed in the Publishing WG. There, we will adtopt something more general. It doesn’t affect JSON-LD, although we’ll need to specify something someplace.
07:07:24 <bigbluehat> q?
07:07:41 <azaroth> TOPIC: JSON Syntax
07:07:58 <bigbluehat> SUB-TOPIC: https://github.com/w3c/json-ld-syntax/issues/37
07:08:05 <gkellogg> azaroth: the first block of issues is around JSON syntax vs JSON-LD.
07:08:25 <gkellogg> … obsoleting the use of blank nodes for properties.
07:08:31 <ivan> Subtopic: Consider obsoleting use of blank nodes for properties and "generalized RDF" #37
07:08:41 <ajs6f> scribenick: ajs6f
07:08:48 <ivan> link: https://github.com/w3c/json-ld-syntax/issues/37
07:09:28 <ajs6f> azaroth: we've discussed this and resolved it as accepted
07:09:50 <ajs6f> ... after which Manu objected, on the grounds that our charter does not permit us to deprecate extant features
07:09:57 <danbri> q+ to ask if this provides a way to qualify graph edges (in property graph style)
07:10:03 <ajs6f> ivan: I'd prefer to actually discuss this with Manu himself
07:10:33 <ajs6f> azaroth: Manu has delgated all the JSON-LD stuff to Dave Longley (who is not present at this time)
07:10:46 <ajs6f> ivan: we can close it again, but Manu will just reopen it again
07:10:47 <gkellogg> q+
07:11:09 <ajs6f> ... I believe that his justification was basically wrong
07:11:23 <bigbluehat> ack danbri
07:11:23 <Zakim> danbri, you wanted to ask if this provides a way to qualify graph edges (in property graph style)
07:11:59 <ajs6f> danbri: Can this be used for property graph -style usage
07:12:00 <ajs6f> ...
07:12:04 <bigbluehat> q+
07:12:13 <ajs6f> ... in which properties can have properties
07:12:18 <ajs6f> ... ?
07:12:39 <bigbluehat> ack gkellogg
07:12:42 <ajs6f> ivan: JSON-LD doesn't have that structure by itself, so you would have to rely on the RDF side, and it wouldn't be valid there.
07:13:02 <pchampin> q+
07:13:21 <ajs6f> gkellogg: If RDF supports that in the future (and work is ongoing there) and it was understood to be the correct way to do it, you could do it
07:13:53 <ajs6f> danbri: Wouldn't be good to take something out when in a year it might be very handy?
07:13:59 <azaroth> q?
07:14:04 <ivan> q+
07:14:50 <azaroth> ack bigbluehat
07:15:14 <ajs6f> leonardr: How do you define deprecation? In ISO, we say "Don't write it, but you can read it"
07:15:31 <ajs6f> ivan: There is a formal defn for deprecation at W3C, but we don't have it at our fingertips.
07:15:38 <ajs6f> ... we'll check into that
07:16:10 <ajs6f> gkellogg: One of the issues with deprecation is wrt to semantic versioning. 1.0 vs. 1.1 vs. 2.0. We're at 1.1, not 2.0.
07:17:18 <danbri> q+ to ask plans for <script type="application/ld+json"> and note the n-millions of domains using it
07:18:02 <ajs6f> ... we would still, by deprecating, be taking it out eventually, and Manu would probably object to that.
07:18:29 <ajs6f> ... I'd rather add descriptive notes using "SHOULD NOT" language
07:18:34 <azaroth> q?
07:19:10 <ajs6f> bigbluehat: I work on a graph system capable of provenance for each triple, but none of that survives into JSON-LD.
07:19:28 <ivan> q?
07:19:32 <bigbluehat> https://www.w3.org/Data/events/data-ws-2019/cfp.html
07:19:40 <azaroth> ack pchampin
07:19:44 <bigbluehat> ack pchampin
07:19:59 <ajs6f> ... we do need to address that, to make it possible for those systems to use JSON-LD
07:20:51 <bigbluehat> s/work on a graph system/work on a graph system, levelgraph.io/
07:21:37 <bigbluehat> ack ivan
07:21:38 <danbri> earlier literals as subjects discussion, https://www.w3.org/2001/sw/wiki/Literals_as_Subjects
07:21:56 <ajs6f> pchampin: Recently, some proposals have come out showing research into the "use bnodes to add properties to properties" technique And there are "spaces" in the SPARQL rec that allow, e.g. literals as subject. This is all generalized RDF, but is that the thing to which you want to round trip?
07:22:15 <gkellogg> q+
07:22:19 <ajs6f> ivan: property graphs are great, but this WG should not have an issue for encoding property graphs in JSON-LD
07:22:29 <ajs6f> ... that's a 2.0 thing.
07:22:49 <ajs6f> ... maybe in a year.
07:22:59 <danbri> for the record, property graphs have drivers for a lot of databases beyond neo4j
07:23:03 <ajs6f> ... but discussion now is very premature, not appropriate for this WG
07:23:47 <ajs6f> ... my problem with bnodes as properties is demonstrated by Manu's reaction: one is liable to believe that one has solved a problem when the solution is, in fact, wrong.
07:24:11 <danbri> http://tinkerpop.apache.org/ lists 24 graph data systems with some kind of property graph interface
07:24:14 <ajs6f> ... Manu is using the preservation of bnode labels from scope to scope as a feature.
07:24:23 <ajs6f> ... it's not. It's a particularity of some implementations.
07:25:00 <ajs6f> ... he's using a syntactical quirk as support to solve another problem.
07:25:15 <bigbluehat> q?
07:25:38 <ajs6f> ... usages of bnode-predicates is only possible within RDF/OWL in the most obscure and esoteric and private places
07:25:57 <ajs6f> ... certainly not a technique that anyone should be using, we should stick to what is in RDF
07:26:08 <bigbluehat> ack danbri
07:26:08 <Zakim> danbri, you wanted to ask plans for <script type="application/ld+json"> and note the n-millions of domains using it
07:26:22 <ajs6f> ... after the upcoming Berlin workshop, perhaps this could be discussed for 2.0, but not now.
07:26:57 <ajs6f> danbri: I am hearing the word "deprecate", and that is scary for something with the audience of Google.
07:27:19 <ivan> q?
07:27:45 <ajs6f> ... we could put versioning into resources we control (e.g. the schema.org context), but we won't do that if it's liable to irritate or confuse millions of people
07:28:04 <ajs6f> ... we don't use the bnode-property thing ourselves, at Google.
07:28:30 <ajs6f> ... but schema.org folks have real interest in qualifying graph edges, so if this could help with that...
07:28:37 <azaroth> q?
07:28:40 <ajs6f> ivan: there are other ways to do that
07:28:54 <ajs6f> danbri: that would be fine.
07:29:30 <bigbluehat> ack gkellogg
07:29:40 <ajs6f> danbri: we originally objected to the charter for this group, because we felt it was taking advantage of success for which  Google bore responsibility
07:29:55 <ajs6f> ... we don't want to injure our users!
07:30:17 <ajs6f> ivan: the CG would normally be the place where these things are discussed
07:30:26 <ajs6f> gkellogg: the CG is not very live now
07:30:57 <danbri> ajs6f, not so much taking advantage of, ... but justified in terms of. And the google-promoted schema.org rollout is powered by millions of sites who don't follow w3c latest developments religiously. It would unfortunate to start deprecating what they do, so quickly.
07:31:13 <ajs6f> ... I wouldn't want to cut off property graphs. let's put it on the side and deal with it at a later date
07:31:32 <bigbluehat> q?
07:31:46 <ajs6f> ... specifically after being informed by the upcoming workshop
07:32:03 <ajs6f> ... bnodes-as-properties was _not_ meant in support of property graphs
07:32:44 <bigbluehat> q+
07:32:46 <ajs6f> ... it was more about worries that demanding an IRI for every property would be a bridge too far for many developers.
07:33:13 <ajs6f> ... I suport Ivan's point that the use Manu suggests is technically wrong
07:33:55 <ajs6f> ... it's a bad idea. there is an expectation from users that labels won't change, but we don't want to reinforce that
07:33:56 <azaroth> q+ to ask about document relative IRIs
07:33:59 <pchampin> q+ to notice that '#' is usually a good candidate for replacing '_:'
07:34:39 <ajs6f> ivan: ironically, the canonicalization algorithm would change those labels anyway
07:35:23 <ajs6f> gkellogg: there are toggles for doing that, but usually people say that canonicalizaed datasets are text strings, not abstract syntax
07:35:40 <azaroth> ack bigbluehat
07:36:01 <pchampin> q-
07:36:29 <ajs6f> bigbluehat: This issue is for people who write contexts, not content (not instances), this is about a much smaller community than everyone who publishes JSON-LD
07:37:00 <ajs6f> ... the confusion that can result from bnode labels not being preserved does need to be recognized and dealt with
07:37:20 <bigbluehat> q?
07:37:26 <ajs6f> ... we need to make sure that people understand what's happening and why they need stable identifiers, perhaps in the forthcoming primer
07:37:43 <azaroth> ack azaroth
07:37:43 <Zakim> azaroth, you wanted to ask about document relative IRIs
07:37:44 <bigbluehat> ack azaroth
07:37:46 <ajs6f> ivan: we gave examples of this happening in the rec, and we shouldn't have done that
07:38:26 <ajs6f> azaroth: the original JSON-LD 1.0 use case would be covered by being able to use relative IRIs for @vocab
07:38:59 <mmocny> mmocny has joined #json-ld
07:39:08 <ajs6f> ... we should continue as we have chosen, using the term "obsolete" as HTML does-- to mean "you can use this, but conforming processors will throw a warning"
07:39:22 <ajs6f> ... and we can ask Manu and danbri whether this really is used in the wild.
07:39:29 <ajs6f> danbri: Pretty sure it isn't.
07:39:48 <ajs6f> ... but hard to say for sure.
07:39:57 <ajs6f> ivan: Should we close?
07:40:10 <ajs6f> danbri: We could put a "feature at risk" on it.
07:40:47 <ajs6f> gkellogg: That would be good because future people who aren't repressented in this discussion could object
07:41:04 <gkellogg> q+
07:41:47 <ajs6f> danbri: Can we adjust the language to not tell people they're WRONG, but that this has implications for what you can do with your JSON-LD?
07:41:55 <ajs6f> ivan: It is just _wrong_.
07:42:19 <ajs6f> bigbluehat: It may be wrong from a OWA perspective. "Culturally" wrong.
07:42:22 <bigbluehat> q+ to suggest we state it at risk and that we encourage other approaches
07:42:41 <ajs6f> gkellogg: We can't pretend that this was experimental. We didn't mark it as such.
07:43:02 <azaroth> PROPOSAL: Mark bnode as property as a Feature At-Risk for the next WD, with a view towards marking as Obsolete with a warning in 1.1
07:43:05 <ajs6f> ... there's  a good bit of explanatory text about this in 1.0. We could certainly remove that.
07:43:17 <bigbluehat> q-
07:43:21 <bigbluehat> ack gkellogg
07:44:05 <ajs6f> gkellogg: A suggested URN-based replacement for this would be good.
07:44:36 <azaroth> +1
07:44:45 <ajs6f> bigbluehat: URNs can be as fragile as bnodes, but there is a whole world of identifiers out there
07:45:03 <ivan> +1
07:45:04 <simonstey> +1
07:45:06 <bigbluehat> +1
07:45:10 <ajs6f> ivan: Every resolution is temporary for a week, so we can do this and still have discussion with Manu et al.
07:45:12 <gkellogg> +1
07:45:16 <paul> +1
07:45:30 <pchampin> +1
07:45:33 <ajs6f> +1
07:46:00 <laudrain> [abstain]
07:46:04 <danbri> +0.666_
07:46:12 <azaroth> RESOLVED: Mark bnode as property as a Feature At-Risk for the next WD, with a view towards marking as Obsolete with a warning in 1.1
07:46:54 <ajs6f> azaroth: Since we have danbri for now, let's move some relevant issues up from the afternoon
07:47:03 <ivan> subtopic: Introduce concept of "sealed” contexts #20
07:47:11 <ivan> link: https://github.com/w3c/json-ld-syntax/issues/20
07:48:15 <ajs6f> azaroth: the issue from my POV is that it would be nice to have a feature that let's context be "sealed" or "frozen"
07:48:31 <ajs6f> ... this lets people identify an immutable context
07:48:52 <ajs6f> ... this could prevent a huge amount of people retrieving context over the wire
07:48:54 <danbri> cf https://www.w3.org/RDF/Group/Schema/openissues.html#c12  "Closed 19980707 - deferred until 1.1; M+S to supply a mandatory extensions mechanism" ("We would like to define a mechanism for 'sealing' an RDF Class, so that it becomes illegal to make certain RDF statements involving it. This is loosly analagous to the notion of 'final' classes in Java / OO programming. ...")
07:49:16 <ajs6f> ... as well as preventing people from overriding term expansion
07:49:45 <ajs6f> ... since choosing an expansion is "last in wins"
07:49:54 <ajs6f> ivan and gkellogg: Those are two different issues!
07:50:25 <gkellogg> https://github.com/w3c/json-ld-syntax/issues/9
07:50:31 <bigbluehat> q+
07:50:40 <pchampin> q+
07:50:41 <ajs6f> azaroth: https://github.com/w3c/json-ld-syntax/issues/9 is the first part of what I was describing
07:50:50 <ajs6f> ... immutability
07:51:11 <bigbluehat> Immutable header https://tools.ietf.org/html/rfc8246
07:51:22 <ivan> q?
07:51:22 <gkellogg> q+
07:51:24 <ivan> q+
07:51:30 <ajs6f> ... I believe there is no argument about this being a good functionality-- the question is just, how do we do this in practice?
07:51:35 <ajs6f> ... is this an HTTP thing?
07:51:37 <leonardr> q+
07:51:46 <azaroth> ack bigbluehat
07:51:48 <ajs6f> ivan: We are overloading the term "frozen".
07:51:56 <ajs6f> danbri: Similar metaphors, but not the same.
07:52:40 <ajs6f> bigbluehat: There is an identifier-based approach, and for schema.org the semantics have changed
07:52:47 <ajs6f> ... over time
07:53:34 <ajs6f> danbri: well, it's always meant schema.org, but we have resolved it in different ways, because of the history
07:53:48 <ajs6f> ... we have just kept adding terms, and the context just keeps growing
07:54:04 <ajs6f> gkellogg: You might be able to pare it down with @vocab
07:54:08 <azaroth> q?
07:54:18 <ajs6f> danbri: It's rarely been the case that we don't have to touch it for a long period of time
07:54:43 <ajs6f> ... and there's constantly things to fix
07:55:10 <ajs6f> bigbluehat: That's the POV that this identfier will always get you the most up-to-date, "best" version of the resource
07:55:45 <ajs6f> ... but for the way I work, which uses separate context documents for differetn versions, would behave completely differently
07:56:13 <ajs6f> ... so one proposal is to bake version into the identifier, and another is to seal the context
07:57:04 <azaroth> ack pchampin
07:57:20 <ajs6f> danbri: Not too worried about that part of the problem: It's not inconceivable that we might maintain a couple of high-value vocabs, but much of schema.org isn't used now
07:58:00 <ajs6f> pchampin: Have to leave... I don't think the JSON-LD spec is the right place to solve the bnode-property question
07:58:13 <azaroth> ack gkellogg
07:58:17 <danbri> q+ to mention search vs iot usecases
07:58:28 <ajs6f> ... and for the sealed context question, another approach-- perhaps allow to specify import order and thereby prevent inappropriate overrides
07:58:54 <ajs6f> gkellogg: looking at the mechanism by which a processor can be encouraged to not contantly be fetching context,
07:59:11 <ajs6f> .... HTTP has cache-control, and we suggest using it, but that doesn't seeem to be enough.
07:59:20 <bigbluehat> q+
07:59:34 <ajs6f> ... so can we add some of the HTTP semantics right inside the context?
07:59:55 <ajs6f> ... e.g. "this is valid for this time, do not refetch within that time"
08:00:17 <ajs6f> ... processing tools could even throw on an inappropriate retrieval
08:00:24 <laudrain> q?
08:00:40 <laudrain> q+
08:00:49 <ajs6f> ... we'd also like to be able to "preload" contexts (prefill a cache).
08:01:14 <azaroth> ack ivan
08:01:14 <danbri> We are reliving the XML Catalog discussions from couple decades back, https://en.wikipedia.org/wiki/XML_catalog
08:01:49 <ajs6f> ivan: I am afraid of conneg and HTTP headers, which are great, BUT many users cannot control them
08:02:19 <ajs6f> ... relying on that is attractive to a spec, but may not be a good solution
08:02:44 <ajs6f> ... so gkellogg's suggest is uglier than relying on HTTP headers, but way more secure
08:03:03 <ajs6f> ... the schema.org example shows us that many context _cannot_ be sealed.
08:03:11 <azaroth> q?
08:03:20 <ajs6f> ... the "freezing" (no bad overrides) things-- I'm guilty of that myself
08:03:50 <ajs6f> ... we do that on top of schema.org
08:03:54 <ajs6f> danbri: We're fine with that!~
08:04:00 <azaroth> ack danbri
08:04:00 <Zakim> danbri, you wanted to mention search vs iot usecases
08:04:13 <azaroth> q+ danbri
08:04:16 <ajs6f> ivan: sealing a popular context could create problems for that
08:04:48 <ajs6f> danbri: Sure, we can do conneg. But it's frustrating as a vocab provider. For the rest of the site we are moving to pure static hosting.
08:04:59 <paul> +q
08:05:23 <azaroth> ack leonardr
08:05:37 <ajs6f> ... we would like our work as vocab providers to end with creating files
08:05:47 <hsolbrig> hsolbrig has joined #json-ld
08:06:08 <ajs6f> leonardr: Other vocabulary providers have a different approach. In our defns and vocabs, we have a policy that says
08:06:22 <ajs6f> ... once this is stable, any future version must be backwards-compatible
08:06:32 <ajs6f> ... can't remove fields, can't change value types, etc.
08:06:42 <ajs6f> ... in part because we didn't want to deal with versioning
08:06:57 <ajs6f> ... but we also maintain a registry, so at any time anyone can go and get a schema
08:07:19 <ajs6f> ... so we get some of the benefits (e.g. we don't have to do uneeded fetches)
08:07:28 <ajs6f> ... we don't have to worry about the versioning because of the policy
08:07:50 <azaroth> q?
08:07:59 <azaroth> ack danbri
08:08:14 <ajs6f> danbri: two things where I've been raising concerns around @context
08:08:26 <hsolbrig> present+ hsolbrig
08:08:36 <ajs6f> ... when you're a search engine, you may not have all the resources in hand at once
08:08:37 <azaroth> Welcome Harold :)
08:08:52 <ajs6f> ... also, @context doesn't work for IoT, where devices are resource-constrained
08:09:03 <ajs6f> ... they don't want to be fetching stuff across the network
08:09:20 <ajs6f> ... not sure whether "frozen" or "sealed" is the right metaphor
08:09:47 <ajs6f> ... but the assumption that fetching a @context is trivial isn't necessarirly a good one
08:10:14 <azaroth> q?
08:10:15 <ajs6f> ... 1.1 should not force many fetches, e.g. because of privacy concerns
08:10:31 <ajs6f> ivan: understood, but how do we avoid the problem?
08:10:46 <ajs6f> danbri: We shouldn't allow the difficulty of the problem to prevent us from facing it.
08:10:46 <leonardr> q+
08:11:05 <ajs6f> azaroth: We'll be talking to the IoT folks this afternoon.
08:11:21 <ajs6f> leonardr: Why (other than parsing) do you need to fetch contexts?
08:11:40 <ajs6f> others: Can't interpret the data at all w/o the context
08:11:55 <ajs6f> leonardr: Doesn't mean that you have to fetch it, does it?
08:12:36 <ajs6f> danbri: We ran into this with RDF/XML-- we forced you to put all the semantics into the instance. Made the syntax much disliked.
08:12:39 <azaroth> ack bigbluehat
08:12:44 <leonardr> q-
08:12:45 <bigbluehat> https://json-ld.org/spec/latest/json-ld-api-best-practices/#cache-context
08:12:45 <ivan> q+
08:12:50 <ajs6f> ... JSON-LD went the other way
08:13:08 <ajs6f> bigbluehat: There is to be a best-practice document, which can discuss these issues.
08:13:30 <ajs6f> ... the docs may say you can fetch all the time, but the tools understand how bad an idea that is.
08:13:30 <danbri> ajs6f, to be more explicit: it isn't even the semantics (in terms of the rdfs/owl model), it is very basic graph structure issues. Does "foo":"bar" expand to "bar" or http://..../bar URI
08:13:49 <azaroth> q+ to suggest an API cache function
08:14:18 <ajs6f> bigbluehat: I manually solve this problem, and it's sort of like what we would want
08:14:42 <ajs6f> ... but we haven't encouraged people to create workflows that are safe in that way
08:14:51 <danbri> q+ to ask if anyone here is engaged with https://github.com/WICG/webpackage ?
08:15:21 <azaroth> ack laudrain
08:15:32 <ajs6f> ... users don't necessairly even know that they should know HTTP at the depth needed for control caching
08:16:28 <hsolbrig> q+ to mention @context as document type identifier
08:19:01 <azaroth> ack paul
08:19:28 <ajs6f> laudrain: in Publishing, we are using JSON-LD to build metadata about books, and push it to webpages. We have, today, standards like ONIX, which are in use all over the world. But we know we have qualifications on our metadata. E.g. we might send a link to a cover image. When the book goes on sale, we might change the image to include the new price. We assume people refetch to get the updated image. It's a similar problem. It would be nice if we could provid[CUT]
08:19:33 <ajs6f>  azeroth: That's at a different level, the level of instances. They will always require refetching. That's not quite within our
08:19:58 <ajs6f> paul: Can someone define the term "sealed"?
08:20:05 <ajs6f> ... who makes that decision?
08:20:13 <ajs6f> azaroth: the publisher would decide that.
08:20:25 <ajs6f> ... that's the feature that prevents overrides.
08:20:42 <ajs6f> for the other feature (content-addressable contexts)...
08:21:05 <ajs6f> ... to the extent that we want to include HTTP-type features to control/prevent  fetching
08:21:32 <azaroth> q?
08:21:34 <ajs6f> ... What is the extent to which we should go, to make that easy for devs?
08:21:36 <azaroth> ack ivan
08:21:48 <ajs6f> ivan: there is an analogy that might inspire us
08:21:53 <danbri> In RDFS, W3C Working Draft 14 August 1998  https://www.w3.org/TR/1998/WD-rdf-schema-19980814/ we wrote  """"Since an RDF Schema URI unambiguously identifies a single version of a schema, RDF processors (and Web caches) should be able to safely store copies of RDF schema graphs for an indefinite period. The problems of RDF schema evolution share many characteristics with XML DTD version management and the general problem of Web resource versioning. Is is ex[CUT]
08:21:59 <ajs6f> ... it's like the way that CSS handles fonts
08:22:02 <danbri> "Is is expected that a general approach to these issues will presented in a future version of this document, in co-ordination with other W3C activities. Future versions of this document may also offer RDF specific guidelines: for example, describing how a schema could document its relationship to preceding versions.""""
08:22:17 <gkellogg> q+ to ask about TAG review of JSON-LD cache design
08:22:19 <ajs6f> ... they have an indirection. I define a font symbol, to which I can attach URIs or filenames
08:22:32 <ajs6f> ... the processor picks the first that is available.
08:23:10 <ajs6f> .... so e.g. I could perhaps make a list, with my file of schema.org first, then the network address.
08:23:48 <ajs6f> .... that's what CSS does-- they have the same problem (in their case huge font files)
08:24:24 <ajs6f> ... how could we shoehorn this into the syntax?
08:24:35 <azaroth> q?
08:24:37 <ajs6f> leonardr: You'd have to change the meaning of @context
08:24:52 <ajs6f> gkellogg: The fact that there is a practice in CSS is good.
08:25:00 <azaroth> ack gkellogg
08:25:00 <Zakim> gkellogg, you wanted to ask about TAG review of JSON-LD cache design
08:25:16 <pchampin> pchampin has joined #json-ld
08:25:20 <ajs6f> ... piggybacking on an existing pattern in CSS will make arch review easier
08:25:40 <azaroth> ack azaroth
08:25:40 <Zakim> azaroth, you wanted to suggest an API cache function
08:26:18 <danbri> ajs6f: it may be worth talking to the CSS folks to see how that feature is working out in practice
08:27:00 <bigbluehat> q?
08:27:17 <ajs6f> azaroth: Seems like something we could put into the API spec.
08:27:25 <ajs6f> ... if cache management was part of the API
08:27:38 <leonardr> q+
08:27:57 <ajs6f> ... as opposed to reimpling another document loader
08:28:13 <azaroth> ack leonardr
08:28:23 <ivan> -> https://www.w3.org/TR/css-fonts-3/#font-face-rule Font face rule in CSS
08:28:26 <azaroth> (queue closed)
08:28:41 <ajs6f> leonardr: The problem w/ putting it into the API is that you've got to think of the various devices on which it might run-- what about embedding devices, e.g.?
08:28:52 <azaroth> q?
08:28:59 <ajs6f> ... the API must be flexible enough to let clients control the amount of caching that takes place.
08:29:03 <azaroth> ack danbri
08:29:03 <Zakim> danbri, you wanted to ask if anyone here is engaged with https://github.com/WICG/webpackage ?
08:29:14 <simonstey> https://drafts.csswg.org/css-font-loading-3/ ?
08:29:21 <ajs6f> gkellogg: The API spec does permit that-- we only spec the relevant behavior
08:29:36 <ajs6f> ivan: There are some nice examples from the CSS doc abovelinked
08:30:01 <ajs6f> danbri: Is anyone here tracking the WebPacakging work?
08:30:22 <ajs6f> ... seems to address the problem of leaking URLs
08:30:30 <ajs6f> i.e. querys from Google
08:31:06 <ajs6f> ... it's also about what happens when you don't retrieve from the resource's identifier, but from somewhere else, which is the same problem
08:31:13 <azaroth> q?
08:31:29 <ajs6f> ... different timescales to cultural heritage, bu the same underlying problem!
08:31:46 <ajs6f> ivan: Yes, but IIUC not something to change in the spec
08:32:16 <ajs6f> bigbluehat: the thing that is "hiding" in the WebPackage is that you don't get the content from the content owner.
08:32:40 <ajs6f> ... there is no way to discover the webpackage from the live URL
08:33:41 <ajs6f> danbri: There are many ways to get content. How you get content is a different question from JSON-LD-- we don't have to solve it.
08:34:08 <ajs6f> ... we might look at this in terms of parser APIs. How do parsers report the timeliness of their operations?
08:34:34 <azaroth> ack hsolbrig
08:34:34 <Zakim> hsolbrig, you wanted to mention @context as document type identifier
08:34:36 <ajs6f> ... we might want to say that JSON-LD doesn't mandate the only parser APIs-- to create some space in which to expand/eplore
08:35:09 <ajs6f> ... I want the schema.org contexts to be available into the future...
08:35:13 <ivan> present+ hsolbrig
08:35:42 <ajs6f> hsolvig: The ShEx spec states that to be valid JSON ShEx, the context must have a _specific_ URI
08:35:54 <gkellogg> q+
08:36:11 <ajs6f> ... that muddles the identity of the operation with the identity of a resource involved therewith
08:36:16 <bigbluehat> ack gkellogg
08:36:21 <ajs6f> ... what do we do with contexts that may never resolves?
08:36:54 <ivan> guests+ ralph
08:36:57 <ajs6f> gkellogg: For ShEx on the web, we established a media type. Then we gave rules for that media type.
08:37:08 <danbri> hsolbrig, we lost you
08:38:06 <hsolbrig> I'm CDT
08:38:10 <ajs6f> azaroth: Seems like there's a general feeling that there are many possible solutions to this issue, and baking something into the specs might be shortsighted.
08:38:20 <bigbluehat> s/I'm CDT//
08:38:28 <danbri> the more I think about it, the more I like the idea of the poor parser just reporting what it did, weaknesses and all
08:38:42 <ajs6f> ivan: We could almost verbatim copy what CSS did
08:38:57 <ajs6f> gkellogg and leonardr: but that would break extant parsers
08:39:14 <ajs6f> ivan: No, we could add more syntax for this purpose, not change @context
08:39:26 <ajs6f> danbri: Who uses this
08:39:35 <ajs6f> ivan: Whoever publushes data.
08:39:54 <ajs6f> danbri: That's tens of millions of sites, thousands of which will be hacked....
08:40:31 <ajs6f> bigbluehat: it's different from fonts-- you have fallbacks in that case, and @context is more central to JSON-LD than fonts are to CSS
08:40:45 <ajs6f> azaroth et al: COFFEE!
09:03:58 <ivan> scribenick: leonardr
09:04:24 <leonardr> azaroth : we should take 15m to continue on the context addressable context to find a resolution/direction
09:04:41 <leonardr> ...it would be good to have a decision around the approach
09:04:43 <bigbluehat> s/context addressable/content addressable/
09:05:16 <leonardr> ...cache loading into the instance (eg. font-face), http-level info (in the context doc)
09:05:23 <leonardr> gkellogg : there is some precident on http changes
09:05:43 <leonardr> azaroth : or we can change things at the API level (since we have doc loading there)
09:06:15 <leonardr> ..so that library writers bear the cost
09:06:22 <leonardr> s/../...
09:07:10 <leonardr> gkellogg : one thing we coudl do is change the doc loader about how it looks for the context - eg. prescribe the specifics - as well as specific support for "side lookups"
09:07:38 <leonardr> ...that would lead to greater consistency
09:07:48 <leonardr> ...doc loading is in the specs
09:08:07 <bigbluehat> API spec area about Document Loading https://w3c.github.io/json-ld-api/#remote-document-and-context-retrieval
09:08:15 <leonardr> azaroth : can we promote (make more obvious) the doc loader in the API doc?
09:08:36 <bigbluehat> q?
09:08:37 <bigbluehat> q+
09:08:45 <leonardr> ...perhaps make it a top level item?
09:09:25 <leonardr> gkellogg : this comes back to best practice.  Algos described in API.
09:09:45 <leonardr> ...our practice has been to put a thin veneer over the APIs but didn't do that for doc loader.  But we could
09:10:05 <leonardr> ...there is a non-normative features section that we could also use.  (eg. "do it this way")
09:10:51 <leonardr> ...we could describe that sources of contexts may require excessing loading (etc.)
09:10:53 <bigbluehat> q?
09:11:02 <leonardr> ...what does WOT do?
09:11:15 <leonardr> azaroth : don't forget privacy/security
09:11:50 <azaroth> ack bigbluehat
09:11:52 <leonardr> gkellogg : there are things we expect them to do (from a syntax perspective), and they won't read the API doc
09:12:18 <leonardr> bigbluehat : the section "remote doc..." could easily be renamed.  (and I like everything y'all were saying)
09:12:52 <leonardr> ...also want to make sure we highlight the security./privacy stuff (not just about "remote")
09:12:59 <azaroth> q+
09:13:03 <leonardr> ...also a bunch of work in best practices to explain this.  (and nothing in syntax)
09:13:34 <leonardr> ajs6f : do we want to talk about other situations where we retrieve docs?  or is it just context?
09:14:18 <leonardr> gkellogg : there is also a section on expansion which talks about remote IRIs and documents.
09:14:32 <bigbluehat> q?
09:14:34 <leonardr> ajs6f : so maybe we should not just put this in terms of context
09:14:35 <bigbluehat> q+
09:15:10 <leonardr> gkellogg : but you migth not want the entire JSON-LD doc reloaded each time either, so cache-control would be useful there too.  (does this belong in the body)
09:15:21 <leonardr> bigbluehat : my data shouldn;'t be that smart (about caching)
09:15:41 <leonardr> azaroth : the data carries ontology and not necessary processing
09:16:32 <leonardr> ...to ivan's point about fallbacks.  Today there is a callback (which shoudln't need to change) and the list of things to retrieve (which we would)
09:17:00 <leonardr> ...unless there is a way for the doc loader to get a list of URLs to work from (in order of precedence)
09:17:26 <leonardr> ivan : I produce my data an want to publish it, and I have a local context file and will point to it first and then a remote version.
09:17:46 <leonardr> gkellogg : context-path/reference, it could interact with the doc loader
09:17:47 <bigbluehat> ack azaroth
09:17:53 <leonardr> ivan : but we need a syntax too
09:18:27 <leonardr> ajs6f : do the things got to an existing doc loader or do they find a doc loader?
09:18:58 <azaroth> q?
09:19:21 <azaroth> q+ to ask about data providers and local file contexts vs consuming applications
09:19:31 <leonardr> ...the doc loader is smarter
09:19:45 <leonardr> gkellogg : an array of strings is fairly simple to understand
09:20:05 <leonardr> ajs6f : but what if there are other policies that control the order the array is processed
09:20:07 <azaroth> ack bigbluehat
09:20:17 <azaroth> ack azaroth
09:20:17 <Zakim> azaroth, you wanted to ask about data providers and local file contexts vs consuming applications
09:20:18 <leonardr> gkellogg : we still have a year+ to figure otu details
09:20:28 <leonardr> bigbluehat : we need a proposal to work from
09:20:37 <leonardr> azaroth : question for ivan
09:21:05 <leonardr> ...in what situations would the data provider want to provide the "context set:" rather than the processor?
09:21:51 <leonardr> ivan : if I set up a WoT in my home, I have to manage them.  I might include a local copy of schema.org there to avoid them all having to reach outside the network.
09:22:01 <leonardr> gkellogg : but that's an http proxy
09:22:22 <leonardr> ivan : but it might also fall into caching model
09:22:45 <leonardr> gkellogg : webpacking and activity streams could also help to improve caching
09:23:30 <leonardr> ajs6f : even a refrigerator might have a filesystem where I know what the URLs on it are, so I can point to those as local cached copies
09:23:36 <bigbluehat> q?
09:23:57 <leonardr> azaroth : 15m done.
09:24:29 <leonardr> ...there is agreement that we want to promote the doc loader in the API spec into something more visible and point to it from other docs (esp. about privacy/security)
09:25:07 <leonardr> ...we have discussed the idea of "context list" (ordered lists of contexts) where the loader can try to find things from these multiple items
09:25:32 <leonardr> ...but we need requirements and use case to help understand what to specify and where to put it
09:25:48 <leonardr> ajs6f : also be sure to include the horizontal bits too
09:25:57 <leonardr> azaroth : do we need a resolution?
09:26:02 <leonardr> ivan : just leave it open
09:26:15 <leonardr> bigbluehat : can we take an action?
09:26:28 <leonardr> gkellogg : lets use some issue(s) to track ideas
09:26:39 <azaroth> ACTION: azaroth to create issues for ContextList and DocumentLoader editorial changes
09:26:57 <leonardr> azaroth : back to issue 20
09:27:06 <leonardr> ...sealed contexts
09:27:20 <gkellogg> q+
09:27:25 <leonardr> ...introduced in the CG by dave longley in June
09:27:42 <leonardr> dlongley_ - that's you
09:28:05 <bigbluehat> ack gkellogg
09:28:06 <azaroth> hey dlongley_ ... any chance you can come to talk about "sealed" contexts?
09:28:47 <leonardr> gkellogg : so the idea is that there is something in the context that says if a given context refers to something else that tries to override a known term
09:29:03 <azaroth> SUBTOPIC: unoverrideable (or "sealed") contexts
09:29:12 <leonardr> ...that there is a way to prevent the overriding (but w/o stopping processing)
09:29:16 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/20
09:29:31 <leonardr> ...one example, a context with a list of other contexts the others can't overrride
09:30:04 <pchampin> pchampin has joined #json-ld
09:30:15 <leonardr> ...how do we cause overriding to take place when you absolutely need to?  context:null?
09:30:25 <leonardr> ...scoped contexts should do the same thing
09:30:31 <leonardr> ivan : who would freeze the context?
09:30:37 <leonardr> gkellogg : author
09:30:49 <leonardr> ajs6f : perhaps to avoid caching problems?
09:30:54 <leonardr> gkellogg : but that's not what it means
09:31:08 <leonardr> ...but they do work together
09:31:24 <leonardr> ivan : there is somethign in my forgotten past that is making me unhappy about this
09:31:51 <leonardr> ajs6f : the use case that gkellogg mentioned is a good one
09:32:04 <bigbluehat> q+
09:32:14 <azaroth> q+ to question the nuclear option
09:32:15 <leonardr> ivan : once I have nulled things, I can do what I want anyway
09:33:00 <leonardr> ...for an example, when there is something mising in schema.org we eitehr come up with a our own term or we use a context to override
09:33:32 <leonardr> ...but it's not a very elegant solution, but it works and solves a need.
09:33:33 <azaroth> ack bigbluehat
09:33:43 <ajs6f> q+
09:34:00 <leonardr> gkellogg : but you could just as well solve it by creating a new term but then schema.org isn't going to recognize it
09:34:20 <leonardr> bigbluehat : the sealed context goes against compaction
09:34:27 <leonardr> gkellogg : no it does not.
09:35:01 <leonardr> bigbluehat : if you look on the playground this isn't what I see...so maybe there is a difference between spec and implementation?
09:35:20 <leonardr> gkellogg : the sealed context is relevant in expansion
09:35:32 <azaroth> q?
09:35:33 <leonardr> ...by treating the input as always being expanded
09:35:39 <azaroth> ack azaroth
09:35:39 <Zakim> azaroth, you wanted to question the nuclear option
09:35:45 <leonardr> ...also algos start from expanded form
09:35:58 <leonardr> azaroth : I want to question the nuclear option
09:36:31 <leonardr> ...if that is allowed, then why would that be useful instead of just specifying new context?
09:36:48 <leonardr> gkellogg : the reason to do it is that you don't want to inherit things outside your scope
09:37:10 <leonardr> azaroth : if have a context that wipes out all the previous ones, then everything form that point is known
09:37:20 <leonardr> gkellogg : you can also set a single term to null
09:37:31 <leonardr> ...as a way to undefine a single tyerm
09:37:35 <bigbluehat> q+ to suggest this idea is/was 200% about Linked Data Signature stability https://w3c-dvcg.github.io/ld-signatures/
09:37:52 <azaroth> ack ajs6f
09:38:41 <danbri> q+ to admit to not seeing v convincing deployment scenarios for sealing (wrt. schemaorg, Search in public Web, at least; maybe IoT too)
09:38:47 <leonardr> ajs6f : given ivan's example, where I want to change the value type of a known term...that is quite different from completely overriding a term with completely different semantics.
09:38:58 <leonardr> ...we should be sure that all use cases are addressed with the same solution
09:39:23 <leonardr> gkellogg : in the case of schema.org, we want to make it legimate to avoid loading contexts
09:39:35 <leonardr> danbri : and be sure to differentiate search from other cases
09:41:11 <azaroth> q?
09:41:14 <leonardr> gkellogg : verifyable claims wants sealed, but we're not sure why
09:41:14 <azaroth> ack bigbluehat
09:41:14 <Zakim> bigbluehat, you wanted to suggest this idea is/was 200% about Linked Data Signature stability https://w3c-dvcg.github.io/ld-signatures/
09:41:55 <leonardr> bigbluehat : VC relies on LD signatures, and sealing ensures that the output graph (which is what is signed) is always the same.
09:42:15 <leonardr> gkellogg :  but if they were defined in the scope of the client
09:42:18 <leonardr> ivan : which is why nuclear works
09:43:13 <leonardr> ...they need a controlled environment and so they want to ensure that any previous state doesn't impact the sig contexts
09:43:32 <leonardr> bigbluehat : but their user data goes lower and the sig is the higher tree
09:43:42 <leonardr> ....they are the first context not the last
09:43:55 <danbri> w.r.t. signature over this, there are some old experiments around signing *schemas* (links near https://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC/FOAF_Use_Case#Signed_RDF somewhere)
09:44:15 <leonardr> ajs6f : is this a real concern?
09:44:54 <bigbluehat> q+
09:44:54 <ajs6f> ajs6f: actually thinks this _is_ real, just ? whether sealed contexts can fix it
09:44:59 <leonardr> gkellogg : yes, if you could somehow (maliciously) change the context earlier on, then all breaks down
09:45:25 <azaroth> ack danbri
09:45:25 <Zakim> danbri, you wanted to admit to not seeing v convincing deployment scenarios for sealing (wrt. schemaorg, Search in public Web, at least; maybe IoT too)
09:45:42 <leonardr> danbri : this could introduce some serious problems with nuclear overriding needed things
09:46:02 <leonardr> danbri : not feeling it.  this doesn't seem to align with the rest of the web and its use of JSON-LD
09:46:29 <leonardr> ivan : this seems to be useful from the security/sig concerns
09:46:42 <leonardr> bigbluehat : but if you expanded everything then you wouldn't have the problem
09:47:08 <jyrossi_> jyrossi_ has joined #json-ld
09:47:08 <leonardr> ivan : but can I add signatures to a context?  verifying authenticity of a context
09:47:18 <leonardr> q+
09:47:19 <azaroth> ACTION: azaroth to create context signature issue, related to #20
09:47:21 <danbri> q?
09:47:56 <leonardr> gkellogg : if we have a signature on a given context, has integrity, etc. - but that's different from a new context
09:48:07 <leonardr> ajs6f : both could be valid or one/both could be malicious
09:48:18 <danbri> q+ to suggest that signing of HTML+JSON, HTML+Microdata, HTML+RDFa, HTML+SVG, CSS, Javascript, Typescript, WebAssembly, GLSL, blahblah ... should all have a common design
09:48:28 <leonardr> ivan : the whole thing is a security thing that has to be built on top of JSON-LD
09:48:43 <azaroth> ack bigbluehat
09:49:25 <leonardr> bigbluehat : since the people that wanted it aren;'t here, so let's not touch it right now.  If we get it wrong, it will make things worse
09:49:55 <leonardr> ...we need some use cases
09:50:01 <azaroth> ack leonardr
09:50:09 <azaroth> scribenick: azaroth
09:50:21 <azaroth> leonardr: If we're worried about signing things, we should do it consistently.
09:50:45 <azaroth> ... there's a mechanism in HTML to verify a linked resource - sub resource integrity - can we apply that there as well?
09:50:48 <bigbluehat> https://www.w3.org/TR/SRI/
09:50:54 <azaroth> ack danbri
09:50:54 <Zakim> danbri, you wanted to suggest that signing of HTML+JSON, HTML+Microdata, HTML+RDFa, HTML+SVG, CSS, Javascript, Typescript, WebAssembly, GLSL, blahblah ... should all have a common
09:50:55 <bigbluehat> https://w3c-dvcg.github.io/http-signatures/
09:50:56 <danbri> (there's some relationship between the subresource integrity and webpackging . that I don't totally understand)
09:50:57 <Zakim> ... design
09:51:02 <azaroth> scribenick: leonardr
09:51:06 <leonardr> leonardr: also resource integrity might be useful here as well
09:51:14 <leonardr> danbri : <reads his list of things>
09:51:26 <bigbluehat> https://github.com/WICG/webpackage
09:51:38 <leonardr> ...what happens when we come to a future TPAC and everyone has their own signatures :(
09:51:47 <bigbluehat> q+
09:51:53 <azaroth> q?
09:51:55 <leonardr> ...integrity and signatures isn't the scope of this group
09:52:08 <azaroth> ack bigbluehat
09:52:09 <leonardr> gkellogg : this seems like something for HTML or Web Platform
09:52:29 <azaroth> q?
09:52:38 <leonardr> bigbluehat : put some links in the chat for various other options
09:53:05 <leonardr> ...LD signatures might be part of DID but they are debating it there
09:53:17 <leonardr> ...so let's kick the can over to them and see what happens.
09:53:33 <bigbluehat> q+ ivan
09:53:35 <bigbluehat> ack ivan
09:54:05 <leonardr> ivan : that being said, SRI is so simple that we might consider how we could use it for contexts.
09:54:16 <leonardr> ...it certainly doesn't solve anything, but it would be useful
09:54:40 <leonardr> bigbluehat : the may be some issues about exactly what are you validating/checking.
09:55:05 <leonardr> ...there are some known issues, but we may be able to work around those with some specific info about JSON-LD
09:55:55 <leonardr> leonardr: SRI is just hashing a "binary stream"
09:56:09 <leonardr> q+
09:56:10 <gkellogg> q+
09:56:48 <leonardr> leonardr: we need an action item to create an issue around use of SRI
09:57:05 <leonardr> gkellogg : thinks we discussed this last TPAC
09:57:06 <pchampin> pchampin has joined #json-ld
09:57:47 <bigbluehat> q+ to mention https://tools.ietf.org/html/rfc6920 for whoever files this SRI issue
09:57:54 <leonardr> ivan : how would the syntax work?
09:57:59 <leonardr> gkellogg : yes, we'd have to work on that
09:58:43 <azaroth> PROPOSAL: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing
09:59:11 <bigbluehat> q?
09:59:15 <leonardr> q-
09:59:21 <leonardr> +1 to proposal
09:59:22 <ivan> +1
09:59:25 <azaroth> ack gkellogg
09:59:27 <azaroth> +1
09:59:33 <bigbluehat> +1
09:59:34 <ajs6f> +1
09:59:36 <azaroth> ack bigbluehat
09:59:36 <Zakim> bigbluehat, you wanted to mention https://tools.ietf.org/html/rfc6920 for whoever files this SRI issue
09:59:38 <gkellogg> +1
09:59:43 <bigbluehat> https://www.w3.org/TR/2014/WD-SRI-20140318/
10:00:16 <leonardr> bigbluehat : wanted to point out that RFC as well which is much better than the current SHA expression as used in SRI
10:00:18 <hsolbrig> +1
10:00:21 <azaroth> RESOLVED: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing
10:00:45 <azaroth> SUBTOPIC: What is 'base' for an embedded json-ld?
10:00:50 <leonardr> ...not our problem and lots of solutions
10:00:54 <simonstey> +1
10:01:36 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/23
10:02:36 <leonardr> azaroth : 23 is a long thread...
10:03:12 <leonardr> ivan : the reason it is relevant, so far embedded JSON in HTML is not standardized (non-normative section)
10:03:25 <leonardr> ...one thing to do is to make it nomative in HTML.   Great!
10:03:37 <leonardr> ...but what is the base URL for data in the JSON(-LD) portion
10:03:48 <azaroth> Previous resolution was:  https://github.com/w3c/json-ld-syntax/issues/23#issuecomment-424764186
10:03:50 <leonardr> ...simple solution is to say its the enclosing document
10:04:28 <leonardr> ...but the clean solution would be related to the base element from the HTML (" base URL of the HTML containing the script element must be used as a base for the JSON-LD snippet")
10:04:46 <leonardr> ...we don't care how it gets established, just that it is coming from the DOM (which is well defined)
10:05:06 <leonardr> ...downside is that a JSON-LD would also require an HTML parser
10:05:16 <leonardr> q+
10:05:23 <bigbluehat> scribenick: leonardr
10:05:24 <leonardr> scribenick: bigbluehat
10:05:45 <bigbluehat> ...do we do the simple version, which is not complete in my view
10:05:51 <bigbluehat> ...or do we do the full blown embedded version?
10:06:03 <bigbluehat> gkellogg: wasn't there some conflict in the HTML spec about data blocks?
10:06:06 <danbri> (allusion to https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags )
10:06:12 <bigbluehat> ivan: even if there is, it's up to them to sort it out
10:06:30 <azaroth> q?
10:06:37 <bigbluehat> ...whatever the base value in the DOM tells me what is the base value of the contained content
10:06:50 <bigbluehat> ...danbri since you are one of the biggest users of the embedded use case
10:06:55 <bigbluehat> ...we'd like your help to help us decide
10:07:01 <bigbluehat> q+
10:07:18 <bigbluehat> danbri: if you can help me find some simple cases, I'd be happy to run this through our parsers
10:07:21 <bigbluehat> ...and see how that goes
10:07:29 <azaroth> ack leonardr
10:07:32 <bigbluehat> ...we run ours through a headless browser for a few seconds
10:07:39 <bigbluehat> ...but that doesn't necessarily mean we're using the DOM
10:07:48 <bigbluehat> leonardr: so, there's using JSON-LD in any embedded context
10:07:59 <bigbluehat> ...and there's also the specific case of embedding in PDFs
10:08:03 <bigbluehat> ...and the same issue applies
10:08:10 <bigbluehat> ...so I think we need a consistent mechanism
10:08:23 <bigbluehat> ...so we need a way to understand how all base URIs are calculated
10:08:27 <bigbluehat> ...regardless of embedding
10:08:40 <bigbluehat> ...that said, I think ivan's suggestion that getting the base from the DOM is reasonable
10:08:49 <azaroth> q?
10:08:51 <azaroth> ack bigbluehat
10:08:53 <bigbluehat> scribenick: leonardr
10:09:23 <leonardr> bigbluehat : danbri I have run a few examples but the base isn't taken into account by the tools that I have available
10:09:35 <leonardr> gkellogg : is that true for RDFa?
10:09:44 <leonardr> bigbluehat : I don't believe so
10:10:03 <danbri> q+ to ask what we know of other inline script notation's behaviour w.r.t. bases
10:10:04 <leonardr> ...if I start with an HTML page, put in some JSON, and then try to resolve stuff and the base is wrong
10:10:24 <leonardr> ...but if we change it automatically, that could be a compatibility issue
10:10:43 <leonardr> ...I did some experiments to see how it would work
10:11:11 <azaroth> ack danbri
10:11:11 <Zakim> danbri, you wanted to ask what we know of other inline script notation's behaviour w.r.t. bases
10:11:12 <leonardr> ...it is a change to the past and complicates the present.
10:11:25 <gkellogg> q+ to ask about @lang
10:11:30 <leonardr> bigbluehat : we also have the email use case with a different base
10:11:55 <leonardr> ...MSFT has their own support in outlook for JSON-LD
10:12:09 <leonardr> danbri : are we aware of other uses cases for base in script?
10:12:13 <ivan> q+
10:12:22 <leonardr> scribenick: bigbluehat
10:12:24 <bigbluehat> scribenick: bigbluehat
10:12:41 <bigbluehat> gkellogg: turtle is defined as allowing to be expressed there
10:12:58 <bigbluehat> ...but it does not state anything about base
10:13:34 <bigbluehat> leonardr: the default type of script is JavaScript
10:13:44 <bigbluehat> ivan: turtle is underdefined as JSON-LD is
10:13:47 <bigbluehat> q+
10:14:00 <bigbluehat> ...we are in a sense the only one I know of where this issue arrises within a recommendation track manner
10:14:06 <bigbluehat> leonardr: what about CSS?
10:14:26 <bigbluehat> ...that calculates base using the DOM base
10:14:30 <azaroth> ack gkellogg
10:14:30 <Zakim> gkellogg, you wanted to ask about @lang
10:14:35 <bigbluehat> ivan: true,  but I have another
10:14:47 <bigbluehat> ...gkellogg help me out
10:14:58 <bigbluehat> ...isn't it correct that in RDFa that the base effects the results?
10:15:02 <bigbluehat> gkellogg: yes. or xml:base
10:15:11 <bigbluehat> ...but that is specifically within the HTML context
10:15:15 <bigbluehat> ...and microdata also
10:15:27 <azaroth> q+ to ask about least surprise
10:15:30 <bigbluehat> ivan: but that also means that if I look at it from schema.org
10:15:45 <azaroth> q?
10:15:56 <bigbluehat> ...then the RDFa and the JSON-LD can't inherit the same base
10:16:08 <bigbluehat> gkellogg: but it'd be the same situation with RDF/XML, etc.
10:16:13 <azaroth> ack ivan
10:16:29 <bigbluehat> ...and I'd wager that schema.org/search-engines are not in a place to support any of this right now
10:16:35 <bigbluehat> gkellogg: I'd like to bring up @lang
10:16:41 <bigbluehat> ...the element inherits a language
10:16:47 <bigbluehat> ...from the surrounding document
10:17:07 <bigbluehat> ...are their cases where that effects the CSS or other inlined non-markup content?
10:17:23 <bigbluehat> ...this is where we would say RDF syntax is clear
10:17:29 <bigbluehat> ...if it has a language, it's a string
10:17:32 <bigbluehat> ...and gets @lang
10:17:54 <bigbluehat> ...but that is explicitly running within the DOM
10:18:06 <bigbluehat> ivan: how these inherit is clearly defined in RDFa
10:18:11 <bigbluehat> ...here it's not defined and unclear
10:18:13 <azaroth> q?
10:18:26 <bigbluehat> ...but to the user there may be expectations about inheriting from the context
10:18:30 <bigbluehat> gkellogg: I guess my feeling is different
10:18:42 <bigbluehat> ...especially if you're using some sort of HTML editor
10:19:01 <bigbluehat> ...putting lang="jp" or whatever on the document does effect all the content in it--and would effect RDFa
10:19:15 <ajs6f> q+
10:19:18 <bigbluehat> ...but to put a code block in there, than now is effected by the language properties by where its embedded
10:19:22 <bigbluehat> ...to have that behavior change
10:19:35 <bigbluehat> ...if I process it raw, but now if I put it in an HTML document and process it there
10:19:39 <azaroth> ack bigbluehat
10:19:49 <bigbluehat> ...that would not meet peoples expectations
10:19:56 <leonardr> scribenick: leonardr
10:20:19 <leonardr> bigbluehat : people's expectations...at Wiley our goal is to create a single merged graph from a single publication
10:20:47 <leonardr> ...in none of this work, did anyone express a desire or interest to deal with either base or lang inheritance
10:21:11 <leonardr> ...because it is scary!!  It is so unclear as to the rules esp. when combining stuff from all other the place
10:21:17 <azaroth> q?
10:21:21 <leonardr> ...and no one would be happy!
10:21:59 <leonardr> ...in my CMS life, things come from all other place and get reused in various uses which may also be multiple languages and expectations aren;'t clear
10:22:06 <azaroth> ack azaroth
10:22:06 <Zakim> azaroth, you wanted to ask about least surprise
10:22:14 <ajs6f> q-
10:22:16 <leonardr> ...the way things work now is happily stupid
10:22:18 <bigbluehat> scribenick: bigbluehat
10:22:22 <bigbluehat> q?
10:22:25 <bigbluehat> ack azaroth
10:22:36 <bigbluehat> azaroth: I wanted to talk about "least surprise"
10:22:51 <bigbluehat> ...first danbri, I wanted to talk about microdata, rdfa, and json-ld in the same page
10:22:59 <bigbluehat> danbri: I wish we did
10:23:12 <bigbluehat> azaroth: so let's assume you do,  which of these proposals would you want?
10:23:22 <bigbluehat> ...do you want base/lang/etc mixed across all of them?
10:23:41 <bigbluehat> ...or is it type-local where the JSON-LD document must restate its own values for those?
10:24:02 <bigbluehat> danbri: so, I did a quick look around stackoverflow, etc.
10:24:16 <bigbluehat> ...well, they never say URI, but we know they mean it deep in their heart
10:24:47 <bigbluehat> ...so, if we were a bit more careful about specifying some of this it would be clearer for them
10:24:58 <bigbluehat> ...people do have a trend toward wanting to type less to get the same result
10:25:13 <bigbluehat> ...just as we were trying to get the near-twins microdata and RDFa to get along
10:25:18 <bigbluehat> ...then JSON-LD came along
10:25:32 <bigbluehat> ...one of the reasons publishers like JSON-LD is that you can inject different bits from everywhere
10:25:37 <bigbluehat> ...and it's kinda carnage
10:25:56 <bigbluehat> ...and a really fabulous HTML page written by the indieweb community could be amazing
10:26:09 <bigbluehat> ...and then you could inject some JSON-LD from whereever--however horible
10:26:16 <bigbluehat> ...but it wouldn't effect your beautiful HTML
10:26:23 <bigbluehat> ...and that leans it toward being a self-contained block
10:26:33 <bigbluehat> ...if you want to be explicit, put full URLs in
10:26:46 <bigbluehat> ...which you may at least want to do when your testing
10:26:49 <bigbluehat> q+
10:26:55 <ajs6f> q?
10:27:05 <bigbluehat> ivan: that's worse than what we propose
10:27:26 <bigbluehat> ...if the block is resolved against the URL of the document or from the base of a containing document
10:27:54 <bigbluehat> leonardr: for PDF in terms of how things work today
10:28:03 <bigbluehat> ...PDF derives it from those of HTML
10:28:10 <bigbluehat> ...if it's from a file system, it the URI from the file system
10:28:19 <bigbluehat> ...if it's from the Web, then it's that URL
10:28:25 <bigbluehat> ...from which it was served
10:28:35 <bigbluehat> ...if you fetched it with a script, then it's from that context
10:28:41 <bigbluehat> ...and it has it's own base tag
10:28:46 <bigbluehat> ...which works just as HTML's
10:28:54 <bigbluehat> ...embedded JSON-LD acts like a linked resource
10:29:04 <bigbluehat> ...so the base is the base of that thing--we don't inherit it from the parent document
10:29:12 <bigbluehat> ...not saying that's right or wrong
10:29:15 <bigbluehat> ...it's just how it is today
10:29:21 <azaroth> q?
10:29:22 <azaroth> ack bigbluehat
10:29:30 <bigbluehat> scribenick: ajs6f
10:29:33 <ajs6f> scribenick: ajs6f
10:30:08 <ajs6f> bigbluehat: There is no precedence for anything in HTML (e.g s script block) inheriting from the larger doc
10:30:44 <ajs6f> ... it may be interesting to explore that, but it's not a JSON-LD thing, it's a markup thing.
10:31:01 <ajs6f> ... HTML says, "Anything in a data block is just text content"
10:31:24 <ajs6f> danbri: Bound to mention WebComponents and custom elements here. In the same territory.
10:31:40 <ajs6f> ... JSON-LD could very well show up inside those guys
10:32:09 <ajs6f> ... suspicion is that they're using some kind of inheritance. If we don't do that here, convergence in time gets harder
10:32:43 <ajs6f> bigbluehat: WebComponents are different, the base is about "where is this running?" not "where is this downloaded?"
10:32:57 <ajs6f> ... they use the current page, now.
10:33:09 <ajs6f> ... Javascript modules might change this
10:33:35 <ajs6f> ... JS and HTML are really a unit now. It's a different relationship than between HTML and JSON-LD
10:33:52 <ajs6f> ivan: Perhaps this gets kicked up to TAG?
10:34:03 <ajs6f> ... this is a Web Architecture issue.
10:34:15 <ajs6f> bigbluehat: Okay to punt!
10:34:20 <ajs6f> gkellogg: That's what they are for.
10:34:26 <danbri> see https://developers.google.com/web/updates/2015/03/creating-semantic-sites-with-web-components-and-jsonld for some experiments from Google a few years back, exploring some of the schema/jsonld/webcomponents possibilities.
10:34:59 <bigbluehat> https://www.w3.org/TR/html5/semantics-scripting.html#data-block
10:35:17 <ajs6f> ivan: We have to answer this qustion to make embedded JSON-LD normative
10:35:27 <azaroth> PROPOSAL: Defer and kick up to the TAG for comment as to a view from the web architecture perspective
10:35:27 <ajs6f> ... and the HTML spec doesn't answer this qquestion
10:35:41 <ajs6f> +1
10:35:43 <azaroth> +1
10:35:44 <simonstey> +1
10:35:46 <gkellogg> +1
10:35:47 <leonardr> +1
10:35:52 <ivan> +1
10:36:24 <hsolbrig> +1
10:36:59 <azaroth> RESOLVED: Defer and kick up to the TAG for comment as to a view from the web architecture perspective
10:37:03 <bigbluehat> +1!!!
10:37:32 <ajs6f> ivan: if a feature that wasn't normative becomes normative, then yes, things will change
10:37:58 <ajs6f> bigbluehat: but JSON-LD's greatest usage right nowis the non-normative use!
10:39:22 <ajs6f> ... and we shouldn't break what's running.
10:39:34 <pchampin> pchampin has joined #json-ld
10:39:35 <ajs6f> ... I want this to make more sense, but this is too dramatic a change too quickly.
10:40:15 <azaroth> ACTION: azaroth and bigbluehat to reach out to the TAG re #20
10:40:17 <danbri> so https://www.w3.org/TR/json-ld/#embedding-json-ld-in-html-documents is basically 4 lines of spec plus an example. We got a lot of deployment out of it, at least...
10:40:20 <ajs6f> ivan: I will not object to closing this, but the TAG discussion should be recorded as part of this discussion
10:41:11 <ajs6f> danbri: The problems at Google with this kind of thing are dwarfed by the basic data quality probems
10:41:30 <leonardr> leonardr has joined #json-ld
10:41:52 <ivan> rrsagent, draft minutes
10:41:52 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/25-json-ld-minutes.html ivan
11:29:11 <leonardr> leonardr has joined #json-ld
11:36:26 <Zakim> danbri, you wanted to ask if we ought to be considering Web Components -> Custom Elements (which might lean us towards following base throughout the DOM)
11:37:36 <azaroth> azaroth has joined #json-ld
11:37:54 <ajs6f> ajs6f has joined #json-ld
11:38:40 <gkellogg> gkellogg has joined #json-ld
11:38:51 <danbri> parting request: could someone help me get a minimal pair of examples for the HTML base (and language) decision, that I can share with Google colleagues
11:39:03 <ivan> ivan has joined #json-ld
11:39:21 <pchampin> pchampin has joined #json-ld
11:39:28 <laudrain> laudrain has joined #json-ld
11:40:19 <jyrossi> jyrossi has joined #json-ld
11:40:27 <azaroth> rrsagent, generate minutes
11:40:27 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/25-json-ld-minutes.html azaroth
11:40:31 <dlongley> dlongley has joined #json-ld
11:40:34 <ChristopherA> present+
11:40:39 <dlongley> present+
11:40:41 <dmitriz> dmitriz has joined #json-ld
11:40:48 <dmitriz> present+
11:41:08 <arln> arln has joined #json-ld
11:42:08 <jyrossi> * jyrossi apologizes, being requested for Web Commerce IG and will do his best to come babk in json-ld wg, around 3:30PM
11:43:11 <azaroth> hsolbrig, simonstey: Can you try reconnecting to webex please?
11:44:01 <ivan> scribenick: pchampin
11:44:06 <gannan_> gannan_ has joined #json-ld
11:44:43 <pchampin> dlongley: we wanted to talk about inboarding allies from the JSON world
11:45:10 <azaroth> SUBTOPIC: Sealed contexts (redux)
11:45:27 <azaroth> Link: https://github.com/w3c/json-ld-syntax/issues/20
11:45:28 <pchampin> ... a number of W3C specs have adopted JSON-LD, to get extensibility and interoperability
11:45:52 <pchampin> ... however, a number of non-RDF people are only going to use this data as plain JSON
11:45:59 <pchampin> ... not apply any JSON-LD algorithm
11:46:07 <gannan_> s/inboarding/onboarding/
11:46:46 <pchampin> ... Most of those standards require that their context is the first one in the @context list;
11:47:02 <pchampin> ... and have the rule that terms from their context should not be overridden.
11:47:50 <pchampin> ... Result: plain JSON interpretation will differ from JSON-LD interpretation.
11:48:06 <bigbluehat> q?
11:48:21 <pchampin> azaroth: if the JSON-only processor does not use the context at all, where's the risk?
11:50:09 <pchampin> dlongley: E.g. Verifiable Credentials defines a 'description' field;
11:50:26 <pchampin> ... if someone uses an additional context redefining 'definition' to mean something else,
11:50:45 <pchampin> ... a pure-JSON  tool will still interpret that as the VC description field.
11:51:22 <pchampin> ... The 'sealed context' feature is required to make JSON-LD-based formats robust,
11:51:31 <pchampin> ... reducing the gap btw JSON and JSON-LD.
11:51:36 <ivan> q+
11:53:56 <azaroth> ack ivan
11:54:02 <ChristopherA> q+
11:54:07 <pchampin> ... JSON people understand how JSON-LD can help interoperability,
11:54:30 <pchampin> ... rather than having anyone defining their own schema,
11:54:44 <pchampin> ... but they don't have an RDF background.
11:55:00 <gkellogg> q+
11:55:49 <pchampin> ivan: the idea of a 'sealed context' is to prevent people from overriding terms in the first context.
11:56:08 <bigbluehat> q+
11:56:31 <pchampin> ... Wouldn't it break the expectation of someone publishing their own data with their own vocabulary?
11:56:51 <gkellogg> q-
11:57:21 <azaroth> q?
11:57:27 <azaroth> ack ChristopherA
11:57:43 <pchampin> dlongley: this only applies in the case you are using a *list
11:57:50 <pchampin> s/*list/array of contexts.
11:58:58 <ivan> q+
11:59:08 <pchampin> ChristopherA: In constructing VC examples or DID examples,
11:59:33 <pchampin> ... I ran in problem linked to the underlying graph model, that only Dave or Manu could explain.
12:00:49 <pchampin> ... In VC, I want to be able to put some metadata of my own,
12:01:17 <pchampin> ... something that's not standardized or even ready for standardization,
12:01:57 <pchampin> ... how do we put it in a way that we are not messing up other things?
12:02:33 <azaroth> q?
12:02:56 <azaroth> ack bigbluehat
12:03:13 <pchampin> dlongley: many people don't get that curly braces in JSON-LD mean that you are talking about a node,
12:03:31 <pchampin> ... and attributes are about the links in this graph;
12:03:50 <pchampin> ... those people tend to produce data that make no sense for people who understand those principles.
12:04:11 <pchampin> bigbluehat: I came to JSON-LD from an RDF-aware background
12:04:35 <gannan_> gannan_ has joined #json-ld
12:04:35 <pchampin> ... I want to make things clearer,
12:04:57 <pchampin> ... but not at the price of hiding completely the graph model from Web developers.
12:05:04 <ajs6f> +1 to bigbluehat
12:05:33 <dlongley> q+
12:06:09 <pchampin> ... Anectode: in some plain-JSON formats, the same attribute 'name' does not expect the same type at different levels of the tree. You don't have that in JSON-LD.
12:06:44 <pchampin> ChristopherA: We are at a jey point where a lot of people are using JSON-LD.
12:07:31 <pchampin> ... We don't want them to decide that they will just do JSON and forget about the LD.
12:07:47 <bigbluehat> q?
12:08:17 <bigbluehat> ack ivan
12:08:21 <pchampin> gkellogg: would the solution be a set of best practices?
12:08:26 <bigbluehat> q+
12:08:51 <azaroth> ack dlongley
12:08:52 <pchampin> ivan: Question: who is expected to seal a context? The author of the context or the author of the data?
12:09:03 <pchampin> dlongley: This is an open question.
12:10:09 <pchampin> ... The notion of sealed context is one way to hide the graph model .
12:10:28 <bigbluehat> ack bigbluehat
12:10:34 <pchampin> ... Best practices, and anything that makes people aware that there is something beyond JSON, is a non-starter.
12:11:06 <ivan> q+
12:11:53 <pchampin> bigbluehat: for you, sealed context only apply for *arrays* of contexts?
12:12:05 <pchampin> dlongley: yes, in all the use cases that I know of.
12:12:23 <pchampin> ... If someone publishes a new context which *extends another one,
12:12:33 <pchampin> s/*extends/*extends*/
12:12:50 <pchampin> ... they can decide to override terms of the inherited context.
12:14:36 <gannan_> gannan_ has joined #json-ld
12:15:12 <ajs6f> q?
12:15:50 <azaroth> ack ivan
12:16:25 <pchampin> ... As this would be a totally differen thing from the POW of pure-JSON.
12:16:35 <bigbluehat> q+
12:16:56 <azaroth> q+ to ask about non @id context definition
12:17:54 <pchampin> ivan: Would it make sense to introduce a JSON datatype?
12:18:56 <pchampin> ... I could put a bunch of JSON in the JSON-LD, that would be interpreted as an RDF literal with the JSON datatype.
12:19:56 <dlongley> q?
12:20:10 <azaroth> ack bigbluehat
12:20:18 <pchampin> bigbluehat: but then you would have problems for signing, because you couldn't determine the exact value of that literal (re. new lines, spaces...).
12:20:28 <pchampin> dlongley: yes, that raises a number of other issues.
12:20:44 <gannan_> gannan_ has joined #json-ld
12:21:24 <pchampin> bigbluehat: One use case in VC is to be able to express an inner graph, with its own context,
12:21:43 <pchampin> ... without compromising the outer graph with the VC metadata.
12:21:57 <pchampin> ... In the old days, we would have used namespaces.
12:22:18 <pchampin> q+
12:22:55 <pchampin> ... Why not use "vc:" in front of the terms you want to keep uncompromised?
12:23:00 <ajs6f> q+ is sealed a special case of prioritization?
12:23:09 <ajs6f> q+ to ask is sealed a special case of prioritization?
12:23:23 <azaroth> ack azaroth
12:23:23 <Zakim> azaroth, you wanted to ask about non @id context definition
12:23:23 <pchampin> dlongley: The prefix wouldn't survive some JSON-LD applications,
12:23:38 <pchampin> ... and would produce something different from the POV of plain-JSON.
12:24:14 <pchampin> azaroth: Is it the expension that's the issue? Or the compaction as well?
12:24:15 <ChristopherA> q+
12:24:40 <pchampin> ... Is it only about the label or the rest of the definition (e.g. "@type": "@list")?
12:24:48 <pchampin> dlongley: the full term definition has to be a constant.
12:25:54 <pchampin> ivan: in the first round, let's stick to sealing contexts, not individual term definitions
12:27:24 <pchampin> ... What we are trying to do is to add a "modifier" on the "@context" link.
12:27:25 <azaroth> ack pchampin
12:27:51 <bigbluehat> q+ pchampin
12:27:54 <azaroth> ack ajs6f
12:27:54 <Zakim> ajs6f, you wanted to ask is sealed a special case of prioritization?
12:28:42 <pchampin> ajs6f: The notion of wrapping is important in this use case.
12:29:08 <pchampin> ... Is "sealing" not a special case of prioritization,
12:29:29 <pchampin> ... which might have more complex requirements?
12:29:37 <azaroth> q?
12:29:38 <azaroth> ack ChristopherA
12:29:48 <pchampin> dlongley: ActivityPub also have requirements for priority.
12:30:07 <pchampin> ... Their answer is "if you nee priorities, use full-fledged JSON-LD"
12:30:42 <azaroth> q?
12:30:56 <azaroth> ack pchampin
12:31:00 <bigbluehat> q+
12:31:01 <gkellogg> q+
12:31:08 <azaroth> ack bigbluehat
12:32:43 <azaroth> q+ to ask about versioning of sealed contexts
12:33:13 <pchampin> dlongley: re. WC, we could ask people to include their own @context,
12:33:29 <pchampin> ... but that could not work in all cases.
12:33:42 <azaroth> ack gkellogg
12:33:48 <pchampin> bigbluehat: pchampin suggested earlier to required that the sealed context be in the end,
12:34:15 <dlongley> q+
12:34:15 <pchampin> ... so it will effectively not be overridden with the current rules.
12:34:30 <azaroth> q?
12:35:15 <azaroth> ack azaroth
12:35:15 <Zakim> azaroth, you wanted to ask about versioning of sealed contexts
12:35:30 <pchampin> gkellogg: yes, but putting the extension *before* the extended context would be odd
12:35:57 <pchampin> q+ to talk about extension vs. wrapping
12:37:42 <azaroth> ack dlongley
12:37:49 <pchampin> azaroth: if terms are marked sealed, and the extension redefines that term,
12:37:56 <bigbluehat> q+
12:38:05 <pchampin> ... the overridden term will not be sealed, which can be detected by a validator
12:38:10 <bigbluehat> q-
12:38:11 <pchampin> ... This could mitigate the problem.
12:39:00 <pchampin> ivan: what if we have two sealed contexts in the list?
12:39:07 <azaroth> ack pchampin
12:39:07 <Zakim> pchampin, you wanted to talk about extension vs. wrapping
12:39:19 <pchampin> dlongley: then we would also need order priority...
12:39:23 <bigbluehat> scribenick: bigbluehat
12:39:36 <bigbluehat> pchampin: seems to me we're discussing two different things with multiple contexts
12:39:40 <bigbluehat> ...extensions
12:39:48 <bigbluehat> ...which are aware of the sealed context
12:39:57 <bigbluehat> ...and it would therefore be carefully designed to not conflict
12:40:02 <bigbluehat> ...the other scenario is a "wrapping" one
12:40:22 <bigbluehat> ...where the contained statements are expected to not match the wrapper
12:40:22 <bigbluehat> q+
12:40:23 <azaroth> q?
12:40:26 <azaroth> ack bigbluehat
12:40:28 <bigbluehat> scribenick: pchampin
12:41:59 <pchampin> bibbluehat: regarding the wrapping scenario, JSON-LD has graph containers.
12:42:06 <pchampin> dlongley: VC is using that.
12:42:19 <pchampin> s/bibbluehat/bigbluehat/
12:43:31 <pchampin> bigbluehat: could we solve the problem by adding some mechanism at the graph containers level.
12:45:03 <pchampin> dlongley: that would only work in named graph. That might solve my problem, but may be not others' (activity streams).
12:45:38 <ivan> present+ ChristopherA, dlongley
12:45:50 <dlongley> q-
12:45:52 <azaroth> q?
12:45:57 <pchampin> bigbluehat: following pchampin's idea that there are two different categories, may be two different solutions are the way to go.
12:46:04 <simonstey> present+
12:46:34 <bigbluehat> q+
12:46:50 <dlongley> present+ Ganesh_Annah
12:46:51 <azaroth> ack bigbluehat
12:46:52 <dlongley> present+ Ganesh_Annan
12:46:54 <dmitriz> present+ Dmitri_Zagidulin
12:46:58 <dlongley> present- Ganesh_Annah
12:46:59 <arln> present+ Antoine_Roulin
12:47:15 <dlongley> present+ Christopher_Allen
12:51:05 <gannan_> gannan_ has joined #json-ld
12:51:41 <dmitriz> dmitriz has joined #json-ld
12:51:51 <pchampin> ivan: to wrap up, the options that we considered are
12:52:08 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/87
12:52:17 <pchampin> ... 1/ modify the semantics of graph containers
12:52:27 <dlongley> dlongley has joined #json-ld
12:52:33 <pchampin> ... 2/ having a "sealed": true attribute in the context
12:52:54 <pchampin> 3/ having a "sealed": true within term definitions
12:53:09 <pchampin> ... 3/ having a "sealed": true within term definitions
12:54:49 <pchampin> gkellogg: when you seal, are you sealing the local context or the active context?
12:55:35 <pchampin> ivan: 4/ having the equivalent of a "rel=" attribute on the "@context" link
12:57:26 <pchampin> gkellogg: seal and integrity should be treated separately
12:58:59 <laudrain> laudrain has joined #json-ld
13:00:53 <pchampin> bigbluehat: why not just go for putting the sealed context in the end?
13:01:01 <gannan_> gannan_ has joined #json-ld
13:01:19 <pchampin> gkellogg: because the following contexts will usually rely on the definitions in the first (sealed) context.
13:01:37 <pchampin> ... e.g. after importing the schema.org context, I know I can use the xsd prefix.
13:03:09 <azaroth> ref: https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions
13:03:47 <azaroth> Yep, thanks Simon!
13:24:09 <leonardr> leonardr has joined #json-ld
13:31:00 <ivan> ivan has joined #json-ld
13:32:37 <gannan_> gannan_ has joined #json-ld
13:35:06 <leonardr> leonardr has joined #json-ld
13:39:21 <azaroth> azaroth has joined #json-ld
13:43:28 <ivan> ivan has joined #json-ld
13:43:30 <azaroth> We have gone to the WoT room
13:43:51 <ajs6f> ajs6f has joined #json-ld
13:44:01 <ivan> rrsagent, draft minutes
13:44:01 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/25-json-ld-minutes.html ivan
13:44:09 <ajs6f> Can someone remind me of the WoT IRC?
13:44:33 <leonardr> #wot
13:44:58 <ajs6f> .me ty leonardr!
13:49:01 <gannan_> gannan_ has joined #json-ld
13:51:33 <gannan_> gannan_ has joined #json-ld
13:53:29 <dlongley> dlongley has joined #json-ld
13:56:04 <danbri> danbri has joined #json-ld
13:56:29 <gannan_> gannan_ has joined #json-ld
13:57:02 <ajs6f> For anyone who just joined, JSON-LD WG is currently meeting with Web of Things WG; the IRC channel is #wot
13:57:16 <ajs6f> Connection info: https://mit.webex.com/mit/j.php?MTID=mfc01bd195bd4f226fbc71dbfef75910f
14:03:25 <gannan_> gannan_ has left #json-ld
14:05:30 <dmitriz> dmitriz has joined #json-ld
14:11:00 <ajs6f> ajs6f has left #json-ld
14:19:07 <gannan_> gannan_ has joined #json-ld
14:24:07 <gannan_> gannan_ has joined #json-ld
14:26:21 <gannan_> gannan_ has joined #json-ld
14:33:47 <gannan_> gannan_ has joined #json-ld
14:33:52 <gannan_> gannan_ has joined #json-ld
14:37:58 <gannan_> gannan_ has left #json-ld
14:42:35 <azaroth> It seems like we should raise the rdf:langString and rdf:HTML incompatibility to a higher power
14:42:48 <azaroth> As "en": "<span> ... </span>" should work, IMO
14:46:06 <azaroth> ACTION: azaroth to raise a meta issue about BIDI and langString / HTML
14:46:16 <azaroth> RRSAgent, actions
14:46:16 <RRSAgent> I'm logging. I don't understand 'actions', azaroth.  Try /msg RRSAgent help
14:46:49 <azaroth> RRSagent, draft minutes
14:46:49 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/25-json-ld-minutes.html azaroth
15:00:12 <gkellogg_> gkellogg_ has joined #json-ld
15:03:36 <Zakim> Zakim has left #json-ld
15:06:38 <laudrain> laudrain has joined #json-ld
15:06:43 <dmitriz> dmitriz has joined #json-ld
15:18:46 <azaroth> azaroth has joined #json-ld
15:19:11 <ivan> ivan has joined #json-ld
15:28:03 <laudrain> laudrain has left #json-ld
15:34:26 <ivan> ivan has joined #json-ld
15:43:51 <azaroth> azaroth has joined #json-ld
15:51:57 <leonardr> leonardr has joined #json-ld
16:25:12 <ivan> ivan has joined #json-ld
16:25:25 <ivan> rrsagent, draft minutes
16:25:25 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/25-json-ld-minutes.html ivan
16:25:30 <ivan> rrsagent, bye
16:25:30 <RRSAgent> I see 5 open action items saved in https://www.w3.org/2018/10/25-json-ld-actions.rdf :
16:25:30 <RRSAgent> ACTION: azaroth to add privacy and horizontal review to guiding principles [1]
16:25:30 <RRSAgent>   recorded in https://www.w3.org/2018/10/25-json-ld-irc#T07-05-18
16:25:30 <RRSAgent> ACTION: azaroth to create issues for ContextList and DocumentLoader editorial changes [2]
16:25:30 <RRSAgent>   recorded in https://www.w3.org/2018/10/25-json-ld-irc#T09-26-39
16:25:30 <RRSAgent> ACTION: azaroth to create context signature issue, related to #20 [3]
16:25:30 <RRSAgent>   recorded in https://www.w3.org/2018/10/25-json-ld-irc#T09-47-19
16:25:30 <RRSAgent> ACTION: azaroth and bigbluehat to reach out to the TAG re #20 [4]
16:25:30 <RRSAgent>   recorded in https://www.w3.org/2018/10/25-json-ld-irc#T10-40-15
16:25:30 <RRSAgent> ACTION: azaroth to raise a meta issue about BIDI and langString / HTML [5]
16:25:30 <RRSAgent>   recorded in https://www.w3.org/2018/10/25-json-ld-irc#T14-46-06
16:25:45 <ivan> zakim, bye