Property talk:P3921

Active discussions


Wikidata SPARQL query equivalent
SPARQL code that returns a set of items that correspond with this category or list. Include ?item
RepresentsWikidata Query Service (Q20950365)
Data typeString
DomainWikimedia category (Q4167836) items (note: this should be moved to the property statements)
Allowed values.*\?item.*
ExampleCategory:Ugandan writers (Q7439502)?item wdt:P31 wd:Q5; wdt:P27 wd:Q1036; wdt:P106 wd:Q36180.
list of people who have walked on the Moon (Q42889227)?item wdt:P793 wd:Q42882411 ; wdt:P31 wd:Q5
kilometre (Q828224)[wikibase:quantityAmount%20?source;%20wikibase:quantityUnit%20?base.%20?item%20p:P2370/psn:P2370%20[wikibase:quantityAmount%20?target;%20wikibase:quantityUnit%20?base].%20BIND(?source%20/%20?target%20as%20?value)%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%2Cde%2Cru%2Cfr%2Ces%2Cit%2Cja%2Czh%22%20%7D%0A%7D%0ALIMIT%20500 wd:Q828224 p:P2370/psn:P2370 [wikibase:quantityAmount ?source; wikibase:quantityUnit ?base]. ?item p:P2370/psn:P2370 [wikibase:quantityAmount ?target; wikibase:quantityUnit ?base]. BIND(?source / ?target as ?value)]
Formatter URL$1%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%2Cde%2Cru%2Cfr%2Ces%2Cit%2Cja%2Czh%22%20%7D%0A%7D%0ALIMIT%20500
Proposal discussionProposal discussion
Current uses1,292
Scope is as main value (Q54828448): the property must be used by specified way only (Help)
List of this constraint violations: Database reports/Constraint violations/P3921#scope, hourly updated report, SPARQL, SPARQL (new)
Format “.*\?item.*: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P3921#Format, SPARQL, SPARQL (new)
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


  Without SELECT
should be without SELECT part of the query (Help)
Violations query: SELECT ?item ?query WHERE { ?item wdt:P3921 ?query . FILTER (STRSTARTS(?query, 'SELECT') = true) }
List of this constraint violations: Database reports/Complex constraint violations/P3921#Without SELECT


No new lineEdit

Just for the record: string don't accept new line. Keep all the query in one row. --ValterVB (talk) 19:51, 5 May 2017 (UTC)

With or Without Select? (Two schools of thought)Edit

How we must add the query? In complete form like in Q20007442, or only the condition like in Q29789760? I think that its' importante keep all the same so it's easy to use the property with {{SPARQL}}, or a more light version. --ValterVB (talk) 20:20, 5 May 2017 (UTC)

I think we should use executable query. This way we could use formatter URL pointing to active SPARQL endpoint/service.
I followed example on this page (limited to group graph patterns). d1g (talk) 12:56, 6 May 2017 (UTC)
On it.wikipedia we have created a template to use directly the property: it:Template:SPARQL link the useful thing is that it can display label and description different language. In this page] there is an example in bottom of the page, click on Lista su Query Service the query autostart and use { bd:serviceParam wikibase:language "it" } also if the query is created with "en". The important thing is that all the query must have { bd:serviceParam wikibase:language "en" } --ValterVB (talk) 19:56, 7 May 2017 (UTC)

Data typeEdit

I've only just seen this, but surely it would be better as a URL? Formatter URLs don't work with string-type properties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:50, 7 May 2017 (UTC)


Since this property does not hold full queries, its values are only useful if the selective variable is called ?item, as we typically name it. I’ve added a constraint that should check whether the given string starts with ?item. Maybe it would also be enough if it just checked for the occurence of ?item — any opinions? —MisterSynergy (talk) 13:18, 9 May 2017 (UTC)

@MisterSynergy: Why you have changed without warning? We were writing little above to use Select etc... A template is already done to use the property with complete query. --ValterVB (talk) 18:26, 9 May 2017 (UTC)
It is just a constraint until now, and I fixed three erroneous cases with missing question marks (but not full queries, which are also in use). The way it is right now follows the property proposal, and this was also discussed today at WD:PC (perma link). —MisterSynergy (talk) 18:36, 9 May 2017 (UTC)
This is the "Property talk of P3921", why discussiono is on english chat? THe decision on specific property must stay in property talk page not in other place. We already started to talk here. For now I'm not agree with this decision. --ValterVB (talk) 18:41, 9 May 2017 (UTC)
Well, the way I set this up was just how it was intended anyway; by propery proposal, given examples, and url formatter. I do not understand how you can just decide to change things completely. With full queries, we lose all flexibility that this property could deliver… —MisterSynergy (talk) 18:45, 9 May 2017 (UTC)
The problem is that without complete query we are limited, for example we can use UNION or sub select or more complex query. --ValterVB (talk) 19:17, 9 May 2017 (UTC)
This property should not be used for complex queries, it should just deliver simple equivalent sets to Wikipedia categories. —MisterSynergy (talk) 19:34, 9 May 2017 (UTC)
Why? The property is for any kind of lists not only for the category. Who decide what is complex? If I want all P31=Q5 the query is simple but a simple query don't work, probably I need more queries that work on a subset of item and I can add more query to the item --ValterVB (talk) 20:27, 9 May 2017 (UTC)
It would still be useful it we’d really restrict the values to the essentially important fragments of the query. Everything else should then be added within the Wikipedia template. This would also allow to add additional aspects to the query on Wikipedia side, such as: “include only items with sitelink to this wiki”, “add labels and descriptions in language xy”, etc.
An option to enable complex queries would be to just test whether ?item appears in the query fragment, since this is the variable which data users and template coders expect. Unlike now, it would not need to appear in the very beginning of the query fragment, thus subqueries, unions, and all the complex sparql magic would be available. We just skip the very outer wrapper and all nonessential parts such as label service etc. —MisterSynergy (talk) 20:40, 9 May 2017 (UTC)
+1 to the view that this property should only contain a SPARQL fragment, not the whole query. It's a basic principle to try to separate as far as possible on the one hand data-dependent content from presentation on the other hand -- so that each can be worked on and modified independently, without affecting the other.
What this property does is very analogous to a template I created a couple of months ago on Commons, c:Template:category contains -- see c:Special:WhatLinksHere/Template:Category_contains for some demonstration pages using it.
By only storing a Sparql fragment in the template on the Commons category pages, and not the whole query, so
{{Category contains|wdt:P131+ wd:Q23143 ; wdt:P1435 wd:Q15700818 ; wdt:P31?/wdt:P279* wd:Q41176}}
this makes it possible to easily choose and modify what other fields the template presents -- for example at the moment the Commons template also presents images associated with the item, Commons categories, co-ordinates, whether the item is an instance or a class, etc.
Keeping all this in the template code (rather than the content) makes it possible to easily add additional columns -- eg start date / end date -- without having to change any of the actual pages the template is used on. (equivalent here, to any of the items the property is used on). The presentation code can be changed, without having to change the item-by-item content.
Similarly, storing only the fragment rather than the whole query makes it easy for different wikis to easily use different variables and column headings for their different languages, with their own preferred language fallback in the internationalisation.
It also makes it possible for people to write their own gadgets, with slightly different queries, all still drawing on the same specification for the content of the category.
So for all of these reasons, it strongly makes sense to have a fragment as the value of this property, rather than the whole query.
As for whether that fragment should necessarily include ?item, I can take or leave.
In the Commons template (made before this property was proposed), I didn't include ?item in the fragment, leaving it to the template code to supply.
But there may be cases where it is difficult to express the category contents without using ?item again one or more further times in the query; so there may be an argument that it should always be included explicitly, to indicate the main variable that the fragment should return. Jheald (talk) 10:48, 10 May 2017 (UTC)
So for a query like this, what we must add in property?
  SELECT ?item {
    BIND( 1000000 * 28 AS ?base ) . # change this 0-30
    ?item wdt:P31 wd:Q4167836 .
    BIND( xsd:integer( STRAFTER( STR( ?item ), STR( wd:Q ) ) ) AS ?num ) .
    FILTER( ?num > ?base + 0 && ?num < ?base + 1000001 ) .
} AS %sub WHERE {
  INCLUDE %sub .
  ?item schema:description ?itDescrizione FILTER( LANG( ?itDescrizione ) = 'es' ) .
  FILTER( STR( ?itDescrizione ) != 'categoría de Wikimedia' ) }

Try it! It's only an example, in this case the key concept is avoid the time out. --ValterVB (talk) 20:06, 10 May 2017 (UTC)

What’s the use case for this query, in the context of this property? —MisterSynergy (talk) 20:28, 10 May 2017 (UTC)
I said: « the key concept is avoid the time out » not the kind of item, If I have a list that normally return a time out, I must split the query in more part. and this query is perfect for this case. If future can be useful or necessary query like or similar to this one and if we limit the query we should create another property for complex query, or fix all the value already used. --ValterVB (talk) 20:43, 10 May 2017 (UTC)
I understand the intention of the query, but I still can’t imagine any situation where we need such hacks.
  • The property is intended to deliver simple Wikidata equivalents of Wikipedia categories (and lists), for automatic inclusion on Wikipedia pages. Since it is an “equivalent”, subselections should not be made on Wikidata side.
  • Thus potential timeouts are not a problem of this property, they are a problem of the query service. Since the timeout limit and the query service performance vary anyway, this is nothing we could rely on.
  • Anyway, if you approach or hit the timeout limit, any automatic inclusion of a query is not a good idea. I don’t have an idea how this can be dealt with, but I guess the amount of items whose Wikidata SPARQL query equivalent times out is pretty low.
Regards, MisterSynergy (talk) 20:57, 10 May 2017 (UTC)
It's an example.... You can find other kind of examples in list of example in "Query Service":
  • #Largest cities per country
  • #Popular television series
  • #Population of countries sharing a border with Germany
  • #Number of handed out academy awards per award type
  • #Popular surnames among humans
  • #Longest river of each continent
  • #Country populations together with total city populations
etc. etc. --ValterVB (talk) 20:00, 11 May 2017 (UTC)
Once again: this property is not intended to cope with all the complex functionality SPARQL has to offer. Those examples definitely do not follow the way categories are set up, and the don’t fit to most lists either. This property should help to provide automatic equivalents for most categories and lists — and that means it has to deal with very simple queries. If we design it to work for any obscure compilation of items, it loses all the useful flexibility and becomes somewhat useless by itself. —MisterSynergy (talk) 10:54, 12 May 2017 (UTC)
  • I don't think one gets around including Select. Many lists use some sort of ordering and limit.
    --- Jura 11:06, 12 May 2017 (UTC)
    • That is done differently in each sitelink anyway; many list also have class="sortable" (if a table holds the list) and can be re-sorted by readers. —MisterSynergy (talk) 11:11, 12 May 2017 (UTC)
      • I meant that e.g. the "Largest cities per country" implies some sorting. Not that the resulting table can be sorted. Wikidata:WikiProject Lighthouses/lists/oldest lighthouses is another sample.
        --- Jura 11:18, 12 May 2017 (UTC)
        • Not necessarily. However, it would even be easier to implement “proper” sorting with a query fragment. It the fragment given in this property only selects the items, you can complement other data on Wikipedia side (e.g. population numbers, etc.), and define some preferred sorting as well. Query fragments even make this easier. —MisterSynergy (talk) 11:27, 12 May 2017 (UTC)
  • Property_talk:P1853#Pivot_table_for_blood_types example should be rewritten in order to fit SELECT-less queries.
  • We are constrained by 400 chars limit. I don't know an exact length WDQS can handle. d1g (talk) 22:27, 12 May 2017 (UTC)
    • This is another complex list. I meanwhile tend to say that a SELECT-less version (SPARQL fragments) would fit best for categories, and full queries fit better for lists. Should we perhaps propose for another property? —MisterSynergy (talk) 06:15, 17 May 2017 (UTC)
      • Probaly yes, but what is the problem with using the most complete version also for category? Complete version can do also simple query, but simple version can't do complex query. --ValterVB (talk) 17:55, 17 May 2017 (UTC)
Two aspects:
  1. i18n is much more difficult with full queries: you can use the label service much easier, if you code it this part of the query on Wikipedia side; if full queries were added to this property, you’d also need to ensure that the label service is used properly in each and every individual claim
  2. query fragments allow to add additional properties to the output, for instance person data for persons, coordinates for geographic entities, etc; you can provide different versions of a template for different types of categories, and let the communities decide which data they want to add per type
MisterSynergy (talk) 19:23, 17 May 2017 (UTC)
For label service isn't a problem, in query we use always english version SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } and in template we can use {{#invoke:String|replace to replace en with correct lang code. For the field to show normally depend by the kind of items to list, and if there is some particular case we can add to the query. --ValterVB (talk) 17:33, 18 May 2017 (UTC)
This string replacement scenario is fragile as hell. Someone used single quotes instead of double quotes? Does not work. The query contains "en" purposely at another place? Will be broken. Someone forgot to add the label service part at Wikidata? Will not be shown. A project wants to add additional individual properties to the output that other projects (including us) don’t want to have? Something between difficult as hell and impossible to negotiate or implement. We would have to twiddle with so many details about all the values that this becomes effectively unmaintainable rather soon. Please mind that there is potentially a seven-figure number of items which can use this property. Seriously, this solution with full queries will not work in practice. —MisterSynergy (talk) 17:51, 18 May 2017 (UTC)

everything with natural labels as domain, not just Wikimedia category (Q4167836)?Edit

My goal is to have human-readable name of the query + translations in one place (same item): cosmopolitan distribution (Q215402) d1g (talk) 01:40, 18 June 2017 (UTC)

@D1gggg: I don't understand what you mean with "name of the query". Do you want something like media legend (P2096) which would be in this case "taxons with habitat on landmass and in the Ocean"? In that case you can propose a Property and it will be discussed. Greetings --Bigbossfarin (talk) 09:59, 20 September 2017 (UTC)
Return to "P3921" page.