- From: Aldo Bucchi <aldo.bucchi@gmail.com>
- Date: Mon, 24 Nov 2008 12:11:39 -0300
- To: "Kingsley Idehen" <kidehen@openlinksw.com>
- Cc: "Peter Ansell" <ansell.peter@gmail.com>, public-lod@w3.org
Kingsley, All, On Mon, Nov 24, 2008 at 9:17 AM, Kingsley Idehen <kidehen@openlinksw.com> wrote: > > Peter Ansell wrote: >> >> 2008/11/24 Kingsley Idehen <kidehen@openlinksw.com >> <mailto:kidehen@openlinksw.com>> >> >> >> Peter Ansell wrote: >> >> 2008/11/23 Juan Sequeda <juanfederico@gmail.com >> <mailto:juanfederico@gmail.com> <mailto:juanfederico@gmail.com >> <mailto:juanfederico@gmail.com>>> >> >> >> Hi Giovanni and all >> >> >> On Sat, Nov 22, 2008 at 7:33 PM, Giovanni Tummarello >> <giovanni.tummarello@deri.org >> <mailto:giovanni.tummarello@deri.org> >> <mailto:giovanni.tummarello@deri.org >> <mailto: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 >> <http://pipes.deri.org> <http://pipes.deri.org> interface for >> mashups, as some fairly sophisticated mashups can be done on >> pipes.deri.org <http://pipes.deri.org> >> <http://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 >> >> Peter, >> >> Has anything happened re. cross-linking the data across >> bio2rdf.org <http://bio2rdf.org> and dbpedia.org <http://dbpedia.org>? >> >> >> I have been waiting for information about what progress has been made with >> the community based infobox extraction framework. Then the relevant >> predicates in the protein/gene/chemical infoboxes can be used pretty easily >> for linkages. > > So I am assuming this hasn't happened, based on your response? >> >> >> Sane cross-linking is vital to Linked Data Web oriented Meshups. >> >> Note, there is a distinct difference between a Mashup and a Meshup >> in my world view. Mashups are nice looking opaque Web pages that >> have code behind them while Meshups are transparent Web pages with >> Linked Data behind them (i.e. the data object URIs are accessible >> to machines). A Meshup style page is really the Linked Data Web's >> equivalent of a traditional DBMS View. >> >> >> I do understand the difference, but I tend to use the term mashup for any >> combining of the data sources independent of the presentation. Its hard >> enough defining a mashup when people ask for a definition without going for >> another similar term from my experience. > > Labels are very secondary in how I tend to look at things. In due course the > difference between "Mashing" and "Meshing" will be self evident, especially > if we get all the major Linked Data hubs connected properly. Connecting Linked Data hubs is the name of the task at hand then. Is there a wiki where community workflows can be instantiated for this? for example: * Hey, I think there is some alignment between bio2rdf and dbpedia. * here are some examples of these links * and then some tools/processes that can aide the process... Mapping is inherently an inter-dataset process and subject to duplication of efforts, we will need a central place to query for the state of the art. The gap discovery ( amongst far away datasets ) and linking process per se can be also potentially aided by software. And then, what happens with transitively linked datasets? Any rules to materialize these links? should these yield provenance metadata? ( just talking in the air here, no concrete examples, but I can imagine that in the future we will end up with tons of noise ) > > Kingsley >> >> Cheers, >> >> Peter >> > > > -- > > > Regards, > > Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen > President & CEO OpenLink Software Web: http://www.openlinksw.com > > > > > > Best, A -- Aldo Bucchi U N I V R Z Office: +56 2 795 4532 Mobile:+56 9 7623 8653 skype:aldo.bucchi http://www.univrz.com/ http://aldobucchi.com PRIVILEGED AND CONFIDENTIAL INFORMATION This message is only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If you are not the intended recipient, please do not distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail. INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL Este mensaje está destinado sólo a la persona u organización al cual está dirigido y podría contener información privilegiada y confidencial. Si usted no es el destinatario, por favor no distribuya ni copie esta comunicación, por email o por otra vía. Por el contrario, por favor notifíquenos inmediatamente vía e-mail.
Received on Monday, 24 November 2008 15:12:20 UTC