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 concernts.
... 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 applicability.
... 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 experience.
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.
Error: (IRC nickname 'cadorn' not recognized)[2018-02-07T20:21:35.961Z] <cadorn> looks like my client is not working; will listen to recording; thanks!
... 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 boilerplate.
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 terms.
... 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. ✪
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 hard. ✪
... 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 mind.
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 Sporny] ✪
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 Sporny] ✪
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 later. ✪
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 Sporny] ✪
... 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 otherthings.
... 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 future. ✪
... 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 Sporny] ✪
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 dereference. ✪
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 way. ✪
... 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 power.
... decentralized systems are harder to build than centralized systems.
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. ✪