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

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

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.

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. 

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

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 <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 <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 <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/ <https://w3c-ccg.github.io/security-vocab/> 
> {
>   "@context": ["https://w3id.org/security/v1 <https://w3id.org/security/v1>", 
> "http://json-ld.org/contexts/person.jsonld <http://json-ld.org/contexts/person.jsonld>"]
>   "@type": "Person",
>   "name": "Manu Sporny",
>   "homepage": "http://manu.sporny.org/ <http://manu.sporny.org/>",
>   "signature": {
>     "@type": "GraphSignature2012",
>     "creator": "http://manu.sporny.org/keys/5 <http://manu.sporny.org/keys/5>",
>     "signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
>   }
> }
> 
> This uses the following json-ld context:
> 
> http://json-ld.org/contexts/person.jsonld <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 <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 <http://schema.org/Person> gets updated, e.g. to use https://schema.org <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/ <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 <mailto:danbri@google.com> hat on)
> 
> On Tue, 6 Apr 2021 at 11:26, Ivan Herman <ivan@w3.org <mailto: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 <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 <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 <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/ <https://www.w3.org/community/credentials/>
> [2] https://w3c-ccg.github.io/ <https://w3c-ccg.github.io/>
> 
> 
> ----
> Ivan Herman, W3C 
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +33 6 52 46 00 43
> ORCID ID: https://orcid.org/0000-0003-0782-2704 <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