Hi Kingsley,

>> will see a substantial increase in server costs
>> when they try to host that same data as a public SPARQL HTTP service.
>
> Again subjective.

No, that's not subjective, that's perfectly measurable.
And that's exactly what we did in our research.

The problem with the SPARQL protocol as an API
is that the per-request cost is a) higher
and b) much more variable than any other API.

Everywhere else on the Web,
APIs shield data consumers from the backend,
limiting the per-request complexity.
That's why they thrive and SPARQL endpoints don't.

Don't get me wrong, I'm happy with every
highly available SPARQL endpoint out there.
Wikidata and DBpedia are awesome.
It's just that there are too few
and I see cost as a major factor there.

> You are implying that cost vs benefit analysis don't
> drive decisions to put services on the Web, of course they do.

Quite the contrary, I am arguing that—and this is subjective—
because cost/benefit analyses drive decisions on the Web,
we will never have substantially more SPARQL endpoints
on the public Web than we have now. They're just too expensive.

>> Federation is where I think public SPARQL endpoints will fail,
>> so it will be worthwhile to see what happens.
>
> Really, then you will ultimately be surprised on that front too!

I really really hope so.
If one day, machines can execute queries on the Web
as well as we can, I'd be really happy.
My way to reach that is lightweight interfaces,
but if it is possible with heavyweight interfaces,
all the better.

Best,

Ruben


_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata