Support Can we have a complete list of possible values ? Just to be sure that this property won't be used as crystal system property.Snipre (talk) 10:06, 26 May 2013 (UTC)
Comment of course we could also use the properties preceded by and followed by for these relations. I'm not really sure how that would influence possible querries in the future. --Tobias1984 (talk) 15:42, 9 April 2013 (UTC)
Well, preceded and followed imply a temporal relation, and there are certain processes which can move older layers on top of newer ones, so overlays =/= follows. Chris857 (talk) 19:29, 25 April 2013 (UTC)
The default should be stratigraphic succession. We could introduce qualifiers for things like unconformities and tectonic contacts. --Tobias1984 (talk) 14:17, 28 April 2013 (UTC)
That may not sound very important -nor the right page to talk about that- but what about fictional worlds with fictional dates (see this infobox). Any way to escape the TimeValue datatype ? --Zolo (talk) 08:54, 3 February 2013 (UTC)
Support once possible. @Eric: P67 was deleted because it used the "item" datatype, when it should've used "TimeValue". For that reason, of course, this property can't be created until TimeValue is enabled as a possible datatype. — PinkAmpers&(Je vous invite à me parler)07:47, 6 February 2013 (UTC)
I think there's consensus for hacking this; I am putting this in a hidden block so it doesn't distract from others that are on-going conversations, whilst we wait for the datatype to be created. James F. (talk) 18:12, 6 February 2013 (UTC)
the time taken for a given astronomic object to make one complete about another object. A qualifier can distinguish different definitions of orbital period (i.e. sidereal period, or synodic period).
SupportComment Why not have a more succinct label like "discovery date"? Label wording aside, this property seems useful. Emw (talk) 03:40, 9 March 2013 (UTC)
Support But it should be made clear that America wasn't "discovered" in 1492. Maybe add something like "discovered by mankind" in the description. --FA2010 (talk) 21:48, 15 March 2013 (UTC)
It is not so simple: in some cases two or more people discover something independently, and all of them are recognized as "discoverer". In these cases the discovery date will result to be not unique! --Paperoastro (talk) 16:06, 20 March 2013 (UTC)
I don't believe we have a date dissolved property pending, but we will need to wait for the timevalue datatype. I think this should be broadened to any organization. --Jfhutson (talk) 18:48, 5 May 2013 (UTC)
OK, sorry bout that. I guess the domain field and the section heading made me think these were intended just for football clubs. --Jfhutson (talk) 19:17, 5 May 2013 (UTC)
We should distinguish between the year a work was first published (Kafka: Der Process, 1925) and the date of a specific edition (El proceso, Madrid 2009). --Kolja21 (talk) 22:05, 31 January 2013 (UTC)
I think that there will be an item for each version of the book in order to allow people to easily quote them in the reference part ofstatements. In that case I'm not sure (but I may have wrong) that the two properties are needed. Tpt (talk) 17:44, 1 February 2013 (UTC)
I'm not a proper librarian, but I know there are a lot of cases for "dates". Data of publication, date of the edition, date of reprint... Maybe we want a general "date" property with several qualifiers? As I said in Comment III up here, it really depends by the purpose of the metadata. We'll probably have a Wikipedia page for the "work" (FRBR-like) Der Prozeß, but we'll have also different scanned books on Commons, (ie translations, different editions, reprints, etc.). I think that Wikidata would be absolutely usefule especially for Commons and Wikisources, so I wonder how should we design the list of properties for books in Wikidata. --Aubrey (talk) 10:37, 18 February 2013 (UTC)
Sorry. What do you need ? An property with a numeric datatype ? Or a property representing a numeric concept with a string as datatype ? If I take your example with swiss franc you want something like "currency division" to give the nominal value of each coin/note ( 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 200, 1000)? Snipre (talk) 21:03, 22 March 2013 (UTC)
In fact I think a good thing would be a generic property (e.g. "DrTrigonBot Value" or even more generic "Bot Value") for the bot in cases when it has data to write for which no property was created yet - as it is the situation right now for a property "Currency Exchange Rate" (or similar) that is needed for swiss franc. This would allow the bot to already be tested or used without having the need to create always the suitable/correct property before being able to check if the bot works at all (in that specific situation), e.g. That would be a really good and useful/helpful thing! Thanks a lot for considering this and Greetings --DrTrigon (talk) 21:41, 22 March 2013 (UTC)
Just for a test you can see if there is a property in request for deletion using string as datatype or a property which not used in a lot of item or finally try on the demo version of wikidata. Snipre (talk) 22:05, 22 March 2013 (UTC)
Thats clear, currently I am using something else. Also the demo was already used to adopt the bot code. What I need is something permanent. In future and daily (usual) operation there will always be a case where you have to test, since the bot is freely configurable from here - by any user. --DrTrigon (talk) 22:36, 22 March 2013 (UTC)
It is not testing bots, but testing setups - as on wikipedia itself you will always have situations were you have to change something, modify setup of data, configuration and so on... at least that is what holds for me. Then I have to disagree because testing of bots is needed, e.g. in order to fullfill the bot flag request a given number (e.g. 250) of test edits have to be done. And there will in future clearly be other situations - as soon wikidata will be used frequently... Greetings --DrTrigon (talk) 20:55, 23 March 2013 (UTC)
I mean ... it does not need to be something bot specific, what about general maintenance (for human users)? I would even more support such a property, that can be used if it is e.g. not clear yet what property to use, one has to be renamed, other name conflicts or anything else... --DrTrigon (talk) 20:59, 23 March 2013 (UTC)
Why not simply a sandbox property per datatype ? I do not see what harm can be done with that, as long as it is clear that it is a sandbox. --Zolo (talk) 21:29, 23 March 2013 (UTC)
Do you plan using that sandbox property only on sandbox/test items, or also on production items? --Faux (talk) 12:12, 24 March 2013 (UTC)
I do not see anything wrong in using it other items. It will not look very good, and if we can avoid using it too massively, that is better, but raw Wikidata items do not look very good anyhow. The important thing is that it does not unintendedly get transcluded to Wikipedias and other clients. And as long as they do not query sandbox statements, I see no reason for that to happen. --Zolo (talk) 12:22, 24 March 2013 (UTC)
So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:
Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
Label: Sandbox-String / Description: Sandbox property for value of type "String" / Data type: String
9 possible inputs per language (approved, grandfathered, redefined, renamed, questionable + approved, questionable + grandfathered, questionable + discredited, published without approval, discredited)
Example
e.g. Abelsonite = approved, Abernathyite = grandfathered
Oppose the datatype. With only few possible values, item would be much better, because then you only have to translate the values to all languages once pr. value instead of once pr. mineral. Byrial (talk) 22:32, 26 April 2013 (UTC)
Note that in cases like population, where change in the real-world value is effectively continuous but is only measured in discrete intervals, this qualifier would indicate the range of time the value was valid according to a given source. Here, that would be the official census of India.Emw (talk) 13:48, 20 April 2013 (UTC)
A good point was made in the proposal for the 'to time' qualifier that because census results typically represent a snapshot (i.e. an instantaneous measurement), it's incorrect to assert that the sources say claims about population counts are valid for a range of time. So I've added an 'as of' alias to this qualifier, and adjusted the 'domain' of this property to reflect that. Emw (talk) 15:32, 20 April 2013 (UTC)
Comment. Maybe an other property for "as of": "from time" is for the beginning of a time range and "as of" for a specific date time. Tpt (talk)
Are you suggesting that the 'from time' qualifier would only be valid if the 'end time' qualifier were also applied to the claim? (And the converse, that 'end time' would only be valid if 'from time' were applied?)
In that case, claims that have begun but not ended, e.g. 'India instance of sovereign state since 26 January 1950', 'Universe instance of physical body since 13.8 billion years ago' would presumably also only be valid for 'as of' and not this 'from time' qualifier. Emw (talk) 16:30, 20 April 2013 (UTC)
Yes, I'm suggesting that the 'from time' qualifier would only be valid if there is an 'end time' qualifier. That will allow us to move easily to a time range (value of the 'as of' qualifier) if the range feature is added in the future. So Support now. Tpt (talk) 16:46, 28 April 2013 (UTC)
Support – Now that it is separated from "as of", it is clear and unambiguous. And it is also very much needed. -- Byrial (talk) 05:51, 21 April 2013 (UTC)
Support Note that we require such a "start date"-property for all kinds of events, too. I think there's no need to create another property, but instead we can use this one. So the domain should include events as well.--Kompakt (talk) 09:05, 23 May 2013 (UTC)
Created as start time (P580), as "start date" considering the above comments that it need not always be a qualifier.
Description: I think that office held should be augmented with the dates during which the subject held that office. In that way, we could specify that e.g. George W. Bush was Governor of Texas from 17 Jan 1995 until 21 December 2000, and then President from 20 Jan 2001 to 20 Jan 2009 (dates taken from enwiki). Inputting the dates that way could also end disputes over how to format them (DMY, MDY, etc.): they could be automatically displayed in the format that users chose, without you having to change anything in edit mode in Wikipedia itself.
Comment. I'd like to see how "qualifiers" work before this type of property is made. This property can't be entered as its own statement as it would have no meaning without reference to some other statement. Espeso (talk) 06:06, 15 March 2013 (UTC)
(See comment from Lavallen below.) Note that in cases like population, where change in the real-world value is effectively continuous but is only measured in discrete intervals, this qualifier would indicate the range of time the value was valid according to a given source. Here, that would be the official census of India.Emw (talk) 13:48, 20 April 2013 (UTC)
I understand the Mexico and US-example, but not the India-example. A census is normally made a certain day, or a at least a certain year. Such numbers are very seldom in a very long range of time. Would it not be better to search for the latest census-date (2001) if you want to know the numbers for 2010? -- Lavallen (block) 14:29, 20 April 2013 (UTC)
Great point! You're right at least about the United States census; the census makes a point of noting that it represents things as they were on precisely April 1. So at least the US census is a snapshot, i.e. an instantaneous measurement. I'm not familiar with the details of the Indian census, but I assume it's the same in that regard.
The broader clarification seems to be this: if a statement represents a fact tied to a specific date, then it should have a "from time" qualifier but not an "to time" qualifier. Population counts and estimates are a good example of this: the sources are only asserting that their claim is valid for one specific date, not a range of time. Emw (talk) 15:22, 20 April 2013 (UTC)
Question – How would you distinguish between a statement for a specific date, and a statement for a state that has not yet ended, and thus is still valid? -- Byrial (talk) 20:31, 20 April 2013 (UTC)
Support. But how to handle two not crossing timelines for an object? From 1992-1999 and 2001-2005 -> will this work? Conny (talk) 14:00, 28 April 2013 (UTC).
It will most likely work, even if it will look like: From: 1992, 2001; To: 1999, 2005; But it will be a challenge to make templates who can make it look nice. -- Lavallen (block) 14:19, 28 April 2013 (UTC)
Wouldn't it be better to just set it as two separate statements, each with their own from-time/to-time qualifiers? --Yair rand (talk) 15:51, 28 April 2013 (UTC)
Should we decide in advance whether the values of this are inclusive or exclusive (ie does September 1-September 20 include the 20th?) ? --Yair rand (talk) 15:51, 28 April 2013 (UTC)
Good question. I think we should decide that before this qualifier (and from time) is created. In George W. Bush, the subject's presidency is shown as January 20, 2001 – January 20, 2009. According to First inauguration of George W. Bush, he was in office as of 12:01 p.m. January 20, 2001. So those 'from date' and 'to date' values are inclusive. I'm not sure if this is standard for that field's use for all politicians, though.
For what it's worth, popular SQL implementations of "BETWEEN" make that operator inclusive, see e.g. BETWEEN in MySQL. Perhaps that indicates that this qualifier should be inclusive.
Are there any prominent counterexamples, where 'from date' or 'to date' are used in the exclusive sense in a certain domain?
There have been property proposals for 'date', 'start time' and 'end time' awaiting feedback for over a month (over three months for 'date') at Wikidata:Property_proposal/Event, which would apply to things like Presidency of George W. Bush (Q1719918). The labels 'start time', 'end time' and 'date' seem more idiomatic to apply to events than 'from time', 'to time' and 'as of', with 'date' and 'as of' seeming especially awkward to interchange. (Saying 'Tenerife airport disaster <as of> March 27, 1977' is clearly worse than saying 'Tenerife airport disaster <date> March 27, 1977'.) Emw (talk) 18:38, 28 April 2013 (UTC)
Support As mentioned above, the domain should include events, too (where this wouldn't be used as a qualifier but a "top-level"-property).--Kompakt (talk) 09:07, 23 May 2013 (UTC)
Created as end time (P582), "end date" considering the above comments that it need not always be a qualifier.
Support – It seems clear to me that we need a separate qualifier for point of time. (Compare to the discussions for "from time" and "to time" -- Byrial (talk) 06:00, 21 April 2013 (UTC)
SupportThey are not. Qualifiers are just properties of properties so every property can be used as Qualifer. That means if the property proposals for 'date', 'start time' and 'end time' are succesful this is not needed anymore.--Saehrimnir (talk) 10:39, 8 May 2013 (UTC)
I would prefer a more general "date" property, as it would be applicable both as an "as of" qualifier and as a stand-alone statement for punctual events. --Zolo (talk) 12:24, 30 May 2013 (UTC)
Some events span periods of time, days, weeks, etc. So, this would need to be start and end date/time. Probably applies to almost all events. Danrok (talk) 20:11, 21 February 2013 (UTC)
Obviously Support. I can't believe that we have over 300 properties, but none to say that the 2004 elections were held in 2004. --NaBUru38 (talk) 19:26, 19 March 2013 (UTC)
Well, Wikidata doesn't actually support the Date data type yet...
Oppose Once the date datatype is available, it seems clear we will quickly have generic 'from/start' and 'to/end' properties which should cover this when used as qualifiers for 'member of team' claims. Joshbaumgartner(talk) 09:33, 9 May 2013 (UTC)
Comment - We should probably rename this to "club" and then add time qualifiers. Queries can return the current club. --Tobias1984 (talk) 13:54, 7 May 2013 (UTC)
The player's most common position or positions. If a player is known for playing in multiple roles then explain the point more fully within the article.
Oppose I am sure we are going to have a "height" property and I don't see that this property could have a different value. --Tobias1984 (talk) 08:24, 4 May 2013 (UTC)
there is already Property:P185, but that does not apply to older times. In greek philosophy the relationship between a student and teacher is most important. For instance, Q859 => Q913 or Q1287486 => Q317947. In fact Student of could even replace P185 as it covers a broader set of situations.
Oppose Subjective property: which criterion is used to determine the largest parameter ? This can be deduced by multiple parameters query like "city of XX with the biggest population" or "city of XX with the biggest GNP". Snipre(talk) 09:17, 12 May 2013 (UTC)
Oppose This is not necessary. Simply use continental confederation with a qualifier from/start (e.g. My Favorite Team - continental confederation - CONCACAF - from - 9 May 2013). Obviously this has to wait on new datatypes, but so does this proposal. Joshbaumgartner (talk) 04:14, 10 May 2013 (UTC)
I'm a bit worried about the range of types. Public vs priavate is binary. Arts vs business vs technical is an axis. University vs universitary institute vs God knows what depends on legislation. --NaBUru38 (talk) 23:15, 25 February 2013 (UTC)
Oppose Start by using Is a(n). There is only one "type" field in that infobox, so there is no risk of conflict. The allowed item objects is not a limited list, so the bots don't need another type property. Mange01(talk) 02:27, 7 March 2013 (UTC)
Looks a little to country-specific to be usefull in a global perspective. It is always difficult for me as a Sweede to describe what kind of education I have, since we normally starts in University later than other in other nations and our time in school is normally shorter. Also post-graduate students have another kind of relation to the school than in other countries, even if the exam is the same. Lavallen (block) 09:05, 20 April 2013 (UTC)
it can be easily excluded from other certain ceremony templates or categories eg. ,and
Domain
subject domain is ceremonies, celebrations, festivals and holiday; object domain is song(s) or pieces of songs or poem(s) name(s) recently or traditionally sung or written
Example 1
MISSING
Example 2
MISSING
Example 3
MISSING
Comments: Some cultural events are traditionally accompanied by several old songs eg. you cannot consider Persian Nowruz ceremony separable from Doa-ye-Tahvil song in Iran. Sometimes there are songs improvised on a ceremony eg. Nowrouz Album, by Iranian singer, Shahram Nazeri, is dedicated exclusively to Nowrouz festival. Another example of this type is Happy Holiday, a popular Christmas song composed by Irving Berlin. As well as, "The Christmas Song" written in 1944 by M. torme & B. Wells and "stay cool by thinking cool", the most-performed Christmas song, together are some other samples for the proposed wikidata property. Doostdar (talk) 20:34, 8 March 2013 (UTC)
Oppose, I think this should be replaced with 'theme' as this would allow a less niche property whilst also helping ensure a better world view (they have different Christmas songs in Spain vs. U.K.). Basically I think this should be a property attached to the song etc. not the event.
Oppose This is not necessary. Simply use member of with a qualifier from/start (e.g. My Favorite Team - member of - FIFA - from - 9 May 2013). Obviously this has to wait on new datatypes, but so does this proposal. Joshbaumgartner (talk) 04:05, 10 May 2013 (UTC)
Actually I had created P:P357 as "title", par another discussion (about journal articles, I think). It was renamed to "original title" afterwards, so that we stil need a "title" property. We can really not assume that the label will always be the same as the title. For instance, old books may have very long titles, that do not fit into a label, or a book may have two titles (for instance translations), or an article in non-latin script may have a transliterated label (which would follow a rather common practice) that would obscure the real title. I think the simplest solution would be to rename P:P357 back to "title", as using a qualifer for "original" would be more flexible, and much clearer books that were never translated, and where title and original title are the same. In any case, a "title" property is needed. I don't see any use to restricting to books though, as the property is even more needed for journal articles cites in sources, and for some artworks. --Zolo(talk) 21:36, 14 April 2013 (UTC)
Sub continental confederation affiliation (en)
Not done
Description
The year the association joined the subregion (i.e. CECAFA, CEMAC, COSAFA, UNAF, WAFU))
Oppose This is not necessary. Simply use subcontinental confederation with a qualifier from/start (e.g. My Favorite Team - subcontinental confederation - UNAF - from - 9 May 2013). Obviously this has to wait on new datatypes, but so does this proposal. Joshbaumgartner (talk) 04:14, 10 May 2013 (UTC)
several infoboxes use this, like the ones given above, and probably others
Robot and gadget jobs
Should presumably be reciprocal with parent company, proposed above.
have left the German/French names blank because the interwiki links for subsidiary both link to articles called "filiale" which translate as "branch", and I'm not 100% if that's exactly the same meaning. (After all, branch can also mean two branches of the same bank, for example.) Buttons to Push Buttons (talk) 09:59, 10 March 2013 (UTC)
You're right, for some reason I was under the impression that property was for people only. Would it be an issue to use a field called owner for infoboxes which use parameter subsid? Not something I'm qualified to answer. And is there a need for distinction between ownership by people and ownership by organisations? Not sure on this one, but perhaps not. Buttons to Push Buttons (talk) 23:43, 11 March 2013 (UTC)
I think, that at the moment only the developers are qualified to answer. In my view,this shows that the property name is used only in the infoboxes, but will not be displayed. --Goldzahn (talk) 00:16, 12 March 2013 (UTC)
Actually, P127 should be on the above property, "subsidiary" is the opposite :). I dont know if there is any benefit in having a different property for people and for companies, but the current trend is toward rather general property, so it would sound more consistent to have just one. And the current property is already used for companies. --Zolo (talk) 18:38, 12 March 2013 (UTC)
Oppose: One property is enough. With checking for a second property e.g. gnd-type or something else one can conclude if the property means subsidiary or something else. I added this name as alias
I don't know if other creative works besides film and television series use this property. It would also be possible to reuse theProperty:P17, if the description is slightly adjusted, but I would prefer to seperate the "country of origin" from a the location of an item (Property:P17). Please comment what your opinion is!--CENNOXX (talk) 16:33, 11 April 2013 (UTC)
Helpful for the info boxes. Especially scientific work tend to have pretty long subtitles, that are not always suitable to print in full length.--Kolja21 (talk) 01:29, 4 February 2013 (UTC)
Comment Maybe, when qualifiers will be available, we could use them to add more subtitles adding a "qualifier" like "language edition". --Viscontino (talk) 10:09, 18 April 2013 (UTC)
Oppose You probably mean "period", but this should be clear by the list of publications. Description: "Dates from first publication to last publication." (w:en:Ferdowsi use this field in a special way.) --Kolja21 (talk) 15:29, 17 March 2013 (UTC)
Comment Ferdowsi's 40 year life had coincided with a change in governing regime i.e. the substitution of two dynasties of Samanids and Ghaznavids in Iran but for most of poets, writers, etc. it's not difficult to conceive the period in which he or she has lived. There won't be even any necessity for searching the date of his or her publications. دوستدار ایران بزرگ (talk) 11:22, 18 March 2013 (UTC)
Oppose Sorry, but this property would be the same as P:P407 (language). P407 is btw itself more or less a duplicate (the other way around) of P:P364 (original language). Qualifiers could be used here if necessary I think. --#Reaper (talk) 20:52, 25 April 2013 (UTC)
Oppose If each edition (including translations) gets a statement on the wikidata page for the book then P:P407 (language) will work as as a qualifier. We don't need this. The seem applies if each edition and translation is a seperate item.Filceolaire (talk) 17:14, 15 May 2013 (UTC)
Basically, it means we will be able to automatically get the number of items that are e.g. instances of live album (Q209939) and have a particular performer (P175). So, there is no need to hand-calculate it and add it ourselves. That would only be redundant and get out of date. I presume at some point such queries will be available for infoboxes, but I don't know the details. Superm401 - Talk21:55, 6 April 2013 (UTC)
I don't think that's really in the spirit of Wikidata. We don't to put in a lot of info we know we'll have to take out when queries arrive. For now, the Wikipedias can keep doing what they're doing. Superm401 -Talk19:31, 7 April 2013 (UTC)
Planned road length / Straßenlänge in der Planung / longueur de la route planifié
Not done
Description
length of the planned part of the road / Länge des geplanten Teils der Straße
Oppose as this is not manageable for most situations. In those cases where it is feasible to have this data, it can be done under 'length' (see above proposals) with a qualifier 'status' or some such. Joshbaumgartner (talk)
The list of studios can be found on the recording's booklet, or the artist's website. This information usually appears on the infobox of WP articles about the recording
Support, but it would be nice if we could set "item" DataType in case there's a WP article (not only for this case). --Viscontino (talk) 11:25, 19 April 2013 (UTC)
Support Mostly because many games have additional specific input devices, like the Dance Dance Revolution or Kinect games.— ΛΧΣ2116:41, 22 April 2013 (UTC)
Support I don't know exactly how to call the English label (TV = Show's creator; film = ?), but there should be a distinction between an artist like Leonardo da Vinci and the creator of a show's. (Right now both have the same property.) --Kolja21 (talk) 07:46, 16 March 2013 (UTC)
Support "An original idea by" is a common phrase in many works, not just television programs. I prefer the "idea by". --NaBUru38 (talk) 19:45, 27 March 2013 (UTC)
Currently Lupus has the MeSH ID instead of the MeSH code. So MeSH ID = D008180. I propose to move this meaning ID into the source and rename MeSH ID to MeSH code which would be C17.300.480 and C20.111.590 for Lupus and ID = D008180.
Format and edit filter validation
If it is used for a lot of different databases we can't apply any filters.
Strong oppose since we have already many properties for the ids in different databases this is not necessary. As you say we can't use filters here which makes it much more difficult and complicated to find wrong values. Also it will be more difficult to add ids for users because they have to set the database in the qualifier section (you should not use sources for that). --Pyfisch (talk) 15:21, 12 May 2013 (UTC)
Thanks for the review Pyfisch. I am still a little confused on how to best handle this kind of things. Could you maybe review this proposal Wikidata:Property_proposal/Term#MeSH_Code. I would like to know your opinion on 1) the creation of a second property 2) if one of the two properties should be a qualifier for the other one. --Tobias1984 (talk) 15:33, 12 May 2013 (UTC)
Oppose per Emw. Also, if there were a "member of" property, then it should be used instead of creating "member of X" for every X, which is redundant and pointless. Silver hr (talk) 00:46, 19 April 2013 (UTC)
Comment I don't see a redundancy with Property:P361 (from it's discussion page I gather the proposed use in cases where no more specific property for a part-whole-relationship is applicable). However "Member of a (musical) group" should be considered a special case of the "affiliation" relation between persons and organizations and as such is qualified by a period of time and roles. The domain of useful roles is influenced by the kind of organization. Affiliation itself would allow statements like "Sam Cutler was Tour manager for The Grateful Death in 197[?])" (or think of other roles like "legal representative", agent, ...) and there probably would still be the need to determine a narrower set of roles expressing bandmembership proper (what about "supporting musicians" anyway: "Tim Bonhomme is (employed as) keyboarder for the Beach Boys since 1993" vs. "David Marks ws guitarrist and vocalist of the Beach Boys from 1962-1963 and in 1997"). So maybe it would be best to keep the musical roles and the membership roles ("bandleader", "lead guitarist", does one really need them) completely separated, but all of them as datatypes strongle need a qualifier for the interval(s) of time this connection was valid. -- Gymel (talk) 07:24, 19 April 2013 (UTC)
The problem with this property and properties like it is that it's essentially creating a domain-specific property where a generic one suffices. It sets a precedent for an explosion of "member of X", "type of X", etc. properties. The expressivity of the statements given above is fully achievable by using generic properties like 'part of' instead of domain-specific versions of those generic properties. Emw (talk) 20:40, 20 April 2013 (UTC)
However this generic one shouldn't be Property:P361 for membership and roles (more general: relations between persons and organizations). My left thumb by transitivity is part of the matter in the universe but David Marks' thumb IMHO shouldn't be considered a member of the Beach Boys. -- Gymel (talk) 22:49, 23 April 2013 (UTC)
The relation seems even broader than just a "part of" relation between persons and organizations. For example, Germany is a member of the EU, but Berlin is not a member of the EU. I think what your use case is searching for is a way to get thehighest-level parts of some item. I think this use case would be better to support with one simple query technique involving part of, rather than a proliferation of "member of" properties that users would need to look up individually. Emw (talk) 04:31, 24 April 2013 (UTC)
There are 32 point groups that subdivide the crystal systems. They are derived from crystallographic symmetry operations. Every macroscopic crystal and mineral belongs to one of these point groups. The point group is equivalent to "crystal class".
Comment: Default unit should be changed to km/h since this property will most often be used for powered aircraft which do not us m/s as a normal unit for speed. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)
Support but there are some difficulties. 1) Incorporated places do have two different GNIS codes, one for the populated place and another for the incorporated subject, the GNIS does have different codes for e.g. Hibbing, Minnesota and the City of Hibbing, Minnesota. The issue is that neither in the EN nor in the DE Wikipedia (refer to de:Vorlage:Infobox Ort in den Vereinigten Staaten) one can be sure that in every case the "right" code was used; I even am not aware that this issue has been discussed before in the EN:WP. 2) GNIS also exists for the US Minor Outlying Areas and Puerto Rico. 3) There exist also GNIS codes in another databas for antarctic objects. At the moment I do not know wether only for those objects which have been named by the BGN or for any antarctic feature. --Matthiasb (talk) 13:24, 7 March 2013 (UTC)
Support But as Matthiasb said above, there's also a separate GNIS database for antarctic features with its own IDs. We probably need a separate property for those. --Kam Solusar (talk)
Enzyme Commission number (EC number) is a numerical classification scheme for enzymes, based on the chemical reactions they catalyze. As a system of enzyme nomenclature, every EC number is associated with a recommended name for the respective enzyme. (See: en:Enzyme Commission number
Seems useful, but unsure about the values. Why not allow further subdivisions (NNE, ENE, ESE etc.) for cases where further precision may be needed. Or even just use degrees to measure the direction? --Byrial (talk) 21:56, 25 April 2013 (UTC)
Well, I chose the 8 directions that have their items to make the extraction of data in various languages easier. Also, having in mind Property:P47, the neighbouring countries, states, regions, counties a.s.o. won't usually be in an exact direction from each other. But I agree that a numeric value can be comparably useful and it has potencial of another use in situations where more precise values would be possible and needed.--Šlomo (talk) 01:08, 26 April 2013 (UTC)
Comment It seems there's consensus that this property should not be restricted to the cardinal directions -- i.e. north, east, south and west. So I think this property should renamed to something like "direction". Also, the documentation should clarify whether the values for this qualifier are based on true north or magnetic north, and which coordinate reference system is used. Emw (talk) 16:49, 28 April 2013 (UTC)
Comment Having looked at the example (in the future, please give the actual labels so it's possible to read without going to each individual page), it's unclear to me why this property would use degrees 0-360 as values. Stating that "United States of America shares <0, 90 degrees> border with Canada" seems odd compared to "United States of America shares <north> border with Canada". So I think the original choice to use cardinal directions (and maybe intercardinal directions like NE, NNE) would be better than allowing degrees 0-360. Emw (talk) 17:03, 28 April 2013 (UTC)
Translating <0, 90 degrees> to <north and east> can be easily done by the software. I found the idea of azimuth values more useful, because it doesn't limit as for the future to use it more precise. If we use Item datatype, we are at this moment limited to cardinal and intercardinal directions - at least I didn't find items for NNE, NbE etc.--Šlomo (talk) 10:54, 1 May 2013 (UTC)
Ah, OK, thanks for the clarification. I think that should be made clear in the proposal. It should also be made clear that this qualifier handles exclaves of its subject. For example the United States shares a significant border on the east with Canada only in Alaska, which is not contiguous with the rest of the United States. Would this qualifier handleenclaves like Lesotho, which is an enclave of South Africa? If so, how? The list of enclaves and exclaves provide more edge cases that might be worth considering. Emw (talk) 00:12, 2 May 2013 (UTC)
Support But with cardinial directions, per Emw and Tobias1984. I would allow 16 items (north, north-east, north-north-east), but that's enough. The full 360 degrees really aren't needed here. On the contrary, it would only pretend to have a precision that the claim in most cases can't have; e.g. is the US-Canadian Border at 89, 90 or 91 degrees from the US?--Kompakt (talk) 09:32, 23 May 2013 (UTC)
16 would be OK too. If anybody want to know the azimuth angle between New York and Rome then that anyway can be calculated from the GPS coordinates of both cities. Everything more complex than a GPS-point will have to wait until geo-lines and geo-polygons can be implemented. --Tobias1984 (talk) 09:46, 23 May 2013 (UTC)
Is everybody Ok with me creating this property with "item"-datatype and 16 possible inputs? The reference system would be geographic and not magnetic. --Tobias1984 (talk) 16:52, 2 June 2013 (UTC)
I'm OK with the property being created, but I think its label should be changed. Cardinal direction refers to only north, south, east and west. If this properties allows more values than those, its label should not indicate it only allows those four values. Emw (talk) 21:26, 2 June 2013 (UTC)
Taxon publication year (withdrawn)
Description: The year of the publication.
Datatype: Date (Precision: Year)
Allowed values: 1753 - present year
Infobox parameter example: "1755" for Prunus avium
I'm not sure. It seems too generic. The property description is "date when this work was published" (or "Date of the publication of the book"), but strictly speaking the taxon description (a work) is not the same as the taxon (which is what the item is about). But maybe it's close enough, I don't know. - Soulkeeper (talk) 14:14, 30 May 2013 (UTC)
The reason to create it is the same as for ATP player ID (P536) (see old discussion here). The id is appended to the urlhttp://www.wtatennis.com/players/player/. It will make it possible for bots to update data automatically from the WTA website.--Kompakt (talk) 09:44, 30 May 2013 (UTC)
Support - analog to the ATP_id parameter we recently introduced. This IFT parameter leads to more player statistics, and is pretty essential. Edoderoo (talk) 07:32, 31 May 2013 (UTC)
Until maybe one or two years ago, all articles were categorized by specialty and urls were formatted in that way. The old urls will still redirect to the new articles, however some have been merged on emedicine and some articles now have several links to the same emedicine page. Maybe they can be updated with the help of a bot one day.--Wouterstomp (talk) 19:20, 26 May 2013 (UTC)
It may be a good idea to look at switching to pubmed health from medline plus. There are slightly better IMO even though both are similar.Doc James (talk · contribs ·email) (if I write on your page reply on mine) 21:20, 1 June 2013 (UTC)
if it is there, it's always notable, because the artwork is notable, so for example the artwork probably influenced another younger artist somewhere who saw it in an exhibition, etc. Though the Mona Lisa was "seen" in print by many artists before travel became easier to do, recording its whereabouts is definitely notable for other reasons (security issues, influences on modern artists or public opinion, art history publications, etc.) --Jane023 (copied from Wikidata:Artworks task force/Properties)
Comment could possibly use a more general property but I cannot think of any (it is distinct from location)--Zolo (talk) 12:55, 31 May 2013 (UTC)
Question We probably should distinguish different versions of NUTS: NUTS 1995, NUTS 1999, NUTS 2003, NUTS 2006 and the current NUTS 2010 in order to facilitate the later automatic integration of statistic data. What do you think? --Monsieurbecker (talk) 07:14, 22 March 2013 (UTC)
Oppose We should name every property as accurate as possible to prevent confusion. If there are really diffrent NUTS versions, we should a.) create multiple properties for every version b.) name it with the version. --Nightwish62 (talk) 21:26, 23 March 2013 (UTC)
Support, but please let us wait one or two weeks till qualifiers are available. Ok? What we also need is a new generic property 'version' (Data value: String). At moment there is only a property 'stable version' for software. However, I even think this property should be deleted/renamed to 'version' and use qualifiers for 'stable/unstable' status also. --Nightwish62 (talk) 15:19, 30 March 2013 (UTC)
Support, perhaps as a temporary solution until qualifiers can be used to differentiate sources, dates and versions of Nuts data from each other.Mange01 (talk) 13:44, 30 March 2013 (UTC)
All gliders could meaningful be caracterized by (most of) the propertis listed below. It would be nice, if after stating, that a LS4 (Q544661) 'is a' Glider (sailplane) (Q180173) the property-list below pops up for filling in.
Construction and production
Title
ID
Data type
Description
Example
Inverse
role
?
Item
the role(s) the sailplane fills, eg. trainer, acrobatic, touring motor glider, motorglider
<Glaser-Dirks DG-400> role <Motorglider>
–
class
?
Item
the classes the glider type usually competes in, eg. club class, standard class, 15 m class, 18 m class, open class
<Glaser-Dirks DG-400> class <Club class>
–
national origin
?
Item
the country, where the type was constructed or first made
Comment Maybe "type of aircraft" would be better than "role"? At least touring motor glider and motorglider should be "type of aircraft", but "trainer, acrobatic" is something else. I think, it is more what this aircraft is used for. --Goldzahn (talk) 12:49, 14 March 2013 (UTC)
Support 'role': 'Role' and 'type' can definitely be distinct properties. 'Role' generally indicates a purpose for the aircraft (i.e. what it does) while 'type' is often more a description of its design (i.e. what it is). These obviously can be hazy lines and overlap, but having the property named 'role' seems to give more indication of usage. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)
Why an opposition ? Here we have different targets for class. Instead of using the same property which will mix different types of association better use an accurate name for the property like plane class Snipre (talk) 20:26, 22 March 2013 (UTC)
Oppose 'national origin' and 'produced period' as proposed. 'National origin' should be changed to 'country of origin', as aircraft are categorized by country, not nation () and 'produced period' should be changed to 'production period' for better English readability. Joshbaumgartner (talk) 02:41, 30 April 2013 (UTC)
This property would be used with the terminus property (which notes the feature at which the item terminates at, like a railway station or intersecting road) to indicate the location of the termini. Initially, this was thought to be able to be handled by a qualifier to the terminus property. Unfortunately, road termini often have several different roads at the terminus intersection; see Oklahoma State Highway 325 as an example, which ends at a traffic circle that five other highways pass through. As a result, the qualifier is in the administrative unit <Boise City> has to be duplicated five times. This property would eliminate the duplication, resulting in a cleaner, more maintainable database. —Scott5114↗[EXACT CHANGE ONLY]09:28, 30 May 2013 (UTC)
The Diseases Database is a database that underlies a free website that provides information about the relationships between medical conditions, symptoms, and medications. (From en:Diseases_Database
Code for Ancient buildings and monuments, Ancient traditions, Astonishing human made creations in Iran enumerated by Iran Cultural Heritage, Handcrafts and Tourism Organization
Interesting queries would be possible with this property. Needs a lot of feedback from different branches of science so it we can get the most out of it. For animals there should probably be a separate food chain property. Tobias1984 (talk) 12:36, 10 May 2013 (UTC)
I think it would be most practical to treat machines and biological organisms separately. Biology is generally much more complex than mechanics. - Soulkeeper (talk) 14:22, 10 May 2013 (UTC)
SupportQuestion There are several applications for this as a generic energy source data point. Many more specific ones have been proposed, such as 'powerplant' for aircraft or similar ones for ships, etc. Is this intended to cover these, or is it only designed to be the more general basic source, and not the engine for the energy to be made available to the subject? i.e. shouldSupermarine Spitfiresource of energyaviation fuel, or should it be more specific and beSupermarine Spitfiresource of energyRolls-Royce Merlin? I think this is good property and support it, but I do think that it will take some refining in practice to get the best out of it. Joshbaumgartner(talk) 06:51, 13 May 2013 (UTC)
I was thinking that this property should only be for the fuel and not for the engine, taking your example. It would allow for such queries as "What are all the things that have wind as a source of energy" and return "Windmills, ...". A query for "aviation fuel" would return "Airplanes". For the individual airplanes we should probably be more specific as the Boeing Dreamliner for example also uses batteries as a source of power. --Tobias1984 (talk) 07:19, 13 May 2013 (UTC)
I am liking this property, and it makes sense to me to think of it as the form of energy that enters a system, vs. how that energy is translated into motive or other force. I am not sure about batteries however, as wouldn't that simply be a way of storing energy that has already entered the system or been created by the system, and be kind of like putting 'fat cells' as a source of energy for 'human'?Joshbaumgartner (talk) 05:33, 16 May 2013 (UTC)
Support I like this is a generic term which would include solar panels for satellites, nuclear reactors for submarines etc. The misnamed "powerplant" is intended for types of engines? Secretlondon (talk) 14:09, 18 May 2013 (UTC)
Comment - Having thought about it, this property could be used for submarines (diesel or nuclear power), cars (as in what kind of fuel, hybrids = Li-battery+fuel), airplanes (kerosine, boeing-dreamliner=Li-batteries and fuel), different toys (AA-battery, AAA-battery), cell phones (Li-battery). --Tobias1984 (talk) 07:08, 6 May 2013 (UTC)
Comment Supporting actors range from bit parts to secondary leads, it's not as clear as on Property:P161 which of them should be named, only walk-on-roles, only "Over-Five"s, ...--CENNOXX (talk) 14:47, 27 March 2013 (UTC)
Support such a property, but unsure which name it should have. 'as' could be used outside move/characters also, but I don't know if this is an advantage or disadvantage. --Nightwish62 (talk) 10:22, 19 April 2013 (UTC)
In eswiki is more common to use this page instead of IMDB. Filmaffinity is in english and spanish. Most articles in eswiki already have the id and only needs to be imported. Kizar (talk) 14:40, 17 April 2013 (UTC)
Since Property 306 (Operatingsystem) only lists the operating systems the software runs native, but not if the program can be used with Wine and including this information directly to Wikidata wouldn't be a good idea for several reasons (depending on versions and setting, fast changing, good database existing, no need for competition), I would suggest to make it possible to connect Wikidata to this existing Database. MichaelSchoenitzer (talk) 16:09, 18 April 2013 (UTC)
Support I think we could add Wine as value for the platform property, I think this would be work and be ok. --#Reaper (talk) 14:03, 21 April 2013 (UTC)
сайт NASA, launchlog, карточки в статьях, список запусков и т. д./ NASA's website, launchlog, articles etc
Robot and gadget jobs
Могу настроить бота на проверку значения свойства по какому-либо источнику, например, launchlog-у./I can set up a bot to get the value from any source eg launchlog
Comment I changed "spacecrafts" to "spacecraft", the English plural (and singular) form of the word is "spacecraft". Cheers. N2e (talk) 12:45, 27 April 2013 (UTC)
Comment - How will this support entries where the exact day or time is not known - for example listing something that happened in October 1997 but on an unknown day, something which happened at an unknown time on 15 October 1997, or something that is listed as happening at 16:01 on that date, but the exact second is not known? --WDGraham (talk) 00:05, 28 April 2013 (UTC)
CommentAdded decay date which use on en: for when a craft re-enters. We need to be careful with sources. Launchlog from Jonathan's space page is a good source, but is it usable? NASA's NSDDC we generally don't think is accurate enough. Secretlondon (talk) 12:27, 27 April 2013 (UTC)
дата первой стыковки, дата первой расстыковки, дата второй стыковки, дата второй расстыковки и т. д., dates of first and second docking and undocking etc.
Railway stations in post-USSR countries usually have two codes: UNL code (Russian код ЕСР) which used for cargo transportation and Express-3 code which used in pessenger transportation, e.g. in the tickets. For the UNL code we can use property P296, but for second code we need separate property.Ahonc (talk) 10:51, 2 May 2013 (UTC)
Comment: I expect it's the same data than the UIC station code I suggested above. The 3 Express-3 code I have found, Kiev(2200001) Tashkent (2900001) and Ulan Bator (3100022), share the same pattern : 7 digits beginning with the 2-digit UIC country code. Ske (talk) 12:12, 22 May 2013 (UTC)
Support Ricordisamoa's proposal, adding a qualifier like "statistic institute" to specify the one that set the code. --Viscontino (talk) 13:22, 5 May 2013 (UTC)
Support I'm agree to create a general "statistic code" property (with a qualifier property to distinguish between institutions), but until its discussion and approval, it is better to create this property to import the ISTAT code of municipality. --Paperoastro (talk) 13:08, 27 May 2013 (UTC)
route of administration (Q621636) A route of administration in pharmacology and toxicology is the path by which a drug, fluid, poison, or other substance is taken into the body.
Protein Data Bank (PDB) contains 3D structures of proteins and nucleic acids. This property will provide access to such structures and associated images for the corresponding biological molecule.
Support - though in cases where multiple PDB IDs exist, I think they should be two instances of the same property (rather than concatenating them into a single field.) Andrew Su (talk) 21:47, 10 June 2013 (UTC)
Support – The filter however should be made more specific (a four letter code composed of a digit followed by three characters that can be either digits or letters, regex: "[0-9][a-zA-Z0-9]{3}"). Boghog (talk) 16:48, 15 June 2013 (UTC)
Support It's a useful database with a lot of information (date of birth, date of death, date of Legion of Honour, the resume of a person...) Pyb (talk) 11:37, 14 June 2013 (UTC)
For sportspeople, we have occupation (P106). For organizations, I would recommend to extend 425 as well, to, say, "field of activity" or something. We will need such a property not only in sports, but for all kinds of different organizations, e.g. companies.--Kompakt (talk) 10:10, 26 May 2013 (UTC)
Support I think "field of activity" is too broad and would prefer a separate property for sport to make it easier for editors to find the appropriate item. A property for "field of business" or similar can be created for businesses.
If the devs decide that a single property covering both of these would make search queries better then they can create a "subproperty" in phase 3 and define "sport" and "business activity" as subproperties of "field of activity". Filceolaire (talk) 21:35, 6 June 2013 (UTC)
It would be used also to indicate the discipline practiced for an athlete? For example, Pietro Mennea --> 200 metres. If yes, I'm Support. If not, it's the same ;-) (but something for Pietro Mennea --> 200 metres would be useful). -- Yiyi.... (talk!) 17:26, 16 June 2013 (UTC)
I'd suggest that sport = 200 metres (Q211155) would work just fine. I've claimed it as a subclass of sprinting, which is a subclass of athletics, and so on. So, the wider sport category can be found. Danrok (talk) 00:32, 17 June 2013 (UTC)
We need a way to say that X is mayor of village Y for any village. As discussed in Wikidata:Project_chat/Archive/2013/05#Political_offices, putting that in the item about the village iteself does not seem a practical solution. Creating a "mayor of village Y" item for every village does not seem really seem a sensible solution either (unless there is anything specific about the mayor of the village compared to mayors of similar villages). --Zolo (talk) 10:43, 11 May 2013 (UTC)
Maybe can also be used for captials: (if we are supposed to use "instance of" for that)
Since different kinds of capitals use different names (huvudstad, residensstad, centralort), something who tells what kind of capital is needed. -- Lavallen (block) 10:53, 11 May 2013 (UTC)
Support The qualifier seems useful, but meanwhile I see the potential for abuse, perhaps someone would add statements like "<X> occupation <politician> of <United States of America>". I suggest that the qualifier should only be used when the information cannot be stated using other properties. --Stevenliuyi (talk) 18:59, 14 May 2013 (UTC)
Okay, adopting this idea would have some serious consequences, so this should be discussed thoroughly before being implemented. Having "of" as a qualifier means that the qualifier property itself isn't really adding any data, so it's basically a way to have a top-level property accept two arguments. If Lavallen's idea about "instance of" "capital" "of" X is used, that would mean that either it or P:P36 is redundant. Re use for mayor, the fact that there are some items like Q785304 complicates it somewhat. There are hundreds of potential uses for this qualifier, but we should examine whether these are generally better than using an alternative solution. Also, we might want to ask the devs whether there are any plans to deploy a proper multi-item/argument property type at any point. --Yair rand (talk) 02:26, 20 May 2013 (UTC)
Could you elaborate on the "serious consequences". I can sort of see that it seems to stretch the intended use of qualifiers, but still I think it would not really break anything. If X is the mayor Y, he is really an instance of mayor, so that it do not really make statements false.
There does not seem to be any plan for anything like that by the developers in the initial development plan, so if something gets developed, it is unlikely to be this year. --Zolo (talk) 15:44, 18 June 2013 (UTC)
Support Needed as a qualifier not only for mayors, but for many other functions (<dean> of a <faculty>, <bishop> of a <diocese>, <coach> of a <sports club> etc., as well as for some other properties (e.g. award received (P166) <honorary citizenship> of a <city/country>). On the other hand, I'm quite afraid about using a general <of item> qualifier together with a general <instance of> statement to make a statement of anything. We could help it if we make clear guidance how to use it. Stevenliuyi's idea (see above) of using it only as "ultima ratio" can be a good start, I would propose creating a list of properties which can take <of item> property as a qualifier - in a similar way as we have a list of acceptable values for some properties.--Shlomo (talk) 10:57, 11 June 2013 (UTC)
Comment As a large contributor to many other external identifiers like Slovakia (Q214), having these connections between the two can make a great bridge to draw other data across. So this could potentially be a boon to our other properties, and means that Wikipedias could include freebase properties. The reason I don't support is because I have to better understand Google's motivations before we start linking with them. Maximilianklein (talk) 19:14, 14 June 2013 (UTC)
Comment Freebase, and by extension the Knowledge Graph, makes use of WP infobox data and it would be great to close the loop so that fixes in either dataset get propagated in both directions. This would make it easier Google and Freebase to use WikiData as well as making it easier for WikiData to pull data from Freebase. This will improve the quality of both datasets over time. --2620:0:1000:147D:1610:9FFF:FEDF:EC57
There should certainly be no loop. Just imagine Wikidata using Freebase as reference and Freebase using Wikidata. We cannot use data from from Freebase. Byrial (talk) 17:29, 17 June 2013 (UTC)
Comment IMHO we should discuss it widely with the community, before even accepting to link a similar database. --Ricordisamoa08:57, 17 June 2013 (UTC)
Actually, I can imagine that there would be some benefits for Google, as it would probably outsource some of the curation work needed for Freebase. I am not so sure about the benefits for Wikidata as we have stricter requirements in terms of sources, and of license, that may make it hard to use Freebase content. That said, I cannot see what harm there can be in having this link. --Zolo (talk) 15:18, 17 June 2013 (UTC)
Support - In my opinion there is no harm to link to Freebase, but nothing really to gain as freebase is of poor quality for most scientific topics (The other items probably not meeting the notability standards). I oppose importing data and properties. That would just increase the "imported from Wikipedia" source problem. Lastly one has to admit that any structured information added to Wikipedia and Wikidata (or the internet for that matter) will benefit the business models of internet search engine providers. A point we might as well ignore, the Wikimedia foundation should charge for, or we have to be thankful for the donations (e.g. Google, Yandex). --Tobias1984 (talk) 16:08, 17 June 2013 (UTC)
Comment – I cannot see any gain from having this property, but I would like to see a motivation for the proposal before definitive saying no. Byrial (talk) 17:29, 17 June 2013 (UTC)
Support linking to Freebase, just like we link to all sorts of other databases, as well as using it as a source in the "imported from" field, seeing as we've historically allowed using user-generated sources for the importing of statements. — PinkAmpers&(Je vous invite à me parler)00:50, 18 June 2013 (UTC)
Support Caution, identifiers are non-unique. There can be several OLXXXXXW work numbers for one work, several OLXXXXXXM edition numbers for one edition, and several OLXXXXXA numbers for one author. There is a redirect mechanism on OpenLibrary, but it does not work cleanly at this time. LeadSongDog (talk) 21:10, 5 June 2013 (UTC)
Support The label is disambiguate. Do we need two identifiers? If this one should be for books (works and editions) what is the label for the "Open Library identifier"s for authors. --Kolja21 (talk) 15:26, 15 June 2013 (UTC)
No, but P596 (P596) appears to be redundant to direction (P560), so I will be headed off to properties for deletion after this. The difference here is that 560/596 are used to tag the direction of something (e.g. distinguishing between the north and south ends of something). This property would be to establish location relative to something else (e.g. establishing that something is north of something else). The reason both are needed is because of things like the terminus location parameter proposed directly above this; a location may need to be qualified as referring to the north end of the item, but being west of some city. —Scott5114↗[EXACT CHANGE ONLY]08:02, 6 June 2013 (UTC)
If P596 (P596) is meant to fulfill the purpose of this proposal, then its documentation needs to be improved to make this evident, as direction of something versus direction relative to something is a subtle point, and the way the documentation is worded now makes it look wholly redundant to direction (P560). —Scott5114↗[EXACT CHANGE ONLY]09:14, 6 June 2013 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Yes, P596 (P596) should be relabelled and better documented, but looking at how it is used, it seems to be different from direction (P560).
I think that this proposal is similar to how P596 is used, except that the syntax is inverted:
In the second case, "West" means West of the property value, while in the first one, it means West of the item, so East of the property value. That seems potentially confusing, and I think we should have just one format, but I really do not know which one. --Zolo (talk) 07:24, 7 June 2013 (UTC)
See, to me that looks a lot like what direction (P560) is doing. Asia has multiple borders. One is with Europe. Which one? The west border. (By analogy to SH-132—the highway has multiple end points. One of them is at SH-51. Which one? The south end point.) I think that P596 (P596) is probably a lot closer to direction (P560) than to this proposal. I agree, it's a somewhat confusing distinction to make, but I think it is one that should be made. —Scott5114↗[EXACT CHANGE ONLY]10:05, 7 June 2013 (UTC)
Support --Chris.urs-o (talk) 12:07, 22 May 2013 (UTC)
Comment of course we could also use the properties preceded by and followed by for these relations. I'm not really sure how that would influence possible querries in the future. --Tobias1984 (talk) 15:42, 9 April 2013 (UTC)
Wait for TimeValue datatype. --Eric-92 (talk) 03:08, 11 February 2013 (UTC)
Done as Property:P576. Generic to all organisations, not just football clubs. Del♉sion23 (talk) 21:18, 29 May 2013 (UTC)
Question – How would you distinguish between a statement for a specific date, and a statement for a state that has not yet ended, and thus is still valid? -- Byrial (talk) 20:31, 20 April 2013 (UTC)
Oppose Once the date datatype is available, it seems clear we will quickly have generic 'from/start' and 'to/end' properties which should cover this when used as qualifiers for 'member of team' claims. Joshbaumgartner(talk) 09:33, 9 May 2013 (UTC)
Move from unsorted to organizations. Joshbaumgartner (talk) 05:17, 17 May 2013 (UTC)
Oppose If each edition (including translations) gets a statement on the wikidata page for the book then P:P407 (language) will work as as a qualifier. We don't need this. The seem applies if each edition and translation is a seperate item.Filceolaire (talk) 17:14, 15 May 2013 (UTC)
Strong oppose per Nightwish62 and Superm401. --Ricordisamoa 22:22, 6 April 2013 (UTC)
Support But with cardinial directions, per Emw and Tobias1984. I would allow 16 items (north, north-east, north-north-east), but that's enough. The full 360 degrees really aren't needed here. On the contrary, it would only pretend to have a precision that the claim in most cases can't have; e.g. is the US-Canadian Border at 89, 90 or 91 degrees from the US?--Kompakt (talk) 09:32, 23 May 2013 (UTC)
Done: Property:P519 Without version, we'll use qualifieres for that. -- MichaelSchoenitzer (talk) 21:35, 14 May 2013 (UTC)
Strong support --Tobias1984 (talk) 20:23, 1 June 2013 (UTC)
