Template talk:Property documentation/Archive 1

From Wikidata
Jump to navigation Jump to search

Coloring based on availability of property type

The formatting changes I made should slightly change the coloring and border of the template based on the availability of items. This as currently most proposals are for property where the type isn't available and there isn't much we can do with the proposals. --  Docu  at 07:57, 13 April 2013 (UTC)

"Suggested values"

I don't see the purpose of this field... maybe it could be merged with "allowed values" or with "example"... --Ricordisamoa 11:23, 13 April 2013 (UTC)

The problem with "allowed values" is that it suggests the number is somewhat limited (of course, you could just write "any", but still).
"sample values" would probably do as well. The "example" reminds me of the pre-formatted "Example" on WD:List of properties. --  Docu  at 12:59, 13 April 2013 (UTC)
I do not see the point of this parameter compared to "example" and "allowed values" either. Are there examples where all three paramters are used ?--Zolo (talk) 18:17, 13 August 2013 (UTC)
Agree. I don't think I used it either ;) --  Docu  at 18:36, 13 August 2013 (UTC)

Consensus needed before inserting P107 into the 'domain' field

Earlier today the 'domain' field in the property documentation was changed to read "Domain/main type" (diff). This change was made without discussion and elevates the status of GND main types, i.e. P107, closer to being Wikidata's official ontology. Given that many contributors consider P107 to have major flaws (see the RFD and P107 talk page), and even more oppose having P107 as any sort of official Wikidata ontology, I think there should be a wider discussion about this change, and consensus reached before making P107 the default template for properties' 'domain' field.

Reasons for not having P107 in the 'domain' field follow from the major flaws that many contributors note with that property, about which supporters of P107 have yet to engage in serious discussion, let alone resolve. To reiterate, those major flaws include how P107:

  1. classifies most of human knowledge as merely a "term",
  2. requires multiple properties for multiple different levels of classification, which requires much more work to update and maintain,
  3. conflates "person" with "family" and "literary figure" etc.,
  4. doesn't use GND types as they're used by the actual GND.

The property field 'domain' is useful because it A) defines for users the valid subjects for a claim involving the property and B) can be used for automated validation. Here's how the major flaws listed above specifically negate those goals, and make P107 unsuitable for the 'domain' field:

  1. Having a domain of "term" is too broad to be meaningful. For example if one were to say the property gene symbol (P353) had a domain "term", then that would imply that the claim "vehicle gene symbol x" were valid. Of course, it wouldn't be. The domain of the 'gene symbol' property is "gene", not "term". This flaw would make the 'domain' field useless for claims about most of human knowledge.
  2. Using the logic that one might use to support P107, one might say "but wait! We can use other attributes to define a more granular domain." This, of course, would require much more work to update and maintain than having one attribute to specify a property's domain.
  3. If we say a property's domain is the GND main type "person", then that means the property can also be validly applied to "family", "literary figure", "spirit", "collective pseudonym", etc. This makes it impossible to say that properties for which the domain is "person" as conventionally understood are being validly applied. For example, families aren't valid subjects for claims involving properties like place of birth, sex, etc -- and literary figures, spirits, collective pseudonym can have nonsensical values for properties for, you know, people.

Until a consensus can be reached, which I suspect would involve resolving the major flaws of P107 and their implications for this situation as listed above, I think it would be best to not insert P107 into the 'domain' field for property documentation. Emw (talk) 17:03, 13 April 2013 (UTC)

It was suggested at Wikidata_talk:Property_proposal#Revision of proposal template. To some extent, this mirrors the sub-page structure of Wikidata:Property_proposal. --  Docu  at 05:56, 14 April 2013 (UTC)

String datatype

I have a small question: in the list of "already available" datatype there is string and in "pending" list there is monolingual-text. Should not be the same datatype? What are the differences? --Paperoastro (talk) 07:44, 15 April 2013 (UTC)

(Probably) a string is not necessarily text, but maybe some type of code; monolingual text can have a language.
value type
n80023535 string
HJ-SJ-KJ string
Mary Poppins monolingual-text (English)
Leonhard Euler monolingual-text (German)
Eulero monolingual-text (Italian)
--Ricordisamoa 10:25, 15 April 2013 (UTC)
They are considered different datatypes even in the development process... maybe you should ask to developers, it isn't related with this template at all... --Ricordisamoa 10:27, 15 April 2013 (UTC)
Also: see here for further explanations. --Ricordisamoa 10:28, 15 April 2013 (UTC)
Thanks! Now it seems more clear! :) --Paperoastro (talk) 11:29, 15 April 2013 (UTC)
Glad to help. :) --Ricordisamoa 11:40, 15 April 2013 (UTC)

New layout: fields not being displayed

Nice work with the new layout: I like it.

There is an issue though with some of the fields: On Property talk:P814 the following are not displayed:

  • infobox parameter
  • allowed values
  • source
Please fix it. --  Docu  at 03:24, 29 August 2013 (UTC)
the new layout has been completely removed. the fields were only hidden when there were empty --Shisma (talk) 13:43, 1 September 2013 (UTC)
As it wasn't fixed, I restored the working version. Just revert my edit and check the above page. --  Docu  at 20:52, 2 September 2013 (UTC)

Question/proposal about the template documentation

Regarding the "domain", User:Emw just changed the description to read "type of items that may have this property, e.g. person, place, organization, event, creative work, astronomical object, disease, etc.". I would like to know if it wouldn't be a good idea to use Q templates both in this description, and (whenever possible) in the template itself. In other words:

Klortho (talk) 23:06, 22 December 2013 (UTC)

 Support. We should absolutely use Q templates in the property documentation for domain and "allowed values" (which I think should be called 'range' and be based on rdfs:range for consistency with Semantic Web conventions). It seems like the documentation of Template:Property_documentation doesn't interpret Q templates, but I've used Q templates in property proposals and it works fine. Emw (talk) 23:23, 22 December 2013 (UTC)
 Support --Paperoastro (talk) 23:50, 22 December 2013 (UTC)

Parameter enhancements

Adding and updating some parameters in this property documentation template would improve how we structure and organize our properties, and bring us closer in line with Semantic Web conventions. Please give your thoughts on the ideas belows.

Base 'allowed values' on owl:oneOf and add a new parameter for 'range'

What we call "allowed values" the rest of the Semantic Web calls "range". This would be consistent with how we now call "allowed items" "domain". Emw (talk) 03:33, 2 January 2014 (UTC)

In the section below, Zuphilip notes that 'allowed values' is often used to define 'one of' constraints. The same 'allowed values' parameter is also sometimes used to define 'range' constraints. This proposal would separate the two properties into two parameters -- 'allowed values' based on owl:oneOf and 'range' based on rdfs:range. Emw (talk) 00:16, 3 January 2014 (UTC)
 Support - I agree that the object of 'allowed values' should be an enumerated list of individuals. Klortho (talk) 13:54, 9 January 2014 (UTC)
 Support. We should also try to merge that with {{Constraint:One of}} and {{Constraint:Type}}. --Zolo (talk) 19:05, 13 January 2014 (UTC)
 Support --Paperoastro (talk) 11:42, 14 January 2014 (UTC)

Base 'domain' and 'range' on rdfs:domain and rdfs:range

Basing our 'domain' and 'range' property parameters on rdfs:domain and rdfs:range would make Wikidata more interoperable with the rest of the Semantic Web and lay groundwork for semantic reasoning. This property would be applied to only properties with an "item" datatype. In brief, the linked RDFS definitions say that 'P range C' means that objects of statements with property P are instances of C. For 'P domain C', subjects of statements with P would be instances of C.

A property can have multiple classes in its domain and range. Notes in http://www.w3.org/TR/owl-ref/#domain-def go into detail about how multiple classes in a domain or range are treated as an intersection (a logical and) by default. It also discusses how to specify a domain or range as a union (a logical or) of classes. Emw (talk) 03:33, 2 January 2014 (UTC)

The domain and range of properties in wikidata are checked at the moment with the constraint templates. I agree that we need to allow the domain and range also to be multiple classes, but the constraint templates are not supporting that at the moment, see Template_talk:Constraint:Item#Several_values or Template_talk:Constraint:Type. Therefore, you can see sometimes a large list of (pseudo-)exceptions, e.g. Property_talk:P964#Type_constraint:_Add_.7B.7BQ.7C262882.7D.7D.2C_.7B.7BQ.7C261023.7D.7D. --Zuphilip (talk) 12:25, 2 January 2014 (UTC)
Zuphilip, there's a subtle but significant difference between range and one of. Per page 16 in Common Errors in OWL, "Domain and range are not constraints to be checked. They are axioms which are used by the reasoner to make inferences. 'Violating' a domain or range constraint does not necessarily mean that the ontology is inconsistent or contains errors." This is because OWL uses an open world assumption (OWA). That said, we can use domain and range as constraints by declaring high-level classes to be disjoint. This would require a new property for 'disjoint' based on owl:disjointWith.
Another important way that 'range' differs from 'one of' is that 'range' uses classes, while 'one of' uses instances. Using a range with disjoint classes rather than 'one of' makes it easier to specify broad restrictions without needing to exhaustively list instances of a class (or classes) -- which can get very unwieldy very fast. Emw (talk) 13:37, 2 January 2014 (UTC)
Emw, then "range" is not simply an other name for "allowed values" as you stated in your first paragraph. For example, male (Q6581097) and female (Q6581072) are allowed values for the property sex or gender (P21), but they would not fit into the rdfs:range. On the other hand from the allowed values of sex or gender (P21) we can create a corresponding constraint, as it is done in Property_talk:P21. Thus, IMO range is different from allowed values, but one could also add range as an additional parameter to the propery documentation. Maybe give them some easier names (implied target type?). --Zuphilip (talk) 16:15, 2 January 2014 (UTC)
Zuphilip, great point: it seems 'allowed values' is sometimes used to define 'one of' constraints and sometimes used to define 'range'. I think it would be best to separate these two things -- to define 'allowed values' as based on owl:oneOf and a new parameter based on rdfs:range. I'd prefer to have parameter labels as close as possible to Semantic Web conventions, to make it clear at a glance that our property properties are based on RDFS and OWL semantics -- this would help users looking for outside resources (Googling "owl range best practices" will yield answers faster than "owl implied target type best practices") and outside consumers know what our property parameters mean (consumers are already familiar with 'range' as a Semantic Web property). 'Range' would also be a natural fit, since we already use 'domain'.
Would it work for you to have the first part of the description of the 'domain' and 'range' parameters be "implied subject type" and "implied object type"? Emw (talk) 00:11, 3 January 2014 (UTC)
Emw, I guess your labels and descriptions for the properties could work. Did you check the current use of the 'domain' property? Is it really thought of in the semantic web definition? E.g. in sex or gender (P21) the domain-value is 'persons or animals'. --Zuphilip (talk) 22:19, 3 January 2014 (UTC)
Zuphilip, Wikidata is in a primordial state. Until recently 'domain' was tied to 6 narrow "main types" according to the documentation in this template. I doubt many editors are aware that 'domain' conventionally functions more as a mechanism of class inference than one of constraints. We have no owl:disjointWith property, but one could be created and we could leverage disjointedness inheritance by applying it to high-level classes to convert 'domain' into a constraint if desired. My goal in basing these fundamental property parameters on W3C standards is so that we can interface with the rich set of tools available in the rest of the Semantic Web. Emw (talk) 04:53, 4 January 2014 (UTC)
 Support I like this idea very much. Klortho (talk) 13:55, 9 January 2014 (UTC)
 Support It could be very useful. --Paperoastro (talk) 11:44, 14 January 2014 (UTC)

Add optional parameters for 'subproperty of', 'inverse of' and 'transitive property'

Adding optional property documentation parameters for 'subproperty of', 'inverse of' and 'transitive' would make our property declarations more similar to Semantic Web conventions. Bases for 'subproperty of' would be rdfs:subPropertyOf and http://www.w3.org/TR/owl-ref/#subPropertyOf-def. The basis for 'inverse of' would be owl:inverseOf. The basis for 'transitive property' would be owl:TransitiveProperty. Emw (talk) 03:33, 2 January 2014 (UTC)

 Support - Sounds good indeed - LaddΩ chat ;) 01:55, 3 January 2014 (UTC)
 Support Agree! Klortho (talk) 13:55, 9 January 2014 (UTC)
 Support --Paperoastro (talk) 11:46, 14 January 2014 (UTC) At now these informations (e.g. inverse) are not well organized. This parameter will do it. --Paperoastro (talk) 11:46, 14 January 2014 (UTC)

disjoint with

Please comment on the proposed property disjoint with. It would not be a property parameter, but it is closely related to the proposals above. Emw (talk) 15:18, 4 January 2014 (UTC)

Steps to better document properties

I added an automatic categorization into Category:Properties missing allowed values (410 entries for now) and Category:Properties with domain missing‎ (112 entries). After I fill the missing info for existing properties, I intend to make these two fields mandatory, to ensure that they get filled as soon as new properties are proposed. Comments welcome. LaddΩ chat ;) 15:51, 2 March 2014 (UTC)

Adding "Usage" field

Too often I see properties with little context, justification or description of how to use it: the "description" field is generally just a one-liner to be used after the property is created. Often the context and usage appear in the discussion text following the proposal, e.g. Geokod or Diplomatic relation; attempts are then made to add usage details to the description field (e.g. P1016, P560 or P580). I believe it is necessary to create a new field Usage/Utilisation/использование/Verwendung (initially optional) where proposers will have the capability to enter multi-line description of intended usage for the proposed property. Comments? LaddΩ chat ;) 18:37, 5 March 2014 (UTC)

Adding "Q" parameter

Some properties, for example ORCID iD (P496), are themselves the subject of a Wikidata entry (and one or more Wikipedia articles); in this case, ORCID iD (Q51044). We should add a |Q= parameter, to record this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:00, 27 June 2014 (UTC)

Anyone? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:52, 15 July 2014 (UTC)
@Pigsonthewing: In general I referred to such q items directly in the "description" field. Since we keep being told that "properties on properties" should be available shortly, I believe it is not worth changing again the structure of this template and handle it as part of the upcoming scheme. IMHO. LaddΩ chat ;) 13:48, 15 July 2014 (UTC)
@Laddo: What's the value of "shortly", in this case? Adding a parameter to the template gives us a structured means of recording such data, until such time that that feature is available, from where it can then be moved, by a bot. Mentioning the Q value in prose, on the other hand, introduces the possibility of ambiguous data being entered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 15 July 2014 (UTC)
@Pigsonthewing:See Wikidata:Development_plan#Statements on properties and bugzilla:49554 ; adding the field is only the first step, someone will need to revisit all property talk pages and we'd also need to update the documentation on Wikidata:Property proposal/Header/en... I can do the first step if you want to process the talk pages. LaddΩ chat ;) 21:26, 15 July 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Belated response, sorry. This is a wiki: once the parameter is available, it can be used as and when people see fit; it's not something one editor is required to do for the whole set of properties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:55, 14 October 2014 (UTC)

@Pigsonthewing: Ok will do, but Q= is not clear enough to me. I would prefer Subject item= or something similar. What do you think? LaddΩ chat ;) 00:21, 15 October 2014 (UTC)
I support Andy's good idea with Laddo's refinement: an optional Subject_item= parameter. Emw (talk) 03:21, 15 October 2014 (UTC)
No problem with that; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:37, 15 October 2014 (UTC)
✓ Done Added support for subject item =; used it for ORCID iD (P496), on Property talk:P496. LaddΩ chat ;) 20:12, 15 October 2014 (UTC)

Required parameters

Is it really necessary that the "allowed values" and the "domain" parameters are required ? When this information is relevant, it is just repeating in vague terms what is better expressed in the consraint templates. And there are plenty of cases where it is just not relevant. These "required" parameters also categorize in pages like Category:Properties missing allowed values, but really is there any point in that ? If someone cares about a property, he will use other means (like {{Constraint}}) to maintain it (note that I would be in favor of integrating the constraint template in {{Property documentation}}, but that is a bit more complicated). --Zolo (talk) 07:37, 7 September 2014 (UTC)

Salut Zolo, this "domain" field existed long before Ivan developed his powerful constraint violation scheme. Since we will soon be deploying attributes on properties, I believe that one of the properties should be a rule restricting the domain, while another property attribute would restrict the domain of allowed values, replacing the corresponding two property doc fields. They might in the future be combined with the Template:Constraint, who knows? Note that some properties still do not have constraints at all. LaddΩ chat ;) 20:17, 7 September 2014 (UTC)
I agree with Zolo's sentiment that domain should not be required. And I think we should rename allowed values to one of to be consistent with Semantic Web conventions, i.e. OWL, which defines its meaning in owl:oneOf. Note that this is a special case of the "domain of allowed values", which is typically called a property's "range". Range can either be a short(!) list of enumerated values, in which case one of would be used, or a broader yet still formal constraint that the values of a property are some instance or subclass of a given item. For the latter case, we would have a property parameter named range, with the semantics of rdfs:range. (Domain would be refined to have the semantics of rdfs:domain.)
These would all be optional, e.g. all properties of datatype 'item' would implicitly have a domain or range of entity (Q35120). This would achieve the important goal of making Wikidata's properties more interoperable with vocabulary used on the rest of the Semantic Web. Emw (talk) 03:35, 15 October 2014 (UTC)

New property metadata proposal page

See Wikidata:Property proposal/Property metadata to discuss upcoming "statements on properties" that shall eventually, in some distant future, replace {{Property documentation}} and all constraint templates. See also some concerns that I have. -- LaddΩ chat ;) 05:34, 12 November 2014 (UTC)

URL format

I suggest that we add an optional |URL format= parameter, to take values like those listed at MediaWiki:Gadget-AuthorityControl.js (e.g http://orcid.org/$1 for ORCID iD (P496)). I note that such values are often - and ambiguously - currently shoehorned into the |example= parameter. I also note that a "URL formatter" property is already approved. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:53, 29 November 2014 (UTC)

Note that we now have formatter URL (P1630) for these. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:10, 8 December 2014 (UTC)

Now added, as |formatter URL=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:19, 21 December 2014 (UTC)

Deprecation message for boolean data type is unclear

For the boolean data type, it says "deprecated; use item instead". How is one supposed to do that? Petr Matas 17:23, 22 December 2014 (UTC)

Subject item

@Petr Matas: about [1]: the template does not contain code for querying Wikidata item of this property (P1629) as I see. So if I remove subject item parameter this value will not displayed in property documentation. — Ivan A. Krestinin (talk) 17:33, 8 January 2015 (UTC)

It does, look at Property talk:P1568. Petr Matas 17:36, 8 January 2015 (UTC)
I am apologize, my mistake. Thank you for clarification. — Ivan A. Krestinin (talk) 17:41, 8 January 2015 (UTC)

Template rewrite

I have rewritten this template in Lua, it should help make it more maintainable. I hope it did not break anything, but as the template was rather messy there may be things I missed.

Changes

  • Translation are now all in Module:I18n/property documentation
  • Slightly different layout (I think it is clearer). One minor consequence is that hacks for repairing bullet points should now be removed ([2]).

Proposed changes

Prposed by parameter

  • This parameter is weird, depending on the namespace, it is two completely different things. In Wikidata namespace, it works like
|proposed by = name of the proposer

giving "proposed by name of the proposer".

In property talk page: 

|proposed by = ID of the archive of the prposoal page

giving: "Proposal discussion : Wikidata/Property proposal/archive/ID of the page" That just sounds like 2 completely different parameters. Can I split it ?

Merger wih constraint violations

If that is compatible with user:Ivan A. Krestinin's bot, merging {{Constraint}} would avoid redundancies between the two templates. I'd also like to integrate {{ExternalUse}} here. -Zolo (talk) 11:33, 12 January 2015 (UTC)

It is interesting question what is more maintainable: 8k of template code or 12k of LUA code :-). {{Constraint}} and this template has many duplicate functionality:
domain property and {{Constraint:Type}}, {{Constraint:Item}}
allowed values and {{Constraint:Value type}}, {{Constraint:One of}}, {{Constraint:Range}}
filter and {{Constraint:Format}}
This redundancy is discussed on Wikidata:Property proposal/Property metadata a bit. But {{Constraint}} is too formal. Many users has no enough experience to write it during property proposal procedure. Also I have planes to replace {{Constraint}} to metadata. — Ivan A. Krestinin (talk) 20:18, 12 January 2015 (UTC)
Could you return back line between header (name and description) and other properties? — Ivan A. Krestinin (talk) 20:38, 12 January 2015 (UTC)
Well now, it is 15 ko instead of 12 ko, but it is partly because the internationalization format is more verbose, and because it has new data-retrieving capabilities. The point is that assembled in 2 pages instead of spread in 5, and it should be easier to add new rows.
I have readded the separation line.
If users do not know how to format a constraint, other users can fix them, can't they ? It is not more difficult than doing it in a separate template. I agree that whenever possible, constraints should be stored in the property itself. But I think that once it is enabled, we can for instance get rid of {{Constraint:One of}} and have let {{Property documentation}} add the link to the constraint violation report ? --Zolo (talk) 23:44, 12 January 2015 (UTC)

Bug: Proposed by is turned into lowercase

The signatures in the Proposed by field are turned into lowercase, which is ugly and breaks their links. See Wikidata:Property proposal/Natural science for example. Petr Matas 18:07, 15 January 2015 (UTC)

Fixes. --Zolo (talk) 18:57, 15 January 2015 (UTC)

Description parameter

Do we neeed the description parameter on property talk pages? Isn't it redundant with the property description or is it intendet to be more verbose? --Pasleim (talk) 22:54, 15 January 2015 (UTC)

I would drop it. Petr Matas 07:47, 16 January 2015 (UTC)
This field in used for property proposals, when there is no property to pull the data from, however, I do not really like this way of doing things in property proposals.
Most |description= parameters in property talk pages seem useless but in some cases, it might be useful to have a field that does not have length limits, and accepts Wikisyntax. --Zolo (talk) 08:16, 16 January 2015 (UTC)

Bug: Status = not done

If the status parameter is set to "not done" only an error is returned, see the first two sections in Wikidata:Property proposal/Archive/28. --Pasleim (talk) 17:40, 19 January 2015 (UTC)

Bad... Fixed. --Zolo (talk) 07:21, 20 January 2015 (UTC)

Modified use of this template on property discussion page

As I´ve enhanced many of this templates on property discussion pages with the {{TranslateThis}} template, I got a message on my talk page. I see the trouble and redundancies in using this template inside the box, but I also see the barrier that is created by having the information of the box presented only in English. I feel it is necessary to discuss this issue on a broader base. So I´m asking for your opinions to find the best solution.--Giftzwerg 88 (talk) 16:38, 30 January 2015 (UTC)

That seems to be the same issue as #Description parameter just above. Actually I do not see why pulling the description from the entity rather than rewriting it in the template would lead to more untranslated English messages. It appears to be quite the opposite: the description of the entity itself is much more often translated than the description parameter of the template. --Zolo (talk) 10:52, 1 February 2015 (UTC)
The description is not the only thing that needs to be translated somehow. There should also be some translation of the other sections in many cases. --Giftzwerg 88 (talk) 17:46, 1 February 2015 (UTC)

Can we "Nowiki" the formatter URL, so that it does not make a link? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 14 April 2015 (UTC)

✓ Done [3]. --Zolo (talk) 21:05, 14 April 2015 (UTC)

Examples

It should now be possible to automatically populate many of the example parameters in this template, using Wikidata property example (P1855) and its qualifiers. See, for example, ORCID iD (P496). Can someone code this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 26 April 2015 (UTC)

@Zolo: Can you help, please. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 3 May 2015 (UTC)
Done. The format may not be ideal, but that's all I have time to do right now. --Zolo (talk) 09:34, 5 May 2015 (UTC)
improved the format. However, before we start to move |example= to Wikidata property example (P1855), it would be good to have more inputs on Property talk:P1855#Which qualifiers?--Pasleim (talk) 12:26, 10 May 2015 (UTC)

Source URL property

In a similar vein to "Formatter URL" and "Examples", above, source website for the property (P1896) is now available. Please can this template be updated to make use of it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:10, 21 May 2015 (UTC)

Done, it's pretty easy to do actually, just do the same as for other similar properties. --Zolo (talk) 11:59, 22 May 2015 (UTC)
@Zolo: Thank you, but as you can see at Property talk:P496, there are now two source properties ("Source" and "Source URL"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:24, 22 May 2015 (UTC)
Oh ok, there was already a "source" parameter, merged them. --Zolo (talk) 12:53, 22 May 2015 (UTC)

Template parameter "Proposed by", when used on a property talk page and when assigned a numerical value, is supposed to link to the corresponding creation discussion on pages; e.g. on Property talk:P1591, there is an automatically generated link to Wikidata:Property_proposal/Archive/27#P1591. These links used to work but seem broken (the target anchor does not seem to be created anymore). -- LaddΩ chat ;) 21:27, 12 April 2015 (UTC)

Fixed, yes, there was an error in the anchor id (actually, there was a similar issue with older version of the templates as well, sections links only worked for old archive pages where {{Property documentation}} was not used). --Zolo (talk) 08:25, 13 April 2015 (UTC)
@Zolo: Now working indeed! thanks ;)
However there is a second related issue (I had hoped it would be indirectly fixed, but it wasn't): see on Property talk:P1635, the automatically generated link to proposal discussion is Wikidata:Property proposal/Archive/27#Q1417657 instead of Wikidata:Property proposal/Archive/27#P1635, so it leads nowhere... I could not figure where the value of variable 'id' comes from... If you can spare another couple of minutes? thanks again. -- LaddΩ chat ;) 13:12, 13 April 2015 (UTC)
@Laddo:. Indeed, I had seen that when debugging, and forgot to see about it... Should be fixed now [4]. --Zolo (talk) 16:17, 13 April 2015 (UTC)
@Zolo: Wow, you had to dig deep, bravo encore une fois! -- LaddΩ chat ;) 18:01, 13 April 2015 (UTC)

If you are still in the mood, there is yet another issue... There is no property categorization anymore, see Category:Properties with incomplete documentation... everything is empty :S -- LaddΩ chat ;) 18:01, 13 April 2015 (UTC)

My bad, I fixed it, but simplified the way it works:
  1. if data marked as "required" is missing it writes "MISSING" in red and categorizes in Category:Property documentation with missing information
  2. if data are present in both the template and in the property statement, it shows a warning message and categorizes in Category:Property with duplicated information
  3. if data are present in the template, but not in the statement, it shows a warning and categorizes in Category:Property documentation with data to be moved to statements.
As discussed some time ago, the "long description" cat does not seem really needed anymore and was removed. I don't think we other parameter-specific categories are needed either, as all parameters should be fixed, and the red message make them easy to spot. Those generic maintenance categories scale more easily (so we can merge {{Constraint}} with {{Property documentation}} ;).
btw new option : if a parameter that is usually required is not needed : add "-" as value. --Zolo (talk) 20:30, 14 April 2015 (UTC)
@Zolo: Excellent move, all very good and scalable indeed. I added some descriptions to the new categories. If it is easy for you to do, will you delete the obsolete Category:Properties with incomplete documentation and its 6 subcategories? I will update the documentation of the template using your explanations above. Thanks -- LaddΩ chat ;) 22:28, 14 April 2015 (UTC)
@Laddo:, done. --Zolo (talk) 08:18, 18 April 2015 (UTC)

Error when missing example on proposal page

If the example parameter is omitted on the proposal page, an error is raised:

Lua error in Module:Property_documentation at line 66: attempt to index upvalue 'entity' (a nil value).

--Pasleim (talk) 12:49, 15 May 2015 (UTC)

Fixed, sorry. Zolo (talk) 08:22, 16 May 2015 (UTC)

Should put properties with mismatched datatypes in a category

For example, Property talk:P968 has type "String" in the template but the actual property is of type "URL"; shouldn't that be automatically put in a category for properties with mismatched types between documentation and reality (implying that the type might have been set incorrectly at creation time)? —SamB (talk) 17:14, 3 May 2015 (UTC)

I've fixed that example, per Wikidata:Property proposal/Archive/15#P968. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 3 May 2015 (UTC)
When a datatype is stored in the template, the page is categorized in Category:Property with duplicated information, which means it will eventually be checked and spotted. Do we want to add a cat warning that there is something fishy about the value ? It makes the module a bit more complicated, and I am not sure it really needed. If the value was created was a bad datatype, I suppose it will quickly be noted anway. -Zolo (talk) 09:37, 5 May 2015 (UTC)
@Zolo: If the two values are the same, the template need not display a warning, but should still apply the category. If the values are different, a more prominent warning may be useful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:30, 21 May 2015 (UTC)
Displaying the text is intends to tell people that data should now stored in statements, and at crowdsourcing the duplicate issue. It's not always easy to know if data from the template are consistent with those in the property statements, because differences can simply come from different formatting (most clearly in the "example" row). --Zolo (talk) 13:02, 22 May 2015 (UTC)
We're discussing datatypes, not exmaples. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:28, 22 June 2015 (UTC)

Formatter URL validation

The |formatter URL= property should throw an error message if the value is present and does not:

  • begin with a valid protocol ("http://", "https://", etc.)
  • contain the sting "$1"

Please can someone make this so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 26 May 2015 (UTC)

There is already a constraint on Property talk:P1630 which does that. --Pasleim (talk) 15:30, 26 May 2015 (UTC)
That affects an existing property . It does not warn people making or considering a new proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 June 2015 (UTC)
@Pigsonthewing: This could work. Matěj Suchánek (talk) 09:53, 14 July 2015 (UTC)
How so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 19 July 2015 (UTC)

Seems someone has added this; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 19 July 2015 (UTC)

Oh, sorry, Andy, I notified you but added wrong link. Yes, it was me who did it. Matěj Suchánek (talk) 17:56, 19 July 2015 (UTC)

New stator for property proposals which are ready to be created

I propose a new status "ready", which will put property proposals into a special category, e.g. Category:Properties ready for creation, which can be monitored by administrators and property creators. Any editor can change this status when they feel that consensus has been reached for a new property.

Proposed code is in Module:Property documentation/sandbox. MSGJ (talk) 08:32, 22 June 2015 (UTC)

I have now added this code. Let me know if there are any problems! I will document it shortly MSGJ (talk) 21:37, 22 June 2015 (UTC)

Highlight "$1" when displaying formatter URL (P1630)

It might be worth displaying the "$1" part of the URL in bold. --- Jura 10:46, 2 May 2015 (UTC)

@Jura1: I was just thinking about implementing this but I'm not sure if everyone agrees, and also am not sure about the right method to use. Matěj Suchánek (talk) 12:43, 14 July 2015 (UTC)
Thanks for having looked into it. I tried to add it myself, but as the url is wrapped into nowiki it failed. --- Jura 12:56, 14 July 2015 (UTC)
Right, that's the problem. I though about mw.text.gsplit( val, $1, true ) ... I will return to it later. Matěj Suchánek (talk) 13:13, 14 July 2015 (UTC)
@Jura1: Available for testing in the sandbox. Matěj Suchánek (talk) 08:30, 17 July 2015 (UTC)
Interesting solution. Looks good. Thanks for your help! --- Jura 09:22, 17 July 2015 (UTC)

Use formatting URL when displaying example

It would be also good if it used the formatting URL when displaying example directly from module, e.g. on Property talk:P214 (now it uses template parameter for examples, but it could be changed if the module could link directly to VIAF (like this: [formatting_URL example_value], where $1 in formatting_URL should be changed to example_value). --Tacsipacsi (talk) 19:56, 13 June 2015 (UTC)

@Tacsipacsi: Done, good idea! (I have found that Module:Wikidata provides this but it wasn't documented.) Matěj Suchánek (talk) 10:29, 14 July 2015 (UTC)

Failure on entry of subject_item

Currently, if anything but an QID is entered, the template fails completely and users find the template replaced by the following red error message: "The ID entered is unknown to the system. Please use a valid entity ID.".

Can this be changed to still display the rest of the template? Sample: Special:Diff/251689609. --- Jura 10:43, 13 September 2015 (UTC)

I think this should be fixed in Module:Wikidata so that formatError('entity-not-found') is raised for unknown IDs --Pasleim (talk) 08:36, 16 September 2015 (UTC)

P17

What is wrong with the template on Property talk:P17? I'm not able to figure that out. --Pasleim (talk) 06:03, 18 September 2015 (UTC)

Q20116958 got deleted. --- Jura 08:26, 18 September 2015 (UTC)
my fault, sorry --Pasleim (talk) 08:35, 18 September 2015 (UTC)
It seems that Thierry Caro deleted and re-created the categories at frwiki .. so we lost track of the tracking categories ;) --- Jura 08:45, 18 September 2015 (UTC)

Adding "allowed qualifiers" as a parameter for the template

Hi, I think it can be useful specifying in the template the allowed qualifiers and for what they are supposed to be used. It looks helpful when there is the qualifiers constraint to let the people know what information they should specify with the qualifier. -- Agabi10 (talk) 12:37, 20 October 2015 (UTC)

Units / monolingual text

Currently when an example uses a unit the unit isn't shown, only the value. Same goes for monolingual text, the language isn't shown. Mbch331 (talk) 11:24, 2 November 2015 (UTC)

Hi, I can't figure why these glitches:

on Property_talk:P18, the second example value shows as "adams portrait cropped.jpg Douglas adams portrait cropped.jpg" ;
on Property talk:P154, the example has no associated hyperlink, despite that it wors on Property:P154 itself.

-- LaddΩ chat ;) 13:47, 14 December 2015 (UTC)

I found the problems: the spaces, they aren't converted to _ or %20, so the link ends at the first space. And there was no formatter URL for P154 (even for commonsMedia this is needed). Mbch331 (talk) 14:15, 14 December 2015 (UTC)
In fact, they are not needed as they are all same, so I will modify the module accordingly. Eh, what spaces are talking about? Matěj Suchánek (talk) 14:18, 14 December 2015 (UTC)
Spaces in the values for P154 or P18 claims (e.g. the spaces in Douglas adams portrait cropped.jpg, they become spaces in URL's https://commons.wikimedia.org/wiki/File:Douglas adams portrait cropped.jpg. And MediaWiki stops after the first space as the rest is the description. Mbch331 (talk) 14:23, 14 December 2015 (UTC)
I see now, thanks. Meanwhile, I added a default formatter URL for commonsMedia.
By the way, I think we should rather use mw.uri.encode() but I can't get it work now... will look at it later. Matěj Suchánek (talk) 14:35, 14 December 2015 (UTC)
Geee, thanks for the quick fixes!! -- LaddΩ chat ;) 17:28, 14 December 2015 (UTC)

I just found out from the weekly report about this tool, the Wikidata Analyst : https://tools.wmflabs.org/wd-analyst/index.php?p=p1116&q=

I believe it would be appropriate to embed an access to these stats from the Property documentation template -- possibly to the right, just under the "<instances>" link? Jut an idea... -- LaddΩ chat ;) 17:36, 14 December 2015 (UTC)

Not sure. We don't know how reliable the tool is. The suggested placement could imply that its an official tool, which it isn't.
Besides, those numbers are hard to interpret and not necessarily relevant and useful for every property. --- Jura 09:51, 15 December 2015 (UTC)
Fair. Just thought it would help improve references on statements. -- LaddΩ chat ;) 14:15, 15 December 2015 (UTC)
The way it calculates percentages is a bit odd. It would probably work better for P31/Qid combinations.
I added a sample link to the "list=" part at Property talk:P27. For some reason, it works with P27/Qid, but not with other properties. --- Jura 11:03, 16 December 2015 (UTC)
I can't see what's wrong with the list request. It works with all properties with wikibase-item-datatype; the "GROUP BY" of the SQL request would have a hard time trying to group by value properties with string, image or URL datatypes, however that's not a reason for failing. -- LaddΩ chat ;) 13:25, 16 December 2015 (UTC)
I tried https://tools.wmflabs.org/wd-analyst/index.php?p=p735&q=Q13365715 , but only displays P735, not Q13365715. Aren't the averages the same for any person related property? --- Jura 13:39, 16 December 2015 (UTC)

More specific maintenance categories

Hi, I don't dare implement myself a new optional row parameter maintenanceCateg that could be used to more finely categorize property documentation issues.

In particular, the generic "required-->missing" processing could check if this attribute exists before falling back on Category:Property documentation with missing information. The very first step would be to add maintenanceCateg = 'Property documentation with missing link to proposal discussion' (to this categ). We could then refine issues with duplicate datatypes and the like. -- LaddΩ chat ;) 16:36, 4 January 2016 (UTC)

Done, the template now distinguishes Category:Property documentation missing a link to its proposal discussion as well as Category:Property originally created without a formal discussion. Coming soon: Category:Property documentation with malformed link to its proposal discussion. LaddΩ chat ;) 16:48, 9 January 2016 (UTC)

Addition?

Maybe we could include a new SPARQL query? For counting uses of property. It would help identify the current situation of property; also useful at property proposal archive.

P.S. Somebody could fix that dash after "Start a query" (it's hyphen now). --Edgars2007 (talk) 10:51, 6 February 2016 (UTC)

The hyphen/dash problem has been solved. Mbch331 (talk) 11:54, 6 February 2016 (UTC)
I added one for counts. It includes three different ways to count. Doesn't work for qualifiers though.
--- Jura 09:10, 7 February 2016 (UTC)
Cool, thanks! --Edgars2007 (talk) 09:54, 7 February 2016 (UTC)
I added one for qualifiers and more ranks as well. I think it's a problem with deletions that makes them appear in counts for some ranks, but not in others.
--- Jura 13:49, 14 February 2016 (UTC)

text-align

How I can change text-align to right in Arabic --Mr. Ibrahem (talk) 22:11, 21 February 2016 (UTC)

How does it look now? I suppose the right-to-left support of this module is not sufficient, so if you have some hints, feel free to share them. Matěj Suchánek (talk) 14:23, 22 February 2016 (UTC)
Thank you very much. It's look more better now --Mr. Ibrahem (talk) 17:22, 22 February 2016 (UTC)

Sparql queries on qualifier-only properties

The current queries work mainly for properties used for statements, not as qualifiers. Would it possible to insert a condition based on the absence of instance of (P31) = Wikidata qualifier (Q18615010)?
--- Jura 13:11, 30 January 2016 (UTC)

✓ Done Now we are only a small step from dynamic adding queries depending on the input from the template or property statements. Matěj Suchánek (talk) 16:21, 24 February 2016 (UTC)

@Jura1:, @Abc82: I won't argue about the tag that we use to get the translation of the query link that changed 1, 2, 3 times in a single day, but

a) Please ensure that the tag remains consistent between Module:Property documentation and Module:I18n/property documentation ;
b) Let's stick to a clear & descriptive label and rather adjust translation in your native language as you like.

Cheers -- LaddΩ chat ;) 22:11, 7 March 2016 (UTC)

Improvements & issues

There are still a few shortcomings with Module:Property documentation; I'm listing them, in case anyone has some time... -- LaddΩ chat ;) 02:33, 20 February 2016 (UTC)

Already settled

Issues settled

1. ✓ Done For parameter |source=, the full URLs of source website for the property (P1896) appears in the property doc ; moreover all value qualifiers of P1896 get listed after each URL (see for example Property_talk:P279). The current handling is adequate for qualifier comment (DEPRECATED) (P2315), but the value of qualifier title (P1476) should rather be used as a label for the URL of the source website;

For 1, I will investigate if Module:Wikidata can provide us some dedicated handling for getting title (P1476) which can be then provided as showntext to the module.
Matěj Suchánek (talk) 09:11, 20 February 2016 (UTC)
 Comment @Matěj Suchánek: A problem with that change: the module picks the title from one source website for the property (P1896) and applies it to all such sites -> see Property_talk:P279. -- LaddΩ chat ;) 11:55, 20 February 2016 (UTC)
I didn't realize each statement holds its own title. So I will have to look into Module:Wikidata instead. Matěj Suchánek (talk) 12:17, 20 February 2016 (UTC)

3. ✓ Done Field "Usage notes" displays values of comment (DEPRECATED) (P2315) associated to the property; however comments are monolingual text properties; if the same comment is supplied in multiple languages, they all get displayed... See for example Property talk:P990. The template should only display the version for one language, the most appropriate based on the applicable language fallback scheme ;

For 3, I have got an idea how to handle this directly inside Module:Property documentation.
Matěj Suchánek (talk) 09:11, 20 February 2016 (UTC)

6. ✓ Done Handling formulae (Property talk:P2534). (Added by Matěj Suchánek.)

String should be enclosed in <math></math> when displayed

7. What is needed to move everything else into statements? (Added by Jura1.)

See #Parameters that are not yet supplied by properties further below. -- LaddΩ chat ;) 13:18, 20 February 2016 (UTC)

8. ✓ Done "Future dates" query should appear in "list". (Added by Jura1.)

Categorization part needs to be re-added

9. ✓ Done Link datatypes to Help:Data type instead of mediawiki.org. (Added by Matěj Suchánek.)

10. ✓ Done Allow more URL formatters. (Added by Matěj Suchánek.)

12. ✓ Done Some queries shouldn't be displayed for properties which are only used as qualifiers. (Added by Jura1.)

13. ✓ Done RTL (request at #text-align.)

14. Add queries also to query.wikidata.org samples (added by Jura1.)

Not sure, this would duplicate maintenance (comment by Jura1.)

16. ✓ Done Fix mix'n'match? See Property talk:P1417 "169", text previously was "Mix'n'match" --Edgars2007 (talk) 18:24, 24 February 2016 (UTC)

Fixed regression in Module:Wikidata, thanks for your report! Matěj Suchánek (talk) 19:19, 24 February 2016 (UTC)

18. ✓ Done Remove P571 support (creation date)? (question added by Jura1.)

Agreed. Pointless. -- LaddΩ chat ;) 02:57, 29 February 2016 (UTC)

20. ✓ Done Fix error (see this page, for example) --Edgars2007 (talk) 11:54, 26 February 2016 (UTC)

21. ✓ Done Place "mix'n'match" link in tools or lists. (added by Jura1.)

26a. ✓ Done Undocumented fields: lists (ones not using statements). (Added by Matěj Suchánek.)

31. ✓ Done Improve failure output for proposals (Added by Jura1.)

Fixed segment 13 in Wikidata:Property proposal/Proposal preload (it included HTML comments in 5 languages). (comment by Jura1.)

32. ✓ Done add link to constraint reports in lists. (Added by Jura1.)

33. ✓ Done Remove prefixes from queries. Except for the "start a query" ones. See Phab:T127740

On hold

15. Rid off "suggested values". (Added by Matěj Suchánek.)

 Comment Category:Property documentation using 'suggested values' is indeed empty. Removing from documentation. -- LaddΩ chat ;) 02:23, 25 February 2016 (UTC)
On hold until May 2016... in case some pending proposals are using that field. -- LaddΩ chat ;) 01:13, 29 February 2016 (UTC)

Still open

2. Examples of monolingual text properties should display the language abbreviation ; see for example Doctor of Philosophy (Q752297) for Property_talk:P1813;

For 2, this is certainly something Module:Wikidata can help us with.  Question Would the new behaviour be always appropriate? Matěj Suchánek (talk) 09:11, 20 February 2016 (UTC)
I guess it's safer to provide some kind of display flag toggle. -- LaddΩ chat ;) 12:23, 20 February 2016 (UTC)
This will be difficult because we have to use different displayformat for mainsnak and qualifiers in Module:Wikidata. Matěj Suchánek (talk) 10:15, 2 March 2016 (UTC)

4. Examples should bring over to the documentation page the qualifiers associated to each example value; otherwise examples may be nonsensical, such as on Property talk:P360 ;

5. The scheme for providing property examples falls short for all properties that can only be used as qualifiers. No way to handle the example on Property talk:P249, for example.

  • The last two issues are more a shortcoming of the current statement system, you can't have qualifiers on qualifiers and that's what's needed to solve these two. Mbch331 (talk) 08:56, 20 February 2016 (UTC)
Matěj Suchánek (talk) 09:11, 20 February 2016 (UTC)
It could load the samples directly from the items. (comment by Jura1.)

11. Some queries shouldn't be displayed for properties with many uses (e.g. "list of values" for P31 with >1000000). Definition could be in the module or with an item "Wikidata property with more than 1 million uses". (Added by Jura1.)

Todo: identify which ones.

17. Add description of identifier characteristics (based on P31 or P1552 or .. values, maybe from subject item, not property itself) (added by Jura1.)

 Question Could you provide an example? Matěj Suchánek (talk) 11:05, 27 February 2016 (UTC)
Wikimedia database name (P1800) → descriptive identifier (Q22975498)

19. Add first proposed date (added by Jura1.)

Oppose. Pointless  ;) -- LaddΩ chat ;) 02:57, 29 February 2016 (UTC)
It would allow to calculate the difference between this and creation date. (comment by Jura1.)

22. Properties listed in "see also" should link to property talk pages. (added by Jura1.)

23. "novalue"/"some value" ir Count query, Jura1? I'm not sure, how useful that would be, so it's up to you and others to decide that :) --Edgars2007 (talk) 09:44, 27 February 2016 (UTC)

I added a full list of novalue items. (comment by Jura1.)
+ somevalue. (comment by Jura1.)
As this is related... Maybe we should include ?item NOT IN (...) in qualifier part of query? Counting the property itself (as this is used by Wikidata property example (P1855)) is rather confusing for some users, I think. --Edgars2007 (talk) 07:38, 23 March 2016 (UTC)

24. There is a feature highlighting "$1" in formatter URLs in the sandbox. Do we want to use it? (Added by Matěj Suchánek.)

I gave it a try. Comments welcome. I'm not that pleased with the result. We could possibly highlight "$1" differently, like using http://toto/$1 ? -- LaddΩ chat ;) 03:44, 29 February 2016 (UTC)
It's the one from #Highlight "$1" when displaying formatter URL (P1630). Still like it. (comment by Jura1.)

25. There is a feature in the sandbox which allows writing queries for the template more "visualy". Do we want to use it? (Added by Matěj Suchánek.)

26b. Undocumented fields: preferred rank (categ). (Added by Matěj Suchánek.)

 Comment Used only on population (P1082). Can Jura1 clarify its purpose? LaddΩ chat ;) 01:47, 29 February 2016 (UTC)
It could give a context related description of the use of the rank. Maybe this can be done in the template. (comment by Jura1.)

27. Add a second line to 'allowed values' to list all P1646 (P1646), comma-separated. (Added by Laddo.)

Constraint templates list them, eventually also from statements. (comment by Jura1.)
Agree. Implementation of Module:Constraints is likely to take more time. (comment by Jura1.)

28. Add stability of value of property. (Added by Jura1.)

29. Enclose TeX string (P1993) samples in <math></math> when displayed ;) (Added by Jura1.)

Same problem as number 2. Matěj Suchánek (talk) 10:15, 2 March 2016 (UTC)

30. Add a question for proposals: How many uses are planned within a month of creation? (Added by Jura1.)

I think this belongs rather into WD:Property proposal/Proposal preload. Matěj Suchánek (talk) 10:15, 2 March 2016 (UTC)

34. Use {{Formatnum:}} to display values of numeric examples, e.g. in Property talk:P1164. (Added by LaddΩ.)

35. When a property bears formatter URI for RDF resource (P1921), add (RDF) with a link built from that pattern after each example value, e.g. the example at Property talk:P349 would become "iridium (Q877) → 00564222 (RDF)". (Added by LaddΩ.)

36. Display aliases (Added by Jura1.)

37. Add link to harvesttemplates somewhere? Probably at "Robot and gadget jobs". Except those properties, which have datatype, that currently isn't supported by harvesttemplates (quantity and coords, I think). It would also raise awareness of the tool. (Added by Edgars2007.)

38. ✓ Done stop history re-write (see #Change_behavior_on_property_proposal_pages.3F)

39. improve count query for ref/qualifier (Added by Jura1.)

40. ✓ Done link Wikidata:Database_reports/Humans_with_missing_claims (Added by Jura1.)

41. add more queries (Added by Jura1.)

Retrieved from "https://www.wikidata.org/w/index.php?title=Template_talk:Property_documentation/Archive_1&oldid=2062332011"