Re: Use case for g-snaps

On 30 September 2011 06:52, Sandro Hawke <sandro@w3.org> wrote:
> On Fri, 2011-09-23 at 20:19 +0100, Richard Cyganiak wrote:
>> On 22 Sep 2011, at 20:02, Sandro Hawke wrote:
>> >> Assuming the data is retrieved from the web (that is, all data is
>> >> received as a representation of some resource that has a URL), then I
>> >> believe that all these issues can be solved using three ingredients:
>> >>
>> >> 1. a graph store for named graphs,
>> >> 2. vocabulary for expressing authorship, trust/reputation and
>> >> source/mirror relationships,
>> >> 3. an incentive for parties on the web to publish trust/reputation
>> >> information.
>> >
>> > I didn't call this out in my examples, but how do you handle the cases where data changes?  How can I say that Errol got the name wrong, in a way which won't make me wrong if he corrects himself?
>>
>> Can you expand a bit? Your use case mentioned the risk that Alice might be mislead into visiting the wrong restaurant because Errol misfiled his review under the wrong restaurant. You seem to have something more than that in mind. Someone comes in saying that Errol's review is misfiled? Then Errol fixes his review? What exactly is the full story?

Here's another related story. It is semi-fictional!

Someone hacks the server hosting a popular RDF vocabulary. Let's say
FOAF. They add malicious triples to the RDF/XML schema.

Let's say the RDF/XML is (as it used to be) PGP-signed with each
legitimate update. This allows applications that choose to merge or
layer key schemas into their trusted environments, to check whether
they're happy to do so.

Does the notion of g-snaps help articulate what is happening here, and
encourage application developers to avoid open-endedly trusting
whatever they find at namespace URIs?

Dan

Received on Friday, 30 September 2011 06:44:58 UTC