I'd agree with both interpretations - the majority of people in Wikidata are Using the existence of Wikipedia articles as a threshold, as suggested, seems a pretty good test - it's flawed, of course, but it's easy to check for and works as a first approximation of "probably is actually famous".

Oh, there is a little misunderstanding here. I have not suggested to create a property "number of sitelinks in this document". What I propose instead is to create a property "number of sitelinks for the document associated with this entity". The domain of this suggested property is entity. The advantage of this proposal over the thing that you understood is that it makes queries much simpler, since you usually want to sort items by this value, not documents. One could also have a property for number of sitelinks per document, but I don't think it has such a clear use case.

On 02.08.2016 20:59, Daniel Kinzler wrote: I just proposed the simple and straightforward way to solve the practical problem at hand. It leads to shorter, more readable queries that execute faster. (I don't claim originality for this; it is the obvious solution to the problem and most people would arrive at exactly the same conclusion). Your concern is based on the assumption that there is some kind of psychological effect that a particular RDF encoding would have on users. I don't think that there is any such effect. Our users will not confuse the city of Paris with an RDF document just because of some data in the RDF store. Markus -- Prof. Dr. Markus Kroetzsch Knowledge-Based Systems Group Faculty of Computer Science TU Dresden +49 351 463 38486 https://iccl.inf.tu-dresden.de/web/KBS/en _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Hi! If we implement T129046 we can have any page props we want to :) Of course, adding them for the whole DB would require new dump and either data reload or some manual work... which can be solved too with some effort. I wonder if Wikidata Toolkit has tools to do filtering like this (i.e. "get me specific triple from all entities in this dump"). If not, it probably should have ;)

Is there a way we could have more than just the number of language links? Eg number of incoming links from other wikipedia pages?

On Aug 2, 2016 10:41 PM, "Markus Kroetzsch" &lt;markus.kroetzsch(a)tu-dresden.de <mailto:markus.kroetzsch@tu-dresden.de>> wrote: On 02.08.2016 20:59, Daniel Kinzler wrote: Am 02.08.2016 um 20:19 schrieb Markus Kroetzsch: Oh, there is a little misunderstanding here. I have not suggested to create a property "number of sitelinks in this document". What I propose instead is to create a property "number of sitelinks for the document associated with this entity". The domain of this suggested property is entity. The advantage of this proposal over the thing that you understood is that it makes queries much simpler, since you usually want to sort items by this value, not documents. One could also have a property for number of sitelinks per document, but I don't think it has such a clear use case. "number of sitelinks for the document associated with this entity" strikes me as semantically odd, which was the point of my earlier mail. I'd much rather have "number of sitelinks in this document". You are right that the primary use would be to "rank" items, and that it would be more conveniant to have the count assocdiated directly with the item (the entity), but I fear it will lead to a blurring of the line between information about the entity, and information about the document. That is already a common point of confusion, and I'd rather keep that separation very clear. I also don't think that one level of indirection would be orribly complicated. To me it's just natural to include the sitelink info on the same level as we provide a timestmap or revision id: for the document. I just proposed the simple and straightforward way to solve the practical problem at hand. It leads to shorter, more readable queries that execute faster. (I don't claim originality for this; it is the obvious solution to the problem and most people would arrive at exactly the same conclusion). Your concern is based on the assumption that there is some kind of psychological effect that a particular RDF encoding would have on users. I don't think that there is any such effect. Our users will not confuse the city of Paris with an RDF document just because of some data in the RDF store. Markus -- Prof. Dr. Markus Kroetzsch Knowledge-Based Systems Group Faculty of Computer Science TU Dresden +49 351 463 38486 <tel:%2B49%20351%20463%2038486> https://iccl.inf.tu-dresden.de/web/KBS/en _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Oh, there is a little misunderstanding here. I have not suggested to create a property "number of sitelinks in this document". What I propose instead is to create a property "number of sitelinks for the document associated with this entity". The domain of this suggested property is

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

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

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

Would page props also give me the creation date of the Wikipedia page in that specific sitelink? Because this is something I needed when

Too bad, because it would be great for all sorts of project workflows! On Wed, Aug 3, 2016 at 10:04 AM, Stas Malyshev &lt;smalyshev(a)wikimedia.org&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Jane, now we are really going into the field of elastic search's relevancy calculation. When searching, things like popularity (pageviews), incoming links, number of different language wiki articles, article size, article quality (good/selected), and many other aspects could be used to better the results. I wish these were available together with the WDQS results, possibly as a number similar to Google's "page rank".