[foaf-protocols] P2P FOAF search
luke at maurits.id.au
Fri Jun 5 10:08:29 CEST 2009
> +1 on XMPP :) I made some experiments with it here -
Cool, I will check that out, thanks!
> I certainly think this kind of search is worth exploring, but I'd
> hesitate re using it just for things described directly in the FOAF
> So I encourage you to explore this but try to have a design which from
> day 1 doesn't exclude these inter-related types of data. For example
> searching in this way for information about opensource software could
> use DOAP, an RDF vocab which links FOAF to the world of opensource
> collaboration. Or SIOC, which covers in more detail the description of
> content and discussion in online fora.
A very valid point. It makes me wonder if it wouldn't actually make more sense to build a P2P network for generic RDF searching and just develop (in addition to general clients, obviously), FOAF-specific clients that hide unecessary generality from users for the sake of friendliness. The downside to this is that such a network would probably get a lot more traffic on it.
> Did you take a look at SPARQL yet?
I have but I get the distinct impression that a few more pennies need to drop. My current gloss of SPARQL is basically
"SQL for RDF", i.e. a query language defined over triples rather than tables. There's obviously a lot more to it than that, though, since people are throwing around terms like "SPARQL endpoint" with more gravity than would seem appropriate given my current level of understanding. Admittedly I need to do a lot more homework in this area.
Nevertheless, it still seems like a no-brainer even to me that SPARQL could/should be used as part of the hypothetical P2P network under discussion, from the points of view of (i) not re-inventing wheels that work well and (ii) enabling usage of non-FOAF vocabularies in search, as mentioned earlier. This makes your jqbus project all the more relevant since the core of the P2P system would really just be passing SPARQL query strings around via XMPP. The extra work would really just be having each node re-distribute queries it couldn't answer to other nodes on its XMPP roster, and adding a time-to-live counter (to prevent endless propagation of stale queries). I'd need to refresh my understanding of XMPP to be sure there's not more required than this, though. Anyway, if it does turn out to be such a relatively simple extension it feels like it would make more sense to add to your codebase than reimplement from scratch, at least for testing the idea out.
> http://aksw.org/Projects/xOperator is also related, see also
> http://blog.dbtune.org/post/2008/02/25/Playing-with-SPARQL-and-XMPP and
> I think Benjamin Nowack has made some similar experiments, re the layer
> for going between user-supplied queries and sparql: see
Thanks, I will check these out too.
> Definitely interested! I think the first point to think about is what
> requirements these scenarios might have which diverge from straight "out
> of the box" SPARQL querying. One thing to keep an eye on is the new
> SPARQL group at W3C, who for example are looking at adding constructs
> for full-text query (see
> http://www.w3.org/2009/sparql/wiki/Feature:FullText) and are also I
> think talking about simple distributed query as well. The work on
> service description there is also relevant - see
Luke Maurits <luke at maurits.id.au>
CompCogSci | Crypto | Maths | Python | Unix
More information about the foaf-protocols