- From: Simon Schenk <sschenk@uni-koblenz.de>
- Date: Tue, 05 May 2009 15:54:17 +0200
- To: bnowack@semsol.com
- CC: Nicolas Raoul <nicolas.raoul.lists@gmail.com>, semantic-web@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > Even if the new SPARQL WG adds query federation to the spec, you will > most probably need a more procedural approach, something like DERI Pipes, > SPARQLMotion, or SPARQLScript*, in combination with store metadata and > stats (à la voiD[1]) and some broker (e.g. Sindice). The pieces are > currently evolving, but "easy" or "efficient" will need a couple more > years, I guess. > > I can imagine "query expanders" built on top of voiD and Sindice (or > eqivalents), that take your input query and extend it to a set of > sub-queries, with each subquery's resource identifiers > canonicalized/adjusted for the individual target store. Creating such > a helper service could be possible already today, but probably only > for very basic sameAs consolidation. You might want to take a look at NetworkedGraphs [1], declarative rules for RDF formulated in SPARQL. Together with distributed querying, this could be used for your task. Beatnik [2] uses it locally for FOAF smushing. Unfortunately I have to agree with Benji: Applied distributedly and to a non trivial dataset, this will probably be horribly slow. Cheers, Simon [1] https://www.uni-koblenz-landau.de/koblenz/fb4/institute/IFI/AGStaab/Research/systeme/NetworkedGraphs/index_html [2] https://sommer.dev.java.net/AddressBook.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoARQgACgkQQ0Lz1fXAQePnqACeMiMcaccb0fQY+Hdm/M4STTRo URcAn0o5ZzVR9Qv3Vrc9MPdCdt8Megyq =GLHA -----END PGP SIGNATURE-----
Received on Tuesday, 5 May 2009 13:54:57 UTC