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

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
>
>