Would page props also give me the creation date of the Wikipedia page in that specific sitelink? Because this is something I needed when analyzing the data for the TED speakers challenge. When running an international writing challenge for Wikipedia it would be nice to rune a daily or weekly count of all articles created in the challenge. I used the Mix-n-Match "stats" page to compute this against a starting position, but it would be nice to filter out sitelink additions that actually pre-date the challenge startdate, and also check for sitelink deletions as well as additions. I think this is only possible if you can compare the sitelink creation date with the Wikipedia article creation date. For some background you can see a spot-check analysis I ran for the Women in Red project here: https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Women_in_Red/Analysis_of_New_articles_6-dec-2015_to_20-mar-2016

On Wed, Aug 3, 2016 at 7:44 AM, Stas Malyshev <smalyshev@wikimedia.org> wrote:
Hi!

> 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.

--
Stas Malyshev
smalyshev@wikimedia.org

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