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

On 5/11/21 6:30 AM, Dan Brickley wrote:
> The point: this isn't just about letting RDF people have a 
> triples/graphs reading of some useful instance data. It is about
> W3C's REC-track claims that being RDF data wholeheartedly rather than
>  coincidentally, includes constraints on the how the truth of the
> whole (graph/description) relates to the truth of its constituent
> claims.

The point isn't concise and specific enough to analyze. I expect there
is a whole class of things you're suggesting the WG might consider that
should be out of scope. For example:

Out of scope:

* "Truth" should be out of scope, we're just trying to canonicalize a
bunch of quads and digitally sign them, not determine if the statements
truth can be evaluated as that can easily devolve into subjective truth
vs. objective truth. We were very careful to avoid that tarpit in the
W3C Verifiable Credentials WG.

* "Can I trust that the RDF ontology used to digitally sign the triples
at the time was the same ontology that I'm using" is absolutely out of
scope in this first iteration. It's an important question, but you can
address many use cases with constrained and well known/stable ontologies.

* OWL reasoning is out of scope. If folks want to kick off a WG to
contemplate the ramifications of this work on OWL reasoners, great...
but in a later group as that's a higher-order class of problem than the
simpler, lower-level stuff the LDS WG charter is proposing.

Dan, it feels like many of your concerns can be addressed by "Out of
Scope" statements. It would be easier to understand what you wanted if
you were to make some simple statements of the following form: "I'm
concerned that X is going to derail the group; let's put X out of
scope". It would be easier to analyze and process those sorts of statements.

> If t-23236 says (of whatever entity / URI) "trueUntil": "Thursday",
> ... "foo": "bar", or "pa12bg12f1g12c2": "FALSE", ... their ability to
>  pollute the rest of the graph or make it unclear whether an asserter
> of the graph has really asserted t-1, t-2, t-3, ...

This is confusing to me -- isn't this a solved problem? This is why we
created W3C Verifiable Credentials... so you can easily understand which
entity said what, when they said it, the thing they said it about, and
that you can draw a neat line around all of those things... all so you
can avoid the graph pollution you refer to above. What am I missing?

> The drafting around this WG seems to lean towards JSON-LD, where
> there is some perceived ambivalence towards aspects of RDF (hi
> Manu!:)

Hi. :)

Yes, there are some parts of RDF that we shouldn't be ambivalent
towards, but should put out of scope so that the WG is tightly scoped so
we can focus on the first couple of steps instead of it turning into a
large expedition.

> This is a legitimate point of view. JSON-LD is defined by its W3C 
> specifications and to some extent by the pragmatics of how it is 
> actually used, rather than the aggregate of the opinions of its
> creators and spec editors. But it shines a light on whether this WG
> is on board with what W3C claims RDF data structures mean, when
> considered to be sets of statements about the world.

I'm not sure anyone here could articulate what the W3C RDF specs mean
because there is 25+ years of history here... there are many opinions
and I don't think that discussion helps us get to a more focused charter.

Putting things out of scope do... can we focus on that?

> Another example that crosses back into Phil's point here, is around 
> unique identification in the face of bnodes using 
> reference-by-description constructions. OWL provides a notion of
> inverse functional property, so that you can use property values as
> indirect identifiers. If the instance data is understood to be OWL
> written in RDF written in JSON-LD, readers of the claims could read
> some data as "*the* x whose foo is bar", e.g. '*the* Language whose
> bcp47 code is "he".' The RDF layer doesn't provide the reading of
> this as saying '*the*'; viewed purely as RDF triples it'd be more
> like saying "*a* Language whose bcp47 code is "he". And to Phil's
> point below, even the claim that the bcp47 property is
> owl:InverseFunctional would depend on actually having access to the
> (possibly evolving) remote schema. Not to mention knowing or caring
> what the associated OWL bits of it mean.

Out of scope. It's important work, but for later, and a smaller group of
people that are actually affected by that particular quagmire. There are
more practical use cases that need to be solved today that don't depend
on an answer to the above.

> Saying "it's RDF" and "it's signed" --- what does that mean in
> practice about the stuff being signed? Presumably something more than
> "it could be loaded into an RDF database". But what exactly? Is the
> atomicity of RDF graphs being a bunch of AND-ed independent
> statements part of the picture, but OWL not? (unless a bunch of OWL
> folks join the WG?). Or is the RDF-ness of the group purely "you
> could convert to and from RDF and get something useful"?

OWL reasoning is out of scope, it's just a slippery slope that we don't
want to go down right now. It's important work that needs to be done in
the future, but not in this group -- we need to focus.

"RDF Graphs" -- those are not what this group is focusing on, they
create all sorts of provenance issues with the signed information...
this is why we pushed hard for RDF Datasets back in the day... we're
focusing on canonicalizing and generating proofs (e.g., digital
signatures) for RDF Datasets.

Dan, at this point I have no idea if the above is helping or muddying.
What I'd like from you is some sort of simple list of things that you
think could derail the work (or take a ton of time). We could then
easily mark each as in scope or out of scope (and then document that in
the charter or the explainer).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Wednesday, 12 May 2021 02:39:44 UTC