- From: Dan Brickley <danbri@google.com>
- Date: Tue, 4 May 2021 15:01:35 +0100
- To: Phil Archer <phil.archer@gs1.org>
- Cc: Ivan Herman <ivan@w3.org>, Dan Brickley <danbri@danbri.org>, Aidan Hogan <aidhog@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, Pierre-Antoine Champin <pierre-antoine@w3.org>, Ramanathan Guha <guha@google.com>, semantic-web <semantic-web@w3.org>
- Message-ID: <CAK-qy=59kF4+CZC9UfqUXpyTD=Jxh8qY0mHVzTu90ycbgXj7PA@mail.gmail.com>
Thanks Phil, and everyone else who has commented. There's been a lot of
interesting points raised. Ivan's PRs look like progress. But I think now
it might be most useful if Ivan, Phil and the other proposers compared
notes and priorities. For now I'd just add: let's not wait until the WG is
chartered before clarifying usecases - the lack of these may be why there's
apparently disagreement amongst the works primary advocates on what is in
vs out of scope.
cheers,
Dan
On Tue, 4 May 2021 at 14:53, Phil Archer <phil.archer@gs1.org> wrote:
> Hi all,
>
> I was offline over the weekend and yesterday and so have not engaged in
> this conversation so far. It's now spread across two separate threads in my
> inbox, one public (this one), one private, plus a lot of Tweets starting
> with https://twitter.com/danbri/status/1388440913941352448
>
> We see this work as very worthwhile. It is increasingly relevant as GS1
> has its own working group on digital signatures and as GS1 moves towards
> semantic data modelling and use of Linked Data:
>
> * to support digitally signed EPCIS event data (our supply chain
> event data standard)
> * to support digitally signed master data (expressed using terms
> from the GS1 Web vocabulary), so that anyone can know whether Linked
> Data markup about a product was actually signed (and authorised) by
> the brand owner - and that nothing else has been added / removed to that
> data
> * to support digitally signed transaction data when EDI transactions
> align with a semantic approach, as we're starting to see in the
> proof-of-concept work on digital receipts
> * to support verifiable credentials for licences of GCPs, keys etc.
> - and eventually to provide robustness when we use VCs to provide
> trustable evidence of connectedness on a chain of custody or ownership,
> to enable trusted data sharing beyond 1-up/1-down.
> * We would also like to be able to sign the Linkset you get back
> from a GS1 Digital Link resolver, such as
> https://id.gs1.org/01/9506000134352?linkType=all. The underlying data is
> JSON but it will soon have an HTTP Link header to the context file to make
> it JSON-LD.
>
> Those bullet pints were written by my colleague Mark Harrison and me, and
> we used the terms 'Linked Data' and 'semantic' (although not Semantic Web).
> Neither of us used the term RDF.
>
> Both Mark and I are perfectly well aware that LD is an application of RDF.
> When we talk to our constituency of manufacturers, retailers and supply
> chain operators, we use the term Linked Data where necessary (upper case L
> and D). But we also use the phrase "links to other sources of data";
> linksets; link relation types, decentralized data, and, occasionally,
> knowledge graphs. I know that the Linkset cited above, even as JSON-LD, is
> not a Knowledge Graph. I also know that a Web page about a jar of jam is
> not a Digital Twin. Guess what the jam maker calls it? When you see a 2d
> barcode on your electronic boarding pass you probably think it's a QR code.
> Ha! You idiot. I mean, really, how could you not recognise an Aztec code
> when you see one. The finder pattern is completely different!! (sic).
>
> So yes, as we all know, it’s a mess, made messier my marketing. But it's
> also evolution and human nature. RDF (as Dan's pinned tweet at
> https://twitter.com/danbri/status/1386993437472432128 reminds us) is 23
> years old. Of course it's just the term RDF that's 23 years old.
> Entity-relationship diagrams are a lot older.
>
> I would like to suggest an expansion of Ivan's proposed line:
>
> A terminological note: in what follows in this charter, and in the
> terminology to be used by the Working Group, the term “Linked Data” is used
> as a synonym to “RDF”.
>
> To something along the lines of:
>
> The term 'Linked Data' was originally defined in 2006 (@@@ link to
> https://www.w3.org/DesignIssues/LinkedData.html@@@), however, this was
> never a formal definition and the term's use has evolved over time. These
> days it can encompass resolvable URI schemes other than HTTP (notably
> Decentralized Identifiers) and may be used informally as a general term for
> any set of facts linked over the Web. Nevertheless, the work proposed here
> necessarily focuses specifically on the underlying RDF technology. For this
> reason in what follows in this charter, and in the terminology to be used
> by the Working Group, the term “Linked Data” is used largely as a synonym
> for “RDF”.
>
> Where I think I seem to have more sympathy than some with Dan's original
> commentary, is the issue of a fixed/signed dataset containing links to
> external sources of data and definitions that are not under the signee's
> control. That is, if my signed RDF dataset includes data expressed using
> schema:Product, and the definition of schema:Product changes, what value
> does my signature have now? This is an issue that I think the WG will need
> to address - that is, we'll need to set a boundary on what should and
> should not be inferred by the presence of whatever crypto doo-hickey
> surrounds the data. IMO, it seems clear that we cannot sign the meaning.
>
> And there's the irony. We can't sign the semantics in a Semantic Web
> dataset unless we also retrieve all externally-referenced sources and sign
> an immutable local copy of those as well (I'm really hoping no one thinks
> that's a good idea ☹ )
>
> As for use cases, there will be a UCR. We (GS1) will have more to say on
> that of course, as will others. In the meantime, I think that the explainer
> document provides a pretty good overview of the kind of problem that the WG
> is being set.
>
> Phil Archer
> Director, Web Solutions, GS1
> https://www.gs1.org
>
> Meet GS1 Digital Link Developers at
> https://groups.google.com/forum/#!forum/gs1-digital-link-developers
>
> https://philarcher.org
> +44 (0)7887 767755 <07887%20767755>
> @philarcher1
> Skype: philarcher
>
> -----Original Message-----
> From: Ivan Herman <ivan@w3.org>
> Sent: 03 May 2021 15:40
> To: Dan Brickley <danbri@danbri.org>
> Cc: Aidan Hogan <aidhog@gmail.com>; Dan Brickley <danbri@google.com>;
> Manu Sporny <msporny@digitalbazaar.com>; Phil Archer <phil.archer@gs1.org>;
> Pierre-Antoine Champin <pierre-antoine@w3.org>; Ramanathan Guha <
> guha@google.com>; semantic-web <semantic-web@w3.org>
> Subject: Re: Chartering work has started for a Linked Data Signature
> Working Group @W3C
>
> Dan,
>
> Trying to move things ahead I have created two different pull requests:
>
> https://github.com/w3c/lds-wg-charter/pull/65 with Preview <
> https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/pull/65.html> :
> https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/pull/65.html
> Diff:
> https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/65/7ace91f...38507c3.html
>
>
> https://github.com/w3c/lds-wg-charter/pull/66 with
> Preview:
> https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/pull/66.html
> Diff:
> https://pr-preview.s3.amazonaws.com/w3c/lds-wg-charter/66/7ace91f...e306629.html
>
>
> The first is a minimal change: it just adds a sentence on the LD/RDF
> equivalence (plus incorporates a separate proposal by Andy to rename one of
> the deliverables). The second is a maximal change in that in uses the term
> RDF uniformly everywhere (including the name of the WG).
>
> At this point I am not sure which of the two changes are better, in view
> of we said about the problem with the term "Linked Data". I expect that,
> apart from the exact wording, the first version is not controversial; I do
> expect some problems with the second version, in view of the differences
> among communities. But I want to get the discussions to continue on
> concrete versions rather than generalities.
>
> However, Dan, I also tried to find the quotes you criticized, like
>
> > ...W3C isn’t helping itself with the “this secures the authenticity and
> integrity of the web of linked data” hype.
> > ...secure the integrity and authenticity of the fast growing web of
> linked data
>
> and I did not find those (I would agree that, if they were there, we would
> need to reduce hype). Either I really have to get my glasses changed or we
> are not looking at the same document…
>
> Cheers
>
> Ivan
>
>
>
>
>
> On 3 May 2021, at 15:25, Ivan Herman <ivan@w3.org <mailto:
> ivan@w3.org> > wrote:
>
>
>
>
> On 3 May 2021, at 14:54, Dan Brickley <danbri@danbri.org
> <mailto:danbri@danbri.org> > wrote:
>
> On Mon, 3 May 2021 at 10:06, Ivan Herman <ivan@w3.org
> <mailto: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?
>
>
> Yes, that too. But the problem is slightly different, I believe: I
> am concerned about institutions not realizing that when we talk about RDF
> Graphs and Datasets, those are the same as what they know as Linked Data
> and Linked Data Sets (emphasis on 'what they know as'!)
>
>
>
>
> 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.
>
>
> Dan, I know that, and you perfectly know I do:-) We are discussing
> about the way this WG would avoid this quagmire. As I wrote below, to make
> it clear I would propose to put this into the charter very clearly so that
> the AC knows what it votes on.
>
>
>
> 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.
>
>
> This is exactly what I proposed at the end of my mail! We seem to
> agree on this, don't we?
>
>
>
> 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.
>
>
> And we do not aim at anything higher. I (and those who are
> co-authors of this charter) happen to believe this is an important tool in
> the 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.).
>
>
> I am sorry, I do not understand the question...
>
>
>
> 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”.
>
>
> Dan, with respect: you are raising questions that are only
> relevant for the original "Linked Data" paradigm and I think we agree that,
> as far as this WG is concerned, we should make it clear in the charter why
> the proposal is not to use that term for more than good-old bare RDF. In
> other words, these questions are not in the planned scope of the WG.
>
> As for "why would anybody care": we did try to collect a number of
> use cases in:
>
> https://w3c.github.io/lds-wg-charter/explainer.html#usage
>
>
>
> 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.
>
>
> We can try to reduce the hype, but some level is necessary to
> place the work of the WG in some general context.
>
> If this discussion gets to an equilibrium point, I am happy to
> create a github PR where the fine details and wording can be discussed
> further.
>
> Cheers
>
> Ivan
>
>
>
> 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 <mailto: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 <
> http://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 <http://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 <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 <
> http://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 <http://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
>
> 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
> <+33%206%2052%2046%2000%2043>
> 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
> <+33%206%2052%2046%2000%2043>
> 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 <+33%206%2052%2046%2000%2043>
> 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 <+33%206%2052%2046%2000%2043>
> ORCID ID: https://orcid.org/0000-0003-0782-2704
>
> CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are
> confidential and are not to be regarded as a contractual offer or
> acceptance from GS1 (registered in Belgium).
> If you are not the addressee, or if this has been copied or sent to you in
> error, you must not use data herein for any purpose, you must delete it,
> and should inform the sender.
> GS1 disclaims liability for accuracy or completeness, and opinions
> expressed are those of the author alone.
> GS1 may monitor communications.
> Third party rights acknowledged.
> (c) 2020.
>
Received on Tuesday, 4 May 2021 14:03:35 UTC