Re: Salmon Protocol for automatic RDF store augmentation?

That's an interesting use case.  B would be a service providing additional
assertions back to A, right?  So instead of the signer being an identifier
for a human, it would be an identifier for a service.

And A could re-syndicate B's additions back out as-is ("B says this") and/or
it could just incorporate them directly into its store and send out
resulting updates.

(Note: In Atom-land, we're leaning on PubSubHubbub as the protocol for both
enabling real-time feed data push and computing efficient diffs to send to
clients.  Diffs are entry-based, so either an entire entry is sent or not,
but clients only see the new/changed entries rather than the entire feed
when they're pushed the data.  This may not be granular enough for RDF
though.)

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Fri, Jan 29, 2010 at 4:22 AM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

>
>
> On 29 January 2010 12:48, Danny Ayers <danny.ayers@gmail.com> wrote:
>
>> After seeing reference to it on the Social Web XG list, I've just been
>> reading about the cutely-named Salmon Protocol (summary at [1]) which
>> is primarily intended for use around syndication feeds, passing
>> downstream comments, ratings, and  annotations back to the originating
>> publisher.
>>
>> Thinking out loud, it seems like there could be a handy use for it in
>> data sharing, in effect:
>>
>> * store A broadcasts it has some information about resource R
>> * store B receives the announcement, discovers it has additional
>> information about R
>> * store B passes that information back to store A
>>
>> Suppose we have a triplestore which publishes a recent-additions feed
>> (Atom with an RDF payload) as well as a Salmon Protocol endpoint.
>> These could presumably be implemented as thin wrappers around a
>> SPARQL/SPARQL Update endpoint.
>>
>> We also have a subscriber to the recent-additions feed, which also has
>> a triplestore.
>>
>> Now say the publisher passes along a triple, for example:
>>
>> <http://example.org/fred#me> a foaf:Person .
>>
>> The subscriber receives this and runs a query like:
>>
>> CONSTRUCT { ?s ?p ?o }
>> WHERE { <http://example.org/fred#me> ?p ?o }
>>
>> - and posts the results back to the original publisher, which adds
>> those triples to its store.
>>
>> While I'm sure it would be possible to do this kind of thing more
>> directly using the semweb stack, use of the Salmon Protocol could
>> offer hooks into more traditional content-oriented Atom
>> datasources/sinks. (Noting that Atom can be mapped to RDF).
>>
>> Does that make any sense?
>>
>
> Yes,
>
> Also thinking out loud, I wonder if it would be possible to make it
> realtime and pass only change sets (SPARQL Updates?) or maybe a
> timestamp/hash to see if your version (of the specific data set you are
> interested in) is out of date?  Then you could work on a "sync or update"
> style protocol, and aim to send differences only, where possible.
>
>
>>
>> Cheers,
>> Danny.
>>
>> [1] http://www.salmon-protocol.org/salmon-protocol-summary
>>
>> --
>> http://danny.ayers.name
>>
>>
>