[Tracker] Distributed joins, federated SPARQL queries

[Philip Van Hoof <philip codeminded be>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,

I was made away by the writers of one of these articles about research
certain people are doing in federated sparql endpoints and distributed
joins. The sites are all public so I guess I can share them here.

https://data.vandenabeele.com/docs/distributed-joins
http://www.slideshare.net/RubenVerborgh/linked-data-fragments
http://arxiv.org/pdf/1407.2899v1.pdf
http://www.w3.org/TR/sparql11-federated-query/

Some of them talk about letting the clients obtain a cache of data
that can be joined locally.

A use-case that I have in mind would be two smartphones of two friends
that have a trust relationship with each other and have configured
their devices to allow sharing of certain data: Friend-A wants to do a
query on both smartphones to return the metadata of songs that they
both like.

In this case the join is on nao:hasTag: Friend-B could send that
joinable information over the wire to allow Friend-A's phone to solve
the query locally (for the songs that are on both phones).

What would be required is a unified resource locator (not file://)
and/or a standardized <subject>-format shared between devices.

The join would be on the nao:hasTag relationship between the subjects
and the tag "Like". That's what would need to be sent from Friend-B to
Friend-A (maybe in a diff fashion like IMAP's QRESYNC or CONDSTORE -
where Friend-A would first inform Friend-B of a MODSEQ, our
tracker:modified field is perfect for that, so that Friend-B knows
what the mimimal changes are Friend-A needs to get its local joinable
nao:hasTag data cache current).

Being a SPARQL endpoint for embedded and mobile clients I think the
Tracker project should pay attention to the ideas flowing around in
this field.

I'm hoping that you all will read above links and references and think
about possibilities.

It's not impossible I think. I'm sure there are other ideas and
possibilities, and I'm sure it'll be hard.

Kind regards,

Philip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxisiAAoJEEP2NSGEz4aDefgIAILJb85S5/D/jZlJRcsjRCnc
qdsX1K44ZeGxN+yG6AVdUQT1J0+s5HwBrrQTmlvN25HoxzlnXhyIm9W7Gz7wiNcH
YP2CDfKzLKes0vVOO7Svg4KfTe4ILfaDrr9NU4UqVONkqqHWS+trvCQ4EzBay3VA
flFlFp+FLSNLqivfdyTly3cxw8dYUMdqOT94JKdWZdo+X3MXYRGorWigckrj+wSz
iyCXFQmC41rQ5IBX51lFD4EHHp/P5QSUjYWRl6WQUXOHJW81V+VjaoY8Dxd9U9zn
TgtDLX9OOjMDdXPGRY4pGk9YZQFPXvsKlKtwiIkfNDfdPZasElDGNwi1SvbztJ4=
=ILPz
-----END PGP SIGNATURE-----