search

w3c / rch-wg-charter

Charter proposal for an “RDF Dataset Canonicalization and Hash Working Group”
https://w3c.github.io/rch-wg-charter/
Other
12 stars 7 forks source link

Add a reference to the RDF-DEV CG to the groups to liaise with #20

Closed iherman closed 3 years ago

iherman commented 3 years ago

The RDF Dev CG is responsible for the development of RDF-star which may also become a work item for W3C. It would be good if there was a clear path for signing RDF-star datasets (even if non-normative...).

cc @pchampin @msporny @dlongley

msporny commented 3 years ago

It would be good if there was a clear path for signing RDF-star datasets (even if non-normative...).

+1 to adding RDF Dev CG as a liason.

I'm struggling to understand what feature (other than syntactic sugar) RDF-star is adding to the ecosystem. It feels like all use cases in the document can be solved using N-Quads? I'm sure I'm missing something critical... I've always struggled to understand the benefit of RDF-star over N-Quads... perhaps it's that RDF-star is to C what N-Quads (currently) is to assember? The end result is the same, but the former is easier to work in than the latter?

One of the things that I don't understand is why the N-Quads syntax needs to change (instead of just translating Turtle RDF-star to N-Quads). RDF-star feels like it could just be a good macro language that "compiles" to N-Quads.

aidhog commented 3 years ago

I'm struggling to understand what feature (other than syntactic sugar) RDF-star is adding to the ecosystem.

I feel the same. It is an interesting proposal but it does not fully solve the issue it is trying to solve, per the Grover Cleaveland example, who was U.S. president from 1893 to 1897, and again from 1885 to 1889. As far as I know, we cannot write:

<< :GLCleaveland :president :US >> :start 1893 ; :end 1897 .
<< :GLCleaveland :president :US >> :start 1885 ; :end 1889 .

... and keep the data separate, which is to say we cannot "pair" the start and end dates. We would still need to create new nodes to represent the presidency (per RDF). We could, however, cover this case quite easily Quads.

That said, I don't think it would be difficult to adapt or define canonicalisation for RDF-Star.

pchampin commented 3 years ago

I won't argue here about the relative merits of RDF-star and N-Quads :) Let's just says that RDF-star has quite some momentum, so addressing it seems important.

I also agree that this should not be too difficult. For the purpose of signing/hashing, emulating RDF-star with N-Quads seems the simplest path.

iherman commented 3 years ago

I leave the pros and cons of RDF-star to @pchampin. But, semantically speaking, it is correct that it can be considered as some sort of a complex syntactic sugar on top of n-quads. That is actually what the semantics of RDF-star shows: the semantics is based on the idea of "unstar" an RDF-star, yielding a good-old RDF graph, and all the rest is based on that one.

Signing/hashing an RDF-star would probably mean using the 'unstar' (with some specificities), and then use what we will define in the WG to produce a signature. Ie, this may end up being a short non-normative section in our final document, which is perfectly o.k. To come back to the original proposal, adding this explicitly to the charter simply means that the RDF-star community would not feel disenfranchised...

There is also a more interesting aspect on long term: RDF-star is a step towards property graphs and their community. Whether that means that the signature work can be extended towards property graphs or not (and whether that community needs that or not) is for further thoughts (but that is definitely not for the charter!).

(One could argue of course that TriG is also just syntactic sugar on top of n-quads. And it certainly is. Except that n-quads is not really made for humans, TriG is... There is an analogy here.)