linked data mashups

2008/11/23 Juan Sequeda <juanfederico@gmail.com>

> Hi Giovanni and all
>
>
> On Sat, Nov 22, 2008 at 7:33 PM, Giovanni Tummarello <
> giovanni.tummarello@deri.org> wrote:
>
>>
>> > I guess that is THE question now: What can we do this year that we
>> > couldn't do last year?
>> > ( thanks to the massive amount of available LOD ).
>>
>> Two days ago the discussion touched this interesting point. I do not
>> know how to answer this question.
>> Ideas?
>
>
> We need to start consuming linked data and making reall mashup applications
> powered by linked data. A couple of days I just mentioned the link for
> SQUIN: http://squin.sourceforge.net/
>
> The idea of SQUIN came out of ISWC08 with Olaf Hartig. The objective is to
> make LOD accesible easily to web2.0 app developers. We envision adding an
> "S" compoment to the LAMP stack. This will allow people to easily query LOD
> from their own server.
>
> We should have a demo ready in the next couple of weeks.
>
> We believe that this is something needed to actually start using LOD and
> making it accesible to everybody.
>

How does SQIUN differ to a typical HTTP SPARQL endpoint? So far it accepts a
"query" parameter as a SPARQL select statement and executes the parameter on
(some configured?) SPARQL endpoints from looking at the single sourcefile I
could find [1]. Having said that, I have been holding off getting my bio2rdf
server to actually process rdf but it doesn't look so hard now. (The bio2rdf
server is actually more generic than just biology or even bio2rdf but it is
still named that in response to its origins. And in contrast to SQUIN it
focuses on CONSTRUCT queries rather than SELECT)

On the subject of mashups I have been thinking in the last few days of
combining the bio2rdf server with the pipes.deri.org interface for mashups,
as some fairly sophisticated mashups can be done on pipes.deri.org, but a
lot of the generic queries seem to be better handled at the client level
where people can control with configurations what endpoints are used and
have backups if a particular endpoint fails.

Cheers,

Peter

[1] http://tinyurl.com/6cvdl8

Received on Sunday, 23 November 2008 03:22:56 UTC