Re: bootstrapping decentralized sparql

Hi Peter,

we all like to think "p2p", distributed, etc.
but the fact is that we love it too much, disregarding the basic
economic reasons that underly how the world (in fairness) works.

But lets put a constraint.

Lets imagine that we dont live forever and tha tthe time one should
work on a topic should be limited (e.g. 10years is a good span so i
began in 2002, 3 years left) dont you want to see some actual
advantange delivered to the end user within this timeframe? I do and
very strongly.

Google and Sindice are NOT closed infrastructures. They work on  open
standards and anyone can implement something like this given the
proper economics and engineering.

Google falls tomorrow, we all use Yahoo Search (which works very well
IMO) or MSN .. etc.anything that's useful on the web will have an
economic value which will keep it alive.

Think of this same discussion like 15 years ago. Immagine that as
Search engines emerge, people would be discussing about "instead using
automatic methods for trackback links across websites becouse this
search engine thing wont really go nowhere"
how realistic and useful would these discussion have been in
hindsight? would these discussion have been the best thing to do to
bring the web "to its full potential"?

this is NOT to say however that the model is clear! Semantic Search
engines (that is an engine which really helps the semantic web) are
all but something that we know exactly how to do or how it should
behave. Lots of work to do really.

Anyway :-)

On my side i can just say that we are committed (e.g. i have base
http://sfi.ie funding for the next 4 years for example) to making life
simpler, spare a lot of hard work to many on the Semantic Web
therefore acting as a catalyst to, hopefully, very exciting apps to
come.

Giovanni

On Sun, May 17, 2009 at 3:08 AM, Peter Ansell <ansell.peter@gmail.com> wrote:
> 2009/5/17 Giovanni Tummarello <g.tummarello@gmail.com>:
>>> for graphs which use a (specific) FOAF term.  It's a bit like
>>> PingTheSemanticWeb or Sindice, but decentralized based on the ontologies
>>> used.
>>
>> [....]
>>
>> Isnt this like saying  "why set up  an infrastructure with
>> professional developers and administrators,  in a backed up , UPSed
>> datacenter..
>> .. when you can ask each ontology creator to do the same."
>
> Why spend resources on creation and upkeep of a triple store and
> search service when an ontology creator can distribute the information
> more efficiently using references to endpoints in their ontologies?
>
>>> The result here will be that a query for a foaf:Person with a
>>> foaf:firstName of "Sandro" can be *complete*, at least across all graphs
>>> which choose to register themselves as having data about instances of
>>> the foaf:Person class and triples using the foaf:firstName property.
>>
>> please explain how this that you describe is different from what's
>> possible already
>>
>> http://sindice.com/search?q=foaf%3Aname&qv=Sandro+Hawke&qt=ifp
>
> It doesn't rely on a single search engine. What happens when the rdf
> web equivalents of google go down? ;) Granted that the ontology
> authors being required for the loop with distributing query
> information is not perfect, but it shows there are other possibilities
> to solving the discovery and query federation problem than just brute
> force and large data stores.
>
> Another alternative to predicate based query federations are the URI
> prefix solutions that I have been developing for the Bio2RDF server
> (although they can be applicable to any domain). The set of providers
> at [1] can be used in a similar way to the predicate and type
> federations described by Sandro here. If you configure queries in [1]
> without regard to the URI prefixes the result is similar to predicate
> based distribution systems. The configuration information is also
> lightweight enough to be distributed easily.
>
> For almost any query that is resolvable with the Bio2RDF server you
> can fetch the instructions using URI's like [2] and perform the query
> resolution process yourself using the same algorithm that the server
> would have used by finishing the resolution. The process is simply
> performed for any RDF URI's that come back from [2] with the rdf:type
> [3]. Being able to have several servers that enable RDF query planning
> without needing to perform any resolution or data storage themselves
> might be a good step towards common federation models in a lightweight
> manner.
>
> Cheers,
>
> Peter
>
> [1] http://qut.bio2rdf.org/admin/configuration/rdfxml
> [2] http://qut.bio2rdf.org/queryplan/pageoffset1/links/geneid:11234
> [3] http://bio2rdf.org/ns/querybundle#QueryBundle
>

Received on Sunday, 17 May 2009 08:07:28 UTC