W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2018

[MINUTES] W3C JSON-LD CG Call 2018-02-07

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 7 Feb 2018 13:32:22 -0800
Message-Id: <B12F9193-BEBF-4B36-9C8D-067DEB10447F@greggkellogg.net>
To: Linked JSON <public-linked-json@w3.org>
Thanks to Gregg Kellogg for scribing this week! The minutes for the ad-hoc JSON-LD CG call with Paul Frazze are  now available: https://json-ld.org/minutes/2018-02-07/index.html.

Full text of the discussion follows for W3C archival purposes.

Gregg Kellogg

JSON-LD Community Group Minutes for 2018-02-07

  Manu Sporny
  Gregg Kellogg
  Gregg Kellogg, Manu Sporny, Paul Frazze, Jamie Pitts

Gregg Kellogg is scribing.
Manu Sporny:  Asking pfrazee to give a background on Beaker
Manu Sporny:  We're fans of decentralizing things on the web, 
  started Web Payments, which was supposed to be to allow people to 
  be online with banking.
  ... How much overlap is there between Beaker's goals and other 
  goals? Maybe more colab makes sense.
Paul Frazze:  Our focus starts with publishing, allowing people 
  to publish without using a 3rd party service.
  ... From there, it's possible to create applications. The stack 
  will grow over time, at the moment we're seeing how much we can 
  get out of a DAT network.
  ... through that, you can build a class of applicaitons, such 
  as social networking and office software. This has led to a 
  couple of things, one which is like Twitter, but another deviates 
  in UI.
  ... It's primarily a filesystem shared over the network, and 
  activly watch the files for change. They can be any data you 
  like, but we chose JSON.
  ... You follow each other by scanning JSON files for changes 
  and then index to use as content.
  ... Eventually, we run into schema coordination issues. That's 
  how we got to the JSON-LD conversation.
Gregg Kellogg:  Hi, Gregg Kellogg, leading efforts for updates to 
  JSON-LD 1.1 [scribe assist by Manu Sporny]
Gregg Kellogg:  There is a charter out for discussion wrt. W3C WG 
  for JSON-LD [scribe assist by Manu Sporny]
Gregg Kellogg:  This is certainly timely, encourage you to 
  participate if you have input on JSON-LD, using IRC to log 
  communications - these get turned into meeting notes. Standard 
  practice for CGs and WGs. We encourage people with diverse 
  backgrounds to collaborate to make best possible thing. [scribe 
  assist by Manu Sporny]
Jamie Pitts:  I work at Etherium in devops, and represent them at 
  the W3C. I'm working on a metadata project that involves JSON-LD. 
  I'm interested in how you reach out to people on how they use it.
Jamie Pitts:  I work at Ethereum Foundation at Devops, intro to 
  W3C. Working on a metadata project that involves JSON-LD, reach 
  out to people on how it works, metadata general. [scribe assist 
  by Manu Sporny]
Manu Sporny:  I want to make sure we get to Paul's concerns.
  ... I did a readthrough of your README and design document 
  (issue 820) and I believe I understand the problem space and your 
  ... All of your design goals have a lot of overlap with 
  JSON-LD. When we were putting the spec together we addressed many 
  of the same problems. For about 20% I could see your concerns 
  about JSON-LD, but for everything else, there's direct 
  ... Perhaps there are some ways it's used that aren't obvious.
  ... The community tries to not push the spec too hard, but if 
  it's not useful, we will try hard to address needs. But, at some 
  point, it may be too different to adapt to goals.
  ... There is quite a bit of community input, so it does more 
  than any one individual wants, but it addressed the needs of an 
  important community.
  ... A lot of 1.1 work is based on community feedback.
  ... JSON-LD is used from between 10% to 19% of all domains on 
  the internet (most probably for SEO).
  ... The other class of people using it tend to be data 
  scientists and government open data. In these cases, getting the 
  semantics right is crucial.
  ... In the worst case, you can at least learn from some of our 
Paul Frazze:  I have a lot of respect for the time and effort put 
  into JSON-LD.
  ... With this project, I talked with people to get opinions. 
  People may have used RDF and really understood the value. Other 
  people didn't see the utility and very much did not like it. So, 
  there's an emotional reaction. I'm trying to understand real 
  problems from perception.
  ... The requirements are somewhat unique; in the service of 
  making publishing easy, we're also looking to make application 
  development very easy and allow programming by view-source.
  ... Ease of use and understaning for programmers of all skill 
  levels; we want people to have fun.
  ... We need to make sure we have the extensibility use case in 
  mind always.
  ... The expectation is that everyone may have their own client; 
  everyone may  have their own datamodel. We may be refering to 
  schemas always.
  ... Our observations are summarized in JSON-LZ (LaZy), which 
  led to this call.
Looks like my client is not working; will listen to recording; 
  ... We wanted to make sure the meta-data information did not 
  need to be pre-meditated. People are probably not going to invest 
  consistently and reliably, and may change things later.
  ... In that vein, I'm concerned about the need for up-front 
  tooling. If we minimize the amount of tooling needed, that would 
  be good, but it may be “painted on” later.
Manu Sporny:  What struck me is that it's the same design space. 
  I can understand why someone using JSON-LD might think there 
  needs to be a lot of up-front work, but that's not quite true.
  ... When we designed, we had JSON programmers in mind, and 
  don't want to for people down the -LD route.
  ... E.g., if you look at the activity pub spec, you don't 
  really need to have a defined vocabulary to use it.
  ... We couldn't do that in the base-JSON-LD spec, but it's 
  something that other groups have done.
  ... So, for all data published by something like Beaker, you 
  might assume a particular context. That might just define a 
  namespace that things go to if not otherwise defined.
  ... This makes you compatibile with LD elsewhere. That allows 
  you to be lazy in your approach.
  ... We have some non-profits and for-profits using JSON-LD. 
  Usually when developing, the schema is the last thing we do. 
  We're Mongo-DB based and we just start doing JSON datastructures. 
  It's only at the end that we start locking things down.
  ... As we figure out the scope, we start to get more formal.
Paul Frazze:  One thing I get a reaction from from people that 
  don't come from RDF/LD is they don't understand the value 
  proposition. A way to short-circuit that might be to use a 
  mechanism similar to the Link header to specify the context to 
  allow it to be painted on externally.
  ... This could allow metadata without syntax. and allows 
  complicated information to be separated and documents to avoid 
Manu Sporny:  In the beginning, we got feedback about squatting 
  on different names, which is where the “@“ syntax came from, 
  but people say that don't like that.
  ... We address that through keyword aliases to, for example, 
  alias “@id” to “id”. Just not for @context.
  ... But the Link header addresses that.
  ... Or, it can be specified as part of the specification.
  ... The other thing is that people don't like namespaces. It's 
  debatable, but people don't want to see compact IRIs. JSON-LD 
  allows prefixing, but doesn't require it. RDF folks get the 
  namespacing, but others can completely avoid it by sticking to 
  ... Things with “.” or “:” in the names are 
  problematic, but the context allows you to get around these.
Paul Frazze:  The aliasing is quite close to what we need. You 
  can individuallly alias terms to namespaces, but to do it at a 
  broad stroke requires prefixing. Otherwise, you need to define 
  each term.
Manu Sporny:  @Vocab allows that.
Gregg Kellogg:  THere is a change in 1.1, that allows scoped 
  contexts... allows data from diferent locations. In one place you 
  might have something like "identifier" that means something 
  particlar, but now you go into some other property... you can 
  previously solve via inline context, but now you can do w/ scoped 
  context. [scribe assist by Manu Sporny]
Gregg Kellogg:  You can set @vocab to schema.org, or you can do 
  @vocab to foaf... that's something that's a way to use the 
  vocabulary mechanism, but have it logically resolve to different 
  namespaces w/o having data users deal w/ it. [scribe assist by 
  Manu Sporny]
Paul Frazze:  The solution I was looking at is a globbing 
  pattern, it has the advantage of painting over multiple different 
  attributes w/o having different applications. [scribe assist by 
  Manu Sporny]
Manu Sporny:  That came up when working on JSON-LD vocab stuff. 
  the danger was people stomping over too much data. Regexps are 
  ... Because the focus was on getting the semantics right, we 
  chose to not go there. As a consequence, contexts can get large.
  ... But in practice, the amount you need tends to be pretty 
  small. For example, look at Activity Pub, they just define a 
  handfull of terms.
  ... Schema.org, on the otherhand, defines many terms, as 
  there's a single flat namespace.
  ... I understand the desire to use globbing to reduce the size 
  of the context, but in practice, it tends not to be a problem.
  ... If we brought up globbing patterns in 1.1, we'd probably 
  hit the same problems. Why not just write the context once 
  without using globbing.
Paul Frazze:  I understand your argument, but if it were 
  possible, engineers would appriciate it.
  ... I wouldn't make it a blocker, but please keep it in your 
Gregg Kellogg:  The way the group thinks about it is by managing 
  issues and through community engagement. I'd encourage you to 
  file an issue and start a dialogue. [scribe assist by Manu 
Gregg Kellogg:  I share Manu's concern around potential 
  complexity around globbing. From a standards perspective, you get 
  into what the regex syntax is, whose regex lib are you going to 
  use. Avoiding that as a practical perspective is useful. Prefixes 
  directly address that issue, but they may not be paletable. Maybe 
  there is a middle ground here. [scribe assist by Manu Sporny]
Gregg Kellogg:  I think the group has been quite open to trying 
  to address these problems over time. [scribe assist by Manu 
Paul Frazze:  Happy to open an issue and continue conversation 
  there. [scribe assist by Manu Sporny]
Gregg Kellogg:  That's where issues are right now, may move it 
  out to CG and spec in a bit.  [scribe assist by Manu Sporny]
Paul Frazze:  I'd like to look for a subset of tools that I could 
  bundle together from the community. We could look at prefixes 
Gregg Kellogg:  Yes, that's what a lot of other groups do... 
  limit JSON-LD to particular dialect. Work on publishing CSV as 
  Linked Data, uses a descriptor format as JSON-LD, but to get to 
  some of the extensibility bits, you can add arbitrary JSON-LD in 
  various locations, but stick to dialect. [scribe assist by Manu 
  ... That can reduce the load on developers
Manu Sporny:  There have been people that use JSON-LD as a 
  back-end language and work through a library. Actual publication 
  happens out of a library.
  ... or, reverse domain notation, instead of colons.
  ... You can always handle these in a library and output JSON-LD 
  in the backend.
  ... As a result, you can transform between different dialects.
Paul Frazze:  Should vocabularies use URL identifiers? I imagine 
  it's been discussed before.
  ... I want people to be free to make extensions to schemas, 
  which may imply that they need to set up documents to maintain 
  for very common tasks.
  ... dispite the advantages of URIs, there's something to be 
  said for simply long strings.
Manu Sporny:  When we started, we though we might hard-code some 
  common schemas, but we ultimately came to URLs as publishing is 
  easy, but may still be too high a barrior.
  ... URLs don't have to be HTTP, they could be dat, or 
  ... Make up names and start using, then publish later.
  ... in JSON-LD processors, you can overload how documents are 
  found, so a small shim can allow you to specify a new way of 
  looking up things. This give you a kind of schema mechanism.
Gregg Kellogg:  You can use URNs today... you can even use 
  bnodes... fundamentally it's an IRI. You don't need to be able to 
  resolve/download. JSON-LD is an enabling technology for that, not 
  an enforcing technology. DAT is just fine. URN is just fine 
  Anything you want to use for that purpose. It might actually be 
  something that is potentially dereferenceable. [scribe assist by 
  Manu Sporny]
Gregg Kellogg:  You may start off w/ something that's 
  dereferenceable, describe a vocabulary, describe metadata on it. 
  [scribe assist by Manu Sporny]
Paul Frazze:  If there was just a string used that didn't 
  resolve, what would happen.
Manu Sporny:  Then, you wouldn't know how to dereference in the 
  ... You don't want to get into a possition where you don't know 
  what protocol to use.
Gregg Kellogg:  THere have been some other things that have been 
  talked about... document-relative properties... it's kind of a 
  hard core RDF issue. Got a document that describe itself, why 
  can't properties used in there relative to the document? 
  Something we might add into 1.1 - fragment identifier that is 
  looked up in the document. [scribe assist by Manu Sporny]
Gregg Kellogg:  Another thing - property that is a URI that is 
  not a property... nothing restricts you from doing that. Once you 
  make use of JSON-LD algorithms, compact/expand/turn into RDF - 
  URI pattern, in danger of being lost.  [scribe assist by Manu 
Gregg Kellogg:  Surface syntax compatible w/ JSON-LD, useful as 
  JSON. It does have long term consequences, that's why we use 
  IRIs, that's why it ends up being a best practice. [scribe assist 
  by Manu Sporny]
Gregg Kellogg:  When testing, having terms relative to doc, have 
  a message that is arbitrary properties, properties can't 
  logically be the same. RDF allows you to make two properties 
  similar... cool semantics that can be relied on when you get to 
  reasoning. But that's a bit cart before the horse. First step is 
  get people to publish what they mean. THey should use well known 
  identifiers. If there are things that are document specific, use 
  document stuff. Lib [scribe assist by Manu Sporny]
Manu Sporny: Rary/framework specific, do that. You can go back 
  and make "sameAs" assertions on URNs as well. But you can't 
Paul Frazze:  I'm not sure engineers will take time to publish 
  schemas, you could use DAT, but if you use something that isn't 
  maintained, the URL gets lost.
  ... We could push them to use short names, but then you're 
  getting into a higher level of expectation.
Manu Sporny:  I don't think the standard workflow is that they 
  must publish a context. We're saying, let's try to figure out a 
  way so they don't have to do that. Perhaps a global context that 
  things fall into while you're playing around. Only when you need 
  interoperability do you cross that bridge.
  ... The only people that really end up publishing contexts and 
  vocabularies are people that understand the semantics and data 
  modeling. I don't think it would be good to count on your 
  community to do that.
Paul Frazze:  Original web browsers were forgiving about HTML, 
  which is what I want to see here.
Manu Sporny:  That's the thinking that went into JSON-LD. 
  Developers should be able to not care and have fun and 
  progressively enhance their data.
  ... It's only when interoperability is an issue that something 
  should be published.
  ... Then, other developers either need to add something, or the 
  framework does it for them.
Paul Frazze:  I may open up an issue on IRIs, and start an issue 
  on globbing.
  ... I'll let the tooling conversation playout online.
Manu Sporny:  There's a big group trying to decentralize the web 
  (identifiers, credentials, ...). What they have in common is 
  JSON-LD and Linked Data. We're trying to do it in a non-invasive 
  ... I understand the knee-jerk reaction to RDF/Linked Data, and 
  it's hard to get across to developers that haven't been involved 
  in it. THe problem is, the more decentralized you get, the less 
  assurance you have in the data that's consumed.
  ... We've been hitting the limits of JSON, either you need to 
  create specific APIs for everything, or you you go to data 
  interoperability and use common tooling; otherwise, we're always 
  needing to create a specific solution for each problem, which 
  doesn't scale.
  ... We're trying to make data-publishing easier.
  ... JSON is the dataformate people use now, but 10 years ago it 
  was XML, now people are using CBOR. The benefit of JSON-LD is 
  that you can transform between different syntaxes.
  ... When you express data, you can sign it independent of the 
  actual serialization format. This creates forward extensibility.
  ... The downside is that it's a bit more complicated. JSON-LD 
  tries to hide this complexity.
  ... We're moving to genric signing libraries.
  ... We're all in this for the same thing, to give people more 
  ... decentralized systems are harder to build than centralized 
Paul Frazze:  The question is how important precision is. Some of 
  the communities are good with duck-typing, and don't want to 
  worry about looking-forward solutions, but just be good enough.
  ... I feel optimistic we can make something happen.
Manu Sporny:  We're happy to jump in and provide feedback, and 
  you might join the linked-data mailing list.
  ... I also want to invite you to join the Web of Trust 
  ... that community knows about secure-scuttlebutt, and they're 
  people that write code to make things work.
Received on Wednesday, 7 February 2018 21:32:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:51 UTC