Shortcuts: WD:PP/GEN, WD:PP/Generic

# Wikidata:Property proposal/Generic

 Before proposing a property Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties. Check if the property was previously proposed or is on the pending list. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically. Select the right datatype for the property. Start writing the documentation based on the preload form below and add it in the appropriate section. Creating the property Once consensus is reached, change status=ready on the template, to attract the attention of a property creator. Creation can be done 1 week after the proposal, by a property creator or an administrator. See steps when creating properties.
 On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2018/06.

## Generic properties

### SNOMED CT identifier

Under discussion

#### Motivation

I think this property is an useful data, different from official website (P856), for example: Gtkmm (Q284796) has official website (P856) value: https://www.gtkmm.org/, and we could have a GNOME Wiki Id property, with a possible value: https://wiki.gnome.org/Projects/gtkmm -- diskutujo 22:56, 1 May 2018 (UTC)

### visible by means of

Under discussion
Description items of interest can be visible through other items (e.g. webcams) Item type of linked items: Q template a water well such as Mosaikbrunnen (Q27229889) might be live-visible on a web cam such as NZZ WebCam (Q53678107) after the WVZ data set import (https://www.wikidata.org/wiki/Q53629101), we want to mark the fountains that are visible live on the webcams of the city offers view on (P3173), webcam page URL (P4238)

#### Motivation

When people want to see an item of interest real time through the internet, this gives them a hint how to do so. Another application may be tourist binoculars available in many city- or mountain-viewpoints.  – The preceding unsigned comment was added by Ralfhauser (talk • contribs) at 03:19, May 18, 2018‎ (UTC).

"offers view on" (P3173) appears to be the reciprocal approach.

Probably, there is yet another property needed "in focus of URL" because the webcam URL is only likely to give access to the webcam, but some webcams hopefully allow to specifiy by means of an url also what (i.e. which direction, focus, zoom) they should point

#### Discussion

•  Support This is a great example of documenting unusual physical relationships thanks to Wikidata. Matthew (talk) 08:22, 18 May 2018 (UTC)
•  Comment you could do it like this without the need of a new property--Pasleim (talk) 16:28, 18 May 2018 (UTC)
• See webcam page URL (P4238). Thierry Caro (talk) 17:37, 18 May 2018 (UTC)
•  Oppose per @Pasleim:'s suggestion that doesn't require the creation of a new property. Dhx1 (talk) 13:49, 6 June 2018 (UTC)

### production website

Under discussion
Description An official page of a television series hosted by the network or production company. URL "production website" in en:template:infobox television property My Mister (Q43111245) → http://www.chorokbaem.com/main/ko/sub04_02_31.html?xid=4&subxid=2 official website (P856)

#### Motivation

Production website is used in the English infobox. It would be nice to be able to link it to other languages Wikipedia pages just like official website (P856). CherryPie94 (talk) 12:27, 18 May 2018 (UTC)

#### Discussion

Do you have an example where it would be different from official website (P856)? Perhaps just a qualifier on official website (P856) would take care of this? ArthurPSmith (talk) 17:34, 18 May 2018 (UTC)
If we are to link it to Wikipedia infobox it would not work. Currently, the official website is migrated from Wikidata to Englis Wikipedia, but since there is no property for the production website, that can't be done. https://en.wikipedia.org/wiki/My_Mister#External_links This TV series has 1 official link, and 2 links to the production company pages about the TV series. CherryPie94 (talk) 10:42, 20 May 2018 (UTC)
Support Ok, I was mainly just looking for the property template to be filled out, I added your example. ArthurPSmith (talk) 15:01, 21 May 2018 (UTC)
Oppose the proposal lack more examples, domain, infobox parameter, cardinality (can it have multiple values?) etc. URL (P2699) with a qualifier could be used, couldn't it? -- JakobVoss (talk) 06:22, 16 June 2018 (UTC)

### Political coalition

Under discussion
Description agreement for cooperation between different political parties politician (Q82955) Item Dilma Rousseff (Q40722) → position held (P39) → President of Brazil (Q5176750) → Political coalition = For Brazil to keep on changing (Q5466690) parliamentary group (P4100)

#### Motivation

I'm involved in a project of strutured narrative about brazilian elections that I think it will be useful to improve elections items at Wikidata. The database of the official electoral institutions can provide a lot of information. Scrap and bring this data is part of the plan. A political coalition is an agreement for cooperation between different political parties. In a parlamentary item, besides party, it would be great to have the coalition that politician was involved while the electoral process. Ederporto (talk) 01:19, 20 May 2018 (UTC)

#### Discussion

•  Comment position held (P39) statement tend to be overloaded with qualifiers. Maybe an item for each coalition government works better.
--- Jura 17:57, 20 May 2018 (UTC)
@Jura1: Can you be more clear? I didn't get it. Thanks, Ederporto (talk) 23:01, 20 May 2018 (UTC)
•  Support David (talk) 12:45, 26 May 2018 (UTC)

### sense for this name

Under discussion
Description sense of a lexeme corresponding to name Sense (not available yet) Warsaw (Q270) native label (P1705) "Warszawa" → Warszawa/capital of Poland

#### Motivation

Not sure how to do this. (Add your motivation for this property here.)
--- Jura 15:22, 13 May 2018 (UTC)

#### Discussion

It sounds like you are trying to create an inverse of item for this sense (P5137) (which you created though we can't use it yet)? Or is this somehow different (can you clarify)? In any case, I think the inverse direction (which P5137 may already cover) is the better one here, otherwise you'll have one statement per language on each place item. ArthurPSmith (talk) 14:48, 14 May 2018 (UTC)
• I'm trying to figure out how to solve last year's usecase. I'm not sure if P5137 would be sufficient. Maybe we could try an equivalent of statement is subject of (P805). This could be used as a qualifier for a statement such as 'native label = "Warszawa" '.
--- Jura 15:12, 14 May 2018 (UTC)
• I updated this accordingly.
--- Jura 12:22, 15 May 2018 (UTC)

If I understand correctly, this is intended to connect a Statement on an Item to a Lexeme using a qualifier. The use case makes sense to me, but if I understand the structure of this page correctly, this request is misplaced: this section appears to be for Properties to be used on Senses. The proposed Property refers to a Sense, but would be used as a Qualifier on a Statement (supposedly on Items), on on Senses. So the request should probably be at Wikidata:Property_proposal/Generic. -- Duesentrieb (talk) 11:24, 24 May 2018 (UTC)

### SPARQL endpoint URL

Description URL of the SPARQL endpoint of the database/website SPARQL endpoint (Q26261192) URL Wikidata (Q2013) → https://query.wikidata.org/sparql official website (P856), feed URL (P1019)

#### Motivation

Seems preferable over other solution, such as adding a second value to P856 and attempting to qualify it.
--- Jura 12:53, 6 June 2018 (UTC)

#### Discussion

Support, looks useful − Pintoch (talk) 10:56, 7 June 2018 (UTC)
I think JakobVoss has a good idea here - why don't we try a more generic property like that. If we get an overwhelming number for a particular protocol we could split that off separately as its own property, as we've done in some other cases before. ArthurPSmith (talk) 18:04, 8 June 2018 (UTC)
Oa01 pointed out that URL (P2699) is already being used for that here: Q5674339#P2699. Do we even need a new property for API endpoints or should we just use that? − Pintoch (talk) 11:12, 9 June 2018 (UTC)
I first though URL (P2699) and qualifiers is enough but it turns out to be difficult to query API endpoints when no standard protocol has been defined (e.g. custom REST APIs). I'd prefer a dedicated property for API endpoints as subproperty of URL (P2699) -- JakobVoss (talk) 12:43, 9 June 2018 (UTC)
@Jura1: Would you consider this generalization? Lymantria (talk) 05:27, 13 June 2018 (UTC)
I think we already have more general properties that can be used in the suggested way (some were suggested for that). So there wouldn't really be the need for an additional one. The advantage of this proposal is that we wont have to repeat a basic aspect of sparql on every node. Details, if needed, can be added to the property itself.
--- Jura 05:32, 13 June 2018 (UTC)
URL (P2699) is too specific to query generic API endpoints independent of the protocol, this should justify an "API endpoint" property. -- JakobVoss (talk) 06:44, 13 June 2018 (UTC)
•  Support I agree with JakobVoss concerning the name. It's better to rename this property 'API endpoint' and make use of protocol. John Samuel 20:08, 11 June 2018 (UTC)
@Jura1, Pintoch, ديفيد عادل وهبة خليل 2, ArthurPSmith, JakobVoss, Pigsonthewing:@John Samuel:  Done for the narrow proposal, now SPARQL endpoint (P5305). A broader approach can be discussed later, SPARQL endpoint (P5305) might become a subproperty of that one. Lymantria (talk) 08:01, 13 June 2018 (UTC)
@Jura1, Pintoch, ديفيد عادل وهبة خليل 2, ArthurPSmith, JakobVoss, Pigsonthewing:@John Samuel: Sorry, this procedure is not right, we had an ongoing discussion and no reason to hurry. Please delete the property and let's exchange arguments and examples first: Wikidata:Properties_for_deletion#SPARQL_endpoint_(P5305) -- JakobVoss (talk) 13:27, 13 June 2018 (UTC)

### Scope of this property

This property was created by accident before rough consensus could be reached, whether to have a specific property for SPARQL endpoints or a more generic property for API endpoints and a qualifier for SPARQL protocol. Let's collect arguments to find a solution that everybody can work with! -- JakobVoss (talk) 21:17, 13 June 2018 (UTC)

@JakobVoss: given the deletion discussion I think at this point it's best to just propose this as a separate property, I think you'll get some support! ArthurPSmith (talk) 14:39, 15 June 2018 (UTC)

#### Arguments for/against SPARQL specific property

•  Support it's easier to express and query SPARQL endpoints (the particular use case of this property) -- JakobVoss (talk) 19:57, 15 June 2018 (UTC)

#### Arguments for/against generic API endpoint property

•  Support API's are intended for machine interaction and so making that distinction from our existing URL properties is useful; there are many protocols, and in fact a lot of places have custom protocols defined by something like OpenAPI (Q18393146). ArthurPSmith (talk) 15:40, 14 June 2018 (UTC)
•  Support I likee the idea that protocols can be defined just by their Qid - this potentially lets us make interesting SPARQL queries. − Pintoch (talk) 13:47, 15 June 2018 (UTC)
•  Support So we can record API endpoints in general. It seems intuitive that we should create more generic properties first, then create more specific sub-properties as required. Deryck Chan (talk) 13:08, 18 June 2018 (UTC)
•  Support for generic properties first, big number of protocols and ease of specifying protocols as mentioned (it seems to get a voting here now more than a collection of arguments, so I want to use it this way …:) ). --Marsupium (talk) 13:33, 20 June 2018 (UTC)

#### Arguments for/against both "SPARQL endpoint" and "API endpoint" properties

•  Oppose more difficult to query all API endpoints because SPARQL is additional property to explicitly query for (subproperties are not included automatically) -- JakobVoss (talk) 19:57, 15 June 2018 (UTC)
•  Question What services will have separate SPARQL and API endpoints? If that were the case, will the API endpoints all need object has role (P3831) to clarify what APIs they are? Taking Wikidata as an example, one may also argue that the API endpoint is https://www.wikidata.org/w/api.php is the endpoint for Wikidata, whereas https://query.wikidata.org/sparql is actually the API endpoint for the Wikidata Query Service. Deryck Chan (talk) 17:13, 18 June 2018 (UTC)

#### Arguments for/against having none of them

•  Oppose The property creation proposal above clearly demonstrated it will be useful to have at least one new property to record SPARQL endpoints, either with a "SPARQL endpoint" property or with an "API endpoint" property. --Deryck Chan (talk) 15:56, 15 June 2018 (UTC)
•  Oppose more difficult to express and query API endpoints (always need to check qualifier, use special qualifier value "unknown" for unknown protocol) -- JakobVoss (talk) 19:57, 15 June 2018 (UTC)

### number of rocket stages

Under discussion
Description number of stages for a rocket rocket stage (Q4809) Quantity rocket (Q41291) positive integers Sputnik (Q1393751) -> 2

#### Discussion

Ideally this would have a less unwieldy name like "number of stages", although I'm afraid people would then start adding it to stuff like 2018 Tour de France (Q28859163).--Reosarevok (talk) 19:34, 9 June 2018 (UTC)
Oppose has parts of the class (P2670) with an item like "rocket stage of Sputnik" and quantity (P1114) would be a better way to specify this relationship. The proposed property is too specific. ChristianKl❫ 14:05, 14 June 2018 (UTC)

### reference has role

Description role, or specific nature, of the given reference reference (Q121769) Item references limited list of allowed values AS PART OF REFERENCE → first description (of a taxon) (Q1361864) convert existing uses of P31 as a reference to use the new property subject has role (P2868), object has role (P3831)

#### Motivation

We currently have about 50,000 cases where instance of (P31) is used as a property in a reference, rather than as a main statement. See queries: tinyurl.com/y78odkdu (counts of values), tinyurl.com/y8owabzc (examples). The use on e.g. Q101538#P225 is typical.

In my opinion, use of P31 in this way is ugly and confusing -- IMO it would be better if P31 was only used for its main purpose, as a direct statement on an item giving its nature.

Use of P31-on-references is similar to the way P31 once used also to be used as a qualifier. But those uses have now everywhere been removed and replaced with subject has role (P2868) and object has role (P3831).

P31-on-references is currently doing some important work. In particular, the #1 value of P31-on-references, first description (of a taxon) (Q1361864), to be able to indicate that the reference in question contained the first description and definition of a taxon is extremely valuable and important to be able to highlight for taxonomic references.

To me it therefore makes sense to propose a new drop-in replacement "reference has role" for P31-on-references, as a specific property to take over this function, which is different from the normal use of P31; and which would allow a constraint to limit acceptable values to an agreed controlled vocabulary. -- Jheald (talk) 14:30, 10 June 2018 (UTC)

#### Discussion

Notified participants of WikiProject Taxonomy -- Jheald (talk) 14:56, 10 June 2018 (UTC)

•  Support. Appears to me, a relatively inexperienced Wikidata-er, to fill a niche role. If/when created, could instance of (P31) be software-restricted from being placed in references, to avoid confusion & accidental placement? —Tom.Reding (talk) 15:24, 10 June 2018 (UTC)
The software wouldn't completely prevent it, but it would register a constraint violation, and place a warning error sign next to it. Jheald (talk) 19:52, 10 June 2018 (UTC)
Comment - This is not an isolated proposal: publication in which this scientific name was established also deals with this issue, but proposes to move this to a statement. Since there are so many cases for this, and likely to become more, a separate property (making this a statement) seems well justified. The qualifier "first description (of a taxon) (Q1361864)," looks quite awkward to me (also wrong: it is the establishing of a name that matters here, not the description): if there are three references listed, will the software that reads in data be able to determine what reference this qualifier belongs to? A separate property would make this unnecessary. - Brya (talk) 17:12, 10 June 2018 (UTC)
@Brya: I don't see the two proposals as necessarily in conflict. Firstly, there are other reasons why one might want to annotate a reference: establishing a taxon is only one example. Secondly, even if there was a separate statement for when the scientific statement was established, one might still want to note of a reference that it was the originating paper, or the statement that redefined the taxon, or some other notable thing about the paper. But it would be a good thing to get rid of the current P31s.
As to your technical question, the annotation becomes part of the reference (as the present uses of P31 do). It is therefore uniquely associated with a single reference, just as much as the properties "stated in" or "volume" or "page" would be. There is no danger of crosstalk with any other reference. Jheald (talk) 19:52, 10 June 2018 (UTC)
Yes, on this last point, I had realized that the danger of software reading it out wrong was quite limited. It will still be confusing to the reader. - Brya (talk) 16:41, 11 June 2018 (UTC)

### mathematical concept defining formula

Under discussion
Description mathematical formula representing the definition of a mathematical concept Mathematical expression instances and subclasses of mathematical concept (Q24034552) absolute value (Q120812) → ${\displaystyle \left\{{\begin{array}{rl}x,&{\text{if }}x\geq 0\\-x,&{\text{if }}x<0.\end{array}}\right.}$ absolute value (Q120812) → ${\displaystyle x\mathop {sgn} (x)}$ defining formula (P2534)

#### Motivation

defining formula (P2534) allows to add the formula that defines a mathematical statement, but currently there isn't a property to add the formula that defines a mathematical concept. Malore (talk) 18:00, 10 June 2018 (UTC)

#### Discussion

•  Support David (talk) 16:21, 14 June 2018 (UTC)
•  Oppose per Arthur, just use defining formula (P2534) - feel free to broaden its description and usage instructions to reflect that. − Pintoch (talk) 13:50, 15 June 2018 (UTC)

### mathematical concept definition

Under discussion
Description definition of a mathematical concept in natural language Multilingual text (not available yet) instance or subclass of mathematical concept (Q24034552) absolute value (Q120812) → "unsigned" portion of a number absolute value (Q120812) → distance of a number from zero

#### Motivation

It's the same of "mathematical concept defining formula" but expressed in natural language instead of mathematical expression.

It differs from the item description because the latter should be a short sentence used only to identify the item. Another difference is that a mathematical concept can have multiple definitions.

It should contain as few symbols as possible to be comprehensible by everyone. Malore (talk) 18:27, 10 June 2018 (UTC)

#### Discussion

Oppose Sorry, but for me is exactly the same as the description. The Wikipedia article fills the function of disambiguate the possible interpretations or definitions of a formula. The item exists to show the metadata about the formula, not its interpretation, if someone is curious about the possible meanings of it, they should go to the Wikipedia article. Good contributions, Ederporto (talk) 23:48, 10 June 2018 (UTC)

Also, this is so subjective. The quantity of symbols does not ensures the unserstanding, the choice of words is more dangerous than the use of symbols. Ederporto (talk) 23:53, 10 June 2018 (UTC)

Oppose this is what the description field is for. Also multilingual text (data type) does not exist. ArthurPSmith (talk) 18:35, 11 June 2018 (UTC)

@ArthurPSmith: They have differentt goals. The goal of the description field is to distinguish the item from similar ones, while the goal of this property is to give all the definitions of the concept. It is the same of "mathematical concept defining formula" (the other property I proposed) but in natural language instead of symbols. --Malore (talk) 21:41, 11 June 2018 (UTC)

Oppose Wikidata is designed to store structured information, definitions of concepts in natural language are not structured. Descriptions can be used for that. − Pintoch (talk) 13:52, 15 June 2018 (UTC)  Oppose -- JakobVoss (talk) 06:13, 16 June 2018 (UTC)

### abgeordnetenwatch.de ID

Description identifier for a German politician, in the abgeordnetenwatch.de database abgeordnetenwatch.de (Q320307) External identifier German politicians [1-9][0-9]* Angela Merkel (Q567) → 79137 Cem Özdemir (Q12839) → 79102 Xaver Jung (Q15813187) → 79269 Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. link to all profiles for German politicians, create potential missing items for German politicians not on Wikidata 709 (Bundestag); > 1.500 altogether eventually complete (Q21873974) https://www.abgeordnetenwatch.de/user/$1 #### Motivation abgeordnetenwatch.de is a non-profit Internet portal that allows German citizens to question their representatives in German parliaments publicly. Users of the site can contact representatives of national Parliament (the Bundestag), German deputies of the European Parliament and of the German federal states. The abgeordnetenwatch.de ID is a numeric value for all current members of parliaments and candidates running in the elections to these parliaments. abgeordnetenwatch.de is the most complete collection of German parliamentary politicians that is freely available. Data is offered to the public through open APIs https://www.abgeordnetenwatch.de/api I propose this property in my function as an employee of abgeordnetenwatch.de (database editor) and a member of the Wikidata community. a_ka_es 07:16, 15 June 2018 (UTC) #### Discussion Notified participants of WikiProject Authority control Notified participants of WikiProject Germany --Lucas Werkmeister (talk) 08:41, 15 June 2018 (UTC) ### API endpoint Under discussion Description base URL of a web service URL data set (Q1172284), web service (Q193424) Wikidata (Q2013) → https://www.wikidata.org/w/api.php (no standard protocol) Library of Congress (Q131454) → "unknown"qualifier described at URL (P973) https://libraryofcongress.github.io/data-exploration/ Library of Congress (Q131454) → http://lx2.loc.gov:210/LCDBqualifier protocol (P2700) Search/Retrieve via URL (Q337367) GitHub (Q364) → https://api.github.com/graphqlqualifier protocol (P2700)qualifier described at URL (P973) https://developer.github.com/v4/ GitHub (Q364) API → https://api.github.com (no standard protocol)qualifier file format (P2701) JavaScript Object Notation (Q2063) websites of each item and third-party directories such as https://www.programmableweb.com/apis/directory SPARQL endpoint (P5305), feed URL (P1019), URL (P2699) #### Motivation Specify API endpoints to access databases via web services. Standard protocols can be added with qualifier protocol (P2700) and link to API documentation with qualifier described at URL (P973). This property was also discussed as part of Wikidata:Property proposal/SPARQL endpoint. API endpoints can already be specified with URL (P2699) and qualifier protocol (P2700) but many endpoints don't follow a standard protocol and it's more convenient to query endpoints without qualifier. -- JakobVoss (talk) 06:58, 16 June 2018 (UTC) #### Discussion Support (but please don't support your own proposal - it makes it clearer to assess at a glance if there is consensus) − Pintoch (talk) 08:23, 18 June 2018 (UTC) Support ArthurPSmith (talk) 14:44, 18 June 2018 (UTC) Oppose duplicates the existing property proposed at Wikidata:Property proposal/Archive/48#P2699. I don't think it can work work as intended by the proposer ("it's more convenient to query endpoints without qualifier."). Maybe it's just that the use case isn't specified. --- Jura 06:15, 19 June 2018 (UTC) This makes no sense to me: you just argued the opposite at Wikidata:Property proposal/SPARQL endpoint -- JakobVoss (talk) 21:07, 20 June 2018 (UTC) • I don't think I did, but it's possible that I just don't understand your usecase. As you haven't given it, that seems normal. So what do you want to do with this property that you can't do with the one proposed for the same at Wikidata:Property proposal/Archive/48#P2699. Please include a sample query and application. --- Jura 04:05, 21 June 2018 (UTC) Support - Bit sad that we already have SPARQL endpoint (P5305), because this seems to be much more versatile. Husky (talk) 19:20, 19 June 2018 (UTC) Support - I actually like that we have SPARQL endpoint (P5305) as well, because I think that a SPARQL endpoint has particularly strong relevance for people working with Wikidata. But I do think this property is a useful distinction over generic URL (P2699) -- an API for data extraction is a very specific sort of URL, that it is useful to separate from other sorts of URLs the site may offer; and the API URL statements are already going to be quite complicated, with quite a lot of potential qualifiers flying around. It's a lot cleaner to be able to consider them separately, without them being muddled together with all sorts of other URLs, with all sorts of other role-specific qualifiers. Jheald (talk) 21:05, 19 June 2018 (UTC) • Oppose As noted above, this duplicates URL (P2699), whose documentation should be clarified. It may, though, be useful to have a new property with an$1 component. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:23, 20 June 2018 (UTC)
@Pigsonthewing: More accurately, it's a specialisation of P2699 rather than a duplication. This property is proposed to segregate off a specific subset of things currently loaded on the reserve backstop property URL (P2699). Jheald (talk) 11:06, 20 June 2018 (UTC)

### type of water

Under discussion
Represents four types of water are specified by the data set data set (Q1172284) fountainsWVZ (Q53629101) Item Water distribution pipe network (Q53633635) own water supply (Q53634173) groundwater (Q161598) spring water (Q1881858)

#### Motivation

For any fountain, it is interesting what type of water it supplies. Also, this is a column in the original data set and we would not want to loose this information upon import. (Will make type of water (Q53673519) obsolete) Ralfhauser (talk) 11:50, 16 June 2018 (UTC)

#### Discussion

Support This property will be useful to indicate the type of water (e.g., spring water, tap water) that we get in the data set that we would like to import from Open Data Zurich into Wikidata [https://github.com/opendata-zurich/wikidata/tree/master/fountains]. Cristina Sarasua (talk) 11:59, 16 June 2018 (UTC)

Support The type of water is a relevant piece of information, because e.g. groundwater has more minerals than water from the distribution mains. Matthew (talk) 12:18, 16 June 2018 (UTC)

Support I'm working for the City of Zurich and think that this property would be really useful +1 Marco Sieber (talk) 12:18, 16 June 2018 (UTC)

Comment The examples as supplied are not valid - please follow the example pattern shown with both a subject item and (for item datatype) a value item for each example. ArthurPSmith (talk) 14:47, 18 June 2018 (UTC)

Comment This is type of water supply, rather than type of water, I think. It seems very specific. All the best: Rich Farmbrough10:31, 20 June 2018 (UTC).

•  Oppose. I don't get it. The proposal is badly formatted. Thierry Caro (talk) 11:12, 22 June 2018 (UTC)