W3C home > Mailing lists > Public > semantic-web@w3.org > February 2010

Re: Salmon Protocol for automatic RDF store augmentation?

From: John Panzer <jpanzer@google.com>
Date: Fri, 29 Jan 2010 09:31:57 -0800
Message-ID: <cb5f7a381001290931l5928fbb7na53e76bac25c7594@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Danny Ayers <danny.ayers@gmail.com>, Semantic Web <semantic-web@w3.org>
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

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

On Fri, Jan 29, 2010 at 4:22 AM, Melvin Carvalho

> 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
Received on Monday, 1 February 2010 02:43:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:16 UTC