- From: Dan Brickley <danbri@danbri.org>
- Date: Sun, 6 Jun 2021 11:17:09 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, Phil Archer <phil.archer@gs1.org>, semantic-web <semantic-web@w3.org>
- Message-ID: <CAFfrAForqK_dmSk+x-d4=NaVsuNGj-V=iOGEqM3Q=ErF_GETEw@mail.gmail.com>
On Sun, 6 Jun 2021 at 10:40, Ivan Herman <ivan@w3.org> wrote: > > > On 5 Jun 2021, at 13:05, Dan Brickley <danbri@danbri.org> wrote: > > > So, in summary: > > Manu tells us there is a huge community and corpus of existing work, > expertise, best practice, and real world applications just waiting for this > WG to begin. > > Ivan tells us to only look at the exact words in the charter because “...the > only thing that counts is what the charter says”. > > The other thing that matters - perhaps more - is who shows up to join the > WG. > > It’s just a gamble, anything could come of this charter as-is. It could > more or less rubberstamp the existing designs, it could start from zero and > build quite fresh designs and usecases, or something painfully in the > middle. My instinct remains that this looks like a RIF-grade painful mix > somewhere in the middle. > > Maybe I am wrong, but the lesser of two may be to lean towards the > rubberstamping of the VC work, but to be explicit about that. > > > Rubberstamping the VC work, as you say, would be a disservice. Let alone > the fact there are use cases (e.g., the one drafted by the VU Amsterdam in > [1], the SOLID case [2,3], or the WoT usage[4]) that would rely on that > deliverable and it are definitely not VC based usages. > Let’s hope they all find common ground! However. A while ago Phil Archer put in a PR[2,3] whose goals is to > "restrict", in some sense, the expected usage of the LDI deliverable, > effectively concentrating on smaller datasets. > That focus sounds promising. VC, the VU nano focus, and Solid do all seem to lean towards small documents/graphs as the foundation. At Google we are also potentially interested in signed RDF at scale, where the most obvious unit might easily be web-age sized, so also small-ish. But then there are feeds (various senses of, but eg atom/rss or regular json-ld dumps etc.) at mid-scale size, alongside open rdf or quad data dumps such as Wikidata/Yago’s where signing the zipped concrete bits might seem to be a better fit. Defining “small” might be interesting of course, but approximately ... the smaller the graph, the more plausible it is to imagine someone else might have cooked up the same triples independently and be looking for evidence supporting them, which seems an interesting characteristic. Another way to keep things small and conveniently regular btw might be factor out the common structure as an (eg SHACL, ShEx, SPIN etc.) shape template, which could be canonicalized and signed separate to the filled out values. Well known shapes could then be omitted from space sensitive application settings like QR codes but referenced via their graph hash. This PR is still pending, but we could work with it to finalize the > charter. This, plus the already existing disclaimer text in the > explainer[4], are enough (in my view) to ensure the avoidance of the "RIF > effect". > Can you let know here when the PRs and other edits are done and ready for a slightly wider review? Cheers Dan Cheers > > Ivan > > > [1] https://github.com/w3c/lds-wg-charter/issues/90 > [2] https://github.com/w3c/lds-wg-charter/issues/49 > [3] https://github.com/w3c/lds-wg-charter/issues/48 > [4] https://github.com/w3c/lds-wg-charter/issues/78 > > > [2] https://github.com/w3c/lds-wg-charter/pull/89 > [3] https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/pull/89.html > [4] https://w3c.github.io/lds-wg-charter/explainer.html#out-of-scope > > > > Dan > > On Sat, 5 Jun 2021 at 10:51, Ivan Herman <ivan@w3.org> wrote: > >> >> >> On 4 Jun 2021, at 17:57, Dan Brickley <danbri@danbri.org> wrote: >> >> >> >> On Fri, 4 Jun 2021 at 16:32, Ivan Herman <ivan@w3.org> wrote: >> >>> >>> >>> On 4 Jun 2021, at 16:16, Dan Brickley <danbri@danbri.org> wrote: >>> >>> >>> >>> That does sound really really bad. Perhaps the WG charter should cover >>> only use of self-contained Linked Data / RDF format, eg Turtle/TRiG? And >>> then try to secure hypertext / multi-stakeholder RDF syntaxes (json-ld, >>> grddl, ...) as a stretch goal rather than core business? >>> >>> >>> Dan, >>> >>> I do not understand what you mean. What do you mean by "multi >>> stakeholder RDF Syntax" that seems to characterize JSON-LD as opposed to >>> Turtle or RDF/XML? This is the first time I meet this type of expression >>> with regards to RDF syntaxes. In view, JSON-LD is not fundamentally >>> different from Turtle or RDF/XML. >>> >> >> Ralph Swick was very clear about this in the 1997 RDF Model and Syntax >> WG. That an RDF document (given a base URI) should unambiguously determine >> the triples/graph, without the content of the resulting graph depending on >> pulling in code from other parties over potentially unreliable connections. >> RDF/XML, Turtle, N3, RDFa etc meet that criteria... >> >> >> “Multi-stakeholder” is new terminology >> >> >> It is not very helpful coming up with a new terminology in the middle of >> a charter discussion. Let us avoid this. >> >> intended to capture the idea that the RDF your document maps to is a >> result of your collaboration with the parties controlling any remote >> contexts it references. And that this is recursive and dynamic; parsers >> without the right context data won’t know what to emit. >> >> >>> I suspect you are referring to the problems that arise with the context >>> file, although I am not sure why that is a "multi stakeholder syntax" >>> >> >> >> <snip> >> >> - but we have already made a change on the charter by making it explicit >>> that the WG will deal with the specific context issue separately, see >>> >>> https://w3c.github.io/lds-wg-charter/#ig-other-deliverables >>> >> >> That is interesting, and progress, but these discussions seem still to >> presuppose JSON-LD is the best and focal foundation for signed Linked Data; >> Manu’s warning suggests instead it may be amongst the least appropriate. >> >> >> Sigh. The discussion, so far, was helpful in clarifying potential >> problems and make some hidden assumptions more visible. But we are coming >> full circles here, and I am beginning to think that we will never get to an >> agreement or common understanding. >> >> Please show me where in the charter it says that "JSON-LD is the best and >> focal foundation for signed Linked Data". (Either in the latest version of >> the charter, or in any earlier incarnation thereof, or in the >> not-yet-approved-and-merged PR [1,2].) In fact, please show me where in the >> charter we privilege *any* concrete RDF syntax in the algorithms (apart >> maybe from N-triples/N-quads in the final steps of the hashing algorithm). >> All the algorithms and vocabularies are meant to be on the abstract RDF >> model. Putting JSON-LD "out of scope" is, in fact, meaningless in this >> context. >> >> I expect your answer will be to find some reference or text somewhere in, >> say, the LDP document hinting at this. And I would consider this irrelevant >> for the current discussion. Those documents are *not* a direct input to >> the deliverables, a.k.a. they are not FPWD-to-be. These are references are >> "primary input to the work" simply because, at this point, there has been a >> significant amount of work put into them that we should not ignore, there >> has not been any similar significant work to cover that area beyond the >> ones mentioned, (If you, or anybody else, have such an input, I am happy to >> propose adding it to the charter.) The WG is *not* bound by these >> documents by any means, i.e., for example, is not bound by anything that is >> related to JSON-LD. >> >> Maybe your answer will be to quote from a mail or other conversation of >> one of the participants of the discussion. And I would consider this >> irrelevant for the current discussion, too. Member companies can delegate >> their experts to the WG, and I do not expect all the experts in that WG to >> have the same opinion on everything. Actually, I hope that is not the case, >> and the WG will be the place for healthy technical discussions. Even in the >> case of past Working Groups that relied much more heavily on some input >> documents than this charter one plans to, there were significant >> disagreements that led to some major changes on those documents when they >> became part of rec-track work. And that is the way it should be; a W3C WG >> is not a rubber stamping body. >> >> We are creating a charter. Although not in a legal sense, but it is a bit >> like creating a contract. You know pretty well the way the W3C process >> works, and you know very well that the only thing that counts is what the >> charter says. Everything else is a subject of discussion in the WG. If >> you want to make it sure that JSON-LD does not unduly affects the final >> deliverables, or that the context related problems are properly discussed, >> then, by all means, join the WG. That is the place where things should be >> discussed. >> >> Cheers >> >> Ivan >> >> >> [1] https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/pull/89.html >> [2] https://github.com/w3c/lds-wg-charter/pull/89 >> >> >> >> >> ---- >> Ivan Herman, W3C >> Home: http://www.w3.org/People/Ivan/ >> mobile: +33 6 52 46 00 43 >> ORCID ID: https://orcid.org/0000-0003-0782-2704 >> >> > > ---- > Ivan Herman, W3C > Home: http://www.w3.org/People/Ivan/ > mobile: +33 6 52 46 00 43 > ORCID ID: https://orcid.org/0000-0003-0782-2704 > >
Received on Sunday, 6 June 2021 10:18:05 UTC