Wikidata:Property proposal/Archive/49
|
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
This archive page is full. Use Wikidata:Property proposal/Archive/50 or subsequent ones.
The previous archive page is Wikidata:Property proposal/Archive/48.
Biography at the Bürgerschaft Bremen
| Description | link to the biography pages of the Bürgerschaft Bremen |
|---|---|
| Data type | URL |
| Domain | Persons |
| Allowed values | URLs like http://www.bremische-buergerschaft.de/index.php?id=358&aid=* |
| Example | Sandra Ahrens (Q2220948) → http://www.bremische-buergerschaft.de/index.php?id=358&aid=631 |
| Proposed by | Olaf Kosinsky |
- Motivation
Ergänzung zu: Biographie beim Deutschen Bundestag (P1713) Olaf Kosinsky (talk) 09:56, 14 October 2015 (UTC)
- Discussion
Support Jonathan Groß (talk) 09:57, 14 October 2015 (UTC)
- @Olaf Kosinsky: The template says "url", but the id seems to be "631" for the example. What is the "358"? If we can only save the "631" and construct the URL for all examples it would be more like an identifier which would be preferrable. --Tobias1984 (talk) 20:24, 3 November 2015 (UTC)
- 358 is just the reference to the list of members – so id instead of url would be possible. But I see there a problem – nether the less if id- or url-datatype – by the fact that the urls are not valid anymore after each election. So after each election they will all be 404-pages. I'm not sure how to handle that. -- MichaelSchoenitzer (talk) 17:42, 7 November 2015 (UTC)
- @MichaelSchoenitzer: Not a real identifier in that case. We could ask the people that run the database to assign real identifiers that don't 404 in the future. Otherwise I see no real benefit in including this. --Tobias1984 (talk) 14:24, 8 November 2015 (UTC)
- It's still a valid description useful for this kind of politician for several years. I'd use URL datatype, we would just need to find a way to set them to "historic" (at some point in the future). --- Jura 15:45, 8 November 2015 (UTC), --- Jura 15:52, 8 November 2015 (UTC)
- Makes we wonder, what will we do with all the Obama-related resources in 2017? --- Jura 14:16, 18 November 2015 (UTC)
- 358 is just the reference to the list of members – so id instead of url would be possible. But I see there a problem – nether the less if id- or url-datatype – by the fact that the urls are not valid anymore after each election. So after each election they will all be 404-pages. I'm not sure how to handle that. -- MichaelSchoenitzer (talk) 17:42, 7 November 2015 (UTC)
Oppose because of unstable urls. --Pasleim (talk) 12:42, 23 March 2016 (UTC)
@Olaf Kosinsky: Not done, no consensus. --Srittau (talk) 13:08, 16 April 2016 (UTC)
PASE name
| Description | Standardised name (including disambiguation number) given to a person in the Prosopography of Anglo-Saxon England |
|---|---|
| Represents | Prosopography of Anglo-Saxon England (Q1565585) |
| Data type | String |
| Template parameter | |2= in w:Template:PASE |
| Domain | human (Q5) |
| Example | Æthelstan (Q170017) → 13909; qualifier: PASE name -> Æthelstan 18 |
| Format and edit filter validation | string should end in \s\d+ |
| Source | Template:PASE / Special:LinkSearch for http://www.pase.ac.uk/jsp / manual lookup on PASE site |
- Motivation
Although internal HTML links within the PASE site use the numerical PASE ID above (exclusively), the "official" identifier for an individual (as for example recommended in the site's suggested citation scheme) is this disambiguated name identifier. So it would make sense to be able to record and retrieve it as well.
I would suggest it be used as a qualifier for PASE ID proposed above, so that if multiple or conflicting PASE IDs are proposed for a Wikidata item, then the right PASE name can be attached to the right PASE ID.
As additional motivation for having this as well as the numerical ID, it is conceivable that the internal numerical IDs might be not be preserved in a future iteration of the site (though they were conserved between version 1 and version 2); also, if anyone is trying to match their own list of PASE entries to Wikidata items (and then perhaps eg to ODNB items), it is possible that they may only have these name identifiers, not the numerical IDs. Finally, it's useful to record and retain this to be able to check on our own extraction procedures -- if the PASE name is not similar to the article name, then something's likely to have gone wrong. Jheald (talk) 15:37, 16 January 2016 (UTC)
- Discussion
- Support. It seems like this could be useful in a few different circumstances and certainly will do no harm. Thryduulf (talk: local | en.wp | en.wikt) 19:59, 14 February 2016 (UTC)
Comment I was about to create this, but I'm not sure whether it should have the "external ID" datatype (which did not exist when the proposal was made). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:14, 19 March 2016 (UTC)
Input/advice on the proper type for this property now also requested at User:Addshore/Identifiers#PASE_name:_identifier_or_string.3F Jheald (talk) 14:26, 22 March 2016 (UTC)
- Comment As it is planned to be used as a qualifier and does not have a URL formatter, it should be a string. ArthurPSmith (talk) 17:47, 22 March 2016 (UTC)
@Jheald, Thryduulf, Pigsonthewing: 
Done --Srittau (talk) 13:26, 16 April 2016 (UTC)
DNZB
| Description | identifier in the Dictionary of New Zealand Biography |
|---|---|
| Represents | Dictionary of New Zealand Biography (1990-present) (Q1210319) |
| Data type | External identifier |
| Template parameter | |id= in w:Template:DNZB |
| Domain | human (Q5) |
| Allowed values | [a-z0-9]+ |
| Example | George Forbes (Q775773) -> 3f9 |
| Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
| Source | Wikipedia |
| Formatter URL | http://www.teara.govt.nz/en/biographies/$1 |
| Robot and gadget jobs | Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.) |
| Proposed by | Jura 13:05, 18 January 2016 (UTC), Please complete as needed. |
- Please provide a valid formatter URL and example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:30, 18 January 2016 (UTC)
@Jura1: Done, despite the very sloppy proposal. Well-defined external ID that is used by templates. --Srittau (talk) 13:37, 16 April 2016 (UTC)
- @Srittau: Thanks for creating it. Seems that all information could still be easily found. Good to have a qualified property creator. It seems it's already mostly populated.
--- Jura 12:27, 19 April 2016 (UTC)
Close friend of
| Description | Close friend of |
|---|---|
| Data type | Item |
| Domain | people in general |
| Allowed values | well-documented main friendships |
| Example | Michel de Montaigne (Q41568) close friend of Étienne de La Boétie (Q290227) |
- Motivation
This would be useful for historical social graphs (and so far, I've not seen anything approaching it in current of rejected properties). For instance, I've been interested in student/teacher relationships in order to map the evolution of intellectual/artistic communities (here's an exemple with ancient greek philosophy, but recently I've been especially focusing on european classic music); having the ability to record horizontal close relationships between two musicians/philosophers would be quite useful. I believe the property should be restricted to main well-documented friendships (hence the proposed name close friend of, but the more generic friend of would suit me as well). Alexander Doria (talk) 15:08, 3 April 2016 (UTC)
- Discussion
- We might have a "colleague" lying around; I'm rather aware that we also have either "teacher" or "student" lying around. This one feels okay, but I'd be concerned that it could (and would) be (mis)used as the more general "any friend of". Are you suggesting those who were close correspondents, or...? I'd prefer "colleague", since we could also say that married persons were close friends (prior to) for their marriage. --Izno (talk) 20:27, 3 April 2016 (UTC)
- Yes, pre-friendship of married people is a good point (as it has been undeniably close and frequently well-documented). For my use, colleague or collaborator might be fine and more precise (with perhaps still a stress on main or close in order to avoid mentionning every person who has ever worked with the entity). Alexander Doria (talk) 09:50, 4 April 2016 (UTC)
- How is partner in business or sport (P1327) for you? What uses can't be described by using that property? --Izno (talk) 11:39, 4 April 2016 (UTC)
- I missed this one. Yes, that could work, even if it can be a bit twisted at oldest times where professions were more vaguely defined than today (people like Montaigne or La Boëtie were rather independent thinkers). I wonder in fact if there could not be a case for a more generic rename (like collaborator/partner/colleague) — that would help btw to extend the adoption of the category (which do not seem to be so in use currently : only 242 relationships recorded apparently). Alexander Doria (talk) 17:30, 4 April 2016 (UTC)
- Pre-marriage is covered by unmarried partner (P451). The things you discover when you're not looking for them. --Izno (talk) 11:50, 5 April 2016 (UTC)
- How is partner in business or sport (P1327) for you? What uses can't be described by using that property? --Izno (talk) 11:39, 4 April 2016 (UTC)
- Yes, pre-friendship of married people is a good point (as it has been undeniably close and frequently well-documented). For my use, colleague or collaborator might be fine and more precise (with perhaps still a stress on main or close in order to avoid mentionning every person who has ever worked with the entity). Alexander Doria (talk) 09:50, 4 April 2016 (UTC)
- Oppose use unmarried partner (P451) and partner in business or sport (P1327) --Pasleim (talk) 18:34, 8 April 2016 (UTC)
- I don't think those quite cover it; partner seems to me like the kinds of partners at a law firm. --Izno (talk) 21:53, 8 April 2016 (UTC)
@Alexander Doria: 
Not done, no consensus at this point. I would suggest to try out partner in business or sport (P1327) for now, maybe slightly widening its scope if necessary. If that doesn't work out, please open a new proposal, which clearly delimits the differences to the existing properties. --Srittau (talk) 13:45, 16 April 2016 (UTC)
File Format PRONOM identifier (PUID)
| Description | identifier for a format in the technical registry PRONOM |
|---|---|
| Represents | PRONOM (Q7120402) |
| Data type | External identifier |
| Domain | file format (Q235557) |
| Allowed values | PUID of the form [x-]fmt/digits |
| Example | TIFF (Q215106) -> fmt/42 |
| Format and edit filter validation | (x-)?fmt\/\d+ |
| Source | https://www.nationalarchives.gov.uk/pronom |
| Formatter URL | https://www.nationalarchives.gov.uk/pronom/$1 |
- Motivation
PUIDs are identifiers for a format in the PRONOM technical registry, which is maintained by the National Archives of UK to help in their digital preservation efforts. Toto256 (talk) 23:27, 31 January 2016 (UTC)
- Discussion
- Comment Perhaps better to have two properties, one for each type [Meta: we need to decide a policy on this; other such cases are being discussed]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:36, 21 March 2016 (UTC)
- As asked I created two different properties Toto256 (talk) 22:22, 28 March 2016 (UTC)
@Toto256: Done --Lymantria (talk) 16:10, 19 April 2016 (UTC)
Software PRONOM identifier (PUID)
| Description | identifier for a software in the technical registry PRONOM |
|---|---|
| Represents | PRONOM (Q7120402) |
| Data type | External identifier |
| Domain | application (Q166142) |
| Allowed values | PUID of the form [x-]sfw/digits |
| Example | Adobe Acobat (Q207902) -> x-sfw/82 |
| Format and edit filter validation | (x-)?sfw\/\d+ |
| Source | https://www.nationalarchives.gov.uk/pronom |
| Formatter URL | https://www.nationalarchives.gov.uk/pronom/$1 |
- Motivation
PUIDs are identifiers for a software in the PRONOM technical registry, which is maintained by the National Archives of UK to help in their digital preservation efforts. Toto256 (talk) 23:27, 31 January 2016 (UTC)
- Discussion
- Support Pikolas (talk) 13:14, 3 April 2016 (UTC)
@Toto256: Done --Lymantria (talk) 16:11, 19 April 2016 (UTC)
YouTube channel name
| Description | Name of YouTube channel (not to be mixed up with the ID of the channel) |
|---|---|
| Represents | YouTube (Q866) |
| Data type | External identifier |
| Example | TED (Q189021) → https://www.youtube.com/ted |
| Source | https://www.youtube.com |
| Formatter URL | https://www.youtube.com/$1 |
- Motivation
The "YouTube" channel ID" property (https://www.wikidata.org/wiki/Property:P2397, e.g. https://www.youtube.com/channel/UCAuUUnT6oDeKwE6v1NGQxug) is not user-friendly (people have to dig heavily into HTML to retrieve ID, instructions here: http://stackoverflow.com/questions/14366648/how-can-i-get-a-channel-id-from-youtube). It is also not readable by humans.
Many YouTube channels have the URL syntax of https://www.youtube.com/channelname (this is the syntax the official YouTube documentation states: https://support.google.com/youtube/answer/2657968?hl=en). On the other hand, https://www.youtube.com/ted AND https://www.youtube.com/c/ted both work, but https://www.youtube.com/user/ted AND https://www.youtube.com/channel/ted don't work Pavner (talk) 14:27, 29 March 2016 (UTC)
- Discussion
- Comment It's easier to retrieve the ID than you'd think: if you go to the channel from a video uploaded by it, the link takes you to the URL with the ID. – Máté (talk) 14:44, 29 March 2016 (UTC)
- Thanks for the data. Didn't know that. Anyways, I believe there should be a way for non-tech-savvy people to add a YouTube identifier to Wikidata. Pavner (talk) 14:48, 29 March 2016 (UTC)
- Comment previous proposal is at Wikidata:Property_proposal/Archive/45#YouTube_address. Maybe @Izno, Visite fortuitement prolongée, Pasleim: want to add something.
--- Jura 17:12, 3 April 2016 (UTC) - Oppose per previous discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:37, 4 April 2016 (UTC)
- @Pavner:
Not done, per the problems outlined in the previous proposal. No additional support in this proposal. Also, we would add redundant, non-consistent data, if we have two ways of referencing the same thing. --Srittau (talk) 22:42, 6 April 2016 (UTC)
- @Srittau: The other proposal was slightly different and there wasn't actually much arguments there to explain why it's not a good idea. Besides, if you want to participate in the discussion and add additional arguments, you shouldn't close the discussion, but comment in the debate. As there is no requirement to close the discussion on the 7th day, your closure seems premature as well. Thus I undid it.
--- Jura 10:09, 7 April 2016 (UTC)- @Srittau: What's better? Having less data (because users will find it extremely hard to add a YouTube ID) + having invalid data (because people will type in channel/user names instead of IDs into the ID field in YouTube channel ID (P2397)) OR more linked data (because more users will be able to add YouTube data) + some redundant data which can be easily consolidated in the future by a bot? --18:26, 9 April 2016 (UTC)
- @Srittau: ?
- I made my decision, the reasons are stated above and are based on the previous discussion. This discussion is closed. --Srittau (talk) 16:41, 12 April 2016 (UTC)
- @Srittau: ?
- @Srittau: What's better? Having less data (because users will find it extremely hard to add a YouTube ID) + having invalid data (because people will type in channel/user names instead of IDs into the ID field in YouTube channel ID (P2397)) OR more linked data (because more users will be able to add YouTube data) + some redundant data which can be easily consolidated in the future by a bot? --18:26, 9 April 2016 (UTC)
- @Srittau: The other proposal was slightly different and there wasn't actually much arguments there to explain why it's not a good idea. Besides, if you want to participate in the discussion and add additional arguments, you shouldn't close the discussion, but comment in the debate. As there is no requirement to close the discussion on the 7th day, your closure seems premature as well. Thus I undid it.
ResearchGate institution ID
| Description | identifier of an institution in ResearchGate |
|---|---|
| Represents | ResearchGate (Q754454) |
| Data type | External identifier |
| Domain | organization (Q43229) |
| Allowed values | [a-zA-Z0-9_]+ |
| Example | National Aeronautics and Space Administration (Q23548) → nasa |
| Formatter URL | https://www.researchgate.net/institution/$1 |
- Motivation
This property is for institution, we have also ResearchGate profile ID (P2038) for people. Edoardo88 (talk) 09:25, 1 April 2016 (UTC)
- Discussion
- Support this looks useful - the ResearchGate institution pages have a lot of info. ArthurPSmith (talk) 19:17, 1 April 2016 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:52, 4 April 2016 (UTC)
Done @Edoardo88, ArthurPSmith, Pigsonthewing: My first property-creation, so please let me know if something is wrong. Lymantria (talk) 14:05, 11 April 2016 (UTC) [Edited regex]
Tate artist identifier
| Description | identifier of an artist in the Tate collection |
|---|---|
| Data type | External identifier |
| Domain | person |
| Allowed values | [1-9]\d* |
| Example | Berthe Morisot (Q105320) → 1663 |
| Source | http://www.tate.org.uk/art/search |
| Formatter URL | http://www.tate.org.uk/art/artists/$1 |
- Motivation
Notable collection of artists. Their data is alsoavailable under CC-Zero. Jean-Fred (talk) 09:28, 2 April 2016 (UTC)
- Discussion
- Support. Looks like a good addition. Multichill (talk) 11:25, 2 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:01, 4 April 2016 (UTC)
- Support Spinster (talk) 14:34, 12 April 2016 (UTC)
@Jean-Frédéric, Multichill, Pigsonthewing, Spinster: Done --Lymantria (talk) 15:25, 12 April 2016 (UTC)
filmportal.de person ID
| Description | identifier for persons at the german Filmportal.de |
|---|---|
| Data type | External identifier |
| Domain | Persons human (Q5) |
| Allowed values | hex-decimal ID Code normalized to lowercase (Example: 16e2b393d11641aa885388d85222f8db for "Rainer Werner Fassbinder") |
| Example | Rainer Werner Fassbinder (Q44426) → 16e2b393d11641aa885388d85222f8db |
| Format and edit filter validation | ^[0-9a-f]{32}$ |
| Source | http://filmportal.de, GND linked data dumps, Template:Filmportal.de name (Q14411077) (exists on de, als, ja, ro) |
| Formatter URL | http://www.filmportal.de/person/$1 |
| Robot and gadget jobs | User:KasparBot should move its additions to Filmportal ID (P2639) into this property --> |
- Motivation
@Fililipa, Landesfilmsammlung, putnik, Pasleim: In March Filmportal ID (P2639) was endorsed at Wikidata:Property proposal/Creative work#Filmportal-ID, apparently everybody had movies in mind, the resolver URL for this property is http://www.filmportal.de/film/$1. Apparently now an IP (the same as already subject of the discussion Wikidata:Project chat/Archive/2016/03#Unregistered bot adding movie related information?) seems to have noticed that this also works for persons (the other kind of entity described at filmportal.de), and added the Fassbinder example. Now User:KasparBot has already added approaching 30.000 Ids for persons to that property. (My applause goes to the target website, their resolver is doing a very good job redirecting anything with a 32digt hex string at the end to the proper page).
I think for better property constraints and eventually formatter URI for RDF resource (P1921) there should be distinct properties for films and persons at filmportal.de, although the identifiers are not in conflict and the target website tolerates mis-addressing. -- Gymel (talk) 09:40, 2 April 2016 (UTC)
- Discussion
Weak oppose I agree with you: Having ../film/..in the formatter url for persons is not the best solution. On the other hand it is easier and less confusing for new users to have only one property. IMDb ID (P345) is also used in all cases neither only for films nor for persons. Maybe filmportal.de (Q15706812) defines in future a better URL which doesn't contain../film/... Then this problem would be solved. We could change the constraints of the existing property and allow only human (Q5) and film (Q11424) (and subclasses) for instance of (P31). -- T.seppelt (talk) 12:57, 2 April 2016 (UTC)- I don`t think so. Filmportal.de has an ID for each Person or Film...nothing is double. Distinct properties for films and persons are not neccessary. In my opinion it would only be an unneccessary double property.--Eddgel (talk) 13:01, 2 April 2016 (UTC)
- Oppose the ID applies for films and persons, maybe that is why the Filmportal provides an generic URL with film/ (film does not necessarily mean movie). A better url would be filmportal.de/id, but thats nothing to discuss here. – The preceding unsigned comment was added by Queryzo (talk • contribs).
- ??? http://www.filmportal.de/person/fa85c5fe1b0349d0b47cfd6bc21b8d97 resolves to the movie. It's more like IMDb, the identifiers for the different kinds of entities don't conflict with each other, but in contrast to IMDB the filmportal doesn't provide a "neutral" URL prefix but rather any of the two specific prefixes also resolves "for the other". -- Gymel (talk) 21:06, 2 April 2016 (UTC)
- I just mailed Georg Eckes from the Deutsches Filminstitut, project manager of The European Film Gateway (EFG) and Metadata Standards for Cinematographic Works (CEN). He answered the following (4 April 2016, 11:59):
- “From my point of view it is all correct what is said in the discussion: the distinction of /person/ and /film/ is actually not necessary, because redirects to a person are working all right with prefix /film/ (and vice versa). That is not the point because double UIDs aren't allowed by the system. Anyway we're not planning to change the structure of the links nor the resolving.”
- Original text in german: „Aus meiner Sicht ist alles, was in der bisherigen Diskussion gesagt worden ist, richtig: Die Unterscheidung nach person/ und /film/ ist eigentlich nicht notwendig weil Weiterleitungen zu einer Person auch mit Präfix /film/ funktionieren (und umgekehrt). Das ist aber kein Problem weil UID-Dopplungen in filmportal systematisch ausgeschlossen sind. Wir planen jedenfalls bis auf weiteres keine Änderungen an der Linkstruktur und am gegenwärtig praktizierten Resolving. “
- Queryzo (talk) 12:50, 4 April 2016 (UTC)
- Thank you Queryzo, then it's apparently just about the constraints and formatter URI for RDF resource (P1921) (in case they have an interface for this). I would stick to one property with two formatter URL (P1630) and
{{Constraint:Type|classes = Q5, 11424|relation=instance}}. -- T.seppelt (talk) 13:58, 4 April 2016 (UTC)
- Thank you Queryzo, then it's apparently just about the constraints and formatter URI for RDF resource (P1921) (in case they have an interface for this). I would stick to one property with two formatter URL (P1630) and
- Not done use Filmportal ID (P2639) for both films and persons. --Pasleim (talk) 08:21, 15 April 2016 (UTC)
International Ski Federation IDs
FIS alpine skier ID
| Description | identifier for an alpine skier, in the International Ski Federation database |
|---|---|
| Represents | International Ski and Snowboard Federation (Q212928) |
| Data type | External identifier |
| Template parameter | en:Template:FIS |
| Domain | human (Q5) |
| Allowed values | [1-9][0-9]+ |
| Example | Lara Gut-Behrami (Q30293) → 125871 |
| Source | http://data.fis-ski.com |
| Formatter URL | http://data.fis-ski.com/dynamic/athlete-biography.html?sector=AL&competitorid=$1 |
| Robot and gadget jobs | My bot can import values from Wikipedias |
FIS cross-country skier ID
| Description | identifier for a cross-country skier, in the International Ski Federation database |
|---|---|
| Represents | International Ski and Snowboard Federation (Q212928) |
| Data type | External identifier |
| Template parameter | en:Template:FIS |
| Domain | human (Q5) |
| Allowed values | [1-9][0-9]+ |
| Example | Kristina Šmigun-Vähi (Q231327) → 57188 |
| Source | http://data.fis-ski.com |
| Formatter URL | http://data.fis-ski.com/dynamic/athlete-biography.html?sector=CC&competitorid=$1 |
| Robot and gadget jobs | My bot can import values from Wikipedias |
FIS freestyle skier ID
| Description | identifier for a freestyle skier, in the International Ski Federation database |
|---|---|
| Represents | International Ski and Snowboard Federation (Q212928) |
| Data type | External identifier |
| Template parameter | en:Template:FIS |
| Domain | human (Q5) |
| Allowed values | [1-9][0-9]+ |
| Example | Hannah Kearney (Q264830) → 29903 |
| Source | http://data.fis-ski.com |
| Formatter URL | http://data.fis-ski.com/dynamic/athlete-biography.html?sector=FS&competitorid=$1 |
| Robot and gadget jobs | My bot can import values from Wikipedias |
FIS ski jumper ID
| Description | identifier for a ski jumper, in the International Ski Federation database |
|---|---|
| Represents | International Ski and Snowboard Federation (Q212928) |
| Data type | External identifier |
| Template parameter | en:Template:FIS |
| Domain | human (Q5) |
| Allowed values | [1-9][0-9]+ |
| Example | Veli-Matti Lindström (Q15742) → 35456 |
| Source | http://data.fis-ski.com |
| Formatter URL | http://data.fis-ski.com/dynamic/athlete-biography.html?sector=JP&competitorid=$1 |
| Robot and gadget jobs | My bot can import values from Wikipedias |
FIS Nordic combined skier ID
| Description | identifier for a Nordic combined skier, in the International Ski Federation database |
|---|---|
| Represents | International Ski and Snowboard Federation (Q212928) |
| Data type | External identifier |
| Template parameter | en:Template:FIS |
| Domain | human (Q5) |
| Allowed values | [1-9][0-9]+ |
| Example | Felix Gottwald (Q380143) → 21155 |
| Source | http://data.fis-ski.com |
| Formatter URL | http://data.fis-ski.com/dynamic/athlete-biography.html?sector=NK&competitorid=$1 |
| Robot and gadget jobs | My bot can import values from Wikipedias |
FIS snowboarder ID
| Description | identifier for a snowboarder, in the International Ski Federation database |
|---|---|
| Represents | International Ski and Snowboard Federation (Q212928) |
| Data type | External identifier |
| Template parameter | en:Template:FIS |
| Domain | human (Q5) |
| Allowed values | [1-9][0-9]+ |
| Example | Shaun White (Q288656) → 66030 |
| Source | http://data.fis-ski.com |
| Formatter URL | http://data.fis-ski.com/dynamic/athlete-biography.html?sector=SB&competitorid=$1 |
| Robot and gadget jobs | My bot can import values from Wikipedias |
- Motivation
International Ski and Snowboard Federation (Q212928) is the governing body for several Olympic sports. Database contains detailed statistical information, that is useful for athlete referencing. IDs will be used in Template:Sports links (Q22674492). --Edgars2007 (talk) 10:50, 28 March 2016 (UTC)
- Discussion
Why so many splitted properties? It's because of ?sector= part of URL, which is different for each type. --Edgars2007 (talk) 10:50, 28 March 2016 (UTC)
- We should have only one property and the URL should be
http://data.fis-ski.com/dynamic/athlete-biography.html?sector=$1with values stored by Wikidata such asSB&competitorid=66030. Thierry Caro (talk) 13:00, 28 March 2016 (UTC)- I should say, that I'm not a big fan of this idea, but if the consensus will be about one property (with arguments), then of course I won't resist. Some of my reasons for splitted property:
- The name says "ID", I don't think &competitorid= would be part of it :) Aim to keep the real ID, not some work-aroundish variant, that could cause problems sometime in future, was also my reasoning to have simple ID for #CricketArchive player ID, where my original idea was to put something like "41/41464/41464" to get working URL at Wikidata. If the URL format for FIS would be something like
http://data.fis-ski.com/dynamic/athlete-biography.html?id=CC001(CC001), where sector is concatenated with ID, then most probably I would propose only one property. - We should think about our client needs, right? Also Wikipedia. So... In case of several sports, where athlete has competed in (I assume, there are some), users won't have to add extra complexity to templates to add all links to FIS, as "normally" you can get only one link (usually the first one). And splitted properties will be easier to maintain.
- Well, we have splitted properties also earlier. See the same Transfermarkt, Soccerbase, ProCyclingStats and others here. OK, previously those were some 2-3 (for player, trainer, team), but I don't see any reason why then we couldn't have one property for my named websites. Note, than I'm not proposing to get them together, that was just an example
- The name says "ID", I don't think &competitorid= would be part of it :) Aim to keep the real ID, not some work-aroundish variant, that could cause problems sometime in future, was also my reasoning to have simple ID for #CricketArchive player ID, where my original idea was to put something like "41/41464/41464" to get working URL at Wikidata. If the URL format for FIS would be something like
- Maybe there are some more good reasons for splitting up :) --Edgars2007 (talk) 16:46, 28 March 2016 (UTC)
- Splitting is not necessary if we make URL
http://data.fis-ski.com/dynamic/athlete-biography.html?competitorid=$1and include the sector in the wikidata-value, like66030§or=SB([1] is a valid link). I think a more generic property is to be preferred. Lymantria (talk) 17:50, 2 April 2016 (UTC)- One of reasons, why I still don't like this approach, is painful manual adding, there would be so many ways to input incorrect value, as you can't also directly copy it from URL :) --Edgars2007 (talk) 08:02, 12 April 2016 (UTC)
- True. The best solution would be a double parameter, but Properties do not have that possibility yet. Meanwhile, I can live with your suggestion to have four seperate properties. Lymantria (talk) 14:32, 16 April 2016 (UTC)
- One of reasons, why I still don't like this approach, is painful manual adding, there would be so many ways to input incorrect value, as you can't also directly copy it from URL :) --Edgars2007 (talk) 08:02, 12 April 2016 (UTC)
- Splitting is not necessary if we make URL
- I should say, that I'm not a big fan of this idea, but if the consensus will be about one property (with arguments), then of course I won't resist. Some of my reasons for splitted property:
- Support Whatever how it will be. --- Løken (talk) 19:52, 28 March 2016 (UTC)
- Comment To get the personal information of an athlete (without the results), it doesn't matter which value you set for sector, i.e. the FIS ID is unique over all sports. --Pasleim (talk) 07:58, 30 March 2016 (UTC)
- @Pasleim: so basically you're suggesting removing URL? IMHO, linking everybody to one sector (alpine skiing, for example) also wouldn't be very good action, because then I need to guess, in which sport the athlete has competed in to get the results. And you get "404" for not providing any sector (leaving it blank or removing the parameter from URL). I want to note, that this is different case from #CricketArchive player ID, because there I can get *working* URL simply knowing the ID, but here I can't do that. --Edgars2007 (talk) 09:29, 30 March 2016 (UTC)
- I think results like this are not useful. The sector has to be included somehow. Lymantria (talk) 17:53, 2 April 2016 (UTC)
- @Pasleim: so basically you're suggesting removing URL? IMHO, linking everybody to one sector (alpine skiing, for example) also wouldn't be very good action, because then I need to guess, in which sport the athlete has competed in to get the results. And you get "404" for not providing any sector (leaving it blank or removing the parameter from URL). I want to note, that this is different case from #CricketArchive player ID, because there I can get *working* URL simply knowing the ID, but here I can't do that. --Edgars2007 (talk) 09:29, 30 March 2016 (UTC)
- Comment Can we whack their developer with a large clue stick? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 4 April 2016 (UTC)
- Options There is also a "FIS Code" for each person on their website. A formatter URL for that is possible and should lead to whatever other page is available. If "competitorid" is preferred, another property (or qualifier) could be used to determine the sector and included in the formatter url. Obviously, whatever their solution may be, it's likely to be mine.
--- Jura 10:18, 15 April 2016 (UTC)
@Edgars2007, Jura1, Løken: Done The FIS-links are very useful and based on the discussions above I did not see a better, more generic, way to include these properties into one property. Hence six properties created. Lymantria (talk) 17:40, 23 April 2016 (UTC)
DE-ISIL
| Description | ISIL starting with "DE" |
|---|---|
| Represents | International Standard Identifier for Libraries and Related Organizations (Q470458) |
| Data type | External identifier |
| Example 1 | MISSING |
| Example 2 | MISSING |
| Example 3 | MISSING |
| Formatter URL | http://dispatch.opac.d-nb.de/DB=1.2/CMD?ACT=SRCHA&IKT=8529&TRM=$1 |
- Discussion
- Comment solution suggested as the formatter url for the ISIL (P791) only works for identifier with "DE". This would save WMDE writing a few lines of code. For other countries, more properties would need to be created. Personally, I'm not convinced by this approach.
--- Jura 16:23, 31 March 2016 (UTC) - Oppose Duplicates ISIL (P791). The solution to the problem described, if any is needed, would be a more sophisticated tool for Formatter URLs, not a property for each country. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:51, 4 April 2016 (UTC)
- @Lydia Pintscher (WMDE):: Maybe you want to add something to explain why this would be needed at this stage from a product management or WMDE development perspective.
--- Jura 09:53, 7 April 2016 (UTC)- Thanks for the ping. Is the DE part of the identifier or not? Can you link me to items that show the problem? Thanks! --Lydia Pintscher (WMDE) (talk) 14:31, 8 April 2016 (UTC)
- @Lydia Pintscher (WMDE): The "DE" is part of the identifier (there's an explanation of the format here). Deutsches Museum (Q131617) has ISIL (P791) with DE-MUS-097410, Library of Congress (Q131454) has US-DLC. This formatter URL works for the former (here) but not for the latter (here). - Nikki (talk) 16:18, 8 April 2016 (UTC)
- Thanks for the ping. Is the DE part of the identifier or not? Can you link me to items that show the problem? Thanks! --Lydia Pintscher (WMDE) (talk) 14:31, 8 April 2016 (UTC)
- Oppose Whether or not the software solution is available, I don't think it is a good idea to split ISIL (P791) (or other properties) in this sort of way. Surely there are better solutions. ArthurPSmith (talk) 15:18, 7 April 2016 (UTC)
- Comment ISIL is interesting. ISIL identifiers are often assigned per country and can thus have a wide variety of formatter URLs. I hope I'm not going off-topic too much, but it would be useful to have a property type that allows us to make custom formatter URL + identifier constructions that can vary within one single property, rather than having one single formatter URL 'hardcoded' in each separate property. This would also make it much simpler to manage the enormous avalanche of (for instance) museums' artwork properties that we will otherwise have to manage. I hope I'm being clear enough here. Spinster (talk) 14:40, 12 April 2016 (UTC)
- Comment I am not sure such a property should be constructed. Perhaps it would be better with a tool that redirects, or e.g., do like it is done with geographical coordinates. — Finn Årup Nielsen (fnielsen) (talk) 12:13, 16 April 2016 (UTC)
Not done Unsufficient support. Lymantria (talk) 14:31, 18 April 2016 (UTC)
- @Lydia Pintscher (WMDE): please take note the above and adjust your development plan accordingly.
--- Jura 14:37, 18 April 2016 (UTC)
PIC ID
| Description | Identifier used in Photographers' Identities Catalog |
|---|---|
| Data type | External identifier |
| Domain | Photographers, photography studios |
| Allowed values | number |
| Example | Berenice Abbott (Q231861) → 1669 |
| Source | http://pic.nypl.org/ |
| Formatter URL | http://pic.nypl.org/map/?DisplayName=$1 |
- Motivation
Photographers' Identities Catalog contains biographical data on 115,000 photographers and studios compiled and aggregated by New York Public Library photography specialists from trusted photography history sources and original research. It currently provides links to 11,000 Wikidata entries. Ideally both databases should provide reciprocal links.
- Discussion
- Support. Perhaps some of the parameters in the Formatter URL are redundant? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:55, 4 April 2016 (UTC)
- I checked and it will work without the extra parameters in the URL. edited Formatter URL accordingly, thanks Andy Mabbett. Davidrlowe (talk) 18:51, 5 April 2016 (UTC)
- Support --T.seppelt (talk) 14:04, 5 April 2016 (UTC)
- Great database. Links back to Wikidata itself too. Support Spinster (talk) 15:43, 12 April 2016 (UTC)
@Davidrlowe: Done --Lymantria (talk) 05:43, 20 April 2016 (UTC)
Roller Coaster Database-ID
| Description | Number in Roller Coaster Database (RCDB) |
|---|---|
| Represents | Roller Coaster DataBase (Q267804) |
| Data type | External identifier |
| Template parameter | "rcdb_number" in en:template:Infobox_roller_coaster |
| Domain | roller coaster (Q204832) |
| Allowed values | natural number (Q21199) |
| Example | Raptor (Q683300) → 1 |
| Formatter URL | http://rcdb.com/$1.htm |
- Motivation
Major database for roller coasters. Used in several Wikipedias. Trockennasenaffe (talk) 08:22, 4 April 2016 (UTC)
- Discussion
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 4 April 2016 (UTC)
- Support. Thierry Caro (talk) 23:50, 6 April 2016 (UTC)
- Support Lymantria (talk) 04:52, 8 April 2016 (UTC)
@Trockennasenaffe: Done --Lymantria (talk) 11:54, 20 April 2016 (UTC)
Identifier for Danish protected area
| Description | Naturfredningsområder i Danmark (da) – (Please translate this into English.) |
|---|---|
| Data type | External identifier |
| Template parameter | Probably none |
| Domain | Items associated with protected area (Q473972) |
| Allowed values | \d{5}.\d{2} |
| Example | Vestvolden (Q3375908) → "07878.00" |
| Source | Example: http://www.fredninger.dk/fredning/vestvolden/ |
| Formatter URL | http://www2.blst.dk/nfr/$1.pdf |
| Robot and gadget jobs | None |
- Motivation
This would benefit Danish participation in Wiki Loves Earth — Finn Årup Nielsen (fnielsen) (talk) 22:42, 6 April 2016 (UTC)
- Discussion
- Support --Edgars2007 (talk) 08:53, 7 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:55, 7 April 2016 (UTC)
- Support -- Nico (talk) 13:23, 16 April 2016 (UTC)
RePEc Series handle
| Description | Research Papers in Economics (RePEc) is a service that indexes academic journals (amongst other things). The Series handle can be used as an identifier that links to the academic journal's page on a site using the RePEc index (for example, EconPapers). |
|---|---|
| Data type | String |
| Domain | academic journal (Q737498) |
| Allowed values | text |
| Example | The American Economic Review (Q1740221) → aeaaecrev |
| Formatter URL | http://econpapers.repec.org/article/$1 |
- Motivation
Research Papers in Economics (Q206316) is perhaps the most important academic journal indexing service for economists, and also provides links to open access publications. This identifier will enable easy linking to RePEc pages and therefore better access to academic journal articles from Wikimedia pages.ChrisSampson87 (talk) 22:05, 7 April 2016 (UTC)
- Discussion
- Support Good addition. Lymantria (talk) 04:57, 8 April 2016 (UTC)
- Support Strakhov (talk) 20:39, 9 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:34, 13 April 2016 (UTC)
@ChrisSampson87: Done with datatype external identifier. Relaxed domain to magazine (Q41298) to avoid constraint violations. Added an example ID that does not contain letters only. Lymantria (talk) 10:30, 21 April 2016 (UTC)
skyscraper building complex ID
| Data type | External identifier |
|---|---|
| Example | International Finance Centre (Q15246) -> 482 |
| Formatter URL | http://www.skyscrapercenter.com/complex/$1 |
| Proposed by | Zolo (talk) 17:09, 8 April 2016 (UTC) |
Like CTBUH Skyscraper Center building ID (P1305) but for building complexes rather than single buildings. Different URL pattern, so different property needed, like for Emporis building ID (P455) / Emporis building complex ID (P2270). --Zolo (talk) 17:09, 8 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:33, 13 April 2016 (UTC)
@Zolo: Done --Lymantria (talk) 16:45, 21 April 2016 (UTC)
blue-style.com ID
| Data type | External identifier |
|---|---|
| Example | NHK Osaka Hall (Q3334412) -> 2058 |
| Formatter URL | http://www.blue-style.com/photo/all/view-$1.html |
| Proposed by | Zolo (talk) 17:09, 8 April 2016 (UTC) |
- Motivation
Another skyscraper / contemporary architecture database, this time for Japan, like PSS-archi ID (P1838) for France and Gaoloumi ID (P1837) for China. Seems to be the most comprehensive database on this topic in Japanese. Would be useful to cleanup external link syntax in frwiki. Zolo (talk) 17:09, 8 April 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 13 April 2016 (UTC)
@Zolo: Done I am not sure about a regex. I thought perhaps the ID's might be restricted to numbers. Lymantria (talk) 21:16, 21 April 2016 (UTC)
- @Lymantria: thanks, yes they seem to be just digits. --Zolo (talk) 05:41, 23 April 2016 (UTC)
JudoInside.com ID
| Description | Identifier for any remarkable judoka (Q6665249) in the JudoInside.com (Q21661943) database. |
|---|---|
| Represents | JudoInside.com (Q21661943) |
| Data type | External identifier |
| Domain | judoka (Q6665249) |
| Allowed values | [1-9][0-9]* |
| Example | |
| Formatter URL | http://www.judoinside.com/judoka/$1 |
- Motivation
This is a useful database for items about judo (Q11420) practitioners. Thierry Caro (talk) 02:14, 9 April 2016 (UTC)
- Discussion
- Support --Edgars2007 (talk) 08:24, 12 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 12 April 2016 (UTC)
@Thierry Caro: Done --Lymantria (talk) 07:46, 22 April 2016 (UTC)
Wrestlingdata person id
| Description | id for a professional wrestling performer on the Wrestlingdata database |
|---|---|
| Data type | External identifier |
| Domain | human |
| Allowed values | [1-9][0-9]* |
| Example | Hulk Hogan (Q44176) → 39 |
| Source | http://wrestlingdata.com or http://genickbruch.com/ |
| Formatter URL | http://wrestlingdata.com/index.php?befehl=bios&wrestler=$1 or http://genickbruch.com/index.php?befehl=bios&wrestler=$1 (German) |
| Robot and gadget jobs | we may be able to scrape values from raw external links, but I've not been able to find templates for this |
- Motivation
Wrestlingdata is a very large database of professional wrestling performers, matches, events, etc. They have about 26,000 profiles, which seems to be mainly wrestlers, but also includes some non-wrestling performers. Silverfish (talk) 23:41, 9 April 2016 (UTC)
- Discussion
- Support --Edgars2007 (talk) 08:41, 12 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 12 April 2016 (UTC)
- Support. Thierry Caro (talk) 17:22, 13 April 2016 (UTC)
- Done @Silverfish, Edgars2007, Pigsonthewing, Thierry Caro: --Pasleim (talk) 19:46, 21 April 2016 (UTC)
BNE journal ID
| Description | Identifier for a journal in BNE's journals archive, an open access digital library of Spanish-language periodical publications, established by Biblioteca Nacional de España (Q750403). |
|---|---|
| Data type | External identifier |
| Domain | periodical (Q1002697) |
| Allowed values | numbers |
| Example | La Ilustración Española y Americana (Q6419450) → 0001066626 |
| Source | http://hemerotecadigital.bne.es/index.vm , es:Plantilla:HemBNE |
| Formatter URL | http://hemerotecadigital.bne.es/details.vm?q=id:$1 |
- Motivation
Providing valuable access to old publications. Journal identifier from Hemeroteca Digital of Biblioteca Nacional de España (Q750403). Strakhov (talk) 12:52 10 abr 2016 (UTC)
- Talk
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:34, 12 April 2016 (UTC)
@Strakhov: Done --Lymantria (talk) 20:43, 22 April 2016 (UTC)
IAT triathlete ID
| Description | identifier for a triathlete, in the Institut für Angewandte Trainingswissenschaft database |
|---|---|
| Represents | Institute for Applied Training Science (Q1664800) |
| Data type | External identifier |
| Template parameter | de:Vorlage:IATTriathletProfil |
| Domain | human (Q5) |
| Allowed values | [A-Z0-9]+ |
| Example | Chris McCormack (Q719376) → 44E97D9397CC4B0E915CF89C64C54938 |
| Source | https://www.iat.uni-leipzig.de/datenbanken/dbtriathlon |
| Formatter URL | https://www.iat.uni-leipzig.de/datenbanken/dbtriathlon/daten.php?spid=$1 |
| Robot and gadget jobs | EdgarsBot can import values from Wikipedias |
- Motivation
Institute for Applied Training Science (Q1664800) is large database for triathletes. Database contains detailed statistical information, that is useful for athletes referencing. ID will be used in Template:Sports links (Q22674492). Edgars2007 (talk) 11:39, 12 April 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:33, 12 April 2016 (UTC)
- Support. Thierry Caro (talk) 17:25, 13 April 2016 (UTC)
@Edgars2007: Done Regex restricted to [A-F0-9]+ as I noticed the ID's to be hexadecimals. Lymantria (talk) 12:11, 24 April 2016 (UTC)
IAT weightlifter ID
| Description | identifier for a weightlifter, in the Institut für Angewandte Trainingswissenschaft database |
|---|---|
| Represents | Institute for Applied Training Science (Q1664800) |
| Data type | External identifier |
| Template parameter | de:Vorlage:IATGewichtheberProfil |
| Domain | human (Q5) |
| Allowed values | [A-Z0-9]+ |
| Example | Hossein Rezazadeh (Q374353) → 517BD6D004B9479CB56405ECFE639166 |
| Source | https://www.iat.uni-leipzig.de/datenbanken/dbgwh |
| Formatter URL | https://www.iat.uni-leipzig.de/datenbanken/dbgwh/daten.php?spid=$1 |
| Robot and gadget jobs | EdgarsBot can import values from Wikipedias |
- Motivation
Institute for Applied Training Science (Q1664800) is large database for weightlifters. Database contains detailed statistical information, that is useful for athletes referencing. ID will be used in Template:Sports links (Q22674492). Edgars2007 (talk) 11:39, 12 April 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:33, 12 April 2016 (UTC)
- Support. Thierry Caro (talk) 17:24, 13 April 2016 (UTC)
@Edgars2007: Done Regex restricted to [A-F0-9]+ as I noticed the ID's to be hexadecimals. Lymantria (talk) 12:12, 24 April 2016 (UTC)
- Nice catch (also with triathletes) :) --Edgars2007 (talk) 12:53, 24 April 2016 (UTC)
IAT diver ID
| Description | identifier for a diver, in the Institut für Angewandte Trainingswissenschaft database |
|---|---|
| Represents | Institute for Applied Training Science (Q1664800) |
| Data type | External identifier |
| Template parameter | de:Vorlage:IATWasserspringerProfil |
| Domain | human (Q5) |
| Allowed values | [A-Z0-9]+ |
| Example | Christin Steuer (Q84871) → 104550 |
| Source | https://www.iat.uni-leipzig.de/datenbanken/dbdiving |
| Formatter URL | https://www.iat.uni-leipzig.de/datenbanken/dbdiving/daten.php?spid=$1 |
| Robot and gadget jobs | EdgarsBot can import values from Wikipedias |
- Motivation
Institute for Applied Training Science (Q1664800) is large database for divers. Database contains detailed statistical information, that is useful for athletes referencing. ID will be used in Template:Sports links (Q22674492). Edgars2007 (talk) 11:39, 12 April 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:32, 12 April 2016 (UTC)
- Support. Thierry Caro (talk) 17:23, 13 April 2016 (UTC)
@Edgars2007: Done Regex restricted to \d+ as I noticed the ID's to be just numerals. Lymantria (talk) 12:13, 24 April 2016 (UTC)
- Yes, that's my typo. Thanks for fix. --Edgars2007 (talk) 12:53, 24 April 2016 (UTC)
Models.com client ID
| Description | identifier of a client in models.com |
|---|---|
| Represents | models.com (Q3859883) |
| Data type | External identifier |
| Domain | organization (Q43229) |
| Allowed values | [a-zA-Z]+ |
| Example | |
| Formatter URL | http://models.com/client/$1 |
- Motivation
This property is for client, we have also Models.com person ID (P2471) for people.--Edoardo88 (talk) 10:04, 12 April 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:31, 12 April 2016 (UTC)
- Support. Thierry Caro (talk) 17:00, 13 April 2016 (UTC)
@Edoardo88: Done --Lymantria (talk) 20:53, 24 April 2016 (UTC)
Danish listed buildings case ID
| Description | Listed building complexes in Denmark has a case number that can be URL-resolved, e.g., https://www.kulturarv.dk/fbb/sagvis.pub?sag=4586620 |
|---|---|
| Data type | External identifier |
| Domain | Instances of fixed construction (Q811430) or subclasses. |
| Allowed values | /d+ |
| Example | Baago lighthouse (Q12304760) -> 10831610 |
| Formatter URL | https://www.kulturarv.dk/fbb/sagvis.pub?sag=$1 |
| Robot and gadget jobs | None probably |
- Motivation
An identifier for listed buildings in Denmark will help Danish participation in Wiki Loves Monuments. We have lists created on Wikipedia with the number but it is difficult to update these. A property on Wikidata will help matching of scraped data and continuous update. — Finn Årup Nielsen (fnielsen) (talk) 11:25, 16 April 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:14, 18 April 2016 (UTC)
- Support. Thryduulf (talk: local | en.wp | en.wikt) 12:30, 19 April 2016 (UTC)
@Fnielsen: Done --Lymantria (talk) 06:40, 25 April 2016 (UTC)
this zoological name is coordinate with
| Description | links coordinate zoological names |
|---|---|
| Data type | Item |
| Domain | items on zoological names/taxa, at the rank of superfamily down to subgenus (inclusive) |
| Allowed values | items on zoological names/taxa, at the rank of superfamily down to subgenus (inclusive) |
| Example |
|
| Source | literature |
| Robot and gadget jobs | perhaps |
- Motivation
With the integration of Wikispecies, we are getting lots of new zoological names, especially for lots of subgenera. Under the International Code of Zoological Nomenclature there are sets of names that have "coordinate status": if there is a name MACROGLOSSINAE (subfamily Q134858), then there is automatically also a name MACROGLOSSINI (tribe Q251656), etc (for all possible ranks). Also, if there is a generic name Aedes (Q310911), then there is automatically also a subgeneric name Aedes (Q21440470) (and vice versa). These names with "coordinate status" have the same author, year, place of publication, type, etc. Therefore, it would be convenient to have these items linked, if only to facilitate checking the correctness of data. -- Brya (talk) 11:49, 13 December 2015 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
- Discussion
Support I can support this, am a little wary of the use of the word automatic. By this I mean that under coordination a subgenus Name only exists under genus Name if another subgenus Name2 exists. That is its not automatic in all cases, only when the taxa has been formally subdivided. However once it has yes there must be a coordinated name also. As a suggestion I would recommend that when this is used reference to the paper doing the combination in question is cited. Cheers Faendalimas (talk) 02:10, 15 December 2015 (UTC)
- @Faendalimas:: Art. 43.1: it is automatic ("simultaneously established"). - Brya (talk) 04:30, 15 December 2015 (UTC)
- PS. Pragmatically, the applicability of this is not restricted to cases where a genus is to be split, but also to cases when a taxon is to be raised or lowered in rank. - Brya (talk) 04:51, 15 December 2015 (UTC)
- @Brya: Your misinterpreting Art. 43.1. What it is saying is that the authorship of the sub name is the same as the original name for purposes of nomenclature. For example: Chelidae (Q583074) Gray 1825 and Chelinae (Q2962189) Gray 1825 have the same author and date despite the fact that the subfamily Chelinae was not established until 1893, by G. Baur. The authorship for these names is coordinated. Cheers, Faendalimas (talk) 14:01, 15 December 2015 (UTC)
- @Faendalimas: Sounds like the classic distinction between nomenclature and taxonomy. Nomenclaturally, the publication of the name of a genus creates, "simultaneously", the name of a subgenus. Taxonomically, this name becomes relevant only once somebody actually recognizes a corresponding taxon. For the purposes of Wikidata, this is academic, as a name, by itself, usually will not be "notable" (and a good thing that is, otherwise we would be buried in them). - Brya (talk) 17:47, 15 December 2015 (UTC)
- @Brya: yes see your pont, just remember the name does not exist until a taxonomic decision to create it occurs, so the full citation for Chelinae (Q2962189) is Chelinae (Q2962189) Gray 1825 (sensu Baur, 1893). Like I said it is Baur's 1893 taxonomic decision that created the name Chelinae not Gray's 1825 taxonomic decision to name the family Chelidae. Chelinae is the nominotypical subgenus, the others being the Hydromedusinae and the Chelodininae. Until the three were created, ie the taxonomic act, the nominotypical was not in existence and not needed. Its more accurate to say the name is created posthumously than simultaneously, is my point here. Cheers, Faendalimas (talk) 22:16, 15 December 2015 (UTC)
- @Faendalimas: The Code says "simultaneously". See also the Example to Art. 36.1. - Brya (talk) 06:22, 16 December 2015 (UTC)
- @Brya: yes see your pont, just remember the name does not exist until a taxonomic decision to create it occurs, so the full citation for Chelinae (Q2962189) is Chelinae (Q2962189) Gray 1825 (sensu Baur, 1893). Like I said it is Baur's 1893 taxonomic decision that created the name Chelinae not Gray's 1825 taxonomic decision to name the family Chelidae. Chelinae is the nominotypical subgenus, the others being the Hydromedusinae and the Chelodininae. Until the three were created, ie the taxonomic act, the nominotypical was not in existence and not needed. Its more accurate to say the name is created posthumously than simultaneously, is my point here. Cheers, Faendalimas (talk) 22:16, 15 December 2015 (UTC)
- @Faendalimas: Sounds like the classic distinction between nomenclature and taxonomy. Nomenclaturally, the publication of the name of a genus creates, "simultaneously", the name of a subgenus. Taxonomically, this name becomes relevant only once somebody actually recognizes a corresponding taxon. For the purposes of Wikidata, this is academic, as a name, by itself, usually will not be "notable" (and a good thing that is, otherwise we would be buried in them). - Brya (talk) 17:47, 15 December 2015 (UTC)
- @Brya: Your misinterpreting Art. 43.1. What it is saying is that the authorship of the sub name is the same as the original name for purposes of nomenclature. For example: Chelidae (Q583074) Gray 1825 and Chelinae (Q2962189) Gray 1825 have the same author and date despite the fact that the subfamily Chelinae was not established until 1893, by G. Baur. The authorship for these names is coordinated. Cheers, Faendalimas (talk) 14:01, 15 December 2015 (UTC)
- PS. Pragmatically, the applicability of this is not restricted to cases where a genus is to be split, but also to cases when a taxon is to be raised or lowered in rank. - Brya (talk) 04:51, 15 December 2015 (UTC)
- @Faendalimas:: Art. 43.1: it is automatic ("simultaneously established"). - Brya (talk) 04:30, 15 December 2015 (UTC)
- Support, very good. I think perhaps a species group exmaple should be added. Like Orgyia splendida (Q13963746) (species) <> Orgyia splendida splendida (Q13963759) (subspecies). Lymantria (talk) 15:24, 24 March 2016 (UTC)
- It would be nice if this can be applied to species and subspecies. The issue is that we have items on species (with a two-part name, a binomen) and subspecies (with a three-part name, a trinomen), while what has coordinate status are the species-group names (the second part of a binomen and the third part of a trinomen). There is no exact match.
- Perhaps we might squeeze by, if the use of this property for species-group names is restricted to a placement in the original genus. However, this distinction may not be easy to explain to the average user, and there would still be odd situations where a subspecific name is combined with multiple species names within the original genus (quite asymmetrical).
- Anyway, the immediate problem is with all these subgenera that we have been flooded with. - Brya (talk) 06:46, 25 March 2016 (UTC)
- Perhaps it is good to stretch definition to nominotypical taxa. Lymantria (talk) 08:25, 9 April 2016 (UTC)
- These are already in "taxonomic type" (taxonomic type (P427)). - Brya (talk) 09:06, 9 April 2016 (UTC)
- I never noticed that? To help me understand, how would taxonomic type (P427) be applied to for example Ovis nivicola nivicola (Q20908578) to show that it is a nominotypical subspecies (Q2612266) of snow sheep (Q918400)? Lymantria (talk) 05:27, 12 April 2016 (UTC)
- PS Clearly it doesn't really belong to this suggested property. You may say that this question is out of discussion scope. Lymantria (talk) 13:03, 12 April 2016 (UTC)
- These are already in "taxonomic type" (taxonomic type (P427)). - Brya (talk) 09:06, 9 April 2016 (UTC)
- Perhaps it is good to stretch definition to nominotypical taxa. Lymantria (talk) 08:25, 9 April 2016 (UTC)
- Yes, you are right, my remark was incorrect. The names MACROGLOSSIDAE (family), MACROGLOSSINAE, (subfamily), MACROGLOSSINI (tribe), etc, have coordinate status, while MACROGLOSSINAE is/could be the nominotypical taxon in a family MACROGLOSSIDAE (not accepted, I believe?), MACROGLOSSINI is/could be the nominotypical taxon in a subfamily MACROGLOSSINAE, etc. In the case of Ovis nivicola nivicola, the specific name nivicola and the subspecific name nivicola have coordinate status, while Ovis nivicola nivicola is the nominotypical taxon in the species Ovis nivicola. It is somewhat dubious if a property "nominotypical taxon" would be very helpful, as there will already be a link (parent taxon), so it wouldn't really improve interconnectedness. But, indeed, this looks out of scope. - Brya (talk) 17:00, 12 April 2016 (UTC)
@Brya, Faendalimas: Done Lymantria (talk) 11:56, 16 April 2016 (UTC)
- Thank you! This is something of a relief. - Brya (talk) 13:43, 16 April 2016 (UTC)
NZOR ID
| Description | identifier for a taxon name, in the New Zealand Organisms Register |
|---|---|
| Data type | External identifier |
| Domain | taxon (Q16521) |
| Example | Brachyglottis bidwillii (Q4953437) -> 799a26fa-5c77-48a1-ab41-7661b7df996a |
| Source | http://www.nzor.org.nz/ |
| Formatter URL | http://www.nzor.org.nz/names/$1 |
- Motivation
Important database of taxon names, with rich matadata. Values will be added to Wikidata at an upcoming editathon. Ambrosia10 (talk) 18:16, 13 April 2016 (UTC)
- Discussion
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Succu (talk) 21:21, 13 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:19, 13 April 2016 (UTC)
- Why not Support. Is based on taxon concepts and has a Web Service. --Succu (talk) 19:44, 13 April 2016 (UTC)
- Support Looks good to me. --Daniel Mietchen (talk) 21:25, 13 April 2016 (UTC)
@Ambrosia10, Succu: Done and regex added. --Lymantria (talk) 19:44, 20 April 2016 (UTC)
AUSNUT Food Identifier
| Description | Identifier of a food within the Australian Food, Supplement and Nutrient Database (AUSNUT) which is managed by Food Standards Australia New Zealand (FSANZ) |
|---|---|
| Represents | food (Q2095) |
| Data type | External identifier |
| Template parameter | No infobox parameter is known to exist at present, however a new parameter could be added to en:template:nutritional value (or another infobox) |
| Domain | food (Q2095) |
| Allowed values | string pattern: \d{2}[A-Z]\d{5} |
| Example | kangaroo meat (Q1795395) → 08B10068 |
| Source | AUSNUT 2011-13 food nutrient database |
| Robot and gadget jobs | Suggest that this database be included into mix-and-match similar to the existing NDB mix-and-match |
- Motivation
This property request is similar to existing property USDA NDB number (P1978) where an American database USDA National Nutrient Database (Q7866379) is linked to foods on Wikidata. The AUSNUT database is Australian and New Zealand specific and includes foods which are more common to Australian and New Zealand populations (for example, kangaroo meat (Q1795395)). AUSNUT 2011‒13 is a set of files that enables food, dietary supplement and nutrient intake estimates to be made from the 2011‒13 Australian Health Survey (AHS). It was first published in May 2014 and included data related to the National Nutrition and Physical Activity Survey (NNPAS) component of the AHS only. It was updated in September 2014 to include additional data related to the National Aboriginal and Torres Strait Islander Nutrition and Physical Activity Survey component of the AHS. This in an authoritative source of nutritional information for foods, and addition of this property to Wikidata will further enhance understanding of nutrition and foods via the ability to link AUSNUT to Wikidata items. Dhx1 (talk) 14:36, 22 November 2015 (UTC)
- Discussion
- Support Interesting information. Will be useful to Open Food Facts, which is also linked to Wikidata. --Teolemon (talk) 12:35, 11 February 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:51, 24 March 2016 (UTC)
@Dhx1: Done --Lymantria (talk) 07:05, 21 April 2016 (UTC)
NUTTAB Food Identifier
| Description | Identifier of a food within the Nutrient Tables for use in Australia (NUTTAB) which is managed by Food Standards Australia New Zealand (FSANZ) |
|---|---|
| Represents | food (Q2095) |
| Data type | External identifier |
| Template parameter | No infobox parameter is known to exist at present, however a new parameter could be added to en:template:nutritional value (or another infobox) |
| Domain | food (Q2095) |
| Allowed values | string pattern: \d{2}[A-Z]\d{5} |
| Example | lemon juice (Q1375049) → 01B30288 |
| Source | NUTTAB 2010 |
| Formatter URL | http://archive.foodstandards.gov.au/consumerinformation/nuttab2010/nuttab2010onlinesearchabledatabase/onlineversion_code.cfm?&action=getFood&foodID=$1 |
| Robot and gadget jobs | Suggest that this database be included into mix-and-match similar to the existing NDB mix-and-match |
- Motivation
This property request is similar to existing property USDA NDB number (P1978) where an American database USDA National Nutrient Database (Q7866379) is linked to foods on Wikidata. The NUTTAB database is Australian and New Zealand specific and includes foods which are more common to Australian and New Zealand populations (for example, indigenous foods from flora endemic to Australia). NUTTAB (NUTrient TABles for use in Australia) is Australia’s reference nutrient database. NUTTAB 2010 contains nutrient data for 2668 foods available in Australia and up to 245 nutrients per food. The nutrients reported in NUTTAB will vary between foods, according to the data currently available to FSANZ. This in an authoritative source of nutritional information for foods, and addition of this property to Wikidata will further enhance understanding of nutrition and foods via the ability to link NUTTAB to Wikidata items.
Note: this identifier is essentially the same as the AUSNUT Food Identifier, except that some identifiers exist in NUTTAB and not AUSNUT, whilst other identifiers exist in AUSNUT but not NUTTUB. An alternative to having two properties (one each for AUSNUT and NUTTAB) would be to define a generic "FSANZ Food Identifier" and then set a boolean qualifier for each use of the property as to whether it is listed in NUTTAB or AUSNUT. Dhx1 (talk) 15:12, 22 November 2015 (UTC)
- Discussion
- Support Interesting information. Will be useful to Open Food Facts, which is also linked to Wikidata. --Teolemon (talk) 12:35, 11 February 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:56, 24 March 2016 (UTC)
@Dhx1: Done Kept two seperate properties, as there apparently is no urge by users to do otherwise. Lymantria (talk) 07:35, 21 April 2016 (UTC)
Australian Geological Provinces Database Entity ID
| Description | Unique identifier of a geologic province in the Australian Geological Provinces Database published by Geoscience Australia (government agency responsible for geological mapping) |
|---|---|
| Represents | geologic province (Q2140450) |
| Data type | External identifier |
| Template parameter | None known to exist, however this property would be suitable to add to a new or existing infobox |
| Domain | geologic province (Q2140450) shield (Q852013), platform (Q666258), orogeny (Q184554), structural basin (Q749565), large igneous province (Q792425), crust (Q16760598), perhaps others more specific (subclasses) |
| Allowed values | string format: \d+ |
| Example | Amadeus Basin (Q451785) → 22078 |
| Source | Australian Geological Provinces Database and Australian Geological Provinces (front page describing the database) |
| Formatter URL | http://www.ga.gov.au/provexplorer/provinceDetails.do?eno=$1 |
| Robot and gadget jobs | I can scrape database entries from the Australian Geological Provinces Database (all results) and add them to mix-and-match. Most have Wikipedia articles with matching names, so it'll be easy. |
- Motivation
Existing property Australian Stratigraphic Units Database ID (P2367) is an identifier for stratigraphic units in the Australian Stratigraphic Units Database also produced by Geoscience Australia. By adding this property to Wikidata, further context is provided for which geologic province each stratigraphic unit is contained within. A large number of provinces within this database have existing Wikipedia (English) articles and thus this property will assist these articles with inclusion of lists of stratigraphic units for each province. Dhx1 (talk) 10:28, 1 December 2015 (UTC)
- Discussion
- Support Useful addition. Lymantria (talk) 05:19, 12 April 2016 (UTC)
- Comment Shouldn't the datatype be external identifier? - Brya (talk) 05:37, 12 April 2016 (UTC)
- It should (copy edited). Clearly this is a long standing proposal (too long IMHO). Lymantria (talk) 13:05, 12 April 2016 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 12 April 2016 (UTC)
@Dhx1: Done --Lymantria (talk) 14:35, 14 April 2016 (UTC)
salinity
| Description | salinity of a body of water |
|---|---|
| Represents | salinity (Q179615) |
| Data type | Number (not available yet) |
| Template parameter | ? |
| Domain | bodies of water |
| Allowed values | non-negative numbers with units of concentration, e.g grams per litre (g/L) |
| Example | Salton Sea (Q503301) → 44 grams per litre; Pacific Ocean (Q98) → 35 g/L; Great Salt Lake (Q178741) → 50 g/L (qualifier: maximum (Q10578722)), 70 g/L (qualifier: minimum (Q10585806)); |
| Source | external reference, Wikipedia list article, etc. |
- Motivation
I discovered this apparently missing when improving the Salton Sea (Q503301) entry, en:Salton Sea makes a big deal about the salinity of the lake. Thryduulf (talk: local | en.wp | en.wikt) 01:02, 12 November 2015 (UTC)
- Discussion
- Support But needs qualifiers like 'average', 'surface water' or numeric qualifiers 'at depth: 10 m below surface', etc... - Large bodies of water are usually layered in their physico-chemical properties so we really need to make it clear where salinity was measured. --Tobias1984 (talk) 11:03, 29 November 2015 (UTC)
- We have and already, although qualifiers "measurement taken at location" (item) and "measurement taken at point" (number with unit) would be possibly better. Thryduulf (talk: local | en.wp | en.wikt) 02:18, 3 December 2015 (UTC)
- Oppose. These situations should use a generic property to indicate the makeup of the body of water, instead of having one for salt and one for each other substance. --Yair rand (talk) 06:55, 16 December 2015 (UTC)
- @Yair rand: which property do you propose to use for that? Which other substances do you forsee that property being used for? Thryduulf (talk: local | en.wp | en.wikt) 00:44, 17 December 2015 (UTC)
- @Thryduulf: Use has part(s) (P527), with proportion (P1107) as a qualifier. P1107 was proposed with material composition as an explicit example: "Earth atmosphere is composed of 80% dinitrogen and 20% dioxygen". --Yair rand (talk) 02:28, 17 December 2015 (UTC)
- That doesn't seem like it is capable of expressing the qualifiers Tobias1984 talks about. has part(s) (P527) is a very blunt instrument - e.g. and are very different uses of the same properties and are not easy to parse separately. Thryduulf (talk: local | en.wp | en.wikt) 02:58, 17 December 2015 (UTC)
- I agree that this isn't as specific as it should be (see further discussion here), but it's still generally usable. In a little project that I'm working on, I distinguish between the first and second kinds by checking whether the target has any
wdt:P279|^wdt:P279|^wdt:P31values. Regarding extra qualifiers for applying the statement proportions to a particular altitude, I'm not sure what properties should be used. --Yair rand (talk) 03:22, 17 December 2015 (UTC)- My reading of that discussion seems to contradict your assertion that subclass of (P279) is usable - we need to be more specific about the nature of parts not increasing the overloading of subclass of (P279). Requiring checks as your project does will not scale as it requires knowing all classes of items that are/may be noted as being a part of the class you are interrogating and determining what properties those class of items you are interested in all have have that none of the others classes of items do (or vice versa). Requiring two or three levels of interrogation and processing before you can interrogate seems a rather inefficient alternative to a simple specific property with relevant qualifiers. Thryduulf (talk: local | en.wp | en.wikt) 21:49, 19 December 2015 (UTC)
- I agree that this isn't as specific as it should be (see further discussion here), but it's still generally usable. In a little project that I'm working on, I distinguish between the first and second kinds by checking whether the target has any
- That doesn't seem like it is capable of expressing the qualifiers Tobias1984 talks about. has part(s) (P527) is a very blunt instrument - e.g. and are very different uses of the same properties and are not easy to parse separately. Thryduulf (talk: local | en.wp | en.wikt) 02:58, 17 December 2015 (UTC)
- @Thryduulf: Use has part(s) (P527), with proportion (P1107) as a qualifier. P1107 was proposed with material composition as an explicit example: "Earth atmosphere is composed of 80% dinitrogen and 20% dioxygen". --Yair rand (talk) 02:28, 17 December 2015 (UTC)
- @Yair rand: which property do you propose to use for that? Which other substances do you forsee that property being used for? Thryduulf (talk: local | en.wp | en.wikt) 00:44, 17 December 2015 (UTC)
- Oppose Use has part(s) (P527) = table salt (Q11254), qualified with proportion (P1107), per Yair rand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:55, 7 March 2016 (UTC)
- Oppose This is not the good solution: we should think about a property composition. A general one which can be used foe sea water or cheese or other description of mixture. Snipre (talk) 19:29, 27 March 2016 (UTC)
Not done Unsufficient support. Lymantria (talk) 05:24, 22 April 2016 (UTC)
characterizes/property of
| Description | This type of mathematical objet or properties is associated to that type of mathematical objects |
|---|---|
| Represents | admissible rule (Q1560157) |
| Data type | Item |
| Domain | rule of inference (Q1068763)   |
| Allowed values | instances of logic (Q8078) |
| Example | |
| Proposed by | author TomT0m / talk page 16:33, 10 March 2016 (UTC) |
- motivations
- motivated by the example. Hard to add any statement to this kind of objects. author TomT0m / talk page 16:33, 10 March 2016 (UTC)
Notified participants of WikiProject Mathematics
- Oppose This can be accomplished with the inverse property, has characteristic (P1552). Swpb (talk) 18:14, 31 March 2016 (UTC)
Not done Unsufficient support. Lymantria (talk) 05:26, 22 April 2016 (UTC)
ISO 4063 process number
| Description | Identifier for a process, in the ISO-approved classification scheme for welding & soldering processes |
|---|---|
| Represents | ISO 4063 (Q22443162) |
| Data type | External identifier |
| Template parameter | Infobox lastechniek: procesnummer (ISO 4063) |
| Domain | Technical processes |
| Example | shielded metal arc welding (Q1992360) → 111 |
| Source | Official document, Complete Table, (en/de/fr) |
- Motivation
ISO-approved classification scheme for welding & soldering processes.--Kopiersperre (talk) 15:02, 2 February 2016 (UTC)
- Discussion
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:52, 24 March 2016 (UTC)
@Kopiersperre: Done --Lymantria (talk) 05:38, 22 April 2016 (UTC)
scheduled services days
| Description | days the public transportation line is operated |
|---|---|
| Data type | Item |
| Template parameter | not in infobox, but could replace Modèle:Jour de fonctionnement in frwiki |
| Domain | public transportation lines |
| Allowed values | to define, but (subclass of (P279) of day of the week (Q41825) or holiday (Q1445650)) is a basis |
| Example | Line 6 (Q18535041) → Monday to Saturday (Q21282379) |
| Source | timetables |
- Motivation
Would be useful to specify the days of the week a public transportation operates. Could be useful maybe for other domains. I don't know how to deal with holidays... Kvardek du (talk) 00:19, 31 October 2015 (UTC)
- Discussion
- Comment I think this requires wider discussion, around the operating/opening days - and hours - of things like shops and visitor attractions, too. Further, I'm not convinced that items are the best way to represent this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:45, 23 November 2015 (UTC)
- @Pigsonthewing: sure. Where could we talk about this ? Kvardek du (talk) 21:51, 27 November 2015 (UTC)
- Kvardek du Wikivoyage may have more on this as they are interested in this kind of info. I found Template:Opening hours (Q19544821). As well as days of the week this records hours of the day. I think that we need "opening time", "closing time" qualifiers with this property to record these.
- I also found http://wiki.openstreetmap.org/wiki/Key:opening_hours/specification and Key:opening_hoursbut I'm not sure how much of that is reusable They do point out that "closing time" might be "sunset" which is a strong argument for item type for closing time.
- Seasonal attractions, including tourist railways need opening days and closing days but I think separate properties will be needed for those
- I disagree with Andy about items. We have an item for every day of the year from January 1 (Q2150) to December 31 (Q2912). I think we can make items work here.
- Joe Filceolaire (talk) 15:32, 28 November 2015 (UTC)
Not done Lack of support.--Micru (talk) 14:45, 27 February 2016 (UTC)
longest span
| Description | length of the longest span of a bridge |
|---|---|
| Represents | span (Q1960395) |
| Data type | Number (not available yet) |
| Template parameter | "mainspan" in en:Template:Infobox bridge |
| Domain | instances of bridge (Q12280) and subclasses |
| Allowed values | positive numbers with units of length |
| Example | Peace Bridge (Q1188691) → 130 metre (Q11573); Second Severn Crossing (Q1287969) → 456 metre (Q11573); Pont du Diable (Q1514576) → 45.45 metre (Q11573) |
| Source | external reference, Wikipedia list article, etc. |
| Robot and gadget jobs | import from infoboxes |
- Motivation
We have properties for number of spans, and overall length, but no way of expressing the length of the longest span that I can find. Thryduulf (talk: local | en.wp | en.wikt) 02:50, 12 November 2015 (UTC)
- Discussion
- Support - clearly significant for bridges. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:57, 23 November 2015 (UTC)
- Comment It might be better to solve this one using has part(s) (P527) > main span then length (P2043) as a qualifier. Otherwise we will find ourselves creating a vast number of length-type properties for parts. Danrok (talk) 13:38, 26 November 2015 (UTC)
- @Thryduulf: Does this suggestion work for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:31, 8 January 2016 (UTC)
- It would work, but my feeling is that it would be harder to query and thus less useful - but that might just be my prejudice for specific properties for the most significant aspects of subjects and using qualifiers for the less ones. Thryduulf (talk: local | en.wp | en.wikt) 21:00, 9 January 2016 (UTC)
- @Pigsonthewing, Danrok: any further comments? Thryduulf (talk: local | en.wp | en.wikt) 13:50, 25 February 2016 (UTC)
- It would work, but my feeling is that it would be harder to query and thus less useful - but that might just be my prejudice for specific properties for the most significant aspects of subjects and using qualifiers for the less ones. Thryduulf (talk: local | en.wp | en.wikt) 21:00, 9 January 2016 (UTC)
- @Thryduulf: Does this suggestion work for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:31, 8 January 2016 (UTC)
- Support per proposer. If we already have number of spans (P1314) (length (P2043), height (P2048) and width (P2049)), the proposed has part(s) (P527) solution sounds too complicated for me.--Jklamo (talk) 14:30, 20 March 2016 (UTC)
@Thryduulf, Jklamo: Done --Lymantria (talk) 14:50, 27 April 2016 (UTC)
clearance
| Description | distance between surface and bottom of a bridge deck |
|---|---|
| Represents | air draft (Q3142285) |
| Data type | Number (not available yet) |
| Template parameter | "clearance_below" in en:Template:Infobox bridge |
| Domain | crossings (e.g. bridges, power lines) |
| Allowed values | positive numbers with units of distance |
| Example | Second Severn Crossing (Q1287969) → 37 metre (Q11573); Millau Viaduct (Q99236) → 270 metre (Q11573) |
| Source | external reference, Wikipedia list article, etc. |
| Robot and gadget jobs | import from infoboxes |
- Motivation
This is a key design feature of bridges over navigable routes, particularly navigable waterways. Thryduulf (talk: local | en.wp | en.wikt) 03:59, 12 November 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 18:00, 12 November 2015 (UTC)
- Support Would also make sense to have an air draft property for ships. Danrok (talk) 13:32, 26 November 2015 (UTC)
Question Can we just make this one property for air draft? If so, I would Support it. Josh Baumgartner (talk) 17:23, 8 January 2016 (UTC)
- @Joshnaumgartner: Maybe. This represents the space between the water and the bottom of the bridge deck, a maximum available distance. Air draft represents the space between the water and the top of a ship, a minimum required distance. Although the two are clearly conceptually related and could be represented by a single property in English I don't know that this will hold true for other languages. If it can represent both, then I'm happy to generalise this. Thryduulf (talk: local | en.wp | en.wikt) 21:20, 9 January 2016 (UTC)
- @Joshbaumgartner, Danrok: any thoughts? Thryduulf (talk: local | en.wp | en.wikt) 19:20, 28 February 2016 (UTC)
- Between the label, aliases, and description, I'm sure that language variances can be handled. There are few properties that don't have this issue in at least some languages. Josh Baumgartner (talk) 19:33, 8 March 2016 (UTC)
- @Joshnaumgartner: Maybe. This represents the space between the water and the bottom of the bridge deck, a maximum available distance. Air draft represents the space between the water and the top of a ship, a minimum required distance. Although the two are clearly conceptually related and could be represented by a single property in English I don't know that this will hold true for other languages. If it can represent both, then I'm happy to generalise this. Thryduulf (talk: local | en.wp | en.wikt) 21:20, 9 January 2016 (UTC)
- I think this property should just be for clearance below a bridge. Danrok (talk) 21:12, 11 March 2016 (UTC)
@Thryduulf, Danrok, Joshbaumgartner: Done Domain (for now) restricted to bridges. Lymantria (talk) 14:13, 29 April 2016 (UTC)
aerodrome reference point
| Description | official coordinates for airport |
|---|---|
| Represents | aerodrome reference point (Q365873) |
| Data type | Geographic coordinates |
| Template parameter | e.g. de:Infobox Flughafen and similar infoboxes in many Wikipedias |
| Domain | aerodrome (Q62447) |
| Example | Munich Airport (Q131402) → N 48° 21' 13.62" E 011° 47' 09.91" |
- Motivation
The aerodrome reference point (ARP) (aerodrome reference point (Q365873)) is the "official" coordinate of an airport, defined in a country's Aeronautical Information Publication (Q1541065). This is a sub-property of coordinate location (P625). Currently coordinate location (P625) sometimes references the ARP, sometimes it doesn't. Different Wikipedias use different coordinates. Therefore it is useful to know, whether this is an official coordinate or just "some" coordinate taken from a map, especially since not every airfield has an ARP. An alternative would be to document ARPs using a P794 (P794) qualifier, nevertheless I think a specialized sub-property is easier to use - both when creating and when querying - and has a higher chance to be discovered and be used consistently. --Srittau (talk) 17:36, 11 January 2016 (UTC)
- Discussion
- Support This is a very specific and controlled point. Josh Baumgartner (talk) 19:34, 8 March 2016 (UTC)
- Oppose. Just use qualifiers. Thierry Caro (talk) 19:53, 19 March 2016 (UTC)
- @Thierry Caro: which property are you proposing should be used, and with which qualifiers? Thryduulf (talk: local | en.wp | en.wikt) 21:44, 19 March 2016 (UTC)
- coordinate location (P625) with qualifier applies to part (P518) → aerodrome reference point (Q365873). Thierry Caro (talk) 21:48, 19 March 2016 (UTC)
- Using applies to part (P518) seems fairly contrived to me. The ARP is not really a "part" of an aerodrome. The reason I prefer a separate property for this is for easier querying and because of its well-defined nature (as opposed to the general coordinate location (P625)). --Srittau (talk) 00:10, 20 March 2016 (UTC)
- coordinate location (P625) with qualifier applies to part (P518) → aerodrome reference point (Q365873). Thierry Caro (talk) 21:48, 19 March 2016 (UTC)
- @Thierry Caro: which property are you proposing should be used, and with which qualifiers? Thryduulf (talk: local | en.wp | en.wikt) 21:44, 19 March 2016 (UTC)
@Srittau, Joshbaumgartner: Done --Lymantria (talk) 13:23, 27 April 2016 (UTC)
net tonnage
| Description | dimensionless index calculated from the total moulded volume of the ship's cargo spaces by using a mathematical formula |
|---|---|
| Represents | net tonnage (Q1781855) |
| Data type | Number (not available yet) |
| Template parameter | "tonnage" in en:template:infobox ship characteristics (Note other tonnages may be listed here, not only NT) |
| Domain | cargo ships |
| Example | MT Mastera (Q1325547) → 30846 |
| Source | Books, ship registers, ship operator's websites, etc. |
| Robot and gadget jobs | No. |
- Motivation
Useful property which gives an indication of how much cargo a ship can carry. Property is defined by the IMO as an international standard. Danrok (talk) 15:33, 27 November 2015 (UTC)
- Discussion
- Support as proposed. Thryduulf (talk: local | en.wp | en.wikt) 19:22, 28 February 2016 (UTC)
@Danrok, Thryduulf: Done --Lymantria (talk) 21:06, 27 April 2016 (UTC)
Maximum gradient
| Template parameter | w:de:Template:BS-daten, parameter "NEIGUNG" |
|---|---|
| Domain | itinerary (Q2450078) |
| Allowed values | 0-100 (percent) or positive numbers for 1 in n |
| Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
| Source | Wikipedia articles, external references |
| Robot and gadget jobs | Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.) |
- Motivation
This is a key property for funicular railways. I'm not sure which units are best for this though? Thryduulf (talk: local | en.wp | en.wikt) 23:13, 12 September 2015 (UTC)
- Discussion
- I guess "for funicular railways" is not meant as a restriction and it should be usable on all railway track items, right? For the datatype, I'd say number with whatever makes it to be like meter and miles (percent and ratio here). --Nenntmichruhigip (talk) 10:32, 14 September 2015 (UTC)
- Indeed, it can be used for any railway. Or anything with a gradient thinking about it, e.g. roads, race tracks, footpaths, ski slopes, etc. Ditto for average gradient below. I'll bow to those with more understanding of data types for how best to represent it in the database. Thryduulf (talk: local | en.wp | en.wikt) 11:13, 14 September 2015 (UTC)
- Comment @Thryduulf: Domain can be broader (itinerary (Q2450078)) to account for all types of routes. I am not sure that allowing both ratio and percentage notation work. For example, would an entry of '5' mean 1 in 5 or 5%? The number datatype is fine, but would have to be expressed as one or the other (description should include 'expressed as the consequent element of a 1-in-n ratio' or 'expressed as a percentage'). Josh Baumgartner (talk) 22:44, 14 September 2015 (UTC)
- I've changed the domain per your suggestion. Regarding the units, my use of "or" was intended as exclusive rather than "and/or" as I doubt that's possible without two properties (gradient as a ratio; gradient as a percentage) which I don't think is necessary? Thryduulf (talk: local | en.wp | en.wikt) 00:04, 15 September 2015 (UTC)
- Isn't this exactly what the new number datatype with units is meant for? --Nenntmichruhigip (talk) 09:44, 15 September 2015 (UTC)
- Sorry I don't understand? Thryduulf (talk: local | en.wp | en.wikt) 12:31, 15 September 2015 (UTC)
- For example height (Property:P2048) can be in different units (meter, millimeter, miles, …), so I assume it's possible that this property can be in ratio, percent, promille, etc --Nenntmichruhigip (talk) 13:44, 15 September 2015 (UTC)
- Ah yeah. I don't know how you'd express that for the ratio though. "Units 1:"? "units ratio"? Thryduulf (talk: local | en.wp | en.wikt) 14:47, 15 September 2015 (UTC)
- I don't know either, but I guess whoever is able to create properties knows and will hopefully tell us until it's created :-) --Nenntmichruhigip (talk) 16:03, 15 September 2015 (UTC)
- Unfortunately, "1:n" or "ration" are not units so it wouldn't be good to use them with the quantity with units datatype. Josh Baumgartner (talk) 17:10, 15 September 2015 (UTC)
- Could you (beeing a 'propertycreator') elaborate how it's different? --Nenntmichruhigip (talk) 17:57, 15 September 2015 (UTC)
- @Nenntmichruhigip: As I understand it, "1:5" is an expression (resulting in the number 0.2), not a unit. Strictly speaking the same is true for %, but we can make it work if we to make a new item "%", because currently you have the choice of "10 percentage" or "10 percent sign", neither of which seem like what we would want. Josh Baumgartner (talk) 04:24, 16 September 2015 (UTC)
- @Lydia Pintscher (WMDE): Seems to me like this might require a change in the software? --Nenntmichruhigip (talk) 16:48, 28 September 2015 (UTC)
- Hmmm for a ratio like that I would probably use string instead. --Lydia Pintscher (WMDE) (talk) 21:41, 28 September 2015 (UTC)
- But that wouldn't allow for it beeing displayed as percent or promille (or ratio as float, though it don't think this is used for gradients anywhere, but in other cases) --Nenntmichruhigip (talk) 20:04, 29 September 2015 (UTC)
- If there isn't a suitable type of unit to use, we could simply label it "average gradient as a percentage"/"maximum gradient as a percentage" and use a number without units. We could then also have separate properties (if desired) for ratios along the lines of scale (P1752). Thryduulf (talk: local | en.wp | en.wikt) 19:47, 3 October 2015 (UTC)
- But that wouldn't allow for it beeing displayed as percent or promille (or ratio as float, though it don't think this is used for gradients anywhere, but in other cases) --Nenntmichruhigip (talk) 20:04, 29 September 2015 (UTC)
- Hmmm for a ratio like that I would probably use string instead. --Lydia Pintscher (WMDE) (talk) 21:41, 28 September 2015 (UTC)
- @Lydia Pintscher (WMDE): Seems to me like this might require a change in the software? --Nenntmichruhigip (talk) 16:48, 28 September 2015 (UTC)
- @Nenntmichruhigip: As I understand it, "1:5" is an expression (resulting in the number 0.2), not a unit. Strictly speaking the same is true for %, but we can make it work if we to make a new item "%", because currently you have the choice of "10 percentage" or "10 percent sign", neither of which seem like what we would want. Josh Baumgartner (talk) 04:24, 16 September 2015 (UTC)
- Could you (beeing a 'propertycreator') elaborate how it's different? --Nenntmichruhigip (talk) 17:57, 15 September 2015 (UTC)
- Ah yeah. I don't know how you'd express that for the ratio though. "Units 1:"? "units ratio"? Thryduulf (talk: local | en.wp | en.wikt) 14:47, 15 September 2015 (UTC)
- For example height (Property:P2048) can be in different units (meter, millimeter, miles, …), so I assume it's possible that this property can be in ratio, percent, promille, etc --Nenntmichruhigip (talk) 13:44, 15 September 2015 (UTC)
- Sorry I don't understand? Thryduulf (talk: local | en.wp | en.wikt) 12:31, 15 September 2015 (UTC)
- Isn't this exactly what the new number datatype with units is meant for? --Nenntmichruhigip (talk) 09:44, 15 September 2015 (UTC)
- I've changed the domain per your suggestion. Regarding the units, my use of "or" was intended as exclusive rather than "and/or" as I doubt that's possible without two properties (gradient as a ratio; gradient as a percentage) which I don't think is necessary? Thryduulf (talk: local | en.wp | en.wikt) 00:04, 15 September 2015 (UTC)
- Support but I would say the unit should always be % and the datatype should be 'quantity with units=%'. Joe Filceolaire (talk) 22:54, 14 September 2015 (UTC)
- Support with caveat that it is always %. Josh Baumgartner (talk) 17:10, 15 September 2015 (UTC)
- Oppose wrong datetype (use number without unit instead), oppose label: create generic gradient instead. --- Jura 22:28, 28 September 2015 (UTC)
- There may be a need for a generic gradient as well, but average gradient and maximum gradient are very different things to each other and need to be expressed separately. Thryduulf (talk: local | en.wp | en.wikt) 00:45, 29 September 2015 (UTC)
- You can add two statements with the same property. --- Jura 07:23, 29 September 2015 (UTC)
- If an item has both it could be inferred that the steeper value is the maximum and the slighter the average (at least by a human who knows that this is what two entries signifies), but many items would only have one gradient and there would not be a way to tell whether a single value was the maximum gradient or the average gradient. Thryduulf (talk: local | en.wp | en.wikt) 18:48, 30 September 2015 (UTC)
- I support having a generic "Average gradient" property for use with roads, railways and anything else and a separate "Maximum Gradient" property for use with the same. Joe Filceolaire (talk) 14:53, 7 October 2015 (UTC)
- If an item has both it could be inferred that the steeper value is the maximum and the slighter the average (at least by a human who knows that this is what two entries signifies), but many items would only have one gradient and there would not be a way to tell whether a single value was the maximum gradient or the average gradient. Thryduulf (talk: local | en.wp | en.wikt) 18:48, 30 September 2015 (UTC)
- You can add two statements with the same property. --- Jura 07:23, 29 September 2015 (UTC)
- There may be a need for a generic gradient as well, but average gradient and maximum gradient are very different things to each other and need to be expressed separately. Thryduulf (talk: local | en.wp | en.wikt) 00:45, 29 September 2015 (UTC)
- Support if expressed as a percentage. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:36, 8 October 2015 (UTC)
- Comment I've updated this to use the type "number" (without unit) and the description to note that it is to be expressed as a percentage. The same should apply to Average gradient too of course. Thryduulf (talk: local | en.wp | en.wikt) 15:08, 10 October 2015 (UTC)
- average gradient (P2198) proposed along with this one was created months ago, and I think all objections have been answered. If there are no further comments in about a week I'll mark it as ready. @Pigsonthewing, Jura1, Nenntmichruhigip, Lydia Pintscher (WMDE), Joshbaumgartner:. Thryduulf (talk: local | en.wp | en.wikt) 13:49, 25 February 2016 (UTC)
- I'm still on the oppinion that this should be in some way to be displayed in different formats (like we're not forcing every length to be in meters, instead of i.e. kilometers), but as apparently this isn't really possible yet and average gradient exists already anyway, I'm fine with this beeing created as well. --Nenntmichruhigip (talk) 07:44, 26 February 2016 (UTC)
@Thryduulf, Joshbaumgartner, Nenntmichruhigip: Done maximum gradient (P2595). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:37, 7 March 2016 (UTC)
Railway electrification system
| Description | Voltage, and frequency |
|---|---|
| Data type | String |
| Template parameter | Electrification |
| Domain | railways (including metro lines) |
| Allowed values | several values, the most usual ones are "3000 V DC", "1500 V DC", "15000 V 16.67 Hz", "25000 V 50Hz" (electricification systems used for major railways in europe) |
| Example 1 | MISSING |
| Example 2 | MISSING |
| Example 3 | MISSING |
| Source | en:Railway electrification system |
I'm documenting railways. There is a property named "railway electricification system to state how the current is brought to the train (overhead lines, thrid rail), but none to state what is the type of current used : DC or AC, voltage value Raminagrobis (talk) 20:18, 25 October 2015 (UTC)
- Discussion
- Oppose, this needs two or three properties (voltage, frequency & current-type), not one - I'd be happy to support then. [Note: I changed the datatype from "two physical data : voltage and frequency" (which is not valid) to "string". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:26, 25 October 2015 (UTC)
- Support. Raminagrobis Andy Mabbett I think the datatype should be 'item' to identify the electrification system used. The items for each system would then need claims for the voltage, frequency, power transfer (overhead line, third rail, fourth rail etc.), invented by etc. Joe Filceolaire (talk) 22:49, 25 October 2015 (UTC) Oppose Use type of electrification (P930) per discussion below. Joe Filceolaire (talk) 15:38, 28 November 2015 (UTC)
- Oppose using string datatype, this affects units which is blocked by phab:T77977. --Liuxinyu970226 (talk) 07:01, 26 October 2015 (UTC)
- Support proposal by user:Filceolaire for an item-valued property, that would point to items from a class of different electrification systems used in the world.
- Oppose use type of electrification (P930) with more specific values, eg 25 kV AC railway electrification (Q1412243), 15 kV, 16.7 Hz AC railway electrification (Q1415234), and further additional items as needed. Jheald (talk) 14:14, 28 October 2015 (UTC)
- Support agred for item values, as there is only a small number of systems in the world. In Europe there are 5 systems : see [2]. Besides the items exist : see Q1415234, Q1412243... --Raminagrobis (talk) 12:25, 26 October 2015 (UTC)
- Support item values. There are a few more than 5 in Europe, see w:Volks Electric Railway for example, but these can easily have items created if they don't currently exist. Thryduulf (talk: local | en.wp | en.wikt) 12:46, 26 October 2015 (UTC)
- Oppose Existing type of electrification (P930) property is sufficient to link to the electrification system. Per Andy, details on the electrification system should be added to the linked item:
- We do need a voltage property, which as far as I know is not through the property creation process. Also, the type of electrification (P930) property could use some clean-up to make it more useful. Josh Baumgartner (talk) 17:31, 27 October 2015 (UTC)
- Sorted to transportation. Josh Baumgartner (talk) 17:32, 27 October 2015 (UTC)
- Oppose type of electrification (P930) exists and is far superior to a string. If a system is missing as an object, add it. --Srittau (talk) 21:34, 7 March 2016 (UTC)
- Not done no consensus --Pasleim (talk) 13:01, 23 March 2016 (UTC)
United Nations Code for Trade and Transport Locations (UN/LOCODE)
| Description | Unique code for Location |
|---|---|
| Represents | UN/LOCODE (Q499348) |
| Data type | String |
| Template parameter | UN/LOCODE |
| Domain | Q253019, Q486972, Q262166 |
| Allowed values | Two character country code (ISO 3166-1 Alpha 2), space, three alphanumeric characters for location (DE BXJ for Sankt Andreasberg) |
| Example | Sankt Andreasberg (Q661700) → DE BXJ |
| Source | http://www.unece.org/cefact/locode/service/location.html |
- Motivation
Property is relevant for international trade Ogmios (Tratsch) 19:20, 28 November 2015 (UTC)
- Discussion
Not done - UN/LOCODE (P1937) already exists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:25, 7 March 2016 (UTC)
connects
| Description | street X <connects> street Y |
|---|---|
| Data type | Item |
| Domain | streets, squares, roads |
| Example |
- Motivation
The property shares border with (P47) is currently used for connecting streets. However, P47 should only be used for administrative area's. Therefore we need a better fitting property to state that a certain street is connected with another street. Michiel1972 (talk) 10:29, 9 December 2015 (UTC)
- Discussion
- Comment I've added some examples, but using an item datatype not a string. A better English description might be "has junction with" if the intention is only to use it with routes (it could also be productively used with canals and railway lines). This has the potential to contain a massive number of statements though on roads like A1 road (Q279859). Thryduulf (talk: local | en.wp | en.wikt) 15:49, 9 December 2015 (UTC)
- Comment This refers to nodes (intersecting lines). We already have terminus (P559) which is used for the end nodes. It may make more sense to rename terminus (P559) so that it can be used for end nodes and intersecting nodes. Danrok (talk) 03:49, 19 December 2015 (UTC)
- @Danrok: if so, then we would need some sort of qualifier to denote which nodes are end nodes as they are special in some situations. Alternatively we might have terminus (P559) for end nodes and this for nodes which may be intermediate or end nodes, or restricting this to intermediate nodes only. Thryduulf (talk: local | en.wp | en.wikt) 21:32, 19 December 2015 (UTC)
- @Thryduulf: You're right it would be best to have the two properties. Danrok (talk) 22:06, 19 December 2015 (UTC)
- @Danrok: if so, then we would need some sort of qualifier to denote which nodes are end nodes as they are special in some situations. Alternatively we might have terminus (P559) for end nodes and this for nodes which may be intermediate or end nodes, or restricting this to intermediate nodes only. Thryduulf (talk: local | en.wp | en.wikt) 21:32, 19 December 2015 (UTC)
- Support Although we have no simple way of putting junctions in the right order, which is a shame because without ordering the usefulness of this is diminished. Danrok (talk) 22:05, 19 December 2015 (UTC)
- We have series ordinal (P1545), follows (P155) and followed by (P156), could they do the job? For motorways and similar routes, a "junction number" property to use as a qualifier (or as an item when the interchanges have items (e.g. Almondsbury Interchange (Q4733905). Thryduulf (talk: local | en.wp | en.wikt) 20:09, 20 December 2015 (UTC)
- Support
as proposedas an item datatype. The issue of junctions is another matter. Each statement using this property would not automatically be sequence-able, as more than two streets can connect in the same intersection. For now, connects will add significant value, and we can further developed ordered sets for junctions downstream. Josh Baumgartner (talk) 20:58, 7 January 2016 (UTC)
- I've marked this as ready as there have been no objections in 3 months and no comments in the last 2 months. Thryduulf (talk: local | en.wp | en.wikt)
- The issue of string vs. item needs to be resolved before this van be created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 7 March 2016 (UTC)
- Agree, this one should be item, absolutely. Josh Baumgartner (talk) 19:48, 8 March 2016 (UTC)
- I thought it was clear that everyone was supporting an item here? @Danrok, Michiel1972: is that the case? Thryduulf (talk: local | en.wp | en.wikt) 20:14, 8 March 2016 (UTC)
- Yes, should be an item as datatype, not a string. Michiel1972 (talk) 19:10, 9 March 2016 (UTC)
- I thought it was clear that everyone was supporting an item here? @Danrok, Michiel1972: is that the case? Thryduulf (talk: local | en.wp | en.wikt) 20:14, 8 March 2016 (UTC)
- Agree, this one should be item, absolutely. Josh Baumgartner (talk) 19:48, 8 March 2016 (UTC)
- The issue of string vs. item needs to be resolved before this van be created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 7 March 2016 (UTC)
- Support --Srittau (talk) 20:02, 9 March 2016 (UTC)
- Question What's the difference to crosses (P177)? --Pasleim (talk) 09:06, 6 April 2016 (UTC)
- From the way I understand those properties, crosses (P177) is used where two items cross each other, without connecting. The domain is bridges and tunnels usually, the value can be any obstacle, and the property is non-symmetric. This property would be for streets that connect to each other, and is symmetric. --Srittau (talk) 09:42, 6 April 2016 (UTC)
@Michiel1972, Thryduulf, Danrok, Joshbaumgartner, Srittau: Done -- Lymantria (talk) 18:06, 27 April 2016 (UTC)
route map
| Description | route map for a linear feature other than a road (railway, trail, canal, etc) |
|---|---|
| Data type | Commons media file-invalid datatype (not in Module:i18n/datatype) |
| Domain | routes |
| Allowed values | image files on Commons |
| Example | Wuppertal cable car line (Q256964) → File:Wuppertaler Schwebebahn Karte.png |
| Source | external reference, Wikipedia list article, etc. |
| Robot and gadget jobs | Migrate non-road uses of route map (P15) to this property |
- Motivation
route map (P15) is labelled, constrained and was proposed as being for road maps only, but it is being used for non-road uses including Wuppertal cable car line (Q256964) (seeing this on my watchlist is what alerted me to the need), Budapest Cog-wheel Railway (Q851167), Budapest–Esztergom railway (Q851254) and Budapest–Vácrátót–Vác railway (Q851277). The alternative to this is broadening route map (P15) but that property indicates it is widely used by roads projects and could logically be a subproperty of this one. Thryduulf (talk: local | en.wp | en.wikt) 13:46, 25 February 2016 (UTC)
- Discussion
- Support--Kopiersperre (talk) 18:14, 25 February 2016 (UTC)
- Oppose - route map (P15) should be repurposed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 7 March 2016 (UTC)
- Oppose per Andy Mabbett, I don't see a reason not to use route map (P15). --Srittau (talk) 17:12, 7 March 2016 (UTC)
- What would happen to uses such as Mayabeque Province (Q115310)? --Rschen7754 04:59, 8 March 2016 (UTC)
- Since Mayabeque Province (Q115310) is a province, not a road, the property is misused there, and should be removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 8 March 2016 (UTC)
- Yes, detail map (P1621) should be used instead, in my opinion. --Srittau (talk) 15:43, 8 March 2016 (UTC)
- Since Mayabeque Province (Q115310) is a province, not a road, the property is misused there, and should be removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 8 March 2016 (UTC)
- What would happen to uses such as Mayabeque Province (Q115310)? --Rschen7754 04:59, 8 March 2016 (UTC)
- Oppose route map (P15) may work, but I think detail map (P1621) is the better option. Either way, no new property is required. Josh Baumgartner (talk) 19:46, 8 March 2016 (UTC)
- For Mayabeque Province (Q115310) I would agree with detail map (P1621) but for the examples given I think route map (P15) would, if broadened, be the better property. Thryduulf (talk: local | en.wp | en.wikt) 20:18, 8 March 2016 (UTC)
- Unless @Kopiersperre: or anyone else objects in the next few days I intend to withdraw this proposal based on there being consensus to broaden route map (P15). I have left a note on the property talk page drawing attention to this too. Thryduulf (talk: local | en.wp | en.wikt) 12:48, 11 March 2016 (UTC)
- Oppose the property creation proposal and Support the idea of broadening route map (P15) to include non-road uses such as rail and other routes. -happy5214 03:02, 12 March 2016 (UTC)
- OK, I think see there is consensus here not to create a new property but for the alternative solution of broadening route map (P15) so I withdraw this proposal. Thryduulf (talk: local | en.wp | en.wikt) 02:22, 21 March 2016 (UTC)
locality or place
| Description | Describe how to find the object - directions, objects along way, comments etc. |
|---|---|
| Data type | Monolingual text |
| Template parameter | "locality" in lv:template:monument |
| Domain | place |
| Allowed values | any text |
| Example | "Walk from waterfall approximately 3 km along Blue river", "500 meters south of the southern outskirts of the village", "Turn right into the forest after 33 km milepost" |
| Source | WLM monuments lists in Wikipedia |
- Motivation
Currently Latvian, Russian and Ukrainian communities are in progress of migration WLM monuments from lists to Wikidata. We have very comprehensive and complete monument lists, so we can't afford to lose the information from these lists. Localities often present in the lists, espesially for archeology monuments and we can't replace such locatity by location (P276) or located in/on physical feature (P706) because its ambiguity. Voll (talk) 17:36, 23 April 2016 (UTC)
- Discussion
- Support as requestor. --Voll (talk) 17:38, 23 April 2016 (UTC)
- Support needed for Wikivoyage.--Ymblanter (talk) 19:13, 23 April 2016 (UTC)
- Support, required for monuments database and Wikivoyage. --Alexander (talk) 19:14, 23 April 2016 (UTC)
- Support Seem usefull of informal localisation. --Fralambert (talk) 00:39, 24 April 2016 (UTC)
- Support. Yes, we need it for objects, which are located somewhere. --Edgars2007 (talk) 07:49, 24 April 2016 (UTC)
- Oppose (and I get the feeling "please support this property" was spammed somewhere...): This information should not be in string format; Wikidata is not a place for free-form text but instead a relational database. These instructions cannot be replicated in any meaningful fashion. See also Nikki's comments and oppose at WD:Property proposal/Unsorted#appears in the list of heritage monument. --Izno (talk) 20:11, 25 April 2016 (UTC)
- And ping Nikki (talk • contribs • logs). --Izno (talk) 20:15, 25 April 2016 (UTC)
- Aha! Conspiracy theory is detected ;-). Yes, this property was discussed earlier here, here and here. WLM volunteers consider it strange to create heritage monument item without information how to find it. WLM list is not escape room and we are not explorers, there should be a precise location as possible. If Wikimedia supports the projects for migration heritage monuments data to Wikidata (meta:Connected Open Heritage, Wikidata:WikiProject WLM, Wikidata:WikiProject Cultural heritage), we may go halfway to meet WLM needs. --Voll (talk) 22:04, 25 April 2016 (UTC)
- "How to find it" is determined from the coordinates. These can be passed to any number of routing engines. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:10, 26 April 2016 (UTC)
- May be in Netherland or in similar country each heritage monument has coordinates already. But in Latvia we can't get coordinates from public governmental data. So mentioned at this page location "pie Ezerkalniem" (near Ezerkalni farm) is a real direction for photographer. --Voll (talk) 15:55, 26 April 2016 (UTC)
- "How to find it" is determined from the coordinates. These can be passed to any number of routing engines. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:10, 26 April 2016 (UTC)
- Oppose per Izno. --Pasleim (talk) 22:14, 25 April 2016 (UTC)
- Question Why is this information supposed to be transferred to Wikidata? This sounds like something that would make much more sense on local projects (like Wikivoyage). --Srittau (talk) 23:41, 25 April 2016 (UTC)
- P.S. I don't think transferring the lists completely to Wikidata is the right approach. Instead, I would suggest to use a hybrid approach, where base data about the monuments is gotten from Wikidata, but localized information (like this information) is added on the local projects. --Srittau (talk) 23:44, 25 April 2016 (UTC)
- With the hybrid approach we should support data in two places (Wikipedia/Wikivoyage and Wkikidata), whereas with location in Wikidata we can generate lists dynamically from WD and support only Wikidata items. It gets us time for more useful works. --Voll (talk) 09:52, 26 April 2016 (UTC)
- P.S. I don't think transferring the lists completely to Wikidata is the right approach. Instead, I would suggest to use a hybrid approach, where base data about the monuments is gotten from Wikidata, but localized information (like this information) is added on the local projects. --Srittau (talk) 23:44, 25 April 2016 (UTC)
- I think we already have this property approved with datatype multi-lingual string. Given that we don't known if and when that will be available, a solution with monolingual string should be considered.
--- Jura 05:47, 26 April 2016 (UTC)- Jura1, you are right about Directions proposal. We are using in WLM only official directions (places) descriptions in official language, so the mono-lingual string type is suitable for us. --Voll (talk) 09:38, 26 April 2016 (UTC)
- Oppose per Izno. Per the arguments at en:WP:CCC, we need not be bound by decisions made in 2013, but not yet enacted. Also: directions from where? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:08, 26 April 2016 (UTC)
- As I mentioned in this example direction (place,location) not only from where? but also near what? - "pie Ezerkalniem" (near Ezerkalni farm). --Voll (talk) 15:59, 26 April 2016 (UTC)
- Oppose. I can support this but only if it is a multilingual text, not a monolingual text. In WLM Ukraine we have at least one region with multilingual lists, i.e. Crimea with lists in Ukrainian and in Russian (and potentially also in Crimean Tatar at some point), and I do not want an edit war about replacing Ukrainian location with Russian or vice versa. Sorry but I do not see how to do this without multilingual text, and we already have a relevant multilingual Directions field — NickK (talk) 15:19, 27 April 2016 (UTC)
Weak support I see some issue that this might lead to importing data that is actually encyclopedic content. That should be monitored in my opinion. @NickK: I don't understand the issue with two languages and a "monolingual text" since we may allow multiple values. So there can be a Ukrainian as well as a Russian text as values. Lymantria (talk) 15:39, 27 April 2016 (UTC)
- Firstly, I kind of like a solution to turn a monolingual field into a multilingual one by use of qualifiers, but is this really acceptable? Secondly, if we use a monolingual text, it might be redundant to P969 (P969) (as "500 meters south of the southern outskirts of the village" is also a sort of address) — NickK (talk) 16:19, 27 April 2016 (UTC)
- I think having more than one language does not need qualifiers. See for instance the title of A Fistful of Dollars (Q76479). In my opinion allowing more than one language is not really problematic. Lymantria (talk) 06:55, 29 April 2016 (UTC)
- NickK, my goal was to split real address (High street, 123) from locality. But you are right - if a new property will be not created, the only solution is filling address property with "500 meters south of the southern outskirts of the village". --Voll (talk) 08:48, 29 April 2016 (UTC)
- Firstly, I kind of like a solution to turn a monolingual field into a multilingual one by use of qualifiers, but is this really acceptable? Secondly, if we use a monolingual text, it might be redundant to P969 (P969) (as "500 meters south of the southern outskirts of the village" is also a sort of address) — NickK (talk) 16:19, 27 April 2016 (UTC)
- Done as Property:P2795, please note Property talk:P2795#label. I will also archive the proposal "directions". Even with property datatype monolingual string, descriptions in several languages are possible. @Voll, Ymblanter, Atsirlin, Fralambert, Edgars2007, Lymantria: please make good use of it.
--- Jura 08:01, 30 April 2016 (UTC)
![[2]](https://en.wikipedia.org/wiki/Railway_electrification_system#/media/File:Europe_rail_electrification_en.svg%7Chere){kind=link}
Directions (en)
- Agreed to be created; waiting for multilingual text datatype
| Description | voy:Template:Listing |
|---|---|
| Data type | Multilingual text (not available yet) |
| Template parameter | Directions |
| Domain | Items with Wikivoyage listings |
| Allowed values | any text |
| Example 1 | MISSING |
| Example 2 | MISSING |
| Example 3 | MISSING |
| Source | Wikivoyage listings |
| Proposed by | Filceolaire (talk) 00:11, 19 August 2013 (UTC) |
- Discussion
- Support Support as nom. See this RFC. Filceolaire (talk) 00:11, 19 August 2013 (UTC)
- Support Danrok (talk) 21:55, 30 August 2013 (UTC)
- Support Nicolas1981 (talk) 08:01, 28 November 2013 (UTC)
- Support -- DerFussi 11:27, 24 January 2014 (UTC)
- Support --NatiSythen (talk) 07:59, 28 January 2014 (UTC)
- Support --RolandUnger (talk) 13:10, 2 February 2014 (UTC)
- Comment archived following the creation of P2795.
cct applicable property
| Description | qualifier for category combines topic (Property:P971). Maps categories to statements. Use this instead of "see also" (Property:P1659) for the same. |
|---|---|
| Data type | Property |
| Domain | statements with category combines topics (P971) |
| Allowed values | any property that generally generates a valid statement in combination with the value of P971 |
| Example | Category:Lithuanian-language newspapers published in the United States (Q8598983): category combines topics (P971) Lithuanian (Q9083): qualifier cct applicable property: original language of film or TV show (P364) |
| Robot and gadget jobs | Add statements with Autolist2 based on lists like Wikidata:Database reports/items without claims categories/ltwiki |
| Proposed by | --- Jura 23:28, 2 February 2016 (UTC) |
- Comment withdrawn, using existing property instead
ASF KID Area Code
| Description | Geographical area code within the Karst Index Database of the Australian Speleological Federation |
|---|---|
| Represents | geographic location (Q2221906) |
| Data type | External identifier |
| Template parameter | No parameters known to exist, however a new parameter could be added to en:template:infobox cave |
| Domain | cave (Q35509) and perhaps also geographic location (Q2221906) and similar subclasses (national parks, nature reserves, etc) |
| Allowed values | string pattern: ([A-Z]|\d){1-3} |
| Example | Mammoth Cave (Q10954073) → WI |
| Source | Area list, Karst Index Database of the Australian Speleological Federation |
| Robot and gadget jobs | Manual import is most likely |
- Motivation
Most of the information known about caves within Australia is held by numerous caving clubs/societies, with the ASF hosting a database (KID) which aims to collate the knowledge held by clubs into one shared source. This database defines geographic areas with unique area codes. These area codes are used when identifying caves within Australia. For example, caves usually have a little metal tag at the entrance stating the cave area code and serial number of the cave within the area. Ongoing management of cave identification is performed on a per-area-code basis where various caving clubs/societies maintain responsibility for certain areas. Dhx1 (talk) 03:43, 22 November 2015 (UTC)
- Discussion
- Support. This seems like a useful reference. I've changed the datatype to external identifier though. Thryduulf (talk: local | en.wp | en.wikt) 13:57, 7 March 2016 (UTC)
- Support looks good. --Edgars2007 (talk) 11:06, 9 March 2016 (UTC)
- I don't completely understand this property. In [3] WI is the area code for Witchcliffe (a town). So on which basis do you assign WI to Mammoth Cave (Q10954073)? --Pasleim (talk) 20:44, 22 March 2016 (UTC)
- Comment @Pasleim: @Pigsonthewing: The area code in ASF KID corresponds to a "caving region", the boundary of which isn't formally defined and should never correspond to a town or city. Some "caving regions" may have the same name as a nearby town, however they should always be two separate items. I suggest looking at w:List of caves in Western_Australia for an example of where the "WI" identifer is used in the identifiers of caves within the Witchcliffe caving region (karst region). Examples of "caving regions" (i.e. not an individual cave system and not a town/administrative area) are Bungonia Caves (Q4997677), Capricorn Caves (Q4362307), Buchan Caves (Q4982534) (near the town of Buchan (Q4982529)), Yarrangobilly Caves (Q8049538), etc (many others). Dhx1 (talk) 11:12, 19 April 2016 (UTC)
- Ok I understand. But what's the adavantage of this area code over the full cave number from w:List of caves in Western Australia? --Pasleim (talk) 18:31, 19 April 2016 (UTC)
- Comment @Pasleim: Fair comment. The Wikipedia articles/existing Wikidata items for caving areas can simply point to a list of individual caves stored in Wikidata with the ASF KID Cave Tag Number property. I'll bring the cave tag number proposal back from the dead. Thanks. Dhx1 (talk) 23:32, 21 April 2016 (UTC)
- Ok I understand. But what's the adavantage of this area code over the full cave number from w:List of caves in Western Australia? --Pasleim (talk) 18:31, 19 April 2016 (UTC)
- Oppose if the example stays. Support if the example is changed to . I think another property for the area code + serial number of individual caves etc. makes sense. --Srittau (talk) 13:34, 27 March 2016 (UTC)
- @Dhx1: Can you respond, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 18 April 2016 (UTC)
- Comment @Srittau: @Pigsonthewing: I had another matching proposal ASF KID Cave Tag Number which has since been archived for lack of community response. I believe this archived property should be resurrected as it is the best identification numbering system for caves within Australia, in lieu of a government body keeping a detailed database of caves. These ASF KID Cave Tag Number identifiers are placed at the entrance of caves and are referred to in speleology journals and magazines, and amongst Australian caving communities. Dhx1 (talk) 11:12, 19 April 2016 (UTC)
- Please do. I would support it. The lack of community support is a general problem with proposals due to the low number of people actually reading proposals. --Srittau (talk) 14:48, 19 April 2016 (UTC)
- Comment @Srittau: Thanks, I'll bring it back to life again. Dhx1 (talk) 23:32, 21 April 2016 (UTC)
- Please do. I would support it. The lack of community support is a general problem with proposals due to the low number of people actually reading proposals. --Srittau (talk) 14:48, 19 April 2016 (UTC)
| Description | company or statutory body concerned with the management of a navigable canal or river |
|---|---|
| Represents | navigation authority (Q6982432) |
| Data type | Item |
| Domain | waterway (Q1267889) |
| Allowed values | organisations (should have instance of navigation authority (Q6982432) or a subclass) |
| Example | Royal Military Canal (Q2294027) → Environment Agency (Q5381011), Dartmouth Harbour (Q5225699) → Dart Harbour & Navigation Authority (Q16954392) |
| Robot and gadget jobs | ? |
- Motivation
Filling out the entry for Royal Military Canal (Q2294027) I noticed this was missing. Thryduulf (talk: local | en.wp | en.wikt) 17:49, 1 March 2016 (UTC)
- Discussion
- Why not operator (P137)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 9 March 2016 (UTC)
- Because the navigation authority is not necessarily the owner or operator, and I'm not sure it's right to describe any body as "operating" a natural body of water. Also, there may be other "operators" for different aspects - e.g. the navigation authority will typically not operate any of the vessels that navigate the body of water, and may or may not operate any non-navigation activities (e.g. fisheries, water sports, irrigation, drainage, etc). Thryduulf (talk: local | en.wp | en.wikt) 01:13, 10 March 2016 (UTC)
- Comment. I voted Support first but now I wonder if there should not be some wider scope. We may need a property like this one for other things, like the observatories that monitor volcanoes. It is not an operator (P137) but something like an authority monitoring the target item. Thierry Caro (talk) 19:42, 19 March 2016 (UTC)
- @Thierry Caro: if there is a wider scope for this I think would most likely be "management authority" (with applies to part as a qualifier if needed), and I'd say authorities monitoring items would be a sister class of organisation to authorities managing items rather than the same class - necessitating a property one step too high up the chain for me. Thryduulf (talk: local | en.wp | en.wikt) 21:57, 19 March 2016 (UTC)
- Oppose Use operator (P137). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:38, 19 March 2016 (UTC)
- I've explained above why this would be incorrect. Thryduulf (talk: local | en.wp | en.wikt) 21:57, 19 March 2016 (UTC)
- No, you've said why you think it would be incorrect. I have read your comment, considered its merits carefully, and based my !vote upon it. We have, for example, qualifiers for cases where two operators have different roles. And we're quite comfortable in having an operator for a road, railway, or bridge, even though they don't operate the vehicles that pass over it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:35, 19 March 2016 (UTC)
- I've explained above why this would be incorrect. Thryduulf (talk: local | en.wp | en.wikt) 21:57, 19 March 2016 (UTC)
- Oppose I also think using operator (P137) would be the right thing to do. It fits pretty well for an organization that manages a waterway from what I understand. --Srittau (talk) 13:39, 27 March 2016 (UTC)
- Not done --Pasleim (talk) 22:03, 25 April 2016 (UTC)
WOEID
| Description | Where-on-Earth identifier |
|---|---|
| Data type | External identifier |
| Domain | geolocatable place items which have, or are eligible for, coordinate location (P625). |
| Allowed values | string pattern: [1-9][0-9]{0,9} with values corresponding to integers in the range 1 to 232-1 |
| Example | Canada (Q16) → 23424775 |
| Source | Correlation of Flickr shapefiles data (see http://code.flickr.net/2011/01/08/flickr-shapefiles-public-dataset-2-0/ ) with Wikipedia articles with coordinates, by comparing coordinates with shape data, and feature names |
| Formatter URL | https://www.flickr.com/places/info/$1 |
| Robot and gadget jobs | to be added by User:The Anomebot2 |
| Proposed by | The Anome on 2016-04-18 |
- Motivation
Originally developed by Yahoo! GeoPlanet (see here), WOEIDs are a feature ID that is available under free licensing terms (see here for announcement). It appears that WOEIDs are available from the dataset cited corresponding to hundreds of thousands of Wikipedia articles. Note that though I've given a Flickr URL pattern, this system is open, and not proprietary to Flickr: they are just users of this ID.
Uses:
- WOEIDs can be used to help correlate multiple geodata sources, such as the Flickr shapefiles or sets of Flickr photographs. This could also be used to find Flickr photographs with Commons-compatible licenses, potentially aiding the import of vast numbers of images cross-correlated to Wikidata and Wikipedia.
- Most importantly, since OpenStreetMap supports WOEIDs as a key type ( http://wiki.openstreetmap.org/wiki/Key:woeid ), they can potentially be used to tie together Wikidata entries and OpenStreetMap features. This is potentially a huge win for Wikidata/OpenStreetMap integration.
- Discussion
- Support I'm aware of the excellent and longstanding work by The Anome and his bot, to geotag articles on en.WP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 18 April 2016 (UTC)
- Thanks. I'll start work on generating the dataset, pending formal approval for adding the property and its associated data. It shouldn't be too hard to do: either PostGIS or simple hand-rolled spatial binning in RAM (both datasets are relatively small) should do the trick fairly trivially. -- The Anome (talk) 12:19, 20 April 2016 (UTC)
- @The Anome: What is this different from WOEID (P1281)? Lymantria (talk) 09:50, 27 April 2016 (UTC)
- @Lymantria: Argh! You're right -- it already exists. Request withdrawn -- many thanks for spotting this. I've also merged the formatter URL pattern from this request into WOEID (P1281). -- The Anome (talk) 10:20, 27 April 2016 (UTC)
- No problem, there are so many properties that it's easy to overlook one. Lymantria (talk) 10:26, 27 April 2016 (UTC)
- @Lymantria: Argh! You're right -- it already exists. Request withdrawn -- many thanks for spotting this. I've also merged the formatter URL pattern from this request into WOEID (P1281). -- The Anome (talk) 10:20, 27 April 2016 (UTC)
Using some quite conservative matching criteria, I've now got around 20,000 WOEID assignments ready for entry into Wikidata. A few spot checks suggest the data so far is looking good: can anyone tell me what I should be doing to start putting these into Wikidata? -- The Anome (talk) 20:38, 4 May 2016 (UTC)Update: I've now seen Wikidata:Data_donation -- I'll follow the guidance there... -- The Anome (talk) 21:15, 4 May 2016 (UTC)
Czech neighbourhood ID code
| Description | unique and persistent identifier for a neighbourhood in the Czech Republic |
|---|---|
| Represents | neighbourhood code (Q23893696) |
| Data type | External identifier |
| Template parameter | Not used at the moment, a new parameter could be added to Infobox - sídlo. |
| Domain | neighborhood (Q123705) |
| Allowed values | ([1-9][0-9]{0,4}|[1-4][0-9]{5}) |
| Example | Útěchvosty (Q11088947) → 116947 |
| Source | Definition on the website of the Czech Statistical Office, Source data at the CZUK website (first column). |
| Robot and gadget jobs | Jagro will be in charge of that. |
- Motivation
Unique number code given to each officially designed "neighbourhood" in the Czech Republic. It is created at the moment when the neighbourhood is established, cannot be changed and is guaranteed by the Czech Statistical Office (Q3504917). The last digit is a control digit counted using method MODULO 11-ADDO.
We discovered that Czech neighbourhoods do not have any identifier whatsoever. It could be used in further work (improving geocoordinates etc). Vojtěch Dostál (talk) 17:06, 20 April 2016 (UTC)
- Discussion
- Support Matěj Suchánek (talk) 17:39, 20 April 2016 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:47, 20 April 2016 (UTC)
- Support The codes are ready to be added. ;) --Jagro (talk) 18:01, 20 April 2016 (UTC)
- Support Jagro is skilled in GIS and is doing useful work for the Czech Wikimedia community such as this map. From my own experience, I know how confusing such work has been when one could only identify a place by either its name (ambiguous) or coordinates (imprecise). I support the creation of this property. --Blahma (talk) 00:25, 21 April 2016 (UTC)
- Support --Limojoe (talk) 14:57, 22 April 2016 (UTC)
- Comment Could anyone please correct the regex so that it includes numbers like "3", "11", but also up to "499999"? It currently only accepts numbers such as "000001" which is technically not the same identifier as "1". Thanks :-) --Vojtěch Dostál (talk) 05:25, 23 April 2016 (UTC)
- Support --Frettie (talk) 21:26, 23 April 2016 (UTC)
- Done @Vojtěch Dostál, Matěj Suchánek, Pigsonthewing, Jagro, Blahma: @Limojoe, Frettie: --Pasleim (talk) 16:43, 27 April 2016 (UTC)
ASF KID Cave Tag Number
| Description | Unique identifier for caves within the Karst Index Database of the Australian Speleological Federation |
|---|---|
| Represents | cave (Q35509) |
| Data type | External identifier |
| Template parameter | No parameters known to exist, however a new parameter could be added to en:template:infobox cave |
| Domain | cave (Q35509) |
| Allowed values | string pattern: ([A-Z]|\d){1-3}\-X?\d+ |
| Example | Mammoth Cave (Q10954073) → 6WI-38 |
| Source | Karst Index Database of the Australian Speleological Federation |
| Robot and gadget jobs | Manual import is most likely |
- Motivation
Most of the information known about caves within Australia is held by numerous caving clubs/societies, with the ASF hosting a database (KID) which aims to collate the knowledge held by clubs into one shared source. The database contains a list of caves known within Australia, as well as detailed data on the characteristics of each cave (length, depth, features, date of discovery, etc). Caves usually have a little metal tag at the entrance stating the cave area code and serial number of the cave within the area. This unique identifier is referred to in literature published by speleological/caving societies, on maps and in books.
This property was previously discussed at Wikidata:Property_proposal/Archive/45#ASF_KID_Cave_Tag_Number however no feedback was provided, and the property proposal archived without a decision being made. Based on new discussions at Wikidata:Property proposal/Place for the ASF KID Area Code proposal, it is likely that a re-submission of this request will now result in a decision. Dhx1 (talk) 23:46, 21 April 2016 (UTC)
- Discussion
- Comment @Pasleim: @Srittau: @Pigsonthewing: This property proposal will be of interest given recent discussions surrounding the *ASF KID Area Code* proposal. Dhx1 (talk) 23:46, 21 April 2016 (UTC)
- Support Sounds like a useful, well-recognized property. --Srittau (talk) 10:28, 22 April 2016 (UTC)
- Support I regret having missed the opportunity to do so last time. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 22 April 2016 (UTC)
- Support An excellent idea. -- The Anome (talk) 23:51, 22 April 2016 (UTC)
- Support --AmaryllisGardener talk 00:06, 23 April 2016 (UTC)
- @Dhx1, Srittau, Pigsonthewing, The Anome, AmaryllisGardener: The property is ready. --Fralambert (talk) 00:45, 29 April 2016 (UTC)