W3C home > Mailing lists > Public > public-rdf-prov@w3.org > October 2011

Re: Use case for g-snaps

From: Richard Cyganiak <richard@cyganiak.de>
Date: Sun, 2 Oct 2011 13:53:46 +0100
Cc: public-rdf-prov@w3.org
Message-Id: <FC28CA3C-91AD-42A9-B35A-DF59197A6B12@cyganiak.de>
To: Sandro Hawke <sandro@w3.org>
On 30 Sep 2011, at 13:10, Sandro Hawke wrote:
> This means Charlie can't exactly say, "I agree with Error's RDF graph
> (g-snap) G1" because he can't make an identifier for the G-snap G1;
> instead he says "I agree with Error's RDF graph which I have copied to
> this g-box, <foo>".   


> It's like a programming language that always passes by value, never by reference, so there's
> less confusion.

Well, to take the analogy literally, it's more like a programming language that always passes by reference and never by value.

> So, I guess I'm with you on not having a mechanism for directly
> attaching URIs to g-snaps.   People can attach them to g-boxes, and if
> they are confident it wont change, they can just think of it as a
> g-snap.   Hmmmm.

> One approach is like W3C TRs -- there's a "latest URI", where the
> contents changes, and a new "snapshot URI" every time the contents
> change.  (And old snapshots can be deleted to save space whenever you
> want.)  I think this is a good practice,

I agree it's good practice. If you expect your graph to evolve and improve in quality, it certainly helps to create those snapshot IRIs, because others can say things about specific versions.

> but can we really ask everyone with a foaf file to follow it...?   Maybe....   Yeah.....

No, of course not. But FOAF files and restaurant reviews are not realistic scenarios for pointing out an error in someone else's graph anyways. Realistic scenarios might be in publishing of scientific results and government statistics. Asking them to version their graphs is reasonable.

> I've never implemented it, but I've often thought about making snapshot
> URIs include a secure hash of the contents.   So Errol would publish his
> first statement at:
> http://errol.example.org/check-sha/13ae3ec8f7c3b8f814ab8f1da9510ebdc0f8c740f1763f825429e9e8c3c21878
> and Charlie would copy it over to 
> http://charlie.example.org/check-sha/13ae3ec8f7c3b8f814ab8f1da9510ebdc0f8c740f1763f825429e9e8c3c21878
> Here I'm suggesting "check-sha" would signal to receivers that they
> SHOULD confirm the contents.  That means they wouldn't have to trust
> Errol or Charlie not to maliciously or accidentally change things.

Keeping the hash out of band (in HTTP headers or in RDF) works just as well.

> It would essentially force people to follow the practice of making a new
> URI every time they want to change the contents.

That doesn't make any sense to me. Making new IRIs every time you change the content is easy already. It's just that most publishers have little incentive to do so. And the proposal does nothing to address that. It is also rather difficult to deploy on existing software. It is also ugly.

Received on Sunday, 2 October 2011 12:54:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:07 UTC