Wikidata:Property proposal/Archive/24
|
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
Musicbrainz Series ID
| Description | The series ID of the Thing in musicbrainz. (documentation in the musicbrainz wiki) |
|---|---|
| Data type | String |
| Domain | musical works, series of musical works, series of books published as audiobook series |
| Allowed values | Format "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}": value must be formatted using this pattern |
| Example | Bach-Werke-Verzeichnis (Q214203) → d977f7fd-96c9-4e3e-83b5-eb484a9e6582 |
| Proposed by | Shisma (talk) |
- Discussion
like all the other musicbrainz entites this id should be linked with the page. http://musicbrainz.org/series/[add id here] Shisma (talk) 07:12, 1 July 2014 (UTC)
- MusicBrainz analyse a music file, creates a fingerprint out of it which can then be used to identify the artist / title. It is a collaborative project which anyone can edit and is surprisingly accurate. I love that idea. Hashar (talk) 08:53, 1 July 2014 (UTC)
- so I take it as a
Support.. right? --Shisma (talk) 11:23, 8 July 2014 (UTC)
- so I take it as a
city of license
| Description | community a radio or TV station is officially assigned to |
|---|---|
| Data type | Item |
| Template parameter | "city" in en:Template:Infobox radio station and en:Template:Infobox broadcast |
| Domain | instance of (P31): broadcaster (Q15943455) or subclass |
| Allowed values | instance of (P31): geographic location (Q2221906) or subclass |
| Example |
|
| Format and edit filter validation |
{{Constraint:Single value}} with some exceptions: Stations occasionally are allowed to directly change the city of license; or occasionally a station "swaps" with another station and the Wikipedia article follows the cultural identity (to a new frequency and possibly city of license) rather than the station facility (same frequency/city with new programming). Values should be unique within a start-end period though.{{Constraint:Value type|class=Q2221906|relation=instance}}: some location items don't match this yet, but that's a problem with the location item, not the station item |
| Source | U.S. FCC databases (online and updated frequently) have official city, state, and country for this property in the U.S., and sometimes-lagging last-notified data for Canada and Mexico; similar official Canadian and Mexican lists exist (though, last I checked, Mexico's official publication was PDF) |
| Robot and gadget jobs | A bot or gadget could find the correct Wikidata item:
|
| Proposed by | Closeapple (talk) |
- Discussion
Broadcast stations in Canada and the U.S. (and possibly other places) are assigned a city of license (Q3545675) that appears on the station's license, and which the station required to provide primary service to. Unfortunately, located in the administrative territorial entity (P131) and P1134 (P1134) aren't specific: the station studio, the transmitter/antenna, the broadcast area (metro/media market), and the city of license (Q3545675) are often all different places. In the last few decades, stations have been allowed to intentionally confuse the matter by pretending to be for whatever city they want, except for a quick hourly phrase called "legal ID". --Closeapple (talk) 19:03, 1 July 2014 (UTC)
- Support --AmaryllisGardener talk 19:06, 1 July 2014 (UTC)
Comment: Maybe this proposal should be moved to another proposal page, since it's not really an authority control like FCC Facility ID (P1400) is. (When I saw that proposal, I jumped in with this related one because I was already in the process of writing it.) --Closeapple (talk) 19:12, 1 July 2014 (UTC)
- @Closeapple: It should probably go to Wikidata:Property proposal/Organization. --AmaryllisGardener talk 22:25, 1 July 2014 (UTC)
- Moved from WD:PP/AUTH --Jakob (talk) 00:15, 2 July 2014 (UTC)
- Support Danrok (talk) 17:55, 2 July 2014 (UTC)
- Support -- SERutherford (talk) 05:53, 6 July 2014 (UTC)
Question Closeapple, wouldn't be better to have a generic label like "broadcast area" so this property could be used for all countries?--Micru (talk) 08:03, 7 July 2014 (UTC)
- That seems to be the separate concept media market (Q2270014). A media market (Q2270014) and specific city of license (Q3545675) both exist for the same station, at least in Canada and the U.S.; though on English Wikipedia, we had to stop importing the most common media market (Q2270014) borders for U.S. stations because the private company that creates them decided to hit Wikipedia with en:Wikipedia:Administrators' noticeboard/Archive170#Nielson DMCA Takedown. (Those have now been replaced with Wikipedia community-designed areas, but the Wikipedia-designed ones are not official.) I don't know enough about other countries' media industries to know which (or if) other countries have both a city of license (Q3545675) and a derived media market (Q2270014), and which countries designate only a media market (Q2270014) directly. I assume some countries use some already-existing statistical borders as their official broadcast areas also. --Closeapple (talk) 10:40, 7 July 2014 (UTC)
- @Micru: (I don't know if users get notified when someone replies to them now, or just when they're mentioned.) --Closeapple (talk) 10:49, 7 July 2014 (UTC)
- @Closeapple: To avoid confusions with "media market" and to allow more general uses, what about "licensed to broadcast in"? Some stations have a more general broadcasting license, like "country", or "region", so it would be easier to use the same property for all cases instead of having separate properties for each type of geographic range.--Micru (talk) 10:53, 7 July 2014 (UTC)
- @Micru: Maybe something like "official broadcast target location" or "licensed to broadcast to". The word "in" is a bit of a problem, as is not designating "target" or "to": The subtlety of this property is that it is not necessarily where any of the station facility physically is; it's a specific locale that the station is legally supposed to be targeted to. (And in the U.S., the stations do everything they can to avoid acknowledging it if it doesn't happen to be the main city in the metropolitan area. If there is any chance that someone will mistake this for the advertiser-friendly metro name, it will end up having the wrong data, at least in the U.S. and Canada.) --Closeapple (talk) 11:11, 7 July 2014 (UTC)
- Maybe it's worth mentioning that this is sometimes called "community of license" instead of "city of license", if that makes things more flexible. --Closeapple (talk) 11:15, 7 July 2014 (UTC)
- @Closeapple: "official broadcast target location" sounds perfect because it would allow reuse for communication satellites items, ex. Nimiq 2 (Q14559241)=>North America (Q49), and it would allow to identify stations that are also broadcasting through internet. If you would prefer to have a specific property for "community of license", it is also possible, but I do not see any clear benefit over a more general property.--Micru (talk) 11:25, 7 July 2014 (UTC)
- @Micru:: Is a satellite like that legally obligated to provide service to a specific place, or is there just a practical coverage area based on the satellite's stationary position, with no government obligation to actually target a specific place once it's up there? I think that Internet broadcasting is exactly the opposite of what this property was proposed for: Internet "broadcasters" (content services) normally have no government license, let alone a license condition that mandates service into a specific location. Or does that happen in some places? (I mean other than state-owned broadcasters that also provide their content over the Internet.) --Closeapple (talk) 12:02, 7 July 2014 (UTC)
- @Closeapple:, broadcasters also need a licence for broadcasting from satellites (see: w:Direct-broadcast satellite). AFAIK, Internet broadcasting can also be limited, for instance some UK tv channels can only be watched by IPs from UK.--Micru (talk) 13:00, 7 July 2014 (UTC)
- @Micru: Yes, broadcasters need a license for satellites, but is there a mandated minimum location that must receive coverage, or just an unconditional license to cover whatever of the country's jurisdiction the broadcaster has the resources to hit? The Internet "broadcast" restrictions are almost completely caused by copyright licensing agreements, not government permits: Copyright holders often divide exclusive copyright licenses by country and season, so the broadcaster is obligated not to provide programs outside of the country they paid for. Even public broadcasters, like the BBC, do this with their own productions, because they give exclusive licenses for other countries to their own BBC Worldwide (Q2071905) subsidiaries (which have commercials) or to other broadcasters in other countries — which is why they block video on BBC iPlayer (Q2557489) outside the UK. --Closeapple (talk) 13:23, 7 July 2014 (UTC)
- @Closeapple:, in which way is that relevant for this property?--Micru (talk) 13:41, 7 July 2014 (UTC)
- @Micru: I don't think those two subjects are relevant, which is my point: This property shouldn't be assigned to items based on where their broadcasts happen to be restricted by the broadcaster's own choice (corporate/economic/content rights issues), but should be based on the specific locale (if any) that the law/government license requires a specific station to provide service to, whether or not it also provides service to adjacent areas. --Closeapple (talk) 14:01, 7 July 2014 (UTC)
- @Closeapple: Ok, then what about "licensed to broadcast to"? --Micru (talk) 14:27, 7 July 2014 (UTC)
- @Micru: That seems reasonable; as long as it's clear that the property indicates that the station is required to provide service to at least this locale in order to fulfill its legal mandate; it's not just where the signal is allowed to cover, but where it's required to cover. (I can understand the need to have one property for this concept and another for media market (Q2270014) also, if both are designated by a well-established authority.) --Closeapple (talk) 17:26, 7 July 2014 (UTC)
- @Closeapple: Ok, then what about "licensed to broadcast to"? --Micru (talk) 14:27, 7 July 2014 (UTC)
- @Micru: I don't think those two subjects are relevant, which is my point: This property shouldn't be assigned to items based on where their broadcasts happen to be restricted by the broadcaster's own choice (corporate/economic/content rights issues), but should be based on the specific locale (if any) that the law/government license requires a specific station to provide service to, whether or not it also provides service to adjacent areas. --Closeapple (talk) 14:01, 7 July 2014 (UTC)
- @Closeapple:, in which way is that relevant for this property?--Micru (talk) 13:41, 7 July 2014 (UTC)
- @Micru: Yes, broadcasters need a license for satellites, but is there a mandated minimum location that must receive coverage, or just an unconditional license to cover whatever of the country's jurisdiction the broadcaster has the resources to hit? The Internet "broadcast" restrictions are almost completely caused by copyright licensing agreements, not government permits: Copyright holders often divide exclusive copyright licenses by country and season, so the broadcaster is obligated not to provide programs outside of the country they paid for. Even public broadcasters, like the BBC, do this with their own productions, because they give exclusive licenses for other countries to their own BBC Worldwide (Q2071905) subsidiaries (which have commercials) or to other broadcasters in other countries — which is why they block video on BBC iPlayer (Q2557489) outside the UK. --Closeapple (talk) 13:23, 7 July 2014 (UTC)
- @Closeapple:, broadcasters also need a licence for broadcasting from satellites (see: w:Direct-broadcast satellite). AFAIK, Internet broadcasting can also be limited, for instance some UK tv channels can only be watched by IPs from UK.--Micru (talk) 13:00, 7 July 2014 (UTC)
- @Micru:: Is a satellite like that legally obligated to provide service to a specific place, or is there just a practical coverage area based on the satellite's stationary position, with no government obligation to actually target a specific place once it's up there? I think that Internet broadcasting is exactly the opposite of what this property was proposed for: Internet "broadcasters" (content services) normally have no government license, let alone a license condition that mandates service into a specific location. Or does that happen in some places? (I mean other than state-owned broadcasters that also provide their content over the Internet.) --Closeapple (talk) 12:02, 7 July 2014 (UTC)
- @Closeapple: "official broadcast target location" sounds perfect because it would allow reuse for communication satellites items, ex. Nimiq 2 (Q14559241)=>North America (Q49), and it would allow to identify stations that are also broadcasting through internet. If you would prefer to have a specific property for "community of license", it is also possible, but I do not see any clear benefit over a more general property.--Micru (talk) 11:25, 7 July 2014 (UTC)
- @Closeapple: To avoid confusions with "media market" and to allow more general uses, what about "licensed to broadcast in"? Some stations have a more general broadcasting license, like "country", or "region", so it would be easier to use the same property for all cases instead of having separate properties for each type of geographic range.--Micru (talk) 10:53, 7 July 2014 (UTC)
- @Closeapple, AmaryllisGardener, Danrok, SERutherford:
Done --Jakob (talk) 22:29, 8 July 2014 (UTC)
compression ratio
| Description | compression ratio of the engine |
|---|---|
| Data type | Number (not available yet) |
| Template parameter | w:en:Template:pistonspecs : compression |
| Domain | engines |
| Allowed values | positive |
| Example | Gnome-Rhône Mistral Major (Q902691) => compression ratio => 5.5:1 |
| Proposed by | Joshbaumgartner (talk) 07:02, 2 October 2013 (UTC) |
- Support Simple data point used in the specs infobox. Joshbaumgartner (talk) 07:02, 2 October 2013 (UTC)
Oppose the datatype. Ratios should be entered as one number in relation to one. --Tobias1984 (talk) 14:07, 25 November 2013 (UTC)
Not done Wrong datatype. Maybe the number datatype will support fractions, if not, use relation to 1.--Micru (talk) 17:52, 25 November 2013 (UTC)
- @Joshbaumgartner: Now that we have the number-datatype you could update this proposal. We can't do ratios but the property can state which one of the numbers should be entered (The other one being 1). --Tobias1984 (talk) 18:28, 4 February 2014 (UTC)
- @Tobias1984: Proposal updated and Support.--Micru (talk) 15:04, 26 March 2014 (UTC)
- @Tobias1984: Proposal updated and
- @Joshbaumgartner, Tobias1984, Micru: Done as this has been open half a year and the only opposition is to the data type (which has been changed). --Jakob (talk) 15:21, 11 April 2014 (UTC)
bug report page
| Description | page where bugs, issues, and feature requests are filed for a particular software |
|---|---|
| Data type | URL |
| Domain | software |
| Allowed values | valid urls |
| Example | Wikidata (Q2013) => "https://bugzilla.wikimedia.org/" |
| Format and edit filter validation | unique value |
| Source | official websites of programs |
| Proposed by | -Tobias1984 (talk) 22:59, 18 June 2014 (UTC) |
- Discussion
- Relevant information for software and useful to answer queries like "where do I file bugs for Firefox?". -Tobias1984 (talk) 22:59, 18 June 2014 (UTC)
- @Emw, Jakec, Zuphilip, Danrok, Bene*, 콩가루: - Tobias1984 (talk) 13:58, 28 June 2014 (UTC)
- @TomT0m: and below -Tobias1984 (talk) 20:18, 30 June 2014 (UTC)
- Support--- Jura 21:44, 30 June 2014 (UTC)
- Support - OK. --Jakob (talk) 15:47, 3 July 2014 (UTC)
- Support -- SERutherford (talk) 05:56, 6 July 2014 (UTC)
- Done -Tobias1984 (talk) 20:10, 6 July 2014 (UTC)
nominated to
| Description | nomination received by a person, organisation or creative work (inspired from "award received" (Property:P166)) |
|---|---|
| Data type | Item |
| Template parameter | en:Template:Awards_table |
| Domain | person, organisation or creative work |
| Allowed values | award (Q618779) |
| Example | Wikidata showcase "Arctic Monkeys" : Arctic Monkeys (Q170599) => Grammy Award for Best Alternative Music Album (Q1542129) |
| Format and edit filter validation | no |
| Source | external reference, Wikipedia list article (either infobox or source) |
| Robot and gadget jobs | no |
| Proposed by | Gc.chiron |
- Discussion
Motivation :
I want to include "nominations" facts into Arctic Monkeys (Q170599) (showcase item) by using this proposed "Nomination received" property.
However, it can be discussed. I also see 2 other possible ways of doing it :
1) Awards and nominations can be listed in a new item as the manner of the albums in "Arctic Monkeys Discography" Arctic Monkeys discography (Q638072).
2) Use qualifiers such as "Won", "Nominated", "Shortlisted" to distinguish the nature of awards associated to "Award received" (Property:P166).
Which solution is the best ?
- Support--Micru (talk) 11:31, 19 June 2014 (UTC)
- Changed title to "nominated to", which seems more natural. @Jobu0101, ValterVB:, do you think you could make use of this property in your Oscar-nominated movies?--Micru (talk) 10:41, 11 July 2014 (UTC)
- Support But we can't use it like qualifier, because we already use point in time (P585) like qualifier. --ValterVB (talk) 11:07, 11 July 2014 (UTC)
- @ValterVB: I wouldn't use it as qualifier either, but just as a normal property with qualifier "point in time" and perhaps "applies to" if there are award categories.--Micru (talk) 11:48, 11 July 2014 (UTC)
- @Micru: I absolutely think that Oscar awards and Oscar nominations should be represented in Wikidata. A long-term goal would be to generate lists like en:Academy Award for Best Picture#Winners and nominees automatically. A problem in this Oscar business is that they often changed the names of awards. Wikidata has to know which awards belong together. They also split up awards and merged them. Wikidata has to know how to deal with such problems. --Jobu0101 (talk) 11:11, 11 July 2014 (UTC)
- @Jobu0101: Wikidata cannot know anything if you don't create the structure first. You can connect awards with "instance of", "subclass of", "replaces", etc. Of course the best would be to have a films wikiproject to coordinate efforts.--Micru (talk) 11:48, 11 July 2014 (UTC)
- @Micru: Of course, you have to create the structure first. But before you create the structure you should ensure that the structure you want to create is well designed. Because of the complexity of the Oscar business I'm not so sure about how an optimal design looks like. --Jobu0101 (talk) 12:27, 11 July 2014 (UTC)
- Ok, think about it. In any case the organization of the Oscar awards is independent from this property, so I have proceeded to create it.
- @Micru: Of course, you have to create the structure first. But before you create the structure you should ensure that the structure you want to create is well designed. Because of the complexity of the Oscar business I'm not so sure about how an optimal design looks like. --Jobu0101 (talk) 12:27, 11 July 2014 (UTC)
- @Jobu0101: Wikidata cannot know anything if you don't create the structure first. You can connect awards with "instance of", "subclass of", "replaces", etc. Of course the best would be to have a films wikiproject to coordinate efforts.--Micru (talk) 11:48, 11 July 2014 (UTC)
Done As nominated for (P1411). Notification: @Gc.chiron, ValterVB, Jobu0101:.--Micru (talk) 13:01, 11 July 2014 (UTC)
- @Gc.chiron, Micru, Jobu0101: Example: Farciot Edouart (Q11284)
- Thx. Now the work begins ;) --Jobu0101 (talk) 15:10, 11 July 2014 (UTC)
convicted of
| Description | crime which the subject has been found guilty of by the court |
|---|---|
| Data type | Item |
| Template parameter | "convictions" in en:template:Infobox criminal |
| Domain | human (Q5) |
| Allowed values | items which are crimes |
| Example | Mark Hofmann (Q4354485) => murder (Q132821), forgery (Q1332286) and fraud (Q28813) |
| Source | infoboxes, court websites, etc. |
| Robot and gadget jobs | bots could gather from infoboxes |
| Proposed by | Danrok (talk) 20:38, 28 June 2014 (UTC) |
- Discussion
- Support --AmaryllisGardener talk 21:08, 28 June 2014 (UTC)
- Support Changed label to "convicted of", because "convictions" can also mean "a fixed or strong belief".--Micru (talk) 10:40, 29 June 2014 (UTC)
- @Danrok, AmaryllisGardener, Micru: Done --Jakob (talk) 16:42, 5 July 2014 (UTC)
biome
Not done
| Description | Biome of an ecoregion |
|---|---|
| Data type | Item |
| Template parameter | en:template:Infobox_ecoregion field biome |
| Domain | ecoregion (Q295469) |
| Allowed values | biome (Q101998) |
| Example | Antipodes Subantarctic Islands tundra (Q401979) => tundra (Q43262) |
| Source | Wikipedia infobox |
| Proposed by | John Vandenberg (talk) |
- Discussion
Start to link together the basic ecology framework. John Vandenberg (talk) 08:21, 15 April 2014 (UTC)
- Comment I would use subclass of (P279) or part of (P361) to connect the different ecotypes (in the example above: P279). What would you otherwise do for a taxon which only lives in Bounty Islands (Q41451), a part of (P361) Antipodes Subantarctic Islands tundra (Q401979)? As you say below: Due to the different definitions, we need flexibility here. I am also still not convinced regarding the differentiation to endemic to (P183). This property is already quite ambiguous: Endemic s.s. is only defined for encapsulated regions (endemic to Galapagos) while endemic s.l. is valid for arbitrary regions (Homo sapiens: endemic to earth). Thus, is for example "endemic to Austria" allowed? I would like to sort this out first or - if we see that there exists not a strict definition - I do not see the need for the property "ecoregion". Then, you could also state Sooty Albatross (Q1265896) endemic to (P183) Antipodes Subantarctic Islands tundra (Q401979) and in case you are only interested in ecoregions, restrict the query result to all items which are instance of (P31) ecoregion (Q295469): 0 taxa are currently endemic to an ecoregion — Felix Reimann (talk) 09:14, 15 April 2014 (UTC)
- If we used part of (P361), how do we distinguish between ecozone and biome in the infoboxes, as seen at w:Tigris–Euphrates river system? John Vandenberg (talk) 12:08, 17 April 2014 (UTC)
- Just check if the target of P361 has instance of (P31) ecozone or biome. See also the nice autodescription I found when querying for "all items, which are part of an ecozone" http://tools.wmflabs.org/wikidata-todo/autolist.html?q=claim[361%3A%28claim[31%3A101998]%29] Sounds fitting... ;) — Felix Reimann (talk) 15:32, 17 April 2014 (UTC)
- If we used part of (P361), how do we distinguish between ecozone and biome in the infoboxes, as seen at w:Tigris–Euphrates river system? John Vandenberg (talk) 12:08, 17 April 2014 (UTC)
Just FYI admin wanting to reject & archive this proactively, I will reply to this thread in a few days. John Vandenberg (talk) 02:47, 5 May 2014 (UTC)
I've thought about this a bit and I am happy to not proceed with this proposed property per Felix's comments. John Vandenberg (talk) 05:35, 8 May 2014 (UTC)
Not done Per comments. Notification: @John Vandenberg, FelixReimann:
ploidy
| Description | the number of sets of chromosomes in the nucleus of a cell |
|---|---|
| Data type | Item |
| Template parameter | "ploidy" in en:template:infobox genome |
| Domain | genome (Q7020) |
| Allowed values | subclass of ploidy (Q118406) |
| Example | human genome (Q720988) ploidy: diploid cell (Q504520) |
| Source | biological literature |
| Proposed by | Emw (talk) 13:00, 16 April 2014 (UTC) |
This is basic information about genomes that makes sense to describe on Wikidata. Emw (talk) 13:00, 16 April 2014 (UTC)
- @Emw: Why not item-datatype? diploid cell (Q504520), triploidy (Q504558) (just English Wiki is about the syndrome. Others seem to be in general about triploide organisms), tetraploidy (Q453166), polyploidy (Q213410). Tobias1984 (talk) 13:17, 16 April 2014 (UTC)
- Tobias, good points. I've changed the datatype to item and adjusted other fields. I have also moved the sitelink for "triploid syndrome" to triploidy (Q16354820). Emw (talk) 01:22, 17 April 2014 (UTC)
- It's a ratio (1, 2, 3, 4 ...). I think datatype amount fits better. --Succu (talk) 21:47, 23 April 2014 (UTC)
- Support I think item is better than number for the datatype. --Jakob (talk) 18:27, 5 May 2014 (UTC)
- @Jakec: Why? --Succu (talk) 20:30, 7 May 2014 (UTC)
- @Succu: Because there are only a few ploidys that exist, and items can be made for them. There is no 2.54ploid or 167ploid, for instance. --Jakob (talk) 22:49, 7 May 2014 (UTC)
- OK: Support --Succu (talk) 19:19, 12 June 2014 (UTC)
- OK:
- @Succu: Because there are only a few ploidys that exist, and items can be made for them. There is no 2.54ploid or 167ploid, for instance. --Jakob (talk) 22:49, 7 May 2014 (UTC)
- @Jakec: Why? --Succu (talk) 20:30, 7 May 2014 (UTC)
- Support --LydiaPintscher (talk) 21:23, 10 May 2014 (UTC)
- @Emw, Tobias1984, Succu, LydiaPintscher: Done --Jakob (talk) 10:29, 13 June 2014 (UTC)
Cycling Archives Cyclist ID
| Description | Identifier in Cycling Archives website which lists competetive cyclists and their results |
|---|---|
| Data type | String |
| Domain | Persons |
| Allowed values | numbers |
| Example | Eddy Merckx (Q103756) => 5892 |
| Source | http://www.cyclingarchives.com/ website |
| Robot and gadget jobs | It could be possible to gather/validate additional data from website |
| Proposed by | Papuass (talk) |
- Discussion
Authority control for cyclists, similar to ATP/WTA ID for tennis players. Unfortunately UCI does not have cyclist profiles on website, but this website regullary appears in cycling bio articles external link section. en:Template:Cycling_archives uses this value as parameter. Papuass (talk) 14:03, 2 July 2014 (UTC)
- Support -- SERutherford (talk) 05:51, 6 July 2014 (UTC)
- Support --Micru (talk) 07:56, 7 July 2014 (UTC)
- @Papuass, SERutherford, Micru: Done --Jakob (talk) 17:44, 9 July 2014 (UTC)
language spoken
| Description | languages that a given person speaks |
|---|---|
| Data type | Item |
| Domain | people |
| Allowed values | languages |
| Example | Sabine Lisicki (Q76338) => German (Q188) |
| Source | external reference, Wikipedia |
| Proposed by | AmaryllisGardener talk |
- Discussion
Like native language (P103), but all languages that a person speaks. Could there possibly be a better label? --AmaryllisGardener talk 01:38, 3 July 2014 (UTC)
- Whether a person "speaks" a language isn't such a clear-cut concept, unfortunately...
- Would the contents of native language (P103) be duplicated with this property, or would they be omitted? --Yair rand (talk) 01:49, 3 July 2014 (UTC)
- @Yair rand: Hmm... I guess list a ref? About P103, could we change this one's label to "non-native language spoken", or possibly use a "language spoken" property using a qualifier to denote the native language? --AmaryllisGardener talk 01:57, 3 July 2014 (UTC)
- Support we need a property for this. Not sure about the ideal name for it, but I would probably have suggested the same one. --- Jura 03:39, 3 July 2014 (UTC)
- Support but not 100% sure. Couldn't native language (P103) be change to « languages » (not only native) and native/spoken be a qualifier ? Cdlt, VIGNERON (talk)
- Comment Anybody wish to state their opinions about the native language/languages spoken problem? --AmaryllisGardener talk 01:32, 11 July 2014 (UTC)
- @AmaryllisGardener: The problem with spoken languages other than the native one, is that they do not belong to the same category. Learned languages are learned skills, and as such they have a level of expertise, which can increase or decrease over time. I would not treat "spoken language" differently than any other skill. For that reason I think it would be better to aim for a "skill" property with perhaps "skill level" and "start/end date" qualifiers.--Micru (talk) 07:06, 11 July 2014 (UTC)
- @AmaryllisGardener, Yair rand, Jura1, VIGNERON, Micru: Done, let's give it a try. --Jakob (talk) 13:34, 11 July 2014 (UTC)
- Support, but practised language rather than spoken language would be better, especially for linguists who currently read many dead languages that nobody speaks any more...
- language is a "skill" for most people, like tennis players, but a "professional tool" for writers, linguists and translators... whose case should be treated with more options…
- also, a "direction" of language (if I may use this risky term), would be very useful for translators, who translate from English to French (for example), but not from French to English., or maybe a qualifier with "language" - "native language", "spoken", "written", "translated from", "translated to" ? --Hsarrazin (talk) 17:22, 11 July 2014 (UTC)
- Comment Here we go: Roger Federer (Q1426), since Sabine's article doesn't say that German is her native language for sure. --AmaryllisGardener talk 19:24, 11 July 2014 (UTC)
greatest
Not done
| Description | Füge die englische Beschreibung für die Eigenschaft hier ein, z. B. entsprechend der Dokumentation in der Infobox. (de) – (Please translate this into English.) |
|---|---|
| Data type | Item |
| Template parameter | Hier den Infobox-Parameter einfügen, falls es einen gibt. Beispiel: "Bevölkerung" (population) in en:template:infobox settlement |
| Domain | geographical feature (Q618123), buildings |
| Allowed values | geographical feature (Q618123), buildings |
| Example | Honshu (Q13989) greatest list of islands of Japan (Q1125331); https://www.wikidata.org/w/index.php?search=größte&title=Special%3ASearch&go=Seite |
| Format and edit filter validation | (Beispiel: eine siebenstellige Zahl kann mit dem Missbrauchsfilter 17 überprüft werden) |
| Source | Externe Referenzen, Listenartikel in der Wikipedia (entweder Infobox oder Quelle) |
| Robot and gadget jobs | Führen Bots oder Helferlein irgendwelche Tätigkeiten mit dieser Eigenschaft aus oder sollten sie solche Tätigkeiten ausführen? (etwa in dem sie andere Eigenschaften auf Konsistenz überprüfen, Daten sammeln etc.) |
| Proposed by | Oursana (talk) |
- Discussion
Motivation. Oursana (talk) 12:15, 8 June 2014 (UTC)
Not done Not enough support and it could be done with a query (once they are available). Notification: Oursana.--Micru (talk) 08:58, 1 July 2014 (UTC)
Number of seats in legislature
| Description | number of seats hold by political group or party in legislature body provided by qualifiers |
|---|---|
| Data type | Quantity |
| Template parameter | "loksabha_seats"/"Rajyasabha_seats"/"assembly_seats" in en:template:infobox indian political party |
| Domain | Unsorted |
| Example | Bharatiya Janata Party (Q10230) => 117 with qaulifier Legislature legislative body (P194): Lok Sabha (Q230003) |
| Format and edit filter validation | maximum 3 digit number can be validated with edit filter Special:AbuseFilter/17 |
| Source | example w:en:Lok sabha see infobox for list if political party and seats hold by them |
| Robot and gadget jobs | possibly yes |
| Proposed by | Nizil Shah (talk) |
- Discussion
Every legislature have seats/constituencies held by political groups so these will be helpful. This can also be used in items of legislatures without qualifiers to add total seats. --Nizil Shah (talk) 20:13, 9 February 2014 (UTC)
- Hm, this is a bit of a tricky issue. First of all, we couldn't use this to figure out the makeup of a legislature, as dealing with "duplicate" seats would be difficult. One seat could feasibly be held by multiple parties/groups, either because one party/group "includes" the other, or because two entities are considered the same by some, or because one parliamentarian is allied with more than one party simultaneously. Second: Using legislative body (P194) might not be work well as the qualifier. That property indicates the entity that is the legislative body for the subject. Using it to simply indicate which legislature is being referred to might not make sense in some languages. Third, this is technically all redundant to the data of the items for the individual members of a legislature. If there are whatever number of items with data indicating that they are a member of whatever legislature, and associated with whatever party, then the number for this is already filled out. I'm not sure whether that's much of an argument against this property, though. --Yair rand (talk) 21:11, 9 February 2014 (UTC)
- User:Filceolaire, sorry but I cant clearly understand why did you opposed this property. Here I am proposing this property to collect number of seats held by political party in specific legislature. The same property can be used in articles of Legislatures where we can add Total number of seats in that legislature. Please clarify as i am missing your point. Regards-Nizil Shah (talk) 20:24, 2 March 2014 (UTC)
- User:Nizil Shah sorry I didn't get back to you before. I've been thinking about this and I Support this property but only for use in elections and Legislatures as your comment above and User:Lavallen's comment below if it is renamed as 'number of seats'. I think that using this property on items for political parties would be clumsy. How many hundreds of local councils is the Bharatiya Janata Party (Q10230) represented on?.
- This should be supplemented by votes received (P1111) then we can do summary results for elections listing all the participant (P710) or candidate (P726) each with qualifiers saying how many votes they got and how many seats they won. With these properties we could reasonably aspire to record the results of every local council election, not just the national parliament. Filceolaire (talk) 16:25, 3 June 2014 (UTC)
- Its Ok if we use this property on "legislature items" instead of political party. But it can work both ways. We need to add "Total seats" and "number of seats held by political group" too. We should have two properties for them. So what do you think? -Nizil Shah (talk) 09:47, 5 June 2014 (UTC)
- User:Nizil Shah sorry I didn't get back to you before. I've been thinking about this and I
- User:Filceolaire, sorry but I cant clearly understand why did you opposed this property. Here I am proposing this property to collect number of seats held by political party in specific legislature. The same property can be used in articles of Legislatures where we can add Total number of seats in that legislature. Please clarify as i am missing your point. Regards-Nizil Shah (talk) 20:24, 2 March 2014 (UTC)
- Support I think this may work, nomatter if there are duplicates or not. And I think it could be used in reverse too, from the election-items:
- "Swedish Riksdag elections 2014": # of seats: 43, qualifier: Political party: "Whatever".
- "EU parlament election 2014 in Sweden": # of seats: 3, qualifier: Political party: "Whatever". Part of: "Parlament group Wearethewinners".
- -- Lavallen (talk) 18:19, 15 March 2014 (UTC)
affiliation
| Description | Organization a person (creator) was attached to |
|---|---|
| Data type | Item |
| Domain | persons, usually researchers. |
| Allowed values | organisations (including projects). |
| Example | Raoul Bott (Q441185) => Institute for Advanced Study (Q635642) |
| Proposed by | Gymel (talk) |
- Discussion
The deletion request for P1298 (P1298) as duplicate of work location (P937) leads attention to the current list Wikidata:Database reports/Constraint violations/P937: Roughly half of the items violate the "place" constraint of work location (P937) by noting an organisation instead of a municipality. These organizations might be an employer (P108) in the proper sense or some academy the person was member of (P463) but for scientists the kind of relation is often unknown - some time spent at institution X but we don't know wether the "home institution", the host institution, some third party or nobody did sponsor this - but on papers stemming from research done during that period it is customary for authors to name the institution as the institution they "belong to" - for mutual benefit. Gymel (talk) 22:18, 9 June 2014 (UTC)
- Support Danrok (talk) 11:17, 15 July 2014 (UTC)
- Support --Micru (talk) 11:24, 15 July 2014 (UTC)
- @Gymel, Danrok, Micru: Done --Jakob (talk) 12:59, 15 July 2014 (UTC)
pet
| Description | pets that a person owns |
|---|---|
| Data type | Item |
| Domain | people |
| Allowed values | individual named animals |
| Example | Barack Obama (Q76) => Bo (Q1273495) |
| Source | Wikipedia |
| Proposed by | AmaryllisGardener talk |
- Discussion
Useful info --AmaryllisGardener talk 00:36, 12 July 2014 (UTC)
- Should the target item be an individual named animal, or a type of animal, e.g. dog, cat, etc.? Or, would both types be allowed? Support the general idea. Also, useful in fiction. Danrok (talk) 12:16, 13 July 2014 (UTC)
- @Danrok: My intent was for individual named animals. --AmaryllisGardener talk 12:44, 13 July 2014 (UTC)
- OK, that will probably work best. Danrok (talk) 13:31, 13 July 2014 (UTC)
- @Danrok: My intent was for individual named animals. --AmaryllisGardener talk 12:44, 13 July 2014 (UTC)
- Support Danrok (talk) 11:15, 15 July 2014 (UTC)
- Support--Micru (talk) 11:25, 15 July 2014 (UTC)
- Support —Wylve (talk) 15:49, 19 July 2014 (UTC)
- @AmaryllisGardener, Danrok, Micru, Wylve: Done --Jakob (talk) 01:28, 21 July 2014 (UTC)
OpenPlaques identifier
| Description | Identifier in the OpenPlaques database |
|---|---|
| Data type | Number (not available yet) |
| Domain | Person |
| Allowed values | positive integers |
| Example | John Scarlett Davis (Q6256854) = 9800 (see http://openplaques.org/people/9800 ) |
| Source | http://openplaques.org/ |
| Robot and gadget jobs | We might get a data dump from OpenPlaques; otherwise extract via Template:Open Plaques (Q14397305). |
| Proposed by | Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits |
- Discussion
Provides images, locations and/ or transcriptions of one or more plaques commemorating the person specified. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:46, 14 July 2014 (UTC)
- Support Danrok (talk) 11:16, 15 July 2014 (UTC)
- Support--Micru (talk) 11:25, 15 July 2014 (UTC)
- @Pigsonthewing, Danrok, Micru: Done --Jakob (talk) 16:49, 21 July 2014 (UTC)
heritage status
| Description | type of historic monuments or historic district of the item |
|---|---|
| Data type | élément-invalid datatype (not in Module:i18n/datatype) |
| Template parameter | « classement » dans fr:Modèle:Infobox Monument |
| Domain | cultural property (Q2065736) |
| Allowed values | type of cultural property (Q2065736) |
| Example | Eiffel Tower (Q243) --> monument historique inscrit (Q10387575) |
| Format and edit filter validation | (exemple : 7 chiffres peuvent être validés avec le filtre d'édition Special:AbuseFilter/17) |
| Proposed by | Fralambert (talk) |
- Discussion
As discuted in Wikidata talk:WikiProject Cultural heritage#Irksome issues with p31. There is a problem to put the heritage protection types in instance of (P31). The main problem is the a bridge, a house or a churche is not a Rijksmonument (Q916333), a classified historical monument (Q10387684) or a national historic site of Canada (Q1568567). It was suggested to create a new property at the image of IUCN conservation status (P141) for animal protection. --Fralambert (talk) 22:35, 24 July 2014 (UTC)
- Support, perdiscussion, still not quite sure about the label though. --Zolo (talk) 15:51, 26 July 2014 (UTC)
- Support
Weak oppose- @Emw: Name changed for "heritage status". I am not sure about "protection status", since some heritage property, like National Register of Historic Places (Q3719) or national historic site of Canada (Q1568567) are not protected.--Fralambert (talk) 01:15, 27 July 2014 (UTC)
- Thanks, Fralambert. Emw (talk) 16:20, 2 August 2014 (UTC)
- @Emw: Name changed for "heritage status". I am not sure about "protection status", since some heritage property, like National Register of Historic Places (Q3719) or national historic site of Canada (Q1568567) are not protected.--Fralambert (talk) 01:15, 27 July 2014 (UTC)
- Support the new label. We will have to be careful when moving statements from instance of (P31) to this new property because lot of them have qualifiers which have to be moved too. — Ayack (talk) 08:44, 28 July 2014 (UTC)
- Support a distinct property is more reliable than P31. --- Jura 11:48, 1 August 2014 (UTC)
- @Fralambert, Zolo, Emw, Ayack, Jura1: Done --Jakob (talk) 16:46, 2 August 2014 (UTC)
Nachlass
Not done
| Description | Archive or organisation that helds the Nachlass (Q6957170) of a person. "Nachlass" means the collection of manuscripts, notes, correspondence, and so on left behind when a scholar dies. |
|---|---|
| Data type | Item |
| Domain | Person |
| Allowed values | Organization |
| Example | |
| Robot and gadget jobs | Kolja21 (talk) 01:05, 20 July 2014 (UTC) |
- Discussion
Needed for scholars, politicians and other famous person. --Kolja21 (talk) 01:05, 20 July 2014 (UTC)
- Oppose since already implemented as proposed in archives at (P485). -- Gymel (talk) 08:12, 20 July 2014 (UTC)
O.k. I'll add the info @P485. --Kolja21 (talk) 10:25, 20 July 2014 (UTC)
ID on Jewish Encyclopedia website
| Description | ID on Jewish Encyclopedia in Russian on the Web website, based on Shorter Jewish Encyclopedia (Q1967250) |
|---|---|
| Data type | String |
| Domain | any |
| Allowed values | \d+ |
| Example | Christopher Columbus (Q7322) → 12170 |
| Source | Template:ShJE Template (Q16787433); site itself |
| Robot and gadget jobs | Gadget URL: 12170 → http://www.eleven.co.il/article/12170 |
| Proposed by | Vlsergey (talk) |
- Discussion
Another encyclopedia website link. Vlsergey (talk) 15:00, 21 July 2014 (UTC)
- Support Jon Harald Søby (talk) 20:51, 24 July 2014 (UTC)
Done -- Bene* talk 18:24, 12 August 2014 (UTC)
Norsk filmografi ID
| Description | The ID from Norsk filmografi, published by the National Library of Norway. |
|---|---|
| Data type | String |
| Template parameter | N/A |
| Domain | film (Q11424) |
| Allowed values | string pattern [0-9]* |
| Example | Farewell, Illusions (Q11650353) => 204225 |
| Format and edit filter validation | up to seven digits |
| Source | Wikipedia, especially in Norwegian |
| Robot and gadget jobs | My bot could import IDs from the Norwegian (Bokmål) Wikipedia; URL gadget: Farewell, Illusions (Q11650353) → 204225 → http://www.nb.no/filmografi/show?id=204225 |
| Proposed by | Jon Harald Søby (talk) |
- Discussion
This would be a nice property to have for Norwegian films. The database is maintained by the National Library of Norway; its url is http://www.nb.no/filmografi/. Jon Harald Søby (talk) 13:23, 24 July 2014 (UTC)
- Support -- SERutherford (talk) 23:36, 27 July 2014 (UTC)
Done -- Bene* talk 18:24, 12 August 2014 (UTC)
taxon synonym
| Description | synonyms of the taxon name |
|---|---|
| Data type | String |
| Template parameter | Synonyms in en:template:taxobox |
| Domain | taxa |
| Allowed values | scientific names |
| Example | Poecilia reticulata (Q178202): Lebistes reticulatus, Acanthocephalus guppii, Acanthocephalus reticulatus, Girardinus guppii, Girardinus petersi, Girardinus poeciloides, Girardinus reticulatus, Haridichthys reticulatus, Heterandria guppyi, Lebistes poecilioides, Poecilia poeciloides, Poecilioides reticulatus |
| Robot and gadget jobs | no |
| Proposed by | Brya (talk) |
- Discussion
Motivation. There is a tendency for users to want to put in synonyms, and they tend to put them in taxon name (P225). This is unhandy: the property "taxon name" should contain the name of a taxon, and not something else which will just confuse the reader. Certainly, there are lots and lots of lists of synonyms available in both the literature and in databases, so there is a lot of material that could be put in here. Some synonyms are found in a great deal of the literature, so including them in Wikidata will help the reader in finding information. Values in this property should be sourced (that is, it is a synonym according to this particular reference). Brya (talk) 17:39, 4 April 2014 (UTC)
- Comment I do not see an additional value compared to adding it to P225 with reduced rank, see also discussion at Wikidata_talk:WikiProject_Taxonomy#new_properties.3F — Felix Reimann (talk) 11:33, 5 April 2014 (UTC)
- Support We indeed should keep synonyms somewhere. But I'd rather rename this property to taxonomic synonym (we don't need manta ray as synonym for manta birostris, and the singular for one synonym per record) -- Alexander Vasenin (talk) 14:20, 12 June 2014 (UTC)
- We could do that, but keep in mind that "taxonomic synonym" is a fixed expression (aka "heterotypic synonym") going with "nomenclatural synonym" (aka "homotypic synonym"). - Brya (talk) 18:33, 12 June 2014 (UTC)
- I'm not an expert in botanical taxonomy, so I leave it up to you. I just don't want common names filed as synonyms. BTW: why we don't have common name property? -- Alexander Vasenin (talk) 19:43, 12 June 2014 (UTC)
- We could do that, but keep in mind that "taxonomic synonym" is a fixed expression (aka "heterotypic synonym") going with "nomenclatural synonym" (aka "homotypic synonym"). - Brya (talk) 18:33, 12 June 2014 (UTC)
- Yes, we propably should have a property "common name", and a property "vernacular name" (otherwise these will be put in "common name"), but this will then need qualifiers to indicate language (in which the name is used) as well as references. Fairly complicated. - Brya (talk) 05:21, 14 June 2014 (UTC)
- @Succu: I see you did not put in a vote one way or the other? - Brya (talk) 11:58, 29 June 2014 (UTC)
- Brya, I think the datatype should be item. This allows us to store database ids and other information. --Succu (talk) 12:57, 29 June 2014 (UTC)
- The problem with that of course is that something like nine out of ten synonyms do not have an item and are not notable (see the example given). Ideally both item and string should be possible. - Brya (talk) 13:02, 29 June 2014 (UTC)
- Both types together are not possible. All taxa (=scientific name) are notable. Another reason for datatype item is: Z could be a synonym of X and Y, depending on the taxon authority. --Succu (talk) 14:09, 29 June 2014 (UTC)
- The problem with that of course is that something like nine out of ten synonyms do not have an item and are not notable (see the example given). Ideally both item and string should be possible. - Brya (talk) 13:02, 29 June 2014 (UTC)
- I don't know much about the technical side of properties, but it would be very handy if both types were possible. I don't really know if all currently accepted taxa should be notable (there are very many for which there is very little literature), but if this is done this will result in some three million items. This is still quite different from accepting everything that was ever given a scientific name as being notable, this would come to some thirty million (pretty much empty) items or so?
- Indeed there are many possible relationships (synonymy) between taxa, and indeed authorities / references are very important, but I don't see why this should be an argument for datatype item? - Brya (talk) 16:27, 29 June 2014 (UTC)
- Brya, I think the datatype should be item. This allows us to store database ids and other information. --Succu (talk) 12:57, 29 June 2014 (UTC)
- An item, including all properties, qualifieres and references, can be reused in different relationships. A string value has to be repeated manually (this could be errornous) and is limited to qualifieres and references. I see no problem with some more million taxa related items. --Succu (talk) 17:06, 29 June 2014 (UTC)
- I can imagine lots of problems with some more million taxa related items. The 1.8 million items we already have are hardly problem free, and it is quite possible that they will never be all right. Half of them don't even have "parent taxon" yet. It may be possible to import relatively problem free data by copying, say, the Index Fungorum, but a) why would one? and b) this probably is not allowed (and is not nice).
- Sure, an item, including all properties, qualifiers and references, can be reused in different relationships but that does not mean that it is worth investing the time and the server space into creating millions of (near empty) items. Not when a string will do the job just fine. - Brya (talk) 18:13, 29 June 2014 (UTC)
- I was refering to the amount of items. Thats not problematic. If someone is interested s/he can create these items and reflect a taxonomic viewpoint (with references). Importing them from other databases is not necessary. A string is simple, but seldom the best solution. Remember the botanic autor citation. Our current (item based) solution is much better. A lot of them are still missing of course. But I and my bot are working on this. ;) BTW the item solution will get my full support. --Succu (talk) 18:59, 29 June 2014 (UTC)
- The comparison with author citation is not all that close. For some purposes it can be very handy to have a link from authors to all the names he published, and vice versa. More importantly, there is no telling how succesful the present model of author citation is, as there is no working taxobox implementation. It may well be that for some designers of a taxobox implementation the chosen model is very troublesome and discouraging. And as you say, in many cases author citations are missing: this may well be due to how cumbersome the model is. For the users, it is just too much work and looks too weird.
- Making this an item would hinder many users who want to put in synonyms, but who do not want to create all these new items. Secondly it would change the nature and scope of the project. Now Wikidata is more or less limited to giving all the accepted taxa their own item (and failing at achieving any kind of minimum quality). With datatype item, Wikidata would be engaged in getting any name ever published its own item. It would become (lots) worse than CoL. - Brya (talk) 05:18, 30 June 2014 (UTC)
- I think its vice versa. A string property allows users the addition of synonyms without double thinking. That could become worse than CoL. Creating an item requires more steps (at least adding our three basic properties). And you can add different database id, reuse the item and so on. Its a more controlable procedure. BTW: There are only a handfull user interested in improving taxon item. So be patient. Its a hard job to become more reliable than CoL. --Succu (talk) 17:23, 2 July 2014 (UTC)
- Yes, that is true: a string would allow users to add a lot of synonyms. These synonyms already can be found in the Wikipedias, so they won't be making things worse, but rather consistent with the rest of the Wikimedia franchise. Compared to many of the items we already have, they are not worse. More importantly, synonyms represent 'information' that is more useful than much that is in Wikidata (like repeating the scientific name as a label in every language).
- From my point of view, nothing in Wikidata is anything like reliable unless these is a real taxonomic reference attached. It would be strange and counterproductive to have a higher standard for synonyms than in used in Wikidata for anything else. Synonyms can be made more useful by adding references. - Brya (talk) 05:44, 3 July 2014 (UTC)
OK let's try an example. According to Das große Kakteen-Lexikon (Q13520496) p.483 Oreocereus hempelianus (Q2029603) has the following synonyms:
- Echinopsis hempeliana (Q14967763) (basionym) ≡ Arequipa hempeliana ≡ Arequipiopsis hempeliana,
- Echinocactus rettigii (Q15009946) ≡ Arequipa rettigii (Q4068985) ≡ Arequipiopsis rettigii ≡ Borzicactus hempelianus var. rettigii ≡ Oreocereus rettigii,
- Arequipa weingartiana (Q4068984) ≡ Arequipiopsis weingartiana ≡ Borzicactus hempelianus var. weingartianus,
- Arequipa erectocylindrica (Q4068990) ≡ Oreocereus erectocylindricus ≡ Arequipa rettigii var. erectocylindrica,
- Arequipa soehrensii,
- Arequipa spinosissima (Q4068988) ≡ Borzicactus hempelianus var. spinosissimus,
- Arequipa australis ≡ Oreocereus australis.
First taxon name (P225) is basionym (P566) for the following recombinations (≡). As you can see there are a lot of synonym items allready present. So why not make use of them? How would your string approach reflect, that Arequipiopsis weingartiana is based on Arequipa weingartiana (Q4068984)? What about author citation and publishing year? (P574). --Succu (talk) 18:10, 3 July 2014 (UTC)
- Some twenty synonyms, of which six have their own item? Yes, put them all in as a "synonym", preferably adding the reference. It is troublesome that the reference will have to be added twenty times, instead of just once, but I see no way around this. The ones that have their own item can keep on doing so. It is a pity that these cannot be linked, but it is an imperfect world. As it is a string an authorship citation can be added where this is desirable (or perhaps this can be added as a qualifier?). - Brya (talk) 05:56, 4 July 2014 (UTC)
- Look at it this way: at present you can't express all those sophisticated relationships that you would like to express, and if this proposed property is accepted this won't change (you are no worse off), but we will be able to include more information than now. - Brya (talk) 17:11, 4 July 2014 (UTC)
- It's an imperfect proposal, not „an imperfect world“. And please no more complaints. We need a solution, but you didn't answers my questions. Please make a proposal (based on my example) how you would model this. With an item approach we can reuse all our installed constraints. And so on... --Succu (talk) 20:29, 4 July 2014 (UTC)
- Some twenty synonyms, of which six have their own item? Yes, put them all in as a "synonym", preferably adding the reference. It is troublesome that the reference will have to be added twenty times, instead of just once, but I see no way around this. The ones that have their own item can keep on doing so. It is a pity that these cannot be linked, but it is an imperfect world. As it is a string an authorship citation can be added where this is desirable (or perhaps this can be added as a qualifier?). - Brya (talk) 05:56, 4 July 2014 (UTC)
- It is an imperfect world; it is not possible to create all the items you want, as the data just does not exist. Not to mention that of the data that does exist not everything is available online, and that not all data that is online may be copied freely, or that there is not the manpower to do the copying. Etc.
- Making best use of what is now present in Wikidata would depend on being able to make a link from a string field, Wikipedia's piping, for example [[Q15009946|''Echinocactus rettigii'']].
- Building the model you want would further require a property "derived combinations" or "names based on the same type", and we don't have this property (see below), so it is not possible for this reason as well. - Brya (talk) 05:27, 5 July 2014 (UTC)
- @Brya, Succu: name changed to "taxon synonym" and original combination (P1403) created. Any further concern?--Micru (talk) 09:34, 7 July 2014 (UTC)
- Oppose datatype string, but Support datatype item. --Succu (talk) 16:16, 7 July 2014 (UTC)
- @Brya, Succu: name changed to "taxon synonym" and original combination (P1403) created. Any further concern?--Micru (talk) 09:34, 7 July 2014 (UTC)
@Brya, Succu: Having an item to store a synonym seems too much. What do you think of having two properties? "taxon synonym" with datatype string for everyday use and "shared taxon synonym" with datatype item for synonyms that are shared with several taxons or already have an item. Would that work?--Micru (talk) 13:56, 16 July 2014 (UTC)
- Yes, two properties would be fine. In theory, Succu is right but we would need to hire a professional staff for it to be practical. I am just not sure what to call the second property. - Brya (talk) 18:13, 16 July 2014 (UTC)
- @Micru: a string property would act as a garbage collector. Put all in, in any format you like. Means you can put in a scientific name only, or add taxon authors with or without the publishing year, surround by parentheses or not... Beginning with genus rank, the taxonomic rank becomes ambiguous... --Succu (talk) 20:00, 16 July 2014 (UTC)
Done @Brya, Succu: Let's try with items, I'm thinking that it would be hard to reference individual claims contained by the synonym, plus they would be harder to assign to authors, etc. --Micru (talk) 08:46, 17 July 2014 (UTC)
- A "garbage collector"? That is stating it much too strongly. It would be filled with low-grade stuff, but this low-grade stuff is already in the Wikipedia's and, for that matter, in the items here. With every day of Lsjbot's activity we have more of these low-grade items. - Brya (talk) 16:37, 17 July 2014 (UTC)
original combination
| Description | for animals: the combination (binomen or trinomen) where the species-group name used in this taxon name was first published |
|---|---|
| Data type | Item |
| Domain | taxa |
| Allowed values | Q template or text |
| Example | lion (Q140) => Felis leo (Q15294488) |
| Robot and gadget jobs | no |
| Proposed by | Brya (talk) |
- Discussion
Motivation. This is somewhat comparable to basionym (P566), but for animals. Under the zoological Code (ICZN), "basionym" does not exist, but the mechanism itself does exist, although much more limited, only when moving a species or subspecies to a new genus (so not for changes of rank and not for genera and subdivisions of genera). This does not really need a reference beyond the place of original publication / autor citation. BTW: "original combination" is not an official term in the zoological Code. - Brya (talk) 17:39, 4 April 2014 (UTC)
- @Brya: You propose item-datatype, but your example looks like it should be a string? Tobias1984 (talk) 17:54, 4 April 2014 (UTC)
- No. This is analagous to basionym (P566). Theoretically both item and string would be possible, but both have consequences. I suppose this started with the discussion on author citation, where I would have preferred to keep it simple and put everything in a string. What we now have is a mechanism for author citation where the last part of the author citation is derived from the item itself, and the first part from the item of the basionym. This is more complicated than I would have liked, but it can be made to work).
- Basically both approaches (item and string) can be made to work, but not both at once. Using item will allow connectivity and relatively uncluttered items; it will deal better with complicated taxonomic situations than strings. Using string will keep everything in a single item, leading to cluttered items (very hard to fill in, given how bad the UI already is) and will poorly handle complicated taxonomic situations. If all taxa were of the kind of Stellaria media (L.) Vill. (1789) with nobody using the basionym Alsine media and with nobody having put it in a third genus, string would work pretty well. For more complicated cases, using string comes down to putting items within items (within items), recursively. There are really complicated cases out there, and Wikidata appears set on making lots of connections, so item appears the way to go.
- Illustrations:Catalog of fishes (try, say, Alosa) uses the put-everything-in-one-item, while The Plant List uses the every-name-its-own-item approach. What is proposed here is somewhat midway. - Brya (talk) 05:01, 5 April 2014 (UTC)
- Comment I would vote for either the one or the other model, not an unclear mixture between both. One possibility could also be to model the taxon (with different names according to the taxonomic viewpoint) and taxon names (one item=one name with author and year of description) as distinct items. — Felix Reimann (talk) 11:38, 5 April 2014 (UTC)
- In reality a lot of taxa are variable, so if you "model the taxon (with different names according to the taxonomic viewpoint)" you are just deceiving the reader. What happened to trying for a high-quality database? - Brya (talk) 16:14, 5 April 2014 (UTC)
- But maybe we should take you up on this and make this datatype "item", if you really want that. - Brya (talk) 17:47, 5 April 2014 (UTC)
- @FelixReimann: As far I understand this issue datatype item stand for voting. --Succu (talk) 20:07, 25 April 2014 (UTC) PS: @FelixReimann: I changed the proposed data type to item a while ago. Any further objections? --Succu (talk) 18:14, 5 May 2014 (UTC)
- Support Makes it possible to create an alternative author citation (see: ICZN Article 51). E.g. for Methiolopsis geniculata (Q10583096) both forms can generated: Methiolopsis geniculata (Stål, 1878) and Methiolopsis geniculata (Stål, 1878) Rehn, 1957. --Succu (talk) 09:04, 5 April 2014 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Succu (talk) 17:26, 2 July 2014 (UTC)
- Support -Tobias1984 (talk) 19:13, 2 July 2014 (UTC)
Done @Tobias1984, Succu, Brya:--Micru (talk) 09:28, 7 July 2014 (UTC)
WWF ecoregion
- ecoregion (WWF)
| Description | the ecoregion of the item |
|---|---|
| Data type | Item |
| Domain | Taxons |
| Allowed values | WWF ecoregion (Q6617741) |
| Example | Sooty Albatross (Q1265896) => Antipodes Subantarctic Islands tundra (Q401979) |
| Proposed by | John Vandenberg (talk) |
- ecoregion ID (WWF)
| Description | the identifier of this ecoregion as defined by the WWF |
|---|---|
| Data type | String |
| Domain | ecoregions |
| Allowed values | WWF ecoregion (Q6617741), see WWF datasets |
| Example | Madagascar lowland forests (Q3079260) => AT0117 |
| Proposed by | --Micru (talk) 09:09, 17 July 2014 (UTC) |
- Discussion
There was a small discussion at Wikidata:Project chat/Archive/2014/03#indigenous species and migration paths about indigenous status of taxa to complement endemic to (P183). While endemic to (P183) is useful as flexible claim ("location or habitat type where the taxon lives"), recording indigenous with as much flexibility will, at this stage, or can result in 'too much data' as there are a lot of data sources with varying levels of granularity. I expect we will need additional properties with greater granularity, but mapping species to defined ecoregions creates a consistent dataset as a baseline from which properties about macro-ecology can be built on top of, and more granular data can be built underneath by different domain and language experts (i.e. many properties about birds in Australian tundra will be different from those plants in the Italian woodlands, due to different authorities, catalogues, methodologies and extensiveness of research conducted). John Vandenberg (talk) 08:21, 15 April 2014 (UTC)
- see my comment above. — Felix Reimann (talk) 09:18, 15 April 2014 (UTC)
- Thanks FelixReimann for an interesting counter-proposition. In my opinion, I would prefer that endemic to (P183) is constrained so each item can only have one geographic region, being the most precise region that encompasses where the species is endemic to, which needs to be flexible. "endemic to Austria" would be a bit too flexible, but it is good data which should trigger a constraint violation and be improved by a domain expert. "endemic to <ecoregion>" feels like it is breaking the meaning of endemic, especially for species that are indigenous to many ecoregions. Your approach would work, and doesnt require an new property, so I am not opposed to it, but I would not prefer it over a clear/unambiguous mapping direct from species to ecoregion which is also easy to populate and needs little maintenance after the initial data load. OTOH, if we have "endemic to <ecoregion>" claims , there will be an endless stream of "endemic to <subnational region>" and "endemic to <geographical feature>" claims, either added or replacing the <ecoregion> mappings, making the dataset rather volatile. John Vandenberg (talk) 12:52, 15 April 2014 (UTC)
- @John What about restricting this to specifically "WWF ecoregion" (or similar)? Reason: While Antipodes Subantarctic Islands tundra (Q401979) as an island is a well-defined geographic entity, I fear the difference and ambiguity in the definitions of ecoregions/bioms on mainland. My gut feeling is that each author, for example Haggett and Whittaker, has it's own definition of bioms which do only fit coarsely together. What "Frog 1: ecoregion: temperate woodland" means would heavily depend on the definition of temperate woodland and would only bear information if you take the definition itself into account, too. — Felix Reimann (talk) 11:26, 17 April 2014 (UTC)
- @FelixReimann:, Restricting this to the WWF ecoregions works for me, and is roughly what I had in mind. John Vandenberg (talk) 11:29, 17 April 2014 (UTC)
- Then, you could also restrict allowed values for the proposed "ecoregion" and the domain for "WWF ecoregion code" to WWF ecoregion (Q6617741). Do you think you need the property "biome"? Still, I think adding
subclass of (P279)part of (P361) to the items tagged as instance of (P31)WWF ecoregion (Q6617741) should be sufficient. See for example Albany thickets (Q4709410) — Felix Reimann (talk) 11:45, 17 April 2014 (UTC)- Done and replied above. John Vandenberg (talk) 12:09, 17 April 2014 (UTC)
- Then, you could also restrict allowed values for the proposed "ecoregion" and the domain for "WWF ecoregion code" to WWF ecoregion (Q6617741). Do you think you need the property "biome"? Still, I think adding
- @FelixReimann:, Restricting this to the WWF ecoregions works for me, and is roughly what I had in mind. John Vandenberg (talk) 11:29, 17 April 2014 (UTC)
- @John What about restricting this to specifically "WWF ecoregion" (or similar)? Reason: While Antipodes Subantarctic Islands tundra (Q401979) as an island is a well-defined geographic entity, I fear the difference and ambiguity in the definitions of ecoregions/bioms on mainland. My gut feeling is that each author, for example Haggett and Whittaker, has it's own definition of bioms which do only fit coarsely together. What "Frog 1: ecoregion: temperate woodland" means would heavily depend on the definition of temperate woodland and would only bear information if you take the definition itself into account, too. — Felix Reimann (talk) 11:26, 17 April 2014 (UTC)
- Thanks FelixReimann for an interesting counter-proposition. In my opinion, I would prefer that endemic to (P183) is constrained so each item can only have one geographic region, being the most precise region that encompasses where the species is endemic to, which needs to be flexible. "endemic to Austria" would be a bit too flexible, but it is good data which should trigger a constraint violation and be improved by a domain expert. "endemic to <ecoregion>" feels like it is breaking the meaning of endemic, especially for species that are indigenous to many ecoregions. Your approach would work, and doesnt require an new property, so I am not opposed to it, but I would not prefer it over a clear/unambiguous mapping direct from species to ecoregion which is also easy to populate and needs little maintenance after the initial data load. OTOH, if we have "endemic to <ecoregion>" claims , there will be an endless stream of "endemic to <subnational region>" and "endemic to <geographical feature>" claims, either added or replacing the <ecoregion> mappings, making the dataset rather volatile. John Vandenberg (talk) 12:52, 15 April 2014 (UTC)
@FelixReimann:, are you happy with this proposal after this revision? Or do you want to explore expanding the scope of endemic to (P183) (and renaming it?) John Vandenberg (talk) 05:42, 8 May 2014 (UTC)
- I think it is ok now. Hopefully, we get enough sourced data to use this property... — Felix Reimann (talk) 08:30, 8 May 2014 (UTC)
@John Vandenberg, FelixReimann: I think this property should be split in two: "WWF ecoregion ID" (to link the ecoregion with its WWF identifier) and "species ecoregion (WWF)" (to link the species with the corresponding ecoregion). Are you ok with that?--Micru (talk) 09:15, 7 July 2014 (UTC)
@John Vandenberg, FelixReimann: Done --Micru (talk) 13:50, 17 July 2014 (UTC)
bugguide ID
Not done
| Description | identifier for an insect/arthropod taxon in BugGuide (Q4986057) ( http://bugguide.net/ ). Highly comprehensive database. |
|---|---|
| Data type | String |
| Domain | insects, some arthropods |
| Allowed values | numerical string |
| Example | Popillia (Q29605) --> 279 |
| Source | http://bugguide.net/ |
| Proposed by | --Jakob (talk) |
- Discussion
Jakob, as you omitted a motivation I have a question: is this ID used in any wiki? --Succu (talk) 20:24, 14 June 2014 (UTC)
- @Succu: I typically provide my motivation in the description, not down here in the discussion section. To answer your question, there is no template, but the site is linked to over 2500 times from enwiki, indicating potential use for one. --Jakob (talk) 21:05, 14 June 2014 (UTC)
- After reading BugGuide (Q4986057) I have to vote with Oppose. This site has no nomenclatural or taxonomic meaning. --Succu (talk) 21:20, 14 June 2014 (UTC)
- The site would seem to be useful mostly for looking at pictures, but these are not necessarily licensed. - Brya (talk) 05:32, 15 June 2014 (UTC)
- After reading BugGuide (Q4986057) I have to vote with
Not done Lack of support. Notification: @Jakec, Succu, Brya:.--Micru (talk) 09:03, 7 July 2014 (UTC)
GRIN-URL
| Description | ID in GRIN Taxonomy database |
|---|---|
| Data type | URL |
| Domain | plants of economic importance |
| Allowed values | number |
| Example | 42207 for Zea mays (http://www.ars-grin.gov/cgi-bin/npgs/html/taxon.pl?42207) |
| Proposed by | Brya (talk) |
- Discussion
The GRIN Taxonomy for Plants-database (of the USDA Germplasm Resources Information Network) is arguably the best kept database in the world, although limited to plants of economic importance. Like most such databases it is a Single-Point-of-View-database; it is connected with the World Economic Plants: A Standard Reference. - Brya (talk) 06:30, 14 June 2014 (UTC)
- Unfortunately the situation is similar to AlgaeBase URL (P1348), so datatype URL fits best:
- URL for family, subfamily, tribus and subtribus is
http://www.ars-grin.gov/cgi-bin/npgs/html/family.pl?$1(Rosaceae) - URL for genus, subgenus and section is
http://www.ars-grin.gov/cgi-bin/npgs/html/genus.pl?$1(Rhododendron) - URL for species and lower ranks is
http://www.ars-grin.gov/cgi-bin/npgs/html/taxon.pl?$1(Rhododendron acraium)- Taken from de:Vorlage:GRIN
- URL for family, subfamily, tribus and subtribus is
- But yes: Support --Succu (talk) 20:13, 14 June 2014 (UTC)
Done @Brya, Succu: notification.--Micru (talk) 08:50, 17 July 2014 (UTC)
ZipcodeZoo-URL
Not done
| Description | url to the ZipcodeZoo applied biogeography database (ZipcodeZoo (Q15078690)) |
|---|---|
| Data type | URL |
| Domain | taxonomy |
| Allowed values | url |
| Example | Sicilian Shrew (Q1763190) => http://zipcodezoo.com/Animals/C/Crocidura_sicula_sicula/ |
| Proposed by | --Micru (talk) 13:01, 16 July 2014 (UTC) |
- Discussion
- Field guide to plants and animals of the world. About 10000 uses in cawiki.--Micru (talk) 13:01, 16 July 2014 (UTC)
Oppose This site is full of errors and dubious names. I had to use this to source some Aloe taxa from ptwiki ([1]). --Succu (talk) 13:09, 16 July 2014 (UTC)
Oppose This is an easy one, ZipcodeZoo is an aggregator (collects stuff from wherever it can find it). No real content. - Brya (talk) 18:02, 16 July 2014 (UTC)
Not done As per comments.--Micru (talk) 09:15, 17 July 2014 (UTC)
Foundational Model of Anatomy
| Description | Foundational Model of Anatomy identifier. Unique identifier for human anatomical terminology. |
|---|---|
| Data type | String |
| Template parameter | "FMA" in en:Template:infobox bone, en:Template:infobox brain, en:Template:infobox muscle. |
| Domain | human body (Q23852) (human body) |
| Allowed values | Numbers |
| Example | en:Tibia tibia (Q178366) => 24476 |
| Format and edit filter validation | Numbers |
| Source | http://fme.biostr.washington.edu/FME/index.html (FM expoler) http://www.ontobee.org/browser/term.php?o=FMA&iri=http://www.w3.org/2002/07/owl%23Class&graph=http://purl.obolibrary.org/obo/merged/FMA (partial list) http://www.unifr.ch/ifaa/Public/EntryPage/TA98%20Tree/Alpha/All%20KWIC%20EN.htm (Terminologia Anatomica Online contains correspondence information with FMA ID) |
| Robot and gadget jobs | Is it possible to import data which already exist in English Wikipedia articles? |
| Proposed by | Was a bee (talk) 21:23, 21 May 2014 (UTC) |
- Discussion
Motivation. Was a bee (talk) 21:23, 21 May 2014 (UTC)
- Support-Sounds good--Petermahlzahn (talk) 22:37, 21 May 2014 (UTC)
Done Notification: @Petermahlzahn, Was a bee:.--Micru (talk) 09:00, 7 July 2014 (UTC)
- Thank you @Micru:! --Was a bee (talk) 21:53, 15 July 2014 (UTC)
World Glacier Inventory ID
| Description | ID in the World Glacier Inventory. |
|---|---|
| Data type | String |
| Template parameter | none |
| Domain | glacier (Q35666) |
| Allowed values | all values mentioned in source |
| Example | Aletsch Glacier (Q204658) => "CH4N01336026" |
| Format and edit filter validation | Format filter, unique value |
| Source | http://nsidc.org/data/docs/noaa/g01130_glacier_inventory/ |
| Robot and gadget jobs | Bot could probably search the spread sheets and match them with existing items |
| Proposed by | Tobias1984 (talk) |
- Discussion
Add identifiers to glaciers. Tobias1984 (talk) 16:09, 7 May 2014 (UTC)
Support --Succu (talk) 19:01, 11 June 2014 (UTC)
Done @Tobias1984, Succu:.--Micru (talk) 09:31, 7 July 2014 (UTC)
elevation
Not done
| Description | height above or below sea level in metres |
|---|---|
| Data type | string (ideally validated as a height in metres)-invalid datatype (not in Module:i18n/datatype) |
| Template parameter | "elevation_m" in en:template:infobox mountain |
| Domain | mountain (Q8502) or more generally geographic location (Q2221906) |
| Allowed values | positive or negative numbers (maybe integer?) |
| Example | Ben Nevis (Q104674) => 1344, Mont Blanc (Q583) => 4810 |
| Format and edit filter validation | ? |
| Source | external reference, Wikipedia list article (either infobox or source) |
| Robot and gadget jobs | Most mountains will have an elevation listed on Wikidata, either in first sentence or infobox. |
| Proposed by | Nhumfrey (talk) |
- Discussion
I am interested in adding the properties of British mountains to Wikidata. Often mountains with the same name are disambiguated by its height. Possible Aliases: altitude, height
- Nhumfrey (talk) 18:45, 8 August 2014 (UTC)
- @Nhumfrey: Thank you for proposing. You probably have missed this page with pending proposals: Wikidata:Property_proposal/Pending/2#Height_.2F_depth_over_terrain. We have to wait until the developers release the numeric datatype with dimension. The dimension or physical unit is important so we can make conversions into non-SI units or different SI-prefixes. Are any other properties missing to describe mountains? ---Tobias1984 (talk) 20:02, 8 August 2014 (UTC)
- @Tobias1984: Ah, yes, that makes sense. Sorry, I was struggling to navigate all the property proposal pages. Other mountain related properties:
- Prominence (example Ben Lomond is 819m)
- Parent peak (example Ben Lomond parent is Ben More)
- Munro identifier (example Ben Lomond is M184): http://www.smc.org.uk/munros/MunrosTable.php, http://www.openstreetmap.org/node/25697071
- --Nhumfrey (talk) 09:44, 9 August 2014 (UTC)
Not done Duplicates Wikidata:Property_proposal/Pending/2#Height_.2F_depth_over_terrain. -- LaddΩ chat ;) 23:49, 9 November 2014 (UTC)
infobox's main topic
| Description | primary topic of the subject template or infobox |
|---|---|
| Data type | Item |
| Domain | meta / all |
| Allowed values | all items |
| Example | Template:Taxonomy/Syngnathiformes (Q14464882) => Syngnathiformes (Q650692) |
| Format and edit filter validation | must be an instance of Wikimedia template (Q11266439) |
| Robot and gadget jobs | perhaps? |
| Proposed by | Micru (talk) |
- Discussion
Motivation. To avoid confusion with other "main topic" properties. See: Property_talk:P301#template_main_topic--Micru (talk) 14:59, 23 June 2014 (UTC)
- Support --- Jura 19:42, 24 June 2014 (UTC)
- Question: The phrasing of the label is similar to things that have a 1-to-1 relationship on Wikidata. I think this may require a many-to-1 relationship, though. Would this property allow multiple types of templates to point to the same topic item as long as they all have the same primary subject of the template? If so, then this is probably OK. But, if this is supposed to be a 1-template-per-subject relationship, we're going to have trouble. There are multiple kinds of topic templates: For example, English Wikipedia has a topic-specific template that goes at the top of an article or section: Category:Infobox templates (Q6154820); then two types of topic templates that usually go at the bottom of the article: Category:Navigational boxes (Q5607945) (almost always topic-specific) and Category:Succession templates (Q6804414) (which have topic-specific versions). Then there are the well-used Category:External link templates (Q5612193). Then there are templates that substitute specific names, like Category:Taxon authority templates (Q8832383). Other projects may have different ones: I don't know if the template styles that are important on English Wikipedia are the important ones on other projects. And that's not counting Category:Userboxes (Q8307767), which — at least on English Wikipedia — is mostly idiotic except for the very important Category:Language user templates (Q5824304) and a couple of other topics. --Closeapple (talk) 15:19, 1 July 2014 (UTC)
- Closeapple, This would be used as category's main topic (P301). If a property has more than one topic, it is possible to add an exception on the constraint check. If a template doesn't have a main topic, that is fine too.--Micru (talk) 15:28, 1 July 2014 (UTC)
- But unlike categories, multiple types of templates for a single subject are pretty frequent, particularly for broad topics like government offices, types of places, etc. All the topic templates other than in Category:Navigational boxes (Q5607945) would probably be exceptions. To be clear: I'm not opposing a multiple-to-1 relationship. I just think it needs to be treated that way, not as an exception: If we use
{{Constraint:Unique value}}on this, the exception list is going to be huge. (And if someone makes an inverse property to pair with this property, it should be made clear that{{Constraint:Single value}}is not appropriate for that property either.) --Closeapple (talk) 16:24, 1 July 2014 (UTC)- I understand, it would be hard to model all combinations. Let's focus on the easiest cases first and let's see how far we can get. Maybe we need more properties (like "template combines topics" or others).--Micru (talk) 16:50, 1 July 2014 (UTC)
- But unlike categories, multiple types of templates for a single subject are pretty frequent, particularly for broad topics like government offices, types of places, etc. All the topic templates other than in Category:Navigational boxes (Q5607945) would probably be exceptions. To be clear: I'm not opposing a multiple-to-1 relationship. I just think it needs to be treated that way, not as an exception: If we use
- Closeapple, This would be used as category's main topic (P301). If a property has more than one topic, it is possible to add an exception on the constraint check. If a template doesn't have a main topic, that is fine too.--Micru (talk) 15:28, 1 July 2014 (UTC)
- Question would not it be more convenient the other way around ? Such as ? I think a specific property is not absurd here. Eventually it seems also interesting to code a generic infobox template, which looks the class of the item in wikidata and find in the superclasses the relevant infoboxes template. TomT0m (talk) 19:25, 1 July 2014 (UTC)
- @TomT0m: that would be hard to accomplish since each language edition of wikipedia might have different templates for the same topic (class). For now the suggested "template's main topic" might work well with Wikipedia templates, but later on we should aim for a "Wikidata template" property to link a class with the (recommended) Wikidata template for the class: . When Wikidata becomes its own client (see: Bugzilla: 55570) then it will make sense to maintain a central version of the infobox here so each language Wikipedia can adapt it to their own needs.--Micru (talk) 18:38, 7 July 2014 (UTC)
- @Micru: I don't get your point. It does not seem different from article. We can have as many implementation of Infobox:Roads in any language version as we get different articles linked by the same item, even if they show different properties. This does not seem related to the use of a central infobox module to me. TomT0m (talk) 19:16, 7 July 2014 (UTC)
- @TomT0m: There is more than just one infobox for each topic. Some wikipedias have generic infoboxes, other have more infoboxes for the same topic. This happens specially with municipality infoboxes, where some wikipedias prefer a generic infobox and other ones have an infobox per region. Anyhow, you can suggest the inverse of this one and we could create both, it cannot hurt.--Micru (talk) 19:42, 7 July 2014 (UTC)
- It's not really a problem, basically a generic infobox at the higher level can be linked both way to the entity class. Both ways works. We can make the assumption that a generic infobox will be linked to a higher level class in the class tree, and more specific will be linked to classes more at the leafs of the tree. If we want to get a suitable infobox we go up the subclass tree and find the most specific infobox with a template matching in the language. It's does not seem to me like a problem of this property or its inverse. Let's not find wrong explanations and justification to our properties ;) TomT0m (talk) 21:34, 7 July 2014 (UTC)
- @TomT0m: Changed title and proposed below. Let's hope for many productive uses :)--Micru (talk) 08:31, 8 July 2014 (UTC)
- It's not really a problem, basically a generic infobox at the higher level can be linked both way to the entity class. Both ways works. We can make the assumption that a generic infobox will be linked to a higher level class in the class tree, and more specific will be linked to classes more at the leafs of the tree. If we want to get a suitable infobox we go up the subclass tree and find the most specific infobox with a template matching in the language. It's does not seem to me like a problem of this property or its inverse. Let's not find wrong explanations and justification to our properties ;) TomT0m (talk) 21:34, 7 July 2014 (UTC)
- @TomT0m: There is more than just one infobox for each topic. Some wikipedias have generic infoboxes, other have more infoboxes for the same topic. This happens specially with municipality infoboxes, where some wikipedias prefer a generic infobox and other ones have an infobox per region. Anyhow, you can suggest the inverse of this one and we could create both, it cannot hurt.--Micru (talk) 19:42, 7 July 2014 (UTC)
- @Micru: I don't get your point. It does not seem different from article. We can have as many implementation of Infobox:Roads in any language version as we get different articles linked by the same item, even if they show different properties. This does not seem related to the use of a central infobox module to me. TomT0m (talk) 19:16, 7 July 2014 (UTC)
- @TomT0m: that would be hard to accomplish since each language edition of wikipedia might have different templates for the same topic (class). For now the suggested "template's main topic" might work well with Wikipedia templates, but later on we should aim for a "Wikidata template" property to link a class with the (recommended) Wikidata template for the class: . When Wikidata becomes its own client (see: Bugzilla: 55570) then it will make sense to maintain a central version of the infobox here so each language Wikipedia can adapt it to their own needs.--Micru (talk) 18:38, 7 July 2014 (UTC)
Done @Jura1, TomT0m, Closeapple, Soulkeeper: done this and the inverse (see below).--Micru (talk) 13:30, 17 July 2014 (UTC)
topic's main infobox
| Description | primary infobox or template of this subject |
|---|---|
| Data type | Item |
| Domain | meta / all |
| Allowed values | all items |
| Example | Syngnathiformes (Q650692) => Template:Taxonomy/Syngnathiformes (Q14464882) |
| Format and edit filter validation | must be an instance of Wikimedia template (Q11266439) |
| Robot and gadget jobs | perhaps? |
| Proposed by | Micru (talk) |
- Discussion
Motivation. See above.--Micru (talk) 08:31, 8 July 2014 (UTC)
- Support. Reverse of property proposed just above this one. --- Jura 16:08, 9 July 2014 (UTC)
Done --Micru (talk) 13:30, 17 July 2014 (UTC)
shape
| Description | the shape an entity normally has |
|---|---|
| Data type | Item |
| Domain | meta / all |
| Allowed values | all items |
| Example | <pyramid (Q12516)> shape <pyramid (Q3358290)> // human eye (Q430024) => sphere (Q12507) |
| Proposed by | --Micru (talk) 14:57, 9 July 2014 (UTC) |
- Discussion
Basic property needed to generate descriptions.--Micru (talk) 14:57, 9 July 2014 (UTC)
- Support --- Jura 16:08, 9 July 2014 (UTC)
- Support, great idea! (It's surprising we don't have this already.) Emw (talk) 04:05, 10 July 2014 (UTC)
- Support--Zolo (talk) 08:59, 10 July 2014 (UTC)
- Human eyes aren't exactly spherical. How this property is supposed to be used seems unclear. --Yair rand (talk) 16:33, 10 July 2014 (UTC)
- @Yair rand: Nothing is the way it is supposed to be... they are all approximations. Maybe some day we can have a "3D model" property for more exact shapes, but til then I hope you find convenient enough statements like: <wing (Q161358)> shape <airfoil (Q4698744)> with qualifier applies to <cross section (Q845080)>.--Micru (talk) 07:43, 11 July 2014 (UTC)
- Support the general idea. Would this be for claiming both 2D and 3D shapes that make-up the object's form? A box could be said to be cube shaped (3D) and/or square shaped (2D) - that is constructed from squares to form a cube. Danrok (talk) 01:30, 15 July 2014 (UTC)
- Comment Could we add a constraint that the value should be an instance of geometric shape (Q815741) to make sure that the value has some well defined characteristics. I am wary that allowing "it is shaped like a duck" would make make the property harder to exploit. --Zolo (talk) 13:39, 15 July 2014 (UTC)
SFDb ID
| Description | ID in Svensk Filmdatabas (http://www.sfi.se/sv/svensk-filmdatabas/) |
|---|---|
| Data type | String |
| Template parameter | Not form infoboxes, but from "External links" section. We can import IDs using the SFDb template (for exemple, see here) (this template does exist on others Wikipedia too, see interwikis links) |
| Domain | actor (Q33999) or film (Q11424) or film production company (Q1762059), especially form Sweden. |
| Allowed values | whole numbers |
| Example | Sven Magnusson (Q6151694) => 59287 |
| Format and edit filter validation | 5 numbers |
| Source | Wikipedia, especially in Swedish |
| Robot and gadget jobs | Bots could import IDs form corresponding articles of the Swedish Wikipedia. |
| Proposed by | Mathieudu68 talk |
- Discussion
It would be nice to have this property, in order to complete items on Swedish actors and actresses. It looks like Internet Movie Database. Mathieudu68 talk 14:16, 4 July 2014 (UTC)
- Support --AmaryllisGardener talk 14:45, 4 July 2014 (UTC)
- Support -- SERutherford (talk) 05:52, 6 July 2014 (UTC)
- Support --Micru (talk) 07:56, 7 July 2014 (UTC)
- Comment it seems that films and people (and possibly the other 2 types) can have the same number. Thus several properties might be needed.--- Jura 17:03, 9 July 2014 (UTC)
- There are two possible solutions for this, either we save the whole URL http://www.sfi.se/sv/svensk-filmdatabas/Item/?type=PERSON&itemid=59287), or we save the type plus the identifier (PERSON/59287) like it is done with P1361 (P1361). What do you prefer Mathieudu68?--Micru (talk) 13:43, 10 July 2014 (UTC)
- I prefer the second solution, because it is simpler and less constraining than the first one. Mathieudu68 talk 18:59, 10 July 2014 (UTC)
- @Mathieudu68, AmaryllisGardener, SERutherford, Micru, Jura1: Done --Jakob (talk) 14:19, 11 July 2014 (UTC)
ODNB
| Description | Authority control data for Oxford Dictionary of National Biography |
|---|---|
| Data type | String |
| Domain | human (Q5) |
| Allowed values | numerical |
| Example | Charles William Miller (Q430712) => 95491 |
| Format and edit filter validation | not sure |
| Source | http://www.oxforddnb.com/public/index.html |
| Robot and gadget jobs | Mix'n'match |
| Proposed by | Magnus Manske (talk) |
- Discussion
ODNB is a UK-centric biography database with ~60K entries. Magnus Manske (talk) 22:18, 6 July 2014 (UTC)
- Support. Would be a significant help in work on historical biography, including areas such as colonial America and Canada, India, Ireland, Australasia etc. Charles Matthews (talk) 07:36, 7 July 2014 (UTC)
- Support --Micru (talk) 07:56, 7 July 2014 (UTC)
- Support (either this identifier or a similar one). However, would it be better to use the "Oxford Biography Identification Number", described here? It maps directly to ODNB IDs (in this case it would be
101095491), but there's apparently the intention to expand it to other resources such as the ANB. Andrew Gray (talk) 18:34, 7 July 2014 (UTC)
- Comment If it's really a superset with "computable" translation, it would be better. However, your example 101095491 doesn't seem to work. Or did I use the wrong URL? --Magnus Manske (talk) 09:15, 8 July 2014 (UTC)
- Very strange! Not sure why that is. Perhaps it's because it's in the most recent update and the OBIN is lagging? Andrew Gray (talk) 15:44, 8 July 2014 (UTC)
- Well, should we go ahead with the ODNB one until they get their act together? It should be trivial to bot-move it to OBIN once that happens. --Magnus Manske (talk) 13:28, 10 July 2014 (UTC)
- @Magnus Manske, Charles Matthews: - you've got mail :-) Andrew Gray (talk) 19:13, 12 July 2014 (UTC)
- Well, should we go ahead with the ODNB one until they get their act together? It should be trivial to bot-move it to OBIN once that happens. --Magnus Manske (talk) 13:28, 10 July 2014 (UTC)
- Very strange! Not sure why that is. Perhaps it's because it's in the most recent update and the OBIN is lagging? Andrew Gray (talk) 15:44, 8 July 2014 (UTC)
- @Magnus Manske, Charles Matthews, Micru, Andrew Gray: Done about an hour early. --Jakob (talk) 21:11, 13 July 2014 (UTC)
Encyclopædia Britannica online ID
| Description | ID of article in online version of Encyclopædia Britannica |
|---|---|
| Data type | String |
| Domain | any |
| Allowed values | \d+ |
| Example | Alfred Hitchcock (Q7374) → 267959 |
| Source | Template:Britannica (Q6727827), Encyclopædia Britannica site itself |
| Robot and gadget jobs | URL gadget: Alfred Hitchcock (Q7374) → 267959 → http://global.britannica.com/EBchecked/topic/267959/ |
| Proposed by | Vlsergey (talk) |
- Discussion
Another linking ID. Vlsergey (talk) 09:58, 10 July 2014 (UTC)
- Support--Micru (talk) 12:52, 10 July 2014 (UTC)
- Support --AmaryllisGardener talk 12:57, 10 July 2014 (UTC)
- Comment is there a list of IDs and article titles somewhere? I can easily link EB IDs and existing Wikipedia articles via links from the latter to the former, but a full EB list would be nice. --Magnus Manske (talk) 13:41, 10 July 2014 (UTC)
- Question: Do we have reason to think these numbers are actual authority control for EB? w:en:Wikipedia:Templates for discussion/Log/2010 June 13#Template:Britannica seems to imply that someone though the control number for George Orwell (Q3335) was 9057505, but then the number in the URL turned out to be 433643. Are they permanent internal IDs, or are they just some side-effect of Britannica's current site layout the last 4 years? --Closeapple (talk) 14:15, 10 July 2014 (UTC)
- @Closeapple: that is exactly why I labeled it "Encyclopædia Britannica online ID". Yes, it can be changed in future, but still so far having those data in Wikidata simplify bot works for quick update in case of site layout change. -- Vlsergey (talk) 14:38, 10 July 2014 (UTC)
- @Vlsergey, Closeapple: I sent EB an email asking them for that and if they could provide a list of identifiers. Let's see what they answer.--Micru (talk) 14:42, 10 July 2014 (UTC)
- @Micru: I suspect that they're probably still a little unhappy about one-to-one correlation with Wikipedia after that 2005 Nature review. (See en:Encyclopædia Britannica#Internet encyclopaedias.) But I guess it's worth a shot. --Closeapple (talk) 15:03, 10 July 2014 (UTC)
- @Vlsergey, Closeapple: I sent EB an email asking them for that and if they could provide a list of identifiers. Let's see what they answer.--Micru (talk) 14:42, 10 July 2014 (UTC)
- @Vlsergey: Makes sense. Thanks. --Closeapple (talk) 15:03, 10 July 2014 (UTC)
- @Closeapple: that is exactly why I labeled it "Encyclopædia Britannica online ID". Yes, it can be changed in future, but still so far having those data in Wikidata simplify bot works for quick update in case of site layout change. -- Vlsergey (talk) 14:38, 10 July 2014 (UTC)
Done I received no answer, but I see no problem creating this property. Notification: @Vlsergey, Closeapple, AmaryllisGardener:
Sandrart.net ID
| Description | identifier in the web-based edition of Joachim von Sandrart’s "Teutscher Academie der Edlen Bau, Bild- und Mahlerey-Künste" (1675–80) |
|---|---|
| Data type | String |
| Domain | Persons |
| Allowed values | numbers |
| Example | Alfonso V of Aragon (Q312304) => 1206 |
| Robot and gadget jobs | move the identifiers from "catalog code" |
| Proposed by | Micru (talk) |
- Discussion
The database has over 5000 people, it is being added to WD, but without its own property cannot link to the catalog. Micru (talk) 13:00, 10 July 2014 (UTC)
- Support --Magnus Manske (talk) 13:26, 10 July 2014 (UTC)
- Support Jane023 (talk) 21:19, 11 July 2014 (UTC)
Done @Magnus Manske, Jane023:.--Micru (talk) 13:12, 17 July 2014 (UTC)
Official name / Name / Nom /
| Description | the name of the item |
|---|---|
| Data type | Monolingual text |
| Template parameter | |
| Domain | all items |
| Example | <Rome> official name Roma; |
| Proposed by | Paperoastro (talk) 23:35, 29 March 2013 (UTC) |
- Before multilingual text will became available, it is useful to discuss if have only one general property for item names or more specific ones. --Paperoastro (talk) 23:35, 29 March 2013 (UTC)
- Support for people: <A. Einstein> surname Albert --★ → Airon 90 23:43, 29 March 2013 (UTC)
- Comment I: Why surname? Why not middle name? Or nickname? The name of an item is the title. It not clear what you want. --Kolja21 (talk) 02:01, 31 March 2013 (UTC)
- Comment II: Please see Wikidata:Property proposal/Person for "given name" and "surname". --Kolja21 (talk) 02:06, 31 March 2013 (UTC)
- Comment If it's just "name", then I don't see how it's different from the item label. However, if what you mean is "official name", then I'd support it. Currently, the label is supposed to have the most common/widely known name for something, which sometimes is and sometimes isn't the same as its official name (in cases where an official name exists). An "official name" property would remedy that inconsistency. Silver hr (talk) 03:23, 31 March 2013 (UTC)
The difference is that this property can be useful for infobox parameter name. If labels cannot be used in query or in {{#property}} calls in Wikipedias, this property can be used. Furthermore using qualifiers, can be used also for the "official name", as you suggested. --Paperoastro (talk) 21:36, 31 March 2013 (UTC)- Yes, I would intend to use this property for "official names": e.g. for cities (and towns) the name(s) in their language(s), Latin name for animals and plants, catalog names for astronomic objects... and so on. A lot of infoboxes have more than one kind of name parameters and one of them is for the "official names". --Paperoastro (talk) 14:22, 4 April 2013 (UTC)
- Support. This will also be useful for places which change their Official name over time or have multiple official names in different languages. Most wikipedias cover the place on one page so there is one wikidata page for the different names. Each name can have a statement with suitable qualifiers - start date/finish date; language=foo, language=bar etc. Note this must not be multilingual text. If there are official names in different languages then each should have it's own statement with a monolingual string spelling out that official name. Multi lingual text will encourage people to start translating the official names which will give something that isn't official. Name changes over time can be subtle. Q745989 seems to have been in turn Borough of Kingstown/Borough of Dun Laoghaire/Corporation of Dun Laoghaire/Dun Laoghaire Rathdown County as it grew and extended over the last 150 years (but I'm still trying to find sources for some of those and their dates). Filceolaire (talk) 20:13, 4 April 2013 (UTC)
- Infobox parameter and datatype changed. Filceolaire (talk) 11:43, 5 April 2013 (UTC)
- Support as "official name". Silver hr (talk) 23:18, 12 April 2013 (UTC)
- Oppose There are already some properties covering that proposal: for animals property:P225, for works property:p357,... Snipre (talk) 15:47, 18 April 2013 (UTC)
- Wouldn't it be better to have a single general "official name" property rather than multiple domain-specific ones? Silver hr (talk) 00:29, 19 April 2013 (UTC)
- Good question! For me there is no differences between the two solutions, but it would be better to discuss them. --Paperoastro (talk) 12:47, 19 April 2013 (UTC)
- Wouldn't it be better to have a single general "official name" property rather than multiple domain-specific ones? Silver hr (talk) 00:29, 19 April 2013 (UTC)
- Oppose – It is too vague, have too many meanings. Living organism already have a property for taxon names. I fail to see why a catalogue code for galaxy should be offical. Only one example is left (Rome), and I think that should discussed in Wikidata:Property proposal/Place. -- Byrial (talk) 19:08, 20 April 2013 (UTC)
- As I see it, the meaning of this property would be to state the name of something whenever that something can be officially named by a sovereign body that has sole authority over the naming. That includes administrative regions of all kinds, institutions, legal entities, various political offices, awards, etc. Silver hr (talk) 12:40, 25 April 2013 (UTC)
- That sounds reasonable, and I guess I would support if the description was updated to this. Properties have to have clear definitions for their use, and I opposed because the proposal didn't define what was meant by official. Byrial (talk) 12:54, 25 April 2013 (UTC)
- As I see it, the meaning of this property would be to state the name of something whenever that something can be officially named by a sovereign body that has sole authority over the naming. That includes administrative regions of all kinds, institutions, legal entities, various political offices, awards, etc. Silver hr (talk) 12:40, 25 April 2013 (UTC)
- Comment if it is better for you to create more specific properties to manage official names, I will close this proposal, then I will open one proposal (or move this) for geographical names and one for "catalogue code" of astronomic objects (good name). --Paperoastro (talk) 16:03, 21 April 2013 (UTC) P.S. @Byrial: you are right, but only the brightest and most important deep-sky objects have official names. Most of them have only a catalogue code.
- Support as "official name". Also useful for sports events that sell their name to sponsors; e.g. en:Indian Wells Masters, officially the "BNP Paribas Open".--Kompakt (talk) 08:54, 29 April 2013 (UTC)
- Comment I think we need something like this for places who has changed name, like Oslo/Kristiania, Halden/Fredrikshald, to be used with a qualifier. But such a property has to use a multilanguage string-datatype, I guess. -- Lavallen (block) 09:21, 29 April 2013 (UTC)
- No. Instead we should have separate claims for each official name, in different languages with qualifiers to identify the years that name applied and the language corrresponding to that name. Having multilingual "Official name"s would just invite people to enter official names in multiple languages where no official name was established. Filceolaire (talk) 09:56, 8 May 2013 (UTC)
- Í think you are correct. The official name does not change for all languages at the same time. Another problem can be that we today spell old official names in a way they didn't when the name was official. My example is Kristiania, who I belive wasn't spelled like that at the time it had that name, but it is how we spell it today. -- Lavallen (block) 10:19, 8 May 2013 (UTC)
- No. Instead we should have separate claims for each official name, in different languages with qualifiers to identify the years that name applied and the language corrresponding to that name. Having multilingual "Official name"s would just invite people to enter official names in multiple languages where no official name was established. Filceolaire (talk) 09:56, 8 May 2013 (UTC)
- Support for places and organisations as these can change names over time. I don't know if it is needed for other types of item though Taxa and astronomical features do seem to have a case. Filceolaire (talk) 09:56, 8 May 2013 (UTC)
- Comment I follow some of your suggestions: I remove from the examples astronomical features (I proposed a property and a qualifier property for catalogue names) and also Taxa (because there are already some properties for Taxa. Good idea, imho, use this property also for the official names of sports event. --Paperoastro (talk) 13:04, 8 May 2013 (UTC)
- Comment I see a favourable support for the creation of this property with the multilingual string datatype. If there is not opposition, I will archive this proposal in Wikidata:Property proposal/Pending. --Paperoastro (talk) 22:21, 27 May 2013 (UTC)
- Support I suggest legal name as a possible label. See Legal name (business). Also, we should consider a property for trading name. These two names are formally registered, so can be correctly sourced along with start/end dates. For example HSBC (trading name) is HSBC Holdings P.L.C. (legal name). Danrok (talk) 15:16, 28 August 2013 (UTC)
- use 'instance of' 'trading name' or 'legal name' as a qualifier to show which type of official name this name is. Filceolaire (talk) 02:28, 29 August 2013 (UTC)
Moved from Multilingual to monolingual text datatype. Filceolaire (talk) 18:57, 18 July 2013 (UTC)
- @Paperoastro, Airon90, Kolja21, Silver hr, Filceolaire: @Snipre, Byrial, Innocent bystander, Danrok: Done --Jakob (talk) 22:05, 19 August 2014 (UTC)
Nickname
| Description | The club's most common nickname. |
|---|---|
| Data type | Monolingual text |
| Template parameter | en:template:Infobox football club nickname |
| Domain | organization (football clubs) |
| Source | External reference, Wikipedia list article |
| Robot and gadget jobs | they should be allowed |
| Proposed by | Xaris333 (talk) 17:33, 5 May 2013 (UTC) |
- Support This should be a generic name-related property, applicable to any organization, person, place, or other item with a colloquial name in common usage. Joshbaumgartner (talk) 03:46, 10 May 2013 (UTC)
- Support - Definitely. We need a nickname property for all the college and high school sports teams! TCN7JM 00:30, 28 May 2013 (UTC)
- Support Danrok (talk) 01:09, 17 June 2013 (UTC)
- @Xaris333, Joshbaumgartner, TCN7JM, Danrok: Done --Jakob (talk) 22:08, 19 August 2014 (UTC)
Sandbox-Monolingual texts (en)
| Description | A sandbox type per available data type |
|---|---|
| Data type | Monolingual text |
| Domain | any |
| Proposed by | GZWDer (talk) 09:37, 6 June 2013 (UTC) |
- Discussion
- @GZWDer: Done --Jakob (talk) 22:10, 19 August 2014 (UTC)
Motto / Wahlspruch / Devise
| Description | motto (short motivation sentence) |
|---|---|
| Data type | Multilingual text (not available yet) |
| Template parameter | en:template:infobox settlement motto |
| Domain | place, organization |
| Allowed values | any text |
| Example | Concordia Salus for Montreal |
| Robot and gadget jobs | None |
| Proposed by | Laddo (talk) |
Valuable info, I believe. Could be imported from existing infoboxes Laddo (talk) 05:34, 7 April 2013 (UTC)
- Support --Nightwish62 (talk) 09:16, 21 April 2013 (UTC)
- Valuable, true, but tricky. Concordia Salus is neither French or English, but I guess it is has an official en- and/or fr-translation. That would be even more valuable than a Swedish translation of Concordia Salus in the Swedish infobox. -- Lavallen (block) 11:08, 21 April 2013 (UTC)
- Comment Maybe it should be "monolingual text" with the language identified if possible (e.g. Latin). -- Docu at 14:45, 21 April 2013 (UTC)
- Support Emw (talk) 20:41, 5 May 2013 (UTC)
- Support Useful for events as well (Olympic Games, etc.)-.Kompakt (talk) 13:31, 22 May 2013 (UTC)
- Support Danrok (talk) 00:18, 11 June 2013 (UTC)
- Comment Could the original language be identified? --Ricordisamoa 02:24, 17 June 2013 (UTC)
- This may fail the CC0 nature of the database. --Izno (talk) 21:42, 22 July 2013 (UTC)
- In some cases, yes. Those cases have to be solved locally where fair use or equal can be used. -- Lavallentalk(block) 12:47, 17 August 2013 (UTC)
- OpposeShould be monolingual text. If there are official versions of the motto in multiple languages then list each of these with the motto property. Multilingual text is an invitation to our users to provide their own translations into 270 different languages. If you want to do that then create a "translation" property with multilingual datatype and use it as a qualifier to Motto. Filceolaire (talk) 12:43, 17 August 2013 (UTC)
- Agree. Support for a monolingual version. -- Docu at 20:36, 24 August 2013 (UTC)
- Agree.
- @Laddo, Nightwish62, Innocent bystander, Emw, Kompakt: @Danrok, Ricordisamoa, Izno, Filceolaire, Docu: Done --Jakob (talk) 22:16, 19 August 2014 (UTC)
Absolute magnitude / Absolute Helligkeit / Magnitude absolue
| Description | the absolute magnitude of an astronomic object. |
|---|---|
| Data type | Number (not available yet) |
| Template parameter | en:template:Infobox planet abs_magnitude |
| Domain | types of astronomical object (Q6999) |
| Allowed values | real number |
| Example | Sirius A (Q13415844) -> -1.09 |
| Source | astronomical database or professional article (e.g. SIMBAD (Q654724), NASA/IPAC Extragalactic Database (Q488563), Lyon-Meudon Extragalactic Database (Q6709611)) |
| Proposed by | --Paperoastro (talk) |
- Discussion
Astronomers, to indicate the intrinsic brightness, use also luminosity that is the intrinsic brightness expressed in solar unit. Is it useful another property? --Paperoastro (talk) 21:34, 7 February 2013 (UTC)
- Magnitudes are used almost exclusively in the optical and near-infrared passbands. MER-C (talk) 13:10, 8 February 2013 (UTC)
- Support πr2 (t • c) 16:37, 9 February 2013 (UTC)
- Support Nicolas M. Perrault (talk) 20:53, 24 March 2013 (UTC)
Color index
| Description | the color index of a star |
|---|---|
| Data type | Number (not available yet) |
| Template parameter | en:template:Starbox character u-b, b-v, v-r, r-i, j-h, j-k |
| Domain | stars |
| Allowed values | real numbers |
| Example | <Aldebaran> color index <1.90 (U-B)>, <1.54 (B-V)> |
| Source | the color index can be found in scientific literature, but also in some astronomical databases (see for example SIMBAD) |
| Proposed by | Paperoastro (talk) |
Motivation. Important physical parameter used by astronomers to characterize stars. Some Wikipedias report color index in their infoboxes. The number is dimensionless, but this property needs qualifiers to distinguish the different passband filters used. -- Paperoastro (talk) 10:31, 18 April 2013 (UTC)
- Support Are the filters (U-B, ...) going to be properties or qualifiers? --Tobias1984 (talk) 10:43, 18 April 2013 (UTC)
- My idea is use qualifiers to distinguish the different filters. --Paperoastro (talk) 10:47, 18 April 2013 (UTC)
- Done @Tobias1984: --Paperoastro (talk) 20:09, 28 August 2014 (UTC)
Lost Art-ID
| Description | identifier in the Lost Art Internet Database |
|---|---|
| Data type | String |
| Domain | artificial physical object (Q15222213) |
| Allowed values | strings with pattern \d{6} |
| Example | Two Riders on the Beach (Q17271987)Lost Art-ID448972 |
| Format and edit filter validation | Special:AbuseFilter? |
| Source | http://www.lostart.de/Webs/EN/Datenbank/Index.html |
| Robot and gadget jobs | Auto URL by MediaWiki:Gadget-AuthorityControl.js: 'http://www.lostart.de/DE/Verlust/$1' if BASE_LANGUAGE is de, else 'http://www.lostart.de/EN/Verlust/$1', e.g. 448972 |
| Proposed by | Oursana (talk) |
- Discussion
Motivation. We need this property to show the important information, which art work is part of the lost art databaseOursana (talk) 09:14, 23 June 2014 (UTC)
- Support--Micru (talk) 06:52, 24 June 2014 (UTC)
- Support Thx for the proposal! --Marsupium (talk) 14:28, 19 July 2014 (UTC)
b-side
| Description | the song/track which is the b-side of this single |
|---|---|
| Data type | Item |
| Template parameter | "B-side" in en:template:Infobox single |
| Domain | creative work: single (Q134556) (usually vinyl singles) |
| Allowed values | instances of single (Q134556) and song (Q7366) |
| Example | Love Me Do (Q754877) => P.S. I Love You (Q1419151) |
| Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
| Source | Wikipedia infoboxes |
| Robot and gadget jobs | Can be done by bots. |
| Proposed by | Danrok (talk) 07:15, 30 June 2014 (UTC) |
- Discussion
- Support--Micru (talk) 11:25, 17 July 2014 (UTC)
- Support--Ash Crow (talk) 07:59, 24 July 2014 (UTC)
executive producer
| Description | the executive producer(s) of this film, TV production, etc. |
|---|---|
| Data type | Item |
| Template parameter | "executive_producer" in en:template:infobox television |
| Domain | work (Q386724) |
| Allowed values | instances of human (Q5) |
| Example | Person of Interest (Q564345) => J. J. Abrams (Q188137) |
| Format and edit filter validation | none? |
| Source | infoboxes |
| Robot and gadget jobs | bots can fill-in |
| Proposed by | Danrok (talk) 21:45, 14 July 2014 (UTC) |
- Discussion
- Support--Micru (talk) 11:25, 17 July 2014 (UTC)
- Support --- Jura 13:36, 19 July 2014 (UTC)
- Support --AmaryllisGardener talk 16:05, 21 July 2014 (UTC)
- @Danrok, Micru, Jura1, AmaryllisGardener: Done --Jakob (talk) 00:20, 22 July 2014 (UTC)
published in
| Description | collective work(s), book(s) or periodical(s) where the work was published |
|---|---|
| Data type | Item |
| Domain | published works (article (Q191067), poems, etc.) |
| Allowed values | item subclass of publication (Q732577) and/or work (Q386724) |
| Example | L’Aérostation pendant le siège de Paris (Q15715588): "published in" Revue des Deux Mondes (Q1569226) |
| Source | référence externe, article de liste de Wikipédia (soit infobox, soit source) |
| Proposed by | VIGNERON (talk) |
- Discussion
The name is not obvious; please provide a description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 19 July 2014 (UTC)
- Hi Pigsonthewing. I'm not sure how to describe it : « Property for works published in others works » ? Cdlt, VIGNERON (talk) 15:35, 19 July 2014 (UTC)
- Isn't this a duplicate of place of publication (P291)? —Wylve (talk) 15:47, 19 July 2014 (UTC)
- No I think it's a property about a chapter in a book (usefull for collective book), or a article of a newpapers ou magazines. place of publication (P291) is more about the place where the book was publicated. --Fralambert (talk) 15:54, 19 July 2014 (UTC)
- Not trying to sound like a fervent opposition to the new property, but what about using part of (P361)? —Wylve (talk) 16:07, 19 July 2014 (UTC)
- Wylve : place of publication (P291) is for work published in places not for work puslished in works. It’s more like part of (P361) but much more precise, a bit like a subclass of P361 (it’s a shame there is no subclass for properties). If this property is rejected we could use P361 but could we have constraint violations reports? and in the other way round, will there be no report on P361 constraint violations? Cdlt, VIGNERON (talk) 16:26, 19 July 2014 (UTC)
- Not trying to sound like a fervent opposition to the new property, but what about using part of (P361)? —Wylve (talk) 16:07, 19 July 2014 (UTC)
- No I think it's a property about a chapter in a book (usefull for collective book), or a article of a newpapers ou magazines. place of publication (P291) is more about the place where the book was publicated. --Fralambert (talk) 15:54, 19 July 2014 (UTC)
- Isn't this a duplicate of place of publication (P291)? —Wylve (talk) 15:47, 19 July 2014 (UTC)
- Support after the explication. --Fralambert (talk) 18:21, 19 July 2014 (UTC)
- The difference is that this is much more precise. Like located in the administrative territorial entity (P131) or located in/on physical feature (P706) are more precise than part of (P361) even if it's sill the same meaning in the big picture.
- No I can't add a constraint violations on P131 because this property is too big and too general. If I add a « {{Constraint:Type|class=Q732577|relation=instance}} » or « {{Constraint:Item|property=P50}} » on P131 it won't work/fit because part of (P361) is not limited to works.
- I the other way round, on P361 there is already a constraint violation : Inverse with P527. But it's not unusual for a journal to have 100 articles (for some scientific journal or long-living journal it could be 1,000 or 10,000 !). I'm not sure if this constraint is adapted for published work.
- As I said we can use P131 but it's doesn't seems quite right ; plus, for qualifiers « published in / page(s) (P304) : 56 » seems more logical than « part of (P361) / page(s) (P304) : 56 ».
- Cdlt, VIGNERON (talk) 09:13, 20 July 2014 (UTC)
- Support Thanks for the clarification. --Kolja21 (talk) 10:03, 20 July 2014 (UTC)
- Support Removed "name of" from the description, because we are not storing a name, but linking with an item.--Micru (talk) 10:50, 20 July 2014 (UTC)
- Support I searched this property a few hours ago and was very surprised to see it didn't exist. --Harmonia Amanda (talk) 22:38, 22 July 2014 (UTC)
- Comment. Due to the lack of a sample in the above proposal (as of writing), it's not really clear how this would be used. I'm afraid we end up with academics listing journals in which articles they wrote may have appeared. --- Jura 19:54, 23 July 2014 (UTC)
- It’s not only for articles published in journals, it’s for every works. In could be a poem published in an anthology (or a journal), it could be a chapter or an essay published in a book, etc. What is wrong with « academics listing journals in which articles they wrote may have appeared » ? If the items are acceptables, isn’t linking them a good thing ?
- In the other way, how could you describ the link between an article and its journal without with property ? part of (P361) doesn't fit well, eg. what about articles part of a serie (here P361 could be use) and published in one or multiple journal ? (here P361 would be confusing).
- I'll give a practical example : right now with have the Revue des Deux Mondes (Q1569226) (a journal published since 1829) and about 10000 items of articles (and poetry and novels etc.) in this journal. Only 3 articles are link to the journal (and with part of (P361) :( ).
- Cdlt, VIGNERON (talk) 06:34, 24 July 2014 (UTC)
- I think Jura1 fears that the academics (the person) would list all the journals where she/he had been published. But we can precise the property is just for works published in others works, and not people. --Harmonia Amanda (talk) 12:17, 24 July 2014 (UTC)
- Support. Somehow I missed that the domain already limits it to "published works". As such it's a standard element needed for bibliographies. For easier reading, I edited the proposal above, changing "item" to "work" in the description and adding samples mentioned by Vigneron. --- Jura 12:30, 24 July 2014 (UTC)
- Support it will be useful to me. -Ash Crow (talk) 17:00, 24 July 2014 (UTC)
- Support. —Wylve (talk) 15:03, 25 July 2014 (UTC)
- @VIGNERON, Pigsonthewing, Wylve, Fralambert, Kolja21: @Micru, Harmonia Amanda, Jura1, Ash Crow: Done --Jakob (talk) 16:29, 26 July 2014 (UTC)
describes the fictional universe
| Description | To link a work with the fictional universe it describes |
|---|---|
| Data type | Item |
| Domain | work (Q386724) |
| Allowed values | instance of fictional universe (Q559618) |
| Example | Firefly (Q11622) => Serenityverse (Q17376102) |
| Robot and gadget jobs | Bots could check consistency with the reverse property proposal I'll made just after. |
| Proposed by | Ash Crow (talk) |
- Discussion
Per Wikidata_talk:WikiProject_Fictional_universes#What_property_to_set_the_fictional_universe_for_a_work.3F, as from narrative universe (P1080) can only be used for a fictional element. Ash Crow (talk) 22:44, 23 July 2014 (UTC)
- Support per the discussion. --Harmonia Amanda (talk) 22:51, 23 July 2014 (UTC)
- Support --MaEr (talk) 16:39, 28 July 2014 (UTC)
- Aye. --Dereckson (talk) 12:07, 2 August 2014 (UTC)
- @Ash Crow, Harmonia Amanda, MaEr, Dereckson: Done --Jakob (talk) 12:46, 2 August 2014 (UTC)
character (or character role name)
Not done
| Description | qualifier for cast member (P161) or voice actor (P725) to specify the role played by an actor/actress in a film/play. Compare with character role (P453): Property talk:P453 |
|---|---|
| Data type | String |
| Domain | films, plays |
| Allowed values | name or description of role |
| Example | Sample from Property talk:P453 for comparison:
|
- Discussion
Property:P453 requires creating items for each role. Most of the time, this is too much work. --- Jura 20:11, 21 July 2014 (UTC)
- I am not certain how this differs from P453. --Jakob (talk) 00:25, 22 July 2014 (UTC)
- Except for the datatype, it's quite similar. --- Jura 02:32, 22 July 2014 (UTC)
Oppose. We should use character role (P453) and create new items for characters if necessary. I don't like the idea of having multiple properties representing the same relationship but having different datatypes. We also should not be scared to create too many items, as they satisfy WD:N and fill in holes in the data. —Wylve (talk) 10:51, 25 July 2014 (UTC)
- Is there an item we could look at where you demonstrate what you are writing? --- Jura 11:22, 25 July 2014 (UTC)
- I think what Wylve says is that we shouldn't have a new property but juste use character role (P453). In your exemple it would means creating the entry "Joseph Stangerson". I don't understand why we couldn't just create items for each role. Aye, it's a lot of work, but what will we do if someone else create "Joseph Stangerson" after you have used character as property? Replace all character "Joseph Stangerson" by character role (P453) "Joseph Stangerson"? That would be mean a lot more work. If you don't want to create items (which is really easy and fast, btw), you can just use cast member (P161) without the qualifier, someone else will complete… --Harmonia Amanda (talk) 14:16, 25 July 2014 (UTC)
- I understood what they meant, I was just curious to see their samples. --- Jura 14:19, 25 July 2014 (UTC)
- BTW, I don't think creating new items is easy or fast (unless creator does it). --- Jura 14:21, 25 July 2014 (UTC)
- Oddly neither of you seems to be creating any either. --- Jura 14:24, 25 July 2014 (UTC)
- Well I only created a little more than 120 items, so ok, I'm not very experimented in that, but creating one never cost me more than a few second once I verified it didn't already exist. And you'll need to do the verifications too to know if you use character or character role (P453) so I don't really see the time gain. Cleaning wrong links and approximate links when the real item exists cost me much more time actually… I just don't understand the need to duplicate an existing property only to avoid creating items. --Harmonia Amanda (talk) 14:40, 25 July 2014 (UTC)
- @Jura1: An example would be 12 Angry Men (Q2345). Items were created for each character specifically for this item. Another benefit of this approach is that it can be used for future iterations and versions of the same creative work, just like the 1997 television film 12 Angry Men (Q386042) based on the 1950s film. Both items point to the same characters, with different actors portraying them. Only using items instead of string or other datatypes would we be able to make a list for people who portrayed a certain character, or a list of films/TV show/radio show a character has appeared on. —Wylve (talk) 14:47, 25 July 2014 (UTC)
- I do understand that I have little experience with creating items and may therefore not realise the efforts it takes, but I don't agree that we should let technical limitations affect the quality and integrity of the database. —Wylve (talk) 15:00, 25 July 2014 (UTC)
- Well I only created a little more than 120 items, so ok, I'm not very experimented in that, but creating one never cost me more than a few second once I verified it didn't already exist. And you'll need to do the verifications too to know if you use character or character role (P453) so I don't really see the time gain. Cleaning wrong links and approximate links when the real item exists cost me much more time actually… I just don't understand the need to duplicate an existing property only to avoid creating items. --Harmonia Amanda (talk) 14:40, 25 July 2014 (UTC)
- Comment We have to try to work with the current technical possibilities of Wikidata.
- Of course, we could just wait till someone creates items for us, but I'm not sure that this is happening.
- character role (P453) has only about 500 uses, possibly limited to the lead role or roles in films with many sequels. The sample 12 Angry Men (Q2345) seems to have been made just when the property was created. Not much seems to have followed.
- A string property is much easier for users to start out with. Conversion into items could still be done at a later stage. --- Jura 15:34, 25 July 2014 (UTC)
- If the property is not widely used, then it is preferable to use it in more items than to create an easier alternative. Furthermore, Wikidata is still in development and we can always streamline the item creation process without making any early compromises. Creating strings then converting it (which is also out of Wikidata's current technical possibilities) into items will require more effort than creating the items directly. —Wylve (talk) 15:48, 25 July 2014 (UTC)
- Not really. Conversion could be automatic. --- Jura 05:26, 26 July 2014 (UTC)
- If the property is not widely used, then it is preferable to use it in more items than to create an easier alternative. Furthermore, Wikidata is still in development and we can always streamline the item creation process without making any early compromises. Creating strings then converting it (which is also out of Wikidata's current technical possibilities) into items will require more effort than creating the items directly. —Wylve (talk) 15:48, 25 July 2014 (UTC)
- I think what Wylve says is that we shouldn't have a new property but juste use character role (P453). In your exemple it would means creating the entry "Joseph Stangerson". I don't understand why we couldn't just create items for each role. Aye, it's a lot of work, but what will we do if someone else create "Joseph Stangerson" after you have used character as property? Replace all character "Joseph Stangerson" by character role (P453) "Joseph Stangerson"? That would be mean a lot more work. If you don't want to create items (which is really easy and fast, btw), you can just use cast member (P161) without the qualifier, someone else will complete… --Harmonia Amanda (talk) 14:16, 25 July 2014 (UTC)
- Comment At Q15624215, I tried to follow the suggestion to create an item for each role. Actually it did take less time than I thought: adding the cast had taken more time earlier. The downside is that the created items are limited to the bare minimum, just as the ones at 12 Angry Men (Q2345). Let's see where it leads. --- Jura 05:26, 26 July 2014 (UTC)
- The contents of the character items really depend on how much the creative work tells us. I noticed that you've done a pretty good job with Lucy (Q17374529). It's a good example for a fictional character and with some referencing, it can even be a showcase item. —Wylve (talk) 06:56, 26 July 2014 (UTC)
- Well, luckily there was the ID in the trailer ;)
- It is easier as it's the main character of the film. Anyways, after I created Q17374529, I wrote this proposal, figuring it's unlikely I could do the same for the 49 other characters.
- The ones I created today were items such Regent Hotel Concierge #2 (Q17417423) --- Jura 08:00, 26 July 2014 (UTC)
- The contents of the character items really depend on how much the creative work tells us. I noticed that you've done a pretty good job with Lucy (Q17374529). It's a good example for a fictional character and with some referencing, it can even be a showcase item. —Wylve (talk) 06:56, 26 July 2014 (UTC)
Not done Redundant to existing property.--Micru (talk) 12:03, 17 August 2014 (UTC)
fictional universe described in
| Description | to link a fictional universe with a work that describes it: <universe> "described in the work:" <work> |
|---|---|
| Data type | Item |
| Domain | fictional universe (Q559618) |
| Allowed values | instances of work (Q386724) |
| Example | Serenityverse (Q17376102) => Firefly (Q11622) |
| Robot and gadget jobs | Bots could check consistency with the reverse property proposal I made just before (describes the fictional universe) |
| Proposed by | Ash Crow (talk) |
- Discussion
Per Wikidata_talk:WikiProject_Fictional_universes#What_property_to_set_the_fictional_universe_for_a_work.3F, mirror property of my "describes the fictional universe" proposal. Ash Crow (talk) 22:48, 23 July 2014 (UTC)
- Support per the discussion. --Harmonia Amanda (talk) 22:51, 23 July 2014 (UTC)
- Comment I don't see a point in creating reverse properties in this case. It would make the relationship harder to maintain, especially it involves sourcing. Therefore, I would recommend creating only one of the two properties proposed here. —Wylve (talk) 10:48, 25 July 2014 (UTC)
- Hmm. I see what you mean. In this case, I would prefer the other one "describes the fictional universe" since this one could mean a quite long list. --Harmonia Amanda (talk) 11:42, 25 July 2014 (UTC)
- Same for me, if there is to be only one of the two properties created, I'd prefer the first one. -Ash Crow (talk) 18:02, 25 July 2014 (UTC)
- Hmm. I see what you mean. In this case, I would prefer the other one "describes the fictional universe" since this one could mean a quite long list. --Harmonia Amanda (talk) 11:42, 25 July 2014 (UTC)
- Support --MaEr (talk) 16:40, 28 July 2014 (UTC)
- @Ash Crow: The other property was created. Do you still need this one? If so, perhaps it would be better to call it "fictional universe described in work", so it doesn't get confused with from narrative universe (P1080) --Micru (talk) 10:40, 4 August 2014 (UTC)
@Ash Crow, Harmonia Amanda, Wylve, MaEr: Done--Micru (talk) 12:09, 17 August 2014 (UTC)
Thematic catalogue
Not done
| Description | index used to identify musical compositions |
|---|---|
| Data type | Monolingual text |
| Domain | composed musical work (Q207628) |
| Allowed values | Art der verlinkten Objekte (Q-Vorlage oder Text), eine Liste der möglichen Werte oder ein Wertebereich, Muster für Strings etc. |
| Example | Beispiel: Q275627 =>Thematic catalogue =>HWV 34; or for J.S. Bach BWW, Mozart KV .... |
| Format and edit filter validation | (Beispiel: eine siebenstellige Zahl kann mit dem Missbrauchsfilter 17 überprüft werden) |
| Source | Externe Referenzen, Listenartikel in der Wikipedia (entweder Infobox oder Quelle) |
| Robot and gadget jobs | Führen Bots oder Helferlein irgendwelche Tätigkeiten mit dieser Eigenschaft aus oder sollten sie solche Tätigkeiten ausführen? (etwa in dem sie andere Eigenschaften auf Konsistenz überprüfen, Daten sammeln etc.) |
| Proposed by | Oursana (talk) |
- Discussion
Motivation. composition are usually referenced by Thematic catalogue, so we urgently need this propertyOursana (talk) 09:24, 30 July 2014 (UTC)
- @Oursana: We already have the pair catalog code (P528)/catalog (P972). See example: Grande valse brillante in E-flat major (Q2918877).--Micru (talk) 09:41, 30 July 2014 (UTC)
- Thank you. This property should be in Wikidata:List of properties/Works. We keep it like this, I do not have to delete the proposal?--Oursana (talk) 10:24, 30 July 2014 (UTC)
- @Oursana: No need to delete, I just marked it as "not done", it will be archived in some days. Yes, the list of properties is a bit outdated (some are waiting for statements on properties to automate it), but please do add the properties there if you feel like.--Micru (talk) 10:56, 30 July 2014 (UTC)
- Thank you. This property should be in Wikidata:List of properties/Works. We keep it like this, I do not have to delete the proposal?--Oursana (talk) 10:24, 30 July 2014 (UTC)
collection size
| Description | amount of objects in a collection |
|---|---|
| Data type | Quantity |
| Template parameter | "collection_size "/"фонд" in Template:Infobox museum (Q6232685) |
| Domain | museum (Q33506), library (Q7075), archive (Q166118) |
| Allowed values | organization (Q43229) |
| Example | Maksim Bahdanovič Literary Museum, Minsk (Q12337378) => 16946 |
| Source | infobox |
| Proposed by | Чаховіч Уладзіслаў (talk) |
- Discussion
- Support--Micru (talk) 10:25, 4 August 2014 (UTC)
- Support --- Jura 10:12, 9 August 2014 (UTC)
- Support--Oursana (talk) 00:44, 11 August 2014 (UTC)
- @Чаховіч Уладзіслаў, Micru, Jura1, Oursana: Done --Jakob (talk) 15:55, 11 August 2014 (UTC)
present in work
| Description | mettre la description en anglais ici, par exemple la même que celle de la documentation de l'infobox |
|---|---|
| Data type | Item |
| Template parameter | indiquez ici les attributs d'infobox de Wikipédia correspondants, s'il en existe, par exemple : « population » dans fr:Modèle:Infobox Subdivision administrative |
| Domain | fictional item (fictional character (Q95074), fictional location (Q3895768), fictional object (Q15706911)…) |
| Allowed values | work (Q386724) |
| Example | Frodo Baggins (Q177329) => The Lord of the Rings (Q15228) |
| Format and edit filter validation | (exemple : 7 chiffres peuvent être validés avec le filtre d'édition Special:AbuseFilter/17) |
| Source | infoboxes |
| Robot and gadget jobs | Devrait-il y avoir ou existe-t-il des bots ou des gadgets qui effectueront des tâches avec cette propriété? Par exemple: vérifier les autres propriétés afin d'être cohérent, collecter des données, automatiser un lien externe, etc. |
| Proposed by | Harmonia Amanda (talk) |
- Discussion
We actually can generate list of characters from a fictional universe, but not from a precise work. We know all the dwarves from Tolkien's Middle-earth, but not which ones appears in The Hobbit… part of (P361) was sometimes used but many contributors deleted these. This property could be used to indicate in which episode of a TV series a character appeared, in which book, etc. It's equivalent to from narrative universe (P1080) but for out-universe information. Harmonia Amanda (talk) 12:19, 9 August 2014 (UTC)
- Support could help to describe the participation of a character in another universe (crossover) Otourly (talk) 17:08, 10 August 2014 (UTC)
- Support could also help for sagas that were written over many centuries such as the Knights of the Round stories, with varying character choice depending on the authors of the work. -Ash Crow (talk) 20:34, 10 August 2014 (UTC)
- @Harmonia Amanda, Otourly, Ash Crow: Done --Jakob (talk) 01:21, 17 August 2014 (UTC)
list of works
| Description | link to the article with the works of a person |
|---|---|
| Data type | Item |
| Domain | persons |
| Allowed values | instances of bibliography (Q1631107) |
| Example | Leo Tolstoy (Q7243) => Leo Tolstoy bibliography (Q860998) |
| Source | Wikipedia list article |
| Proposed by | Хоркхаймер (talk) |
- Discussion
Addition to or same case as discography (P358) and filmography (P1283). See Wikidata:Project chat#Bibliography. --Хоркхаймер (talk) 09:41, 4 August 2014 (UTC)
- Support Consistent with other existing properties.--Micru (talk) 10:27, 4 August 2014 (UTC)
- Support No brainer. TomT0m (talk) 12:18, 4 August 2014 (UTC)
- Now I'd rather support the alternative proposal of having one combined property for all lists of work. --YMS (talk) 10:29, 11 August 2014 (UTC)
- This kind of relation should be recovered by using a query and not by a property (query: give all books/movies/albums of this author/actor/singer) Snipre (talk) 15:17, 4 August 2014 (UTC)
- @Snipre: Irrelevant here. There is dedicated articles about the bibliography of some author in the wikis, this property is to link the associated item to the author item. TomT0m (talk) 15:36, 4 August 2014 (UTC)
- Support Necessary I believe - LaddΩ chat ;) 00:57, 5 August 2014 (UTC)
- Comment Wouldn't it make more sense to merge filmography (P1283) with discography (P358) and give the former a more generic name like "list of works"? I can't really see a reason why there should be separate properties for bibliographies, filmographies and discographies and there are many prolific members of other professions like painters and architects that have similar lists. These are basically just links to lists on Wikipedia so I don't see why it would be important to separate them. Väsk (talk) 17:56, 6 August 2014 (UTC)
- I like that idea. I can't really see why these should be separate, since they're basically the same thing. Cbrown1023 talk 18:23, 6 August 2014 (UTC)
- I've opened up a discussion about this on Property talk:P358. Pending the outcome of that discussion, I Oppose the creation of this property. Väsk (talk) 22:03, 6 August 2014 (UTC)
- Support --- Jura 10:10, 9 August 2014 (UTC)
- Oppose I'd rather see a property which unifies discography, filmography and bibliography. --Pasleim (talk) 22:28, 10 August 2014 (UTC)
- Support Since there is no alternative proposal so far. (We can merge later.) --Conchpotters (talk) 16:36, 16 August 2014 (UTC)
Done I asked here and it seems difficult to merge properties, so I have created a new one "list of works". You can import the items from the existing properties, and when they are empty we can proceed to delete them. Notification: @Хоркхаймер, TomT0m, YMS, Snipre, Väsk, Cbrown1023:@Laddo, Jura, Pasleim, Conchpotters:.--Micru (talk) 13:29, 22 August 2014 (UTC)
standards body
| Description | put English description for property here, e.g. same as in the infobox documentation |
|---|---|
| Data type | Item |
| Template parameter | "developer" in en:template:infobox file format |
| Domain | technical standard (Q317623) |
| Allowed values | any item that represents a standards body |
| Example | HTML (Q8811) => World Wide Web Consortium (Q37033), Extensible HyperText Markup Language (Q166074) => World Wide Web Consortium (Q37033), |
| Source | external reference or Wikipedia article |
| Proposed by | Tom Morris (talk) |
- Discussion
Technical standards are produced by standards bodies like W3C, IETF, OASIS, ISO, BSI, ECMA and so on. It'd be useful to link said technical standards to the standards body responsible for them. —Tom Morris (talk) 10:48, 27 August 2014 (UTC)
- Support -Ash Crow (talk) 14:28, 27 August 2014 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 2 September 2014 (UTC)
- @Tom Morris, Ash Crow, Pigsonthewing: Done --Jakob (talk) 11:35, 3 September 2014 (UTC)
Scale
Not done
| Description | Approximative diameter of the place. Necessary when displaying a map of the place, to determine the zoom level. |
|---|---|
| Data type | string (actually integer: number of meters)-invalid datatype (not in Module:i18n/datatype) |
| Domain | Places (even rivers need a proper zoom level when shown on a map) |
| Example | Q90(Paris):10000 Q64436(Arc de Triomphe):70 |
| Format and edit filter validation | number |
| Proposed by | Nicolas1981 (talk) 06:32, 5 September 2013 (UTC) |
- Discussion
Some Wikimedia projects show a map of each place, in particular the Wikivoyages (example, see the map in the infobox). The zoom level has to be specified manually, which is a pain to synchronize between all Wikimedia projects that use them. Wikidata is the obvious place to share this data. Maybe "diameter" is a better name than "scale". Scale can not be calculated from superficy, as some places with strange shapes require a large scale even though their superficy is small (example: rivers). Nicolas1981 (talk) 06:32, 5 September 2013 (UTC)
- Support looks like well known parameter of coord template. But it is better make it part of geo-coord data type. Maybe better contact to developers? — Ivan A. Krestinin (talk) 20:11, 5 September 2013 (UTC)
- The coordinates-datatypes contains
latitude,longitudealtitudeprecisionand aglobe-parameter today. m:Wikidata/Data model talks about adimension-parameter who will describe the size of the object. Maybe we should ask how these parameters are supposed to be used! -- Lavallentalk(block) 06:53, 7 September 2013 (UTC)- Thanks for finding this! The "dimension" parameter in datatype_geocoords seems to be what we need: "rough diameter of the object in meter, used for selecting the scale of the map and for uncertainty of an area". Nicolas1981 (talk) 03:26, 9 September 2013 (UTC)
- I weakly oppose this property as I believe it would be more logical to place the scale in the geocoords data type. Macadamia1472 (talk) 09:16, 16 October 2013 (UTC)
- There is a proposal for a wikimaps Individual Engagement Grant where he talk about a WNES bounding box - i.e. specifying the 4 corners of a box around the item. I think it would be better to specify such a bounding box rather than a circle. Oppose Filceolaire (talk) 22:55, 25 November 2013 (UTC)
- Scale is better than 4 points because 1. in can be extracted from Wikipedia articles, 2. scale is well known parameter, 3. it is hard to specify many points for human, visual editor is needed, 4. if visual editor will be available, then is better to specify full data (KML). — Ivan A. Krestinin (talk) 18:07, 27 November 2013 (UTC)
- There is a proposal for a wikimaps Individual Engagement Grant where he talk about a WNES bounding box - i.e. specifying the 4 corners of a box around the item. I think it would be better to specify such a bounding box rather than a circle.
- I might agree with this property if it were "approximate scale", and scale isn't quite the whole thing anyway. "approximate distance scale"?... --Izno (talk) 20:42, 3 February 2014 (UTC)
- Support property, Oppose name:
- The property: Though simple diameter is a very general dimension, it is useful basic information to have when other data is not yet available. The diameter can immediately be used to create a rough enclosure for other items with coordinates, and provide a rough "zoom" level for maps (that doesn't depend on some previous editor's opinions of context map size). It is a rough measurement, though: If a property equivalent to minimum bounding rectangle (Q1134256) will be created, as Filceolaire (talk • contribs • logs) implies, that would provide complimentary data that could be used instead, or in combination with, the property being proposed here.
- The name: This should probably be "diameter" or "geographic diameter". Perhaps the parameter should be "diameter (in meters)" or something, at least for now, so that it is clear what unit is mandatory, since quantity properties on Wikidata don't yet have a unit/dimension parameter. "Scale" is an imprecise word for this; the word "scale" implies a ratio that does not exist in databases. GeoHack is the service used by the coordinate templates on most wiki projects; the "dim:" GeoHack parameter has existed for quite some time. The "scale:" parameter is older in GeoHack, but is still used by some people; unfortunately, it has long been used to refer to each editor's own opinion about the size of the surrounding map, not the size of the item. (Its meaning has also changed over time: It was originally just the zoom parameter for Google Maps, if I remember correctly, and has now been retroactively given a calculation.) --Closeapple (talk) 07:38, 18 May 2014 (UTC)
- I would add
- 3. the datatype. It should be 'number with units (meters)' not string; but if it is going to take some time to get that then 'dimensionless number' could work in the meantime provided the property name is 'diameter of bounding circle (in meters)' or similar. Using 'number' means these can be compared and ranked.
- This needs a another property for the Centre of the bounding circle - type geocoord - or a description specifying that the center of the bounding circle is the coordinates given by coordinate location (P625) or whatever.
- We also need properties for 'Northernmost point', 'Southernmost point' etc. with type 'coordinate'. I will propose those later - gotta go shopping now. Filceolaire (talk) 13:44, 19 May 2014 (UTC)
- @Nicolas1981, Ivan A. Krestinin, Innocent bystander, Macadamia1472, Filceolaire: @Closeapple:
Not done - no consensus for creation and discussion petered out three months ago. --Jakob (talk) 14:03, 22 August 2014 (UTC)
list of monuments
| Description | link to the list of heritage monuments in the place/area. |
|---|---|
| Data type | Item |
| Domain | place, local or regional category of monuments |
| Allowed values | items (only lists of heritage monuments) |
| Example | Sample: Český Krumlov (Q188082) => list of cultural monuments in Český Krumlov (Q12052348)) |
| Source | monument database of WLM |
| Robot and gadget jobs | import from monument database |
| Proposed by | ŠJů (talk) |
- Discussion
To join articles about settlements and administrative units with local and regional lists of heritage monuments. ŠJů (talk) 17:26, 3 December 2013 (UTC)
- Support, needed.--Ymblanter (talk) 18:56, 13 December 2013 (UTC)
{{S}}, yes, queries does not help when the lists are manually culled. -- Lavallen (talk) 20:01, 13 December 2013 (UTC)
- Agree we need something like this, but now this proposal is a property voor just a "list of <topic A>", although there are many items with a list to be connected. Can we not make a general property "related list" and specify the list topic as a qualifier ("main topic" = monuments ? Michiel1972 (talk) 12:32, 17 December 2013 (UTC)
- Sounds like a good idea.--Ymblanter (talk) 16:02, 17 December 2013 (UTC)
- Lists already have a "list of" property—qualifying the property on the linked page is data duplication. --Izno (talk) 02:55, 31 January 2014 (UTC)
- Agree we need something like this, but now this proposal is a property voor just a "list of <topic A>", although there are many items with a list to be connected. Can we not make a general property "related list" and specify the list topic as a qualifier ("main topic" = monuments ? Michiel1972 (talk) 12:32, 17 December 2013 (UTC)
- I think I would support a "related list" property, but it needs to have a smaller (or different, at least) domain than the somewhat-inverse "list of" property. "list of monuments" is too specific to support, so I would oppose that. --Izno (talk) 02:43, 31 January 2014 (UTC)
- I do have a concern with a property like this or similar in that we should be working to eliminate linkage to list-type pages. Wikidata should fill the purpose that list pages currently serve... --Izno (talk) 02:58, 31 January 2014 (UTC)
- Comment Recently there was a discussion de:Wikipedia_Diskussion:WikiProjekt_Denkmalpflege#Denkmalnummer_als_Normdatensatz about "authority control" for munuments: There are states with centralized registers but also some (like Nordrhine-Westfalia) which organize "their" monuments in a purely local manner (i.e. on the administrative level of communities). Thus for this state alone there are more than 300 official monument lists, each of them with some numbering scheme for the items contained. As I understand the proposal it is not about introducing a property to mark Wikidata items for "list of monuments" articles (we do have is a list of (P360) and architectural heritage monument (Q811165), archaeological site (Q889487) as refinements of monument (Q1187960), don't we?), but to link individual monuments with some kind of list (a geographical object cannot be "contained in" a list).
- The discussion on de:WP did not yield clear results but some ideas how to model this situation, like
- source the ordinary statement X instance of (P31) a monument (Q1187960) by stated in (P248) plus a wikidata item representing the official list (example Denkmalliste der Stadt Bonn (Q15632243) introduced for experimenting with Friedrich-Wilhelm-Straße 14 (Q14544558)). Problem: Where to put the official monument number (source statements only allow page(s) (P304) and the like)
- Variant: Use approved by (P790) in conjunction with the wikidata item for the community as a qualifier, optionally sourced like above-.
- use catalog code (P528), constraining the number with catalog (P972) and the official-list-item as above: (I checked the discussion pages and current usage and it turned out that P528 is not restricted to astronomical catalogues any more)
- introduce some kind of datatype for "structured numbers" which would allow to use monument numbers in the same way as "classical" authority control (there are examples for this way - namely by utilizing a specific template - on de:WP monument-list articles)
- All these approaches base - or at least can gain - from having Wikidata items for the relevant list as official work (not a "creative" work, sometimes a database only, sometimes "published" as a whole, sometimes it is only known that such a list exists by law but can only be queried by parties with demonstrable interest). For these official-list items I think a definitive wikidata property is needed which also can be used to make these items eligible as targets for catalog (P972).
- Actually (for Germany) even the scattered lists in Nordrhine-Westfalia often have no direct equivalent in Wikipedia list-articles: The official lists still contain hundreds of monuments and even when they are replicated in full de:WP breaks them down to smaller geographical subdivisions. IMHO an important aspect to clear beforehand is to clarify / regulate the relation between items-for-official-monument-lists and items-for-list-of-monuments-articles
- BTW a closely related recent proposal is Wikidata:Property_proposal/Unsorted#street_key_.28en.29_.2F_Stra.C3.9Fenschl.C3.BCssel_.28de.29_.E2.80.93_.28Merci_de_traduire_ceci_en_fran.C3.A7ais..29 by User:Leit: Local authorities also administer "their" streets in a way similar to monuments. (And monuments typically are located in or at streets and places and therefore monument items are linked to streed items). Another proposal was Wikidata:Property_proposal/Archive/16#Aktennummer_.28de.29_.E2.80.93_.28Merci_de_traduire_ceci_en_fran.C3.A7ais..29 coined for the situation in Bavaria but unfortunately nobody did understand it.
- The discussion on de:WP also attracted users with knowledge about the WLM-Database on toolserver which is still actively synchronizing monument information between commons and (monument-list articles in) individual wikipedias. For that to work already a great deal of uniformity in the structure of the thousands of monument-list articles has been achieved and modelling in wikidata taking the WLM database as a starting point as it appears to be the intention of the current proposal may be not too bad a start. -- Gymel (talk) 14:03, 1 February 2014 (UTC)
- Another Comment (for those like me who get the impression that my lengthy comment above may be too remotely related to the proposal). The list-of-monuments-in-place-x articles to my understanding are the place where actual data entry happens. These list articles aim to be a complete reproduction of the official monuments list for the relevant municipality (in Germany an instance of municipality in Germany (Q262166)), constrained to a suitable smaller area (town, part of town, village, ...). These list articles are built up from tables, each row representing a (and usually linking to) one individual monument. One list article may contain several tables, each one (in a section of its own?) referring to one village within the broader geographical area covered by the article. The WLM database now to my understanding for example uses data from templates within the list articles to properly align the commons categories for individual monuments within the categories of the appropriate place and municipality. Thus for individual objects the WLM databases contains a double "uplink" to place/area and municipality (a proposal above Wikidata:Property_proposal/Place#située_dans_(village/quartier/parc) tries to establish the relation between object and place, since located in the administrative territorial entity (P131) is reserved for municipality etc. where located in/on physical feature (P706) might be restricted to purely geographical features, not "topographic" ones).
- Now there is a relation between the items for individual monuments or villages, places, areas etc. to items for list-articles, namely "mentioned in wikipedia list" simply by determining the (at most one) list article of the list-of-monuments-kind which covers the item. The relation would be even more useful if anchor information could be exploited. If one - as the proposal does - only considers "places/areas" it is just the inverse of a propery assigning to each of the list-of articles the item for the place it is dealing with (which probably should be done by qualifiying is a list of (P360) by a geographic restriction to the place item).
- However there is an important but absolutely non-trivial relation between objects, places, areas, villages and even municipalities to either the superordinate administrative unit which maintains the official list of monuments (examples: the state of bavaria for all places in bavaria, or the respective municipality for all places in Nordrhine-Westfalia) or - as described in the previous remark - to work-like items for the pertinent monuments list which in turn can be enriched with properties specifying the maintaining administrative unit ("publisher"), the legal regulation, published versions, online availability as a database and so on. But since these official lists are scattered into many list-type articles and their items (for reason, in logical and convincing way, but nevertheless not or not always reflecting structure and subdivisions of the respective official list) a property linking places with list-articles as proposed would only document convenience splitting decisions internal to some Wikipedia and would obfuscate the real need for linking with official monuments lists (or the administrative entities responsible for the monuments list of the area). -- Gymel (talk) 22:29, 1 February 2014 (UTC)
- Support A bit odd, but there seem to be thousands of these lists. --- Jura 05:32, 29 June 2014 (UTC)
- ŠJů, Lavallen, Ymblanter, Izno, Gymel, Jura: this property seems too specific, when there are many cases that require a similar solution. What do you think of calling it "inventory list" and qualify it with of (P642)? That way we could also have:
- ⟨ Český Krumlov (Q188082)
⟩ inventory list Search ⟨ 12052348 ⟩
of (P642) ⟨ cultural monument of the Czech Republic (Q385405) ⟩ - ⟨ Johann Sebastian Bach (Q1339) ⟩ inventory list Search ⟨ 375345 ⟩
of (P642) ⟨ composed musical work (Q207628) ⟩
- --Micru (talk) 08:35, 29 June 2014 (UTC)
- Not too much: For interstellar objects we already have a solution with "catalogue". Oeuvre lists are published catalogues, some of them are influential and used as a reference. "Denkmallisten" on the other hand are official lists by some administrative body for the area it governs. Therefore they are not an arbitrary "list of something" but more - and similar to the examples you gave - like an catalogue. I fear howver, that "catalogue" does not properly reflect the official nature of the inventory (for that reason I would also abstain from using "inventory number" which is coined towards acutal possession of an item by some institution). -- Gymel (talk) 08:52, 29 June 2014 (UTC)
- Gymel, catalog (P972) is not restricted to any domain, if it is an official list then that property should be enough. inventory number (P217) doesn't have a domain constraint either and you can use it for monuments and qualify it with p972. When proposed "inventory lists", I was thinking of user-compiled article lists.--Micru (talk) 10:23, 29 June 2014 (UTC)
- @Micru: Sorry, there are some twists I have not been aware of at my earlier reply:
- Individual Objects get a property with the (catalogue or inventory or proposed[?] monument) number, qualified by the catalogue, inventory or official list item. I don't think it is finally settled yet which property would be most appropriate, IMHO much depends on what type of item will be the value of the qualifier: The governmental publication or database in the sense of a citation or wikipedia lists trying to mirror or transcribe (sections of) these official lists.
- The proposal here tries to tie a region or administrative (sub) area (e.g. municipality or parts of that like boroughs et c.) with items representing the official list of monuments located in that area. Again, one difficulty might arise by the fact that there is no clear idea wether these will be citation items or ones pertaining to list of ... articles. -- Gymel (talk) 11:03, 29 June 2014 (UTC)
- @Gymel: For #1 "inventory number" or "catalog code" would do, with qualifier "catalog". For #2 I would create two separate properties, one that could be called "notable catalog" to link any item with their relevant catalog, and another one to link with related items that represent lists, which might be community-created in the form of wikipedia articles, but they are not specified by a single source.--Micru (talk) 11:57, 29 June 2014 (UTC)
- For catalalogues like BWV or stellar objects I'm fine with notable or relevant catalogue, for inventories (of museum objects in possession or - like here - object lists governed by law or administrative orders) there is some kind of natural monopole: One institution is singled out and this institution administers the list and issues its (numbered) entries. Thus authoritative or official list (or inventory) would be more on the point. At this place however it becomes important what items are the values of the proposed property: The authoritative list itself (even if unpublished) or some surrogate, which of course states the official numbers and maybe more, but can never be more than an adaption of the list. -- Gymel (talk) 12:31, 29 June 2014 (UTC)
- @Gymel: If we want a general property it is more useful to know which ones are the relevant catalogs than to know which ones are official. Besides that is an information that can be queried from the catalog itself (maintained by (P126):government X), so why to put that information in the property when it can be in the item?--Micru (talk) 09:16, 1 July 2014 (UTC)
- Not sure that we want a genral property - the class "list of monuments" is broad enough and to my understanding a kind of authoritativeness is always implied (it's the list, not a list). As for "put that information in the property": Cultural heritage monuments in Quadrath-Ichendorf (Q1833021) stands for a Wikipedia list article reflecting the official list and therefore most certainly is maintained by some unknown wikipedians and not by some government agency and also does not have main regulatory text (P92). I don't think we can discuss the proposal any further as long there is a blank for what the suggested values should or could be. In a sense Cultural heritage monuments in Quadrath-Ichendorf (Q1833021) could be interpreted as an edition of the official list, but this would imply further hassle since the wikipedia articles connected to the items are the edition contrary to the usual supposition that they describe (are about or represent) it. -- Gymel (talk) 09:56, 1 July 2014 (UTC)
- Gymel, if you want this property to link to an authoritative list, then let's call the property like that. It can be further qualified with of (P642) if needed to specify if it is about monuments, street art, parks or whatever.--Micru (talk) 08:49, 4 July 2014 (UTC)
- Not sure that we want a genral property - the class "list of monuments" is broad enough and to my understanding a kind of authoritativeness is always implied (it's the list, not a list). As for "put that information in the property": Cultural heritage monuments in Quadrath-Ichendorf (Q1833021) stands for a Wikipedia list article reflecting the official list and therefore most certainly is maintained by some unknown wikipedians and not by some government agency and also does not have main regulatory text (P92). I don't think we can discuss the proposal any further as long there is a blank for what the suggested values should or could be. In a sense Cultural heritage monuments in Quadrath-Ichendorf (Q1833021) could be interpreted as an edition of the official list, but this would imply further hassle since the wikipedia articles connected to the items are the edition contrary to the usual supposition that they describe (are about or represent) it. -- Gymel (talk) 09:56, 1 July 2014 (UTC)
- @Gymel: If we want a general property it is more useful to know which ones are the relevant catalogs than to know which ones are official. Besides that is an information that can be queried from the catalog itself (maintained by (P126):government X), so why to put that information in the property when it can be in the item?--Micru (talk) 09:16, 1 July 2014 (UTC)
- For catalalogues like BWV or stellar objects I'm fine with notable or relevant catalogue, for inventories (of museum objects in possession or - like here - object lists governed by law or administrative orders) there is some kind of natural monopole: One institution is singled out and this institution administers the list and issues its (numbered) entries. Thus authoritative or official list (or inventory) would be more on the point. At this place however it becomes important what items are the values of the proposed property: The authoritative list itself (even if unpublished) or some surrogate, which of course states the official numbers and maybe more, but can never be more than an adaption of the list. -- Gymel (talk) 12:31, 29 June 2014 (UTC)
- @Gymel: For #1 "inventory number" or "catalog code" would do, with qualifier "catalog". For #2 I would create two separate properties, one that could be called "notable catalog" to link any item with their relevant catalog, and another one to link with related items that represent lists, which might be community-created in the form of wikipedia articles, but they are not specified by a single source.--Micru (talk) 11:57, 29 June 2014 (UTC)
- @Micru: Sorry, there are some twists I have not been aware of at my earlier reply:
- Gymel, catalog (P972) is not restricted to any domain, if it is an official list then that property should be enough. inventory number (P217) doesn't have a domain constraint either and you can use it for monuments and qualify it with p972. When proposed "inventory lists", I was thinking of user-compiled article lists.--Micru (talk) 10:23, 29 June 2014 (UTC)
- Not too much: For interstellar objects we already have a solution with "catalogue". Oeuvre lists are published catalogues, some of them are influential and used as a reference. "Denkmallisten" on the other hand are official lists by some administrative body for the area it governs. Therefore they are not an arbitrary "list of something" but more - and similar to the examples you gave - like an catalogue. I fear howver, that "catalogue" does not properly reflect the official nature of the inventory (for that reason I would also abstain from using "inventory number" which is coined towards acutal possession of an item by some institution). -- Gymel (talk) 08:52, 29 June 2014 (UTC)
- Comment It would probably be possible to simulate this property with a few others, but is it really worth the work? If Wikidata turns out to work better, eventually these lists might not be needed anymore anyways. Identifying them with a separate property seems much easier. --- Jura 08:30, 5 July 2014 (UTC)
Done Use in a generic way. If it is an "authoritative list" you can mark the list as "instance of:authoritative list" or any ad-hoc created item. Notification: @ŠJů, Ymblanter, Lavallen, Izno, Gymel, Jura1:.--Micru (talk) 13:35, 22 August 2014 (UTC)
Gemarkung
Not done
| Description | Attribution of an object to a Gemarkung (highest cadastral district) in Germany |
|---|---|
| Data type | Item |
| Domain | all objects that can be georeferenced (i.e. geographical feature (Q618123)) |
| Allowed values | item |
| Example | Rübhausen (Q1493254) = Gemarkung Wahlfeld (Q15712088) |
| Source | cadastral maps, usually available online (in addition: often known as a Gemarkung is usually equivalent to a former municipality) |
| Proposed by | --Leit (talk) 12:11, 7 February 2014 (UTC) |
The main reason for proposing this property is that a Gemarkung neither is an instance of an administrative territorial entity (Q56061) (usually it used to be one before the municipality was incorporated into another one) nor a geographical feature (Q618123). In many cases a Gemarkung is identical to the area of an existing municipality (usually if the municipality has the same area as 200 years ago) but probably in most cases a municipality consists of several Gemarkungen who are identical to all the former municipalities that have been incorporated into this new municipality. However, it is not possible to represent the Gemarkungen simply by stating the former administrative division (using located in the administrative territorial entity (P131) with start time (P580) and end time (P582)) as Gemarkungen have often been merged in the aftermath of a territorial reform especially a century or so ago (whereas in the case of the territorial reforms of the 1960s and 1970s they have rather not been merged).--Leit (talk) 12:11, 7 February 2014 (UTC) I forgot to mention that Gemarkungen exist (even under this name) over all of Germany which is rather unique as the administrative divisions are very fragmented in that country.--Leit (talk) 12:15, 7 February 2014 (UTC)
- Leit you said that "it is not possible to represent the Gemarkungen simply by stating the former administrative division (using located in the administrative territorial entity (P131) with start time (P580) and end time (P582)) as Gemarkungen have often been merged in the aftermath of a territorial reform especially a century or so ago". The fact that they were merged a century ago just means that the "end date" is a century or so ago. That doesn't stop you using P131. Oppose. Filceolaire (talk) 10:05, 27 June 2014 (UTC)
- Leit you said that "it is not possible to represent the Gemarkungen simply by stating the former administrative division (using located in the administrative territorial entity (P131) with start time (P580) and end time (P582)) as Gemarkungen have often been merged in the aftermath of a territorial reform especially a century or so ago". The fact that they were merged a century ago just means that the "end date" is a century or so ago. That doesn't stop you using P131.
- Support Holger1959 (talk) 23:07, 7 February 2014 (UTC)
- @Leit, Filceolaire, Holger1959: Not done - no consensus for creation after almost half a year of discussion. --Jakob (talk) 00:05, 25 July 2014 (UTC)
Welsh listed building code
| Description | ID number for listed buildings in Wales, similar to National Heritage List for England number (P1216) and Historic Environment Scotland ID (P709) |
|---|---|
| Data type | String |
| Domain | listed buildings in Wales |
| Allowed values | unknown; looks like number-only |
| Example | example usage |
| Format and edit filter validation | ? |
| Source | external reference, Wikipedia list article (either infobox or source) |
| Robot and gadget jobs | Will create items for Wiki Loves Monuments where necessary. Bot will fill in values. |
| Proposed by | Magnus Manske (talk) |
- Discussion
This is part of Wiki Loves Monuments UK. This starts in a few days, so if we could prioritize this please... Magnus Manske (talk) 21:34, 27 August 2014 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:01, 27 August 2014 (UTC)
- Support As other monuments ID. --Fralambert (talk) 02:08, 29 August 2014 (UTC)
- @Magnus Manske, Pigsonthewing, Fralambert: Done. — Ayack (talk) 11:47, 30 August 2014 (UTC)
Northern Ireland listed building code
| Description | ID number for listed buildings in Northern Ireland, similar to National Heritage List for England number (P1216) and Historic Environment Scotland ID (P709) |
|---|---|
| Data type | String |
| Domain | listed buildings in Northern Ireland |
| Allowed values | alpha-numeric |
| Example | example usage |
| Format and edit filter validation | ? |
| Source | external reference, Wikipedia list article (either infobox or source) |
| Robot and gadget jobs | Will create items for Wiki Loves Monuments where necessary. Bot will fill in values. |
| Proposed by | Magnus Manske (talk) 22:48, 29 August 2014 (UTC) |
- Discussion
This is part of Wiki Loves Monuments UK. Same as Welsh codes above. Wiki Loves Monuments starts on Monday, I need to create items with that property by then! --Magnus Manske (talk) 22:48, 29 August 2014 (UTC)
- Support As other monuments ID. --Fralambert (talk) 03:43, 30 August 2014 (UTC)
- @Magnus Manske, Fralambert: Done. — Ayack (talk) 11:55, 30 August 2014 (UTC)