Re: Chartering work has started for a Linked Data Signature Working Group @W3C

On Mon, 3 May 2021 at 10:06, Ivan Herman <ivan@w3.org> wrote:

> (For info: the charter[1] and the related explainer text[2] has changed
> recently following some Github discussions.)
>
> Hi Dan,
>
> Thanks a lot for your thoughts.
>
> I am perfectly aware of the naming issues around RDF vs. Linked Data.
> Naming has evolved over the years, and the community was not consistent in
> using one term or the other. There are communities whose members frown (to
> say the least) when they hear the term "RDF" and then happily use Linked
> Data.
>

Are you or W3M concerned that they would not support or join this group if
they knew it was solely devoted to solving problems with RDF graph and
dataset structures?

We have named a standard JSON-LD (i.e., JSON Linked Data) although the
> right terminology would have been JSON-RDF or something like that, because
> JSON-LD is orthogonal to the Linked Data principles that you refer to. RDF
> Graphs are created routinely that do fully abide to the aspirations of
> Linked Data, but they are never referred to that way. I am sure there are
> other examples. So yes, it is messy.
>

Yes, a mess!

However, it is not the job of this charter, or the proposed Working Group,
> to clean up this particular mess. I would propose to agree that,* for the
> purpose of this charter and WG, the terms RDF and Linked Data are
> interchangeable*; this is certainly the way the WG intends to pursue its
> work.
>

Affectionately and with respect: you are not making any sense! There is no
WG, only a messy sketch of a possible charter. The WG cannot intend
anything until the W3C AC approves a WG, and the intentions of the WG will
depend upon who the charter inspires to support it, and which Members put
people on the group.

As always, we are in a squeeze here.

If the WG is described too boringly, it won’t get enough support, members
or AC votes to happen.

If it is described too flamboyantly - such as the current and implausible
suggestion that it will secure the integrity and authenticity of the fast
growing web of linked data, you will get more members, support and
attention —- but at the expense of vastly overpromising and seeding a WG
dynamic that may struggle to agree on the “obvious to the charter’s
authors” anticipated designs.

My advice is to turn the dial towards boring; if the proposed work is
useful the usecases will shine through.

On the naming choice - if the draft WG charter is describing a group that
W3C leadership expect to use the terms “RDF” and “Linked Data”
interchangeably, W3C should respect the time and attention of its AC, the
future chair(s) and Members by putting that working assumption more
prominently in the document.

To further narrow down the discussion, let us also concentrate on what this
> charter proposes to do. It proposes to provide a standard for the
> canonicalization of, and to calculate a hash for, an RDF Graph or an RDF
> Dataset. (There are some additional, say, "engineering" issues like how to
> express the algorithms and their result in RDF, but that is, comparatively,
> minor.) That is it.
>

This is an occasionally useful tool to have in the toolkit, but only a
small piece of a larger ecosystem.


> As a result, although all the questions you raise are absolutely valid and
> to be solved at some point, I suggest, they must be kept entirely out of
> scope for this particular Working Group. (E.g., as Gregg said in his
> answer, hashing/signing is done on the RDF Dataset, i.e., the triples and
> triples only, and it is oblivious to the other datasets referred from it).
> We all want to avoid a "RIF-like 5 year slog".
>

What does it mean to sign a dataset that consists entirely of either
hashing-artifact bnode labels, or other people’s URIs? (for entities, or
for vocab terms i.e. types, properties etc.).

The use of the phrase “Linked Data” suggests that their being URIs is
relevant to the meaning of the signed data. Specifically if I assert that
entity e-1234 is of type s:PermittedApplication, why would anybody care to
sign just the instance data without also doing some record keeping w.r.t.
how —- at that moment —- the xyz: folks defined that type?

Without also noting the content of schemas it is hard to know what are the
conditions under which the instance data might be considered true. Signing
just the instance parts of the Linked Data (aka rdf) doesn’t tell us what
the signer meant, since it’s literally just a bunch of URIs.

This would be clearer if the the type was called s:a1251b5342g3421 instead
of “PermittedApplication”.

The bnode canonicalization algo is a nice thing to have but W3C isn’t
helping itself with the “this secures the authenticity and integrity of the
web of linked data” hype.

Let us concentrate on how we make the charter text clearer and avoid
> creating a wrong expectations.
>
> I believe that replacing the term "Linked Data" to "RDF" everywhere in the
> text is not a good solution: that would alienate some communities that, in
> fact, use these technologies but whose mindset has been conditioned to use
> the term "Linked Data" and, at the same time, look at the term "RDF" with
> suspicion. If we do such a change, we may risk loosing them.
>
> In my view the cleanest way would be to make it clear, either in the
> charter text, or the explainer, that we consider these terms, for the
> purposes of this Working Group, as synonyms. Additionally, we may also want
> to list some problems whose solutions are explicitly out of scope (although
> we have to have a clear set of terms for those). I would be pleased to hear
> more suggestions. The charter is still in developments, ie, this is the
> time to do it!
>
> Thanks
>
> Ivan
>
>
> [1] https://w3c.github.io/lds-wg-charter/
> [2] https://w3c.github.io/lds-wg-charter/explainer.html
>
>
> On 1 May 2021, at 12:27, Dan Brickley <danbri@danbri.org> wrote:
>
>
> I have concerns. If I had had more time I would have written a shorter
> email.
>
>
>
> Starting from the top -
>
> Is “Linked Data” in the group name serving as a synonym for RDF?
>
> Are there in-scope usecases for non-RDF content? eg property graphs? RIF?
> Microformats? Plain XML, JSON?
>
> Does saying “Linked Data” exclude any RDF practices deemed insufficiency
> “Linked”?
>
> The charter cites
> http://webdatacommons.org/structureddata/#toc3 in support of the
> vague/ambiguous claim that “ The deployment of Linked Data
> <https://www.w3.org/standards/semanticweb/data> is increasing at a rapid
> pace <http://webdatacommons.org/structureddata/#toc3>”, yet the citation
> points to a document focussed on approaches which in various ways go
> against “Linked Data” orthodoxy, narrowly conceived.
>
> The webdatacommons report covers Microdata, RDFa, JSON-LD, and even
> Microformats; the latter effort has long distanced itself from RDF, Linked
> Data and so on. The others, as published in the public Web, are very
> commonly found embedded in containing documents (or even injected via
> Javascript into a running webplatform document object), and being used as
> standalone bnode-heavy descriptions rather than fragmentary pieces of
> hypertext RDF.
>
> A particular problem with calling the group “Linked Data” is the
> expectation that the various (and contested) publishing practices
> associated with the Linked Data slogan will get tangled up in the technical
> work.
>
> For example, the Linked Data community emphasises public data, often but
> not always “Linked Open Data”, and has a strong bias towards RDF being
> published in a form such that all mentioned entities are described with a
> URI. It also has a bias toward those URIs being http(s)-dereferencable,
> with the resulting document containing additional RDF statements pertaining
> directly or indirectly to the entity the URI is considered to identify.
> Arcane rules regarding http redirect codes and the use of #-based
> identifiers for non-webplatform entities are also an important element of
> the post-2006 Linked Data tradition.
>
> By proposing to name the group “Linked Data” W3C risks embedding these
> contested design preferences in the technical work, while justifying the WG
> as impactful using the large scale adoption of practices bases on json-ld,
> microdata, rdfa which actively make different design choices from those
> implicitly endorsed by this naming choice.
>
> Specifically, Schema.org using these formats is on millions of sites (eg
> report led by webdatacommons), in large part by making the explicit choice
> to make things easier for publishers, e.g. by allowing them to write markup
> meaning roughly “the Country whose name is Paris” rather than following
> Linked Data supposed best practice of simply using a well known URI for
> the entity, such as
> http://dbpedia.org/resource/Paris (which would involve publishers finding
> out the mosg currently fashionable URI for every entity they mention).
> Signing data that mostly consists of dangling references to files on other
> people’s websites may be a solved mathematical problem, but it is new
> territory in social, policy, workflow, ecosystem and other ways. If W3C
> values such an endeavour it should be realistic in terms of staff resources
> assigned, and timelines. This is not a “quick win” project.
>
>
> The chartering issue is that “Linked Data” is a broad marketing euphemism
> for RDF that emphasises some but not all of its strengths, such as the ease
> of data merging across loosely coupled systems. But it is not a technical
> term or a W3C standard as such.
>
>
>
> If this is effectively an RDF canonicalization WG there are other issues
> to discuss, such as its impact on expectations around schema evolution,
> linking, and security.
>
> Without being exhaustive, ...
>
> Would it apply to schemas published at http: URIs or only https: URIs?
>
> Are we convinced that there is application-level value in having
> assurances over instance data without also having them for the schemas and
> ontologies they are underpinned by?
>
> Is there an expectation that schema/ontology publishing practice would
> need to change to accommodate these scenarios?
>
> Would schema-publishing organizations like Dublin Core, Schema.org,
> Wikidata, DBpedia, be expected to publish a JSON-LD (1.0? 1.1?) context
> file? What change management, versioning, etc practices would be required?
> Would special new schemas be needed instead?
>
> For eg. if instance data created in 2019 uses a schema ex:Foo type last
> updated in 2021, but which has since 2018 contained an assertion of
> owl:equivalentClass to ex2:Bar, and an rdfs:subClassOf ex3:Xyz, are changes
> to the definitions of these supposed to be relevant to the trustability of
> the instance data? If so, why does
> https://w3c.github.io/lds-wg-charter/index.html not discuss the role of
> schema/ontology definitions in all this?
>
> For concrete example of why 24 months looks ambitious:
>
> The examples in
> https://w3c-ccg.github.io/security-vocab/
> { "@context": ["https://w3id.org/security/v1",
> "http://json-ld.org/contexts/person.jsonld"] "@type": "Person", "name":
> "Manu Sporny", "homepage": "http://manu.sporny.org/", "signature": {
> "@type": "GraphSignature2012", "creator": "http://manu.sporny.org/keys/5",
> "signatureValue":
> "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk=" } }
>
> This uses the following json-ld context:
>
> http://json-ld.org/contexts/person.jsonld
>
>
> ...which currently maps the term “Person” in the instance data to
> foaf:Person, which is a schema we have published in the FOAF project since
> ~ May 2000 or so, evolving the definition in place. We used to PGP sign the
> RDFS RDF/XML files btw; I am not entirely against signing and RDF! Nobody
> used it though.
>
> From person.jsonld above,
>
> {
>
>    "@context":
>    {
>       "Person": "http://xmlns.com/foaf/0.1/Person",...
>
>
> The current English definition of foaf:Person says “ The Person <http://xmlns.com/foaf/spec/#term_Person> class represents people. Something is a Person <http://xmlns.com/foaf/spec/#term_Person> if it is a person. We don't nitpic about whether they're alive, dead, real, or imaginary”.
>
> Its rdf/xml (“Linked Data”) definition says, amongst other things, that it is owl:equivalentClass to schema:Person.
>
> Do we want a spec that cares about whether the context file is served over
> http? That cares if the dependency on FOAF is silently switched out, or
> whether the FOAF Person type’s “Linked Data” stated equivalence to
> http://schema.org/Person gets updated, e.g. to use https://schema.org
> and/or to converge the written definitions which set the meaning of what it
> is to say that something is a foaf:Person or schema:Person.
>
> These are all fascinating issues but I would be astonished if the work
> gets done on the proposed schedule. The very idea of Linked Data puts these
> URI-facilitated connections between RDF graphs at its core. To omit
> discussion of their consequences in the charter is odd. For example, when
> is one the “authenticity and integrity” of one serialized / published graph
> dependent on that of another that it mentions/references/uses?
>
> I am not against this work, but the draft charter feels really off somehow.
>
> RDF with lots of blank nodes is known to be a bit annoying to consume, but
> easier to publish. The general sections of the charter make sweeping and
> grand claims about the utility of the proposed standards, and justify that
> with phrases like “authenticity and integrity of the data”  and
> references to the adoption of json-ld, microdata and rdfa in public web
> content.
>
> The usecases most explicitly listed are however largely from rather
> different perspective - a lot of blockchainy transactional scenarios, some
> frankly blueskies but intriguing:
>
> “ For example, anchoring an RDF Dataset that expresses a land deed to a
> Distributed Ledger (aka blockchain) can establish a proof of existence in a
> way that does not depend on a single point of failure, such as a local
> government office“
>
> ... which echoes TimBL’s old
> https://www.w3.org/Talks/WWW94Tim/
>
>
> I do not want to see a repeat of the JSON-LD 1.0 vs 1.1 debacle, in which
> the massive success of Schema.org’s use of JSON-LD 1.0 in the public Web
> was used to persuade the W3C AC to launch a Working Group focussed on just
> those aspects of the technology (contexts) which don’t work well for the
> web scale search, and which didn’t address the needs of the project that
> had been uses to justify the WG. As discussed elsewhere this week, that
> effort resulted in W3C marking as superseded/abandoned the very technology
> (JSON-LD 1.0) that we at Schema.org were proud to have helped to success,
> and which we now can’t even reliably cite as a stable web standard.
>
> If this WG is addressing needs around RDF for blockchains, or supporting
> software to compare, check and maybe diff RDF graphs, the charter should be
> clearer about this limited scope.
>
> The charter opens as follows:
>
> “ There are a variety of established use cases, such as Verifiable
> Credentials <https://www.w3.org/TR/vc-data-model>, the publication of
> biological and pharmaceutical data, consumption of mission critical RDF
> vocabularies, and others, that depend on the ability to verify the
> authenticity and integrity of the data being consumed (see the use cases
> <https://w3c.github.io/lds-wg-charter/explainer.html#usage> for more
> examples).”
>
> Currently the charter only alludes wavily to a “variety of established use
> cases”, and cites its specific “use cases” for “more”. The established ones
> also should be explicitly listed and analyzed to make sure they also
> motivate the proposed specific technical agenda, which is highly focussed
> on technicalities around bnode-labeling in RDF data.
>
>  For each of these usecases we should ask, amongst other things, whether
> signing the raw bits might work, and if not, how much additional
> surrounding information is needed - eg base URI, referenced
> schemas/ontologies, json-ld contexts, GRDDL transformes; and whether the
> reference-tracing recurses or not. And why.
>
> Sorry for the long note. I just don’t want to see another RIF-like 5 year
> slog happen because a cloud of similar ideas was mistaken for a shared
> standards-making agenda.
>
> Cheers,
>
> Dan
>
> (Sent from my personal account but with a danbri@google.com hat on)
>
> On Tue, 6 Apr 2021 at 11:26, Ivan Herman <ivan@w3.org> wrote:
>
>> Dear all,
>>
>> the W3C has started to work on a Working Group charter for Linked Data
>> Signatures:
>>
>>     https://w3c.github.io/lds-wg-charter/index.html
>>
>> The work proposed in this Working Group includes Linked Data
>> Canonicalization, as well as algorithms and vocabularies for encoding
>> digital proofs, such as digital signatures, and with that secure
>> information expressed in serializations such as JSON-LD, TriG, and N-Quads.
>>
>> The need for Linked Data canonicalization, digest, or signature has been
>> known for a very long time, but it is only in recent years that research
>> and development has resulted in mathematical algorithms and related
>> implementations that are on the maturity level for a Web Standard. A
>> separate explainer document:
>>
>>    https://w3c.github.io/lds-wg-charter/explainer.html
>>
>> provides some background, as well as a small set of use cases.
>>
>> The W3C Credentials Community Group[1,2] has been instrumental in the
>> work leading to this charter proposal, not the least due to its work on
>> Verifiable Credentials and with recent applications and development on,
>> e.g., vaccination passports using those technologies.
>>
>> It must be emphasized, however, that this work is not bound to a specific
>> application area or serialization. There are numerous use cases in Linked
>> Data, like the publication of biological and pharmaceutical data,
>> consumption of mission critical RDF vocabularies, and others, that depend
>> on the ability to verify the authenticity and integrity of the data being
>> consumed. This Working Group aims at covering all those, and we hope to
>> involve the Linked Data Community at large in the elaboration of the final
>> charter proposal.
>>
>> We welcome your general expressions of interest and support. If you wish
>> to make your comments public, please use GitHub issues:
>>
>>    https://github.com/w3c/lds-wg-charter/issues
>>
>> A formal W3C Advisory Committee Review for this charter is expected in
>> about six weeks.
>>
>> [1] https://www.w3.org/community/credentials/
>> [2] https://w3c-ccg.github.io/
>>
>>
>> ----
>> 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
>
>