If you think it is best to implement a more general
feature that adds
even more properties, then I am sure nobody will complain, but it sounds
like more work to me. The number I was asking for is something that you
I don't think it's *much* more work, and I planned to do this work
anyway :) Of course, it may happen that I am wrong about how much work
it is, and then I might reconsider.
compute the number in a SPARQL query from the RDF. It
is a completely
redundant piece of information. It's only purpose is to make SPARQL
queries that currently time out fast. In databases, such things are
called "materialized views".
Speaking of which, Blazegraph does have support for inferring data, but
I don't want to open that particular can of worms just yet.
This leads to a slightly different perspective than
the one you'd have
in T129046. By adding page props, you want to add "new" information from
another source, and questions like data modelling etc. come to the fore.
With a materialized view, you just add some query results back to the
database for technical reasons that are specific to the database. The
two motivations might lead to different requirements at some point
(e.g., if you want to add another materialized query result to the RDF
you may have to extend page props, which involves more dependencies than
if you just extend the RDF converter).
While in theory this is true, we don't have any process that allows us
to do literally materialized views on current platform (there are named
queries but that's not the same I think). Inference "kind of" might be
that, but doing it that way probably would be very inefficient for this
particular case. There are of course other ways to achieve the same, so
I'll look into various options, but so far page props doesn't sound like
that bad an idea, to me.