Re: Use case for g-snaps

Sandro,

On 30 Sep 2011, at 06:52, Sandro Hawke wrote:
> SOLUTION A: Charlie Publishes a Copy of G1

That's a perfectly workable solution AFAICT.

>        I've implemented this kind of thing, but it always makes me a
>        bit nervous, because Charlie could change page2.  

In SOLUTION B, Charlie could change the embedded graph literal in just the same way. This is a shared limitation between SOLUTION A and SOLUTION B. It's a problem only if Alice doesn't trust Charlie. In that case we'd need a trusted third party that takes snapshots of things on the web (like the Wayback Machine, but perhaps with snapshotting on demand). On the named graphs level, that solution looks exactly the same except that it puts page2 on a different domain.

>        This seems quite inefficient, but it might not be as bad as the
>        alternatives.

This inefficiency is again shared with SOLUTION B. SOLUTION B requires making a copy of G1 too. SOLUTION A requires an extra HTTP request, SOLUTION B bloats Charlie's graph. Their relative efficiency depends on the size of G1. SOLUTION A is more efficient than SOLUTION B if G1 is large.

The inefficiency in SOLUTION A can be avoided if Charlie publishes a timestamp and/or hash for G1, as you describe in SOLUTION C.

> SOLUTION-C: Charlie Characterizes G1
> 
>        Maybe there's a way to know about Errol changing the graph
>        without transmitting the graph. For instance, Charlie might
>        include a hash of the contents:

I'd say that hashes, timestamps and so on are clearly out of scope for RDF-WG.

> It's not clear to me yet which parts of this are our domain to
> standardize.    Certainly "{...}" or "turtleText" are.  

Those would be in scope for RDF-WG.

> Maybe "cameFrom"
> and "hashWhenFetched".   Probably not "agreement", at least not in this
> fuzzy form.

None of those are in scope for RDF-WG. They are in scope for PROV-WG.

(Another point regarding your use case: Errol shouldn't have fixed his mistake in place, but deleted the old assertions and published a corrected account under a new address. The latter should be considered best practice in situations of this kind. We can't really expect Charlie to do extra work to ensure that Errol can fix the mistake in place – the incentives are not right. His motive is probably only to prevent Alice from making a poor decision based on Errol's disinformation, not to protect Errol's reputation.)

Best,
Richard

Received on Friday, 30 September 2011 09:12:47 UTC