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 <[email protected]> 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 > [email protected] > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata >
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
