Hi!

> common for WDQS, since people check for labels that are not in the data
> when doing database integration). Even if there are zero results, this
> must either be computed or returned from cache.

Exactly, people do searches like "does this random string look like a
movie name" against both Wikipedia and Wikidata.

> (2) It is misleading since the number of triple patterns is astronomic
> even when restricting to URLs and literals that exist in Wikidata:
>   -> Number of Item-Property-Item triple patterns with one variable:
>     23M x 829 x 2 + 23M x 23M = 529 * 10^12
>         (0.5 Quadrillion)

Note that we also have non-item nodes - like statements and value nodes
- that can come into play if we want to deal with non-current data (such
as list of US presidents), units, coordinates, etc. So the above is
undercounting the real dataset size. That's why I am somewhat skeptical
about how useful naive request caching (one that is not specialized for
this use case) would be.

> * Are request numbers no problem because requests are simple? This
> really depends on the database implementation behind the service. Surely
> it helps if the database has less work. But there is also the notion of
> "thrashing" a database, where you destroy performance not by difficult
> queries but by large numbers of simple ones. Moreover, other components
> of the server could also be challenged, such as logging or other types
> of filtering that happen before you even get to the DB.

This is definitely a factor, so we'll be watching the usage/load numbers
and see if we notice anything dangerous.

> I realise that I am being rather critical here, but I think we must
> cross-check if it is realistic to assume that this approach could become
> useful for Wikidata at some point before investing much more staff time
> into it. I have supported this work as a research work, and I still do,

I don't think we plan to invest more time than we already did into it.
The endpoint is up now, we don't really plan to do anything additional
with it - it's for the users now to see if it's useful. We'll be
watching to see whether it is not overtaxing resources and not dragging
SPARQL part down, but otherwise for now that's all the investment we're
doing for now. If we come up with some use case helpful for us we would
then implement it but nothing planned yet.
-- 
Stas Malyshev
[email protected]

_______________________________________________
Wikidata mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply via email to