:{{s}} and will also be useful for languages/methods where we don't have a specific property :) --[[User:Hsarrazin|Hsarrazin]] ([[User talk:Hsarrazin|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:25, 7 August 2015 (UTC)
:{{s}} and will also be useful for languages/methods where we don't have a specific property :) --[[User:Hsarrazin|Hsarrazin]] ([[User talk:Hsarrazin|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:25, 7 August 2015 (UTC)
:{{oppose}} Transliteration properties make only sense as qualifier on name properties. This proposed property also requires a qualifier. We don't have qualifier on qualifier, so how can you use that? --[[User:Pasleim|Pasleim]] ([[User talk:Pasleim|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:32, 4 October 2015 (UTC)
:{{oppose}} Transliteration properties make only sense as qualifier on name properties. This proposed property also requires a qualifier. We don't have qualifier on qualifier, so how can you use that? --[[User:Pasleim|Pasleim]] ([[User talk:Pasleim|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:32, 4 October 2015 (UTC)
=== {{TranslateThis | anchor = en
| en = construct has conceptual overlap with
| de = <!-- PROPERTY NAME IN German (optional) -->
| fr = <!-- PROPERTY NAME IN French (optional) -->
<!-- |xx = property names in some other languages -->
}} ===
{{Property documentation
|status = <!--leave this empty-->
|description = {{TranslateThis
| en = measures of the strength, or assessments of presence, of these two constructs correlate
I want this for my work with personality traits. There are many named traits and many of them are highly similar to one-another. [[User:Antrocent|Antrocent]] ([[User talk:Antrocent|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 06:38, 29 June 2015 (UTC)
;{{int:Talk}}
: {{comment}} Not a good idea to start a proposal saying "I want this for my work". A property is not a personal tool but a general tool which have to be useful for everyone. [[User:Snipre|Snipre]] ([[User talk:Snipre|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 07:48, 29 June 2015 (UTC)
: {{oppose}} This could be handled by {{P|1382}} (with perhaps minor tweaking of its description and aliases) and/or {{P|460}}. [[User:Swpb|Swpb]] ([[User talk:Swpb|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:28, 24 September 2015 (UTC)
Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2025/06.
Generic properties
language, except for works or persons
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Discussion
CommentP:P364 used to have the label "language". To match more closely its description, it's now labelled "language of the original work". This leaves a gap for cases like the above. --- Jura04:52, 12 December 2014 (UTC)[reply]
SupportComment One day we will have also wictionary linked, so every word must have a language. Not only names, but also radio/tv stations broadcast in languages. However names are a bad example, because names tend to move between languages, sometimes unchanged over centuries and sometimes more or less modified.--Giftzwerg 88 (talk) 05:14, 12 December 2014 (UTC)[reply]
Can you explain why this should have an impact? The properties you mention are about works, this proposed one is explicitly not for works. --- Jura12:35, 18 April 2015 (UTC)[reply]
I don't see that discussion going anywhere, nor is the merge proposal formulated that way. The result is that we still haven't sorted out this issue. --- Jura13:03, 18 April 2015 (UTC)[reply]
Support. The specialised properties are worth having but it is good to have this more general property for cases where those don't apply. Filceolaire (talk) 17:55, 18 June 2015 (UTC)[reply]
Oppose. We don't need specific properties, even two is too much. Single "language" property is enough. P364 shall be merged with P407 to such single property. -- Vlsergey (talk) 16:08, 26 June 2015 (UTC)[reply]
Oppose. Agree with Vlsergey here. One language property is enough for works and other items. It's different for people who need to differentiate native language and other spoken languages. --Hsarrazin (talk) 17:53, 1 August 2015 (UTC)[reply]
I think you might have misunderstood the proposal. We lack a generic property for languages. This is the proposal for it. --- Jura19:44, 29 September 2015 (UTC)[reply]
If that is true, then it should simply be 'language' and lose the 'except for...' part. Those more specific properties can then be marked as sub-properties of this one. Josh Baumgartner (talk) 17:51, 27 October 2015 (UTC)[reply]
So basically this is for entries where a word or name in and of itself is being discussed (i.e. in etymology and usage), and this is inescapably linked to one or a few languages? Circeus (talk) 23:51, 29 October 2015 (UTC)[reply]
(Disjoint)UnionOf (or any better name)
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Note
This proposal is a proposal for Two properties:
UnionOf
DisjointUnionOf
(to get the definition of the first, take the text in green, resp in red for the second) plus one new qualifier :
Together With.
Motivation
Sometime users use has part(s) (P527) as a kind of inverse properties of subclass of (P279). This is semantically wrong as has part if for composition relationship of physical objects (or classes of those type) that are parts of other (bigger) physical objects (or classes of those whole objects), per Help:BMP, and NOT to give a list of the subclasses, like in the example give who was modeled as has part.
There would not be a case if we were just talking of an inverse property of subclass of (P279), but we're not. Here we want to say that the set of all instances of a set of classes (here proton and neutrons), when regrouped, is exactly the set of instances of the superclass (here nucleon). No instance of nucleon is neither a proton nor a neutron.
Example : let Academics be the set of person who teaches, studies or research in a faculty.
let teacher, student, researcher (be the class of persons who teaches, rep. studies and research in a faculty.
means that any student, researcher and teacher is an academic, that no person who is neither student, researcher nor teacher is an academic. But a student can also teach, as a researcher.
With the disjoint variant (in green), the constraint is added that an instance of nucleon is an instance of one and only one of the subclasses. Said differently, that the set of subclasses is a partition of a set (Q381060) of the subject class.
as a nucleon is a proton or a neutron, but not both.
So the motivation is double :
give an alternative to those who want to put a list of subclasses of a class (don't do that, this is incorrect, do that instead)
improve our modeling expression power.
Note : the qualifier Together With is here because the set of subclasses must exist in the same statement. This is because if we gave the list of classes in a list of statement, we could not express that there is no other subclass needed to cover all the instances of the superclass, as Wikidata follows the open-world assumption (Q851949) (This means we could even use two statement to model two alternative divisions of the class in subclasses for all of its instances). For example let's just add a subclass to nucleon, I don't know highly energetic nucleon. It's a subclass of nucleon, but it would not make sense to add it into
Note2 : DO NOT USE if the class list is not close, of course, that is if there is instances of the superclass that is not an instance of any of the child classes, or if it's not sure whether or not.
@Visite fortuitement prolongée: should be better now. this and that is a common way to speak of resp the subject and the object of the claim. The names are the name given in owl as the links can show, but other are OK if people find this more clear. Union in math is the operation on set, for sure. I don't know about common english
Per Help:metaclass_for an explanation. A class is a set of indvidual. two classes unionned gives another set of individuals, another class. A class of class unioned with a class of class gives a class of class, similarly. But a class should not be unioned with a metaclass to avoid some ontological problems. TomT0m(talk)20:38, 11 May 2015 (UTC)[reply]
I'm not sure if I get the "Together with" qualifier point. Qualifiers are also open to be extended, so I don't see why having all values within a statement makes it more close than having one statement for each value. Qualifiers are extendable as statements are, there is no way to prohibit that. Therefore, I'm also not sure if we should actually introduce such limited classes, as that is contradictory to the open system of Wikidata. -- Bene*talk21:08, 9 May 2015 (UTC)[reply]
Good question. I take the opinion of Markus here : see this post on the ML. I think this makes sense for closed lists, it's an easy way to express that, way easier than for example having a sequence of items with followed by (P156)/follows (P155) terminated by
This way, it can not work. TomT0m need a change of Wikidata data structure, or a trick. "together with" is a trick. Of course, since TomT0m has not show an actual example of several, distinct, subclass lists, I do no support "together with", and you are free to oppose it. But I hope that with my explanation, you understand the need. Visite fortuitement prolongée (talk) 19:43, 11 May 2015 (UTC)[reply]
It's not a trick, it's a use of qualifiers to express close lists. TomT0m(talk)
@Filceolaire: No. This must be expressed in one statement. It make sense to say that Paul is a son of Jack. It also make sense that Jenny is a daughter of Jack. But from these two satements, we can't say if Jack have more children per open-world assumption (Q851949) which is reasonable in Wikidatas case. With disjoint union this does not make sense to say « nucleon union of proton » and « nucleon union of neutron », no more than in english. This has to be « nucleon union of proton and neutron ». Plus this allows us to say the list is close (see the discussion with Bene* above and the linked mail for this.) Without a qualifier this is as good as «has subclass». TomT0m(talk)19:58, 11 May 2015 (UTC)[reply]
« Without a qualifier this is as good as «has subclass». » → Not exactly. "nucleon => UnionOf => proton, neutron, antiproton, antineutron" say more than "nucleon => subclass => proton, neutron, antiproton, antineutron"; because it say that the classes list is complete ("closed"). The difference is that without "Together With" qualifier, an item can have only 1 classes list, so we could no tell that... wait, what was this real example of you? Visite fortuitement prolongée (talk) 20:20, 11 May 2015 (UTC)[reply]
No, the meaning argument that a set of two sentence is not the same as one sentence still holds. But you're kind of tiring me. If you really don't want to be convinced follow the links to the owl properties, you'll see they uses one compound statements, not several statements with the same properties, for good reasons. TomT0m(talk)20:30, 11 May 2015 (UTC)[reply]
Oppose I never thought I would O in a proposal of mine the solution without the qualifier. Without it it's as good as has_subclass, as explained above. Of course I Support the original proposal :) TomT0m(talk)20:14, 19 May 2015 (UTC)[reply]
@Visite fortuitement prolongée: That's nonsense, really. First, it's not meant to ba an inverse property of subclass of. Second, I am one of the authors of this template and I can make your example work in no time, no problems, it's not hard. But the real solution is to wait for the devteam to implement simple queries to compute inverse relations, then we will be able to adapt the template properly. TomT0m(talk)20:39, 17 June 2015 (UTC)[reply]
Oppose use as proposed but Support as a qualifier to string and text properties in other languages. The hanja version of the name for Pyongyang should be given by official name (P1448) and/or native label (P1705) and/or name in native language (P1559), not by this property (but use the "Romanisation" qualifier to give the Latin script version of each of these names). This property could however be used to give the hanja name for "London" in a qualifier to the official name (P1448) property for use in Korean language infoboxes. I have changed the example as my version of this property. Nikki please check and confirm you copy. Filceolaire (talk) 01:01, 27 June 2015 (UTC)[reply]
@Filceolaire: Your example is incorrect, that's not en:Hanja, it's en:Hangul (the way Korean is normally written). This property would be very similar to name in kana (P1814) (which you supported without requiring it to only be used as a qualifier - has something changed since then?) - like Japanese is not primarily written in kana, Korean is not normally primarily written in hanja, and like kana is often included in name templates, in brackets in opening sentences, etc, hanja is too, so it should be allowed anywhere that name in kana (P1814) is allowed, i.e. as a qualifier if it's the hanja version of a Korean name in a statement using properties like native label (P1705), name in native language (P1559) and official name (P1448) or as its own statement if it refers to the hanja version of a Korean label (since labels can't have qualifiers themselves). - Nikki (talk) 06:40, 27 June 2015 (UTC)[reply]
You raise a good point Nikki. Thinking about it some more. There is a difference between a property called "name in Hanja" and a property called "hanja".
"name in Hanja" could be a property specifically for names. It is similar to all the other multiple "name" properties we have and it can be used as a primary property just like official name (P1448), native label (P1705) or name in native language (P1559). This is based on the assumption that if an item has multiple names then the hanja name just another, additional name independent of the other names.
If, on the other hand, each of the multiple names needs a it's own hanja version then it seems the "hanja" is an alternative way of writing those names rather than being a separate name (and should be used as a qualifier). Which case applies? Filceolaire (talk) 02:31, 28 June 2015 (UTC)[reply]
@Filceolaire: I feel like I have already explained it as best I can so I don't really know how to continue this discussion without getting frustrated by going round in circles and repeating myself. If you're still opposed to the property, then we might as well reject it and revisit it when people who have experience with Korean are willing to contribute to the discussion. Alternatively, if changing the label to "name in hanja" makes it acceptable, let's do that. - Nikki (talk) 13:01, 18 September 2015 (UTC)[reply]
I'm sorry Nikki. I didn't mean to harass you. I've done some more reading and I think I understand the difference now. Hanja is the name written using 'chinese' characters. I think a better way to handle this is to have two different values for the various monolingual text proeprties - one in hangul and one in hanja with different codes to indicate if it is 'ko-hanja', or 'ko-hangul'. Unfortunately this is not allowed at the moment (I tried something like this on Park Geun-hye (Q138048) but I think you had better check I got it right). There are bugs on manifest for this T74590 and T95286. I'm afraid I do not think that a separate property like this is the way to go so I will Oppose this proposal. Joe Filceolaire (talk) 16:14, 18 September 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Property might be useful for automatic generating readable descriptions from statements if object name is not available in any readable script in user language. This might be a standard way to provide transliteration or transcription of the name between many languages. The examples above are biased because they show romanization only, but other direction is also possible. Unfortunately I am not able to provide any such example. Paweł Ziemian (talk) 17:50, 27 June 2015 (UTC)[reply]
If the conversion is some kind of international standard like Hepburn romanization (Q667558) or ISO 9 (Q913336) it can be promoted to separate property. However, there are cases where such translation is country/language specific and generating N×N - N (country/language) properties is ridiculous. One generic property should serve for all relatively rarely used cases. If some of them became popular it can be always promoted later to dedicated property and converted by bot. Paweł Ziemian (talk) 19:10, 27 June 2015 (UTC)[reply]
One item can have multiple names, even in one language (via aliases). To be clear as to which name you are transliterating this property needs to be a qualifier to one of the other name properties. Unfortunately if this property is a qualifier then it can't have it's own qualifiers to tell you which transliteration system was used. This indicates that we need multiple properties - one for each transliteration system. Fortunately we don't need to transliterate all names since for most items, in most languages, the transliterated name will be in the label. I think. Filceolaire (talk) 03:00, 28 June 2015 (UTC)[reply]
I am not so sure about that! The Swedish transcription of for example Russian names are not always in the label, but rather the German or English, since those transcriptions are sometimes more spread in common media. And I would prefer to see a monolingual datatype in those cases, i.e. when the transcription is langauage dependant. -- Innocent bystander (talk) 10:56, 28 June 2015 (UTC)[reply]
It is not unusual that there exist a few methods for transcription from one language to another. I agree with argument that it should be a qualifier, but with requirement for auxiliary and mandatory qualifier it is impossible to implement this. This is the weakness point in my proposal. I think I should withdraw the proposal and introduce set of new proposals for specific transliterations, what was mentioned above. Paweł Ziemian (talk) 13:33, 28 June 2015 (UTC)[reply]
Support. Even if we end up with specific properties for every transliteration in wikidata we will still need this property for the transliteration properties to be 'sub-property of' so search can do generic transliteration searches. Joe Filceolaire (talk) 22:37, 2 August 2015 (UTC)[reply]
Oppose Transliteration properties make only sense as qualifier on name properties. This proposed property also requires a qualifier. We don't have qualifier on qualifier, so how can you use that? --Pasleim (talk) 19:32, 4 October 2015 (UTC)[reply]
literal translation
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
I don't quite understand what it adds. If the literal translation is used, it should be the label, otherwise it's non-official and shouldn't be added to Wikidata. If somebody wants to know what something is literally translated, I suggest using a translation tool. Mbch331 (talk) 13:30, 20 July 2015 (UTC)[reply]
Kraftwerk (German pronunciation: [ˈkʀaftvɛɐk], "power station") is a German electronic music band formed by …
Neither of these should have the literal translation as an alias because its simply not an alias. In order to generate the introductory phase of an article this information could be useful --15:15, 20 July 2015 (UTC)
Comment The problem with Youtube is that some users have names like "https://www.youtube.com/<name>" others "https://www.youtube.com/user/<name>" or "https://www.youtube.com/channel/<name>". It's even possible that two of these exist and are unrelated, leading to different content. To avoid such ambiguity, URL-datatype seems more appropriate. --- Jura18:43, 22 July 2015 (UTC)[reply]
https://www.youtube.com/mbch331 and https://www.youtube.com/user/mbch331 both point to my YouTube channel. (Wouldn't know the channel id as I never use it) Mbch331 (talk) 11:41, 23 July 2015 (UTC)[reply]
Your comment doesn't actually address the issue of custom URLs, such as "youtube.com/DonaldTrump". Merely focusing on legacy usernames (that are being phased out) doesn't seem forward orientated. For an overview, see "Understand your channel URLs". --- Jura04:27, 24 July 2015 (UTC)[reply]
It most certainly does address that. And the page you cite says that, while user names are no longer issued, existing names (and the URLs of which they are part) are still valid and may still be used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:15, 27 July 2015 (UTC)[reply]
You're right. Never noticed that this was the case. In that case all type should be unique, but youtube.com/user/$1 doesn't have to be unique when comparing to youtube.com/$1. Mbch331 (talk) 13:24, 23 July 2015 (UTC)[reply]
No. This property should be for YouTube user names, type=string, for the same reasons that we don't store full URLs for other identifiers. Other properties may be created for YouTube channels, if needed. We shouldn't muddle two types of identifier in this way. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:12, 23 July 2015 (UTC)[reply]
Support I looked at YouTube's API and they distinguish user names from channel IDs. I also found [1], it seems the Donald Trump example above is a custom URL, not a user name or channel ID. I don't think storing the entire URL would be a very structured way of storing the data. - Nikki (talk) 17:48, 23 July 2015 (UTC)[reply]
The link you provided is most helpful, but it seems they are dropping the "legacy username" from the API. --- Jura19:26, 23 July 2015 (UTC)[reply]
@Nikki: Youtube removed what they call the "legacy username" from their api and exclude the creation of new ones. For new users, only "custom URI" become available and we need to include these in one way or the other. The proposal below for a single URI based property seems better structured (it's called uniform identifier for a reason) and consistent with other properties for complex naming schemes. --- Jura08:58, 1 August 2015 (UTC)[reply]
As you missed it above, I'll repeat: YouTube says that, while user names are no longer issued, existing names (and the URLs of which they are part) are still valid and may still be used. If you wish to start an RfC to change our policy on identifiers to always store full URIs rather than the UID component, please do so in an appropriate forum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits10:41, 1 August 2015 (UTC)[reply]
YouTube's API still supports the username using the "forUsername" parameter (see [2] and [3]). I don't think that storing a single URL property is better structured. It would combine multiple incompatible things into a single property (channel ID and username require different API queries, custom URL doesn't seem to be usable in the API at all). There are also many possible URLs for the same ID or name (http vs https, www vs no www, desktop vs mobile, trailing slash vs no trailing slash, etc) which is not a sign of well structured data. - Nikki (talk) 17:42, 1 August 2015 (UTC)[reply]
You are right about the "forUserName" api parameter. It seems that v3 limited the use of legacy usernames, but still allows this. CustomURLs probably need to use the query in the api. [4]. If one relies on the api, one should be prepared to process URLs The main use for any of these access methods is to actually go to a channel. This works well with URLs and one of the issues we had with the current solution is that this isn't always possible. As any string, we can easily normalize URLs. Even for such simple things as Twitter account names, you already had to do quite a lot of normalization. If actual URLs are used, this is easier, as the input is already limited and we can define the correct format beforehand. --- Jura06:05, 2 August 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Proposing with the aim of splitting website account on (P553) (see Wikidata:Project chat#Website_user_names). Per this, YouTube is the third-most used value for P553, after Twitter & Facebook. The YouTube account can either be a username or a channel id. A channel id needs to be a separate item, because it's different from a user link. Channel id is always 24 characters long and always starts with UC. Mbch331 (talk) 16:31, 23 July 2015 (UTC)[reply]
Discussion
Support I would use "channel ID" rather than "channel name", since it's not a name someone picked. The description could then be something like "ID (starting with UC) of ..." - Nikki (talk) 16:49, 23 July 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Comment: This to replace the current use of website account on (P553) for Youtube. YouTube are basically channels, but these can be addressed as Youtube.com/<name> or Youtube.com/user/<name> or as Youtube.com/channel/<channel id>. Similar to other sites with complex addressing, we apply a single URL as identifier. This ensures that users aren't lost with too many concurring properties. --- Jura17:06, 23 July 2015 (UTC)[reply]
Reject proposal, for the same reasons as discussed in the context of the identifier proposals. As for "lost with too many concurring [sic] properties", we have a number of other property sets where there are multiples (see property:P1217 to 1220; property:P1233 to 1235 and 1239; and a handful of others).
Support URL datatype is not pretty but I don't see how to deal with all different URL formats when using string properties. --Pasleim (talk) 19:42, 4 October 2015 (UTC)[reply]
@Visite fortuitement prolongée: That would actually be an argument to support the previous proposal (#2) and oppose the initial proposal (#1). Just bear in mind the scheme <domain>/<name> replaced <domain>/user/<username> --- Jura09:36, 8 October 2015 (UTC)[reply]
Baike.com entry
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Depends on how much inference you want to do. There are some units (inches) that convert nicely (thanks, Queen of England) to SI, and some (pounds-force) that don't. --Izno (talk) 01:26, 1 September 2015 (UTC)[reply]
A more general conversion property might be better anyway though i.e. to get feet to yards to miles. I don't see a reason for the notion of "standard" vice not standard. Maybe the conversion property could have a qualifier of "unit standard" or perhaps use the "specified by" property as a qualifier. Actually, I like that idea. --Izno (talk) 02:32, 7 September 2015 (UTC)[reply]
An alternative would be to set a goal of always expressing quantities in a chosen set of SI units, and then having a property "source units" which preserve how the quantity was written in the source that supports the value. Ideally such a property would be attached to the reference, since several different references might express the same value in different units. If someone sets the quantity in an undesired unit, someone can always fix it later and preserve the source value with the new property. Jc3s5h (talk) 13:22, 18 September 2015 (UTC)[reply]
I am not very sure it would be very failsafe to write "m2" instead of "barn" here. And it would make it more or less impossible to use non-convertible units. -- Innocent bystander (talk) 07:30, 8 October 2015 (UTC)[reply]
Comment I suppose the question is if there should be single value constraint on this property. I'd tend to say yes, but we might need a second property to convert into a SI base unit. --- Jura22:31, 4 October 2015 (UTC)[reply]
This property should be used for measurement units to convert them to S.I. units so every units for measuring length would have this property for converting to 'meter'. Every unit for measuring energy (from kilotons of TNT to barrels of oil) would use this property to give the equivalent in 'Joule'. This is the crucial middle man that will let us compare any measurements. I suggest we rename this property as 'conversion to SI unit'.
For other conversions just use the general properties we already defined so "foot" is <length:12(unit=inch)>and <conversion to SI unit:0.3048(unit=meter)>. Joe Filceolaire (talk) 18:53, 12 October 2015 (UTC)[reply]
Support, but I would broaden the use to simply 'conversion to alternate units'. The units that are entered will determine inherently whether it is a conversion to a standard unit, SI unit, or whatever other kind of unit. We don't need separate properties for each type of unit you want to convert to. Josh Baumgartner (talk) 18:15, 27 October 2015 (UTC)[reply]
conversion to SI base unit
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Comment Have we considered a generic "is equivalent to" property that would allow as many conversions as deemed fit? Or are people concerned with that getting out of hand? James Hare (NIOSH) (talk) 13:18, 7 October 2015 (UTC)[reply]
Various things have been discussed here and there, it's just that it hasn't gotten to the creation of new property. We could simply use the property "numeric value" for any conversion. The idea of this new property is to do SI conversion calculations when possible. We might need another property if there is a rounding issue involved converting between two non-SI units or if there are some units that can't be converted (reliably) into SI units. --- Jura14:09, 7 October 2015 (UTC)[reply]
Comment Maybe we can try to start using the above proposed property, and see if there really is something missing? I am not sure about that, but not sure enough to stall this proposal with an {{Oppose}}-vote. -- Innocent bystander (talk) 07:34, 8 October 2015 (UTC)[reply]
Support. We need a generic "is equivalent to" (or "size") property but we also need a very specific property converting every measurement unit to SI units. This will be needed to create tools to compare measurements in various units with each other. The tools will need to go straight to this one single value property to get the info they need. If there are three different inches then they need three different items each with one claim using this property or, at worst various historic values and one current, preferred value. Joe Filceolaire (talk) 18:42, 19 October 2015 (UTC)[reply]
I've moved this up next to the related proposal. I'm not sure this separate property is really needed, but as a sub-property of the generic conversion property it may be worthwhile. Josh Baumgartner (talk) 18:59, 27 October 2015 (UTC)[reply]
number of awards
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
@TomT0m: still seems too complicated for me. Let's just consider that second example is off-topic for know and discuss it later. We still need property for number of people who received the award or title. -- Vlsergey (talk) 14:32, 8 September 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
In order to be able to process or query quantities with units, it may be necessary to bring them to the single unit. I.e. some distances can be expressed in kilometre (Q828224), some in mile (Q253276), weights in kilogram (Q11570), some in ton (Q11247037), some in pound (Q100995), which are not directly comparable but can be converted to common measure. It would be nice if for automatic processing we could specify that all metric length units should be converted to, say, metre (Q11573) - then every unit with standard unit marked as metre (Q11573) would be automatically recognized by tools as belonging to the same family and automatic processing of such quantities would be much easier. – The preceding unsigned comment was added byLaboramus (talk • contribs).
Yes, similar, but not the same. You It would be more complex to ensure all length properties have the same standard unit without having dedicated property - i.e. if somebody says that yard is 36 inches, it may be non-trivial to figure out whether inch can be converted to meters. Having this knowledge explicitly would allow to scan for it and have bots or people enforce proper conversions more easily. That said, I support #conversion_to_standard_unit and if the majority things two properties are redundant, we can do with just one. --Laboramus (talk) 22:51, 10 September 2015 (UTC)[reply]
Oppose. I expect the "number with units" datatype to deliver this automatically - i.e. all lengths should be stored internally in meters, no matter if the value is in inches or Angstrom, so all are comparable. If they fail to deliver then we can look at this again. Joe Filceolaire (talk) 15:06, 12 September 2015 (UTC)[reply]
Thinking about this more. I don't think this property is useful for telling us that millimetres are measured in metres - that can be done with the conversion to standard units property proposed above as Galaktos said. This property could be useful for noting that mass is measured in kilogram and luminous flux is measured in lumen and I would Support this proposal if it were ammended in this way. @laboramus:? Joe Filceolaire (talk) 12:27, 18 September 2015 (UTC)[reply]
I think it's a bit different proposal but equivalent to what I proposed, only applied to measured quantities instead of units. Maybe we need a separate proposal for that... --Laboramus (talk) 08:11, 12 October 2015 (UTC)[reply]
"Base unit" has a specific meaning in the International System of Units; derived units are expressed in terms of base units, and some derived units have special names. For example, force is expressed in kg²⋅m / s² and one may use the special name newton for this derived unit, if one wishes. It would be confusing to assign a different meaning of "base unit" in Wikidata. Jc3s5h (talk) 20:43, 24 September 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Allows navigation from the generic (type) to the specific (list of examples of that type, where such list has a wikidata item). Swpb (talk) 19:21, 24 September 2015 (UTC)[reply]
@Yair rand: Could you be more specific about what's not useful about it? I can easily see wanting to navigate from an item about a class to an item about a list of members about that class. The relationship is well-defined and closed. Swpb (talk) 19:58, 20 October 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
This is essential data to inform users of publicly available prices. Please note that this would require a few thousand items to be created for different dosages and presentations (tablet, injection, ...) of the drugs. Tobias1984 (talk) 17:44, 5 October 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
We need alternatives to the present datamodel for precision. Not all sources gives you information about the precison in terms of +/-X. For those cases is this maybe a solution. Innocent bystander (talk) 18:55, 20 October 2015 (UTC)[reply]
What about saying "uncertainty corresponds to" (or "+- corresponds to"). It would be item-datatype and could link to 1-sigma, 2-sigma, etc. Otherwise I think many people will use +-0 for numbers and only add the uncertainty in the qualifiers. --Tobias1984 (talk) 09:28, 28 October 2015 (UTC)[reply]
What about the following changes in your example above?
Oppose I would be in favor of an "uncertainty" property for qualifiers as suggested by Tobias1984 above, with various items as target (standard deviation, 2-sigma, or whatever else is commonly used). I don't think "1 sigma" makes sense as a property in itself. ArthurPSmith (talk) 13:22, 28 October 2015 (UTC)[reply]
Oppose Also, uncertainties can be one-sided, such as the half-lives of ununoctium-294 and other highly radioactive elements, in which case this does not make sense.--Jasper Deng (talk) 16:31, 2 November 2015 (UTC)[reply]
@Jasper Deng: I never proposed that this property should be used in every case, only when the numbers in the sources fits this solution. Anyhow, I have marked this as "Not done", since I agree with the objections above. -- Innocent bystander (talk) 17:34, 2 November 2015 (UTC)[reply]
uncertainty corresponds to
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Support. sounds good to me! To clarify - the allowed value should probably be an item (we do have standard deviation (Q159375) which is ok for 1 sigma, but I think we'd have to add items for 2 sigma, 3 sigma, etc. ?)
metasubclass of
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
The motivation for this property grew out a discussion at Project Chat about the nature and characteristics of metaclasses.
Some further current examples, which may be surprising at first glance:
Arguably some of these relations might be better expressed as properties on the underlying subclasses. However, for the moment the relations between the underlying classes of the two sets of metaclasses are expressed by subclass of (P279) -- which means that the relation between the two metaclasses is indeed currently a metasubclass relationship.
An example of where a property has been introduced, and many of the relations have been changed to use it, can be seen in
Most television series classes use genre (P136) to express their relationship to instances of television genre (Q15961987). However, as a look at the "from related items" section of the Reasonator entry for soap opera (Q23739) reveals, there are still many television series classes using subclass of (P279) -- which should probably be discouraged, given the relationship can instead be expressed by a property.
Some further notes:
The property is intended to capture relationships other than those already captured by subclass. Therefore it should not be applied if metaclass A is genuinely a subclass of metaclass B -- ie if it should be understood that all instances of metaclass A are also instances of metaclass B.
Due to the transitive nature of subclass of (P279), all subclasses of a metasubclass A are also metasubclasses of the metaclass B. So the property should be applied to the highest item for which it is valid in the class tree on the domain side.
Similarly, a metasubclass A is also a metasubclasses of all superclasses of a metaclass B. So the property's value should be the lowest item in the target class tree for which it is valid. In this way the levels on the two sides of the property should match -- engine metaclasses with engine metaclasses, generic manufactured item metaclasses with generic manufactured item metaclasses.
It is possible that in future either metaclass (Q19361238) or metaclass (Q19478619) may be used to manage a controlled vocabulary of metaclasses -- a set of metaclasses that had been 'signed off' as okayed by being made a subclass of one of these items, so that any attempt to use instance of (P31) from a class item to any item not in this 'approved' class would throw a constraint violation. If that happens, then any attempt the "metasubclass of" property on or to an item not in that class should also throw a constraint violation.
I've found the above candidates for the property using this query tinyurl.com/pazxyf4 to throw up potential matches. It could be refined, as at the moment it only has quite a low true positive rate. My main motivation for suggesting the property is therefore simply to record what of these quite curious relationships exist -- because even with the query, there's no obvious way to generate such a list algorithmically, it currently relies so much on manual validation. So given that it's hard to recreate such a list, it seems proportionate to introduce a property to be able to record it.
I should also emphasise that my intention would be for the property to be descriptive rather then prescriptive -- ie to try to identify and make accessible some relationships that are in the database currently, rather than to be proposing any relationships that should be in the database.
Of course, having identified such relationships, one can then look for gaps in them -- what classes that are instances of the metaclass on the domain side appear to be missing superclasses that are instances of the metaclass on the target side? (This is analogous to looking to see which items appear to be missing a particular property) Or, are there items that might be created to make structures more systematic -- for example, should a manufactured object family item be created, to be a superclass for aircraft family (Q15056993) and engine family (Q15057020), a "metasubclass of" target for product model (Q17444171) ?
But my main motivation is simply to identify and have a way to be able to capture these patterns, which are currently implicit in the database, but not easily accessible. I think that's worth a property.
Support (after discussion) : captures something actually. Weak oppose as is, this may be a little clearer to contributors and a little more easy to enforce good practices, at the cost of complicating the model a little more, and to make a little more unnatural statements like "Porshe 911" instance of "car model". Would it imply a second version of instance of (P31) as well ? I'd like to hear a little more explanations from the proposer. author TomT0m / talk page10:12, 23 October 2015 (UTC) Needs a little more thinking after discussion.[reply]
@TomT0m: I hope you find the explanation above now a little more complete and detailed. :-)
The thing I should stress is this is not an attempt to replace subclass of (P279), and I see no purpose that would need a meta version of instance of (P31). The aim is simply to capture some relationships that simply can't be expressed at the moment.
I don't think it really complicates the model much, as the number of instances of the proposed property would be vanishingly few. Remember, it is not intended to be applied where subclass of (P279) can be applied. So rather than being a heavy complication, I think a better way to view the property is as simply identifying a handful of curiosities -- which already exist in the model, they're just not easy to extract.
I think it will therefore hardly impinge on contributors or practices at all, as its domain of application will be so very very limited.
But I think it does have interest, and some potential for usefulness, so I do hope you might reconsider your initial oppose. Jheald (talk) 12:15, 23 October 2015 (UTC)[reply]
(ec) One way to look at the property is to see it in some ways analogous to properties for this type (P1963). For attributes of items that are expressed as properties, P1963 indicates what properties one might expect to find on a particular class of items. Analogously, for attributes of items that are expressed through subclass relationships, the proposed property indicates what sort of "subclass of" targets one might expect to find on a particular class of items. Jheald (talk) 12:35, 23 October 2015 (UTC)[reply]
@Jheald: So a good description would be "subclasses of instances of the subject metaclass's are instances of that metaclass" ? I think I'm beginning to understand : a typical car family subclass is a car models indeed. There may be other kinds of car famylies. But what's the value added to simply say that "car model" is a subclass of "car family" ? The "likely to be" in your description ? author TomT0m / talk page12:46, 23 October 2015 (UTC)[reply]
Because "subclass of" requires that every instance of a "car model" is an instance of a "car family". But that's not true: the two are considered different things. Jheald (talk) 12:59, 23 October 2015 (UTC)[reply]
@Jheald: Sorry, but I fail to understand this proposal. Can you expand one or two of the example relation between two metaclasses: instances of this metaclass are likely to be subclasses of classes that are instances of the target metaclass wrt. say, the element example ? I can't understand the relationship beetween elements and rows in the table. author TomT0m / talk page12:32, 23 October 2015 (UTC)[reply]
But an instance of a Hydrogen is not an instance of a Period. subclass of (P279) is therefore not an appropriate way to model the connection between chemical element (Q11344) and period (Q101843). So I suggest this new property, and then the relationship could be captured.
Note that I'm not claiming that this is necessarily the right (or best) way to represent which period of the periodic table Hydrogen is found in -- I merely wish to be able to note that this appears to be how the relationship is seemingly being modelled, currently. Jheald (talk) 12:50, 23 October 2015 (UTC)[reply]
If we take the "atomic" definition of hydrogen (for simplicity) : «type of atom with number 1 atomic number», so the item may be hydrogen atom (Q6643508), then this would make period 1 (Q191936) a subclass of atom, so a class of atom. period 1 (Q191936) is then "atoms of elements in the first row of the periodic table". This would make period (Q101843) a metaclass of atoms as well.
So if we say that:
«level 0» is the instance level,
«level 1» is the class of atoms level
«level 2» is the class of class of atoms level (so the first metaclss level
It's a bit tricky. There are rather few examples, and they're not particularly easy to find.
To take the example you raise: one would be looking for instances of horse breed (Q3745054) to also be subclasses of instances of horse (Q726). That doesn't work, because instances of horse (Q726) are individual horses, which have no subclasses. It's also the case that there aren't may instances of horse breed (Q3745054) that are subclasses of anything.
@Yair rand, Jheald: I got one more example : see . "Tritium atom" is a class of atoms, as "Hydrogen atom" is. We have SubType|Tritium atom|Hydrogen atom}} because any tritium atom is an hydrogen atom. But we don't have "isotope" (defined as a metaclass of atom) subclass of "element" (defined as a metaclass of atom as well) because "Tritium atom" does not belongs to the class of elements, only "Hydrogen atom" does. With those definitions, we would have "Isotope" metasubclass of "element". author TomT0m / talk page14:42, 2 November 2015 (UTC)[reply]
@Yair rand, Jheald, TomT0m: Please read that document before supporting or not this property. The use of metaclass and all related properties have a strong impact on the type of ontology we want to have for WD. This is typically the kind of decision which will have some impact later when we will build tools to extract information (not only data) from WD or when we will build tools to check data consistency. For me the use of metaclass or not should be a choice of the community with a clear description of the consequences, advantages and drawbacks of each option. If you have time this is another document comparing both structures. Snipre (talk) 15:53, 2 November 2015 (UTC)[reply]
You're a little late, this thing talk of metaclass in (object oriented) programming. A relevant notion would be Liskov substitution principle (Q957386) is that case. But we are not doing programming, and you can read metaclass (Q19478619) to see there is a lot more documentation for metaclasses on knowledge representation. But this precise property is far from being structuring for the use or not of metaclasses and will have a very low impact. If we really don't use metaclasses, which is really not true in current situation, then this property will just stay unused. No fear to have for ... what ? author TomT0m / talk page16:09, 2 November 2015 (UTC)[reply]
The essential question is do we want to allow a more automatic way to generate relation and in that case we will go towards some programming logic. I am not a specialist but I think this is a question which will have some consequences later or even nowas we are developping some query tools.
I don't agree with you about creating metaclass structure and decide later if we will use that system: creating that kind of structure will just allow parallel structures to be used and we will have to convert later all that workbecause we were not able to ask the good question at the good time. Snipre (talk) 18:52, 2 November 2015 (UTC)[reply]
@Snipre: You don't seem to understand. That property won't have any influence on us using Metaclasses or not as we simply don't need it to do so. The project about reasoning is WikiProject Reasoning, created by Markus who always have been supportive on my views about all these. He's an expert, so if this was anything of a problem to use metaclasses, we would know (I think I saw a draft from him and/or Denny about pushing metaclass modelling possibilities on OWL2). found it see Markus' edit on the history. author TomT0m / talk page19:12, 2 November 2015 (UTC)[reply]
upper bound
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Sometimes for a measurement there will be a range of accepted values rather than just a single value. Being able to qualify upper and lower bounds reduces our need to create specialized properties. See also the proposal for a lower bound qualifier property. James Hare (NIOSH) (talk) 17:06, 5 October 2015 (UTC)[reply]
Discussion
Comment The sample should be in the format <item> <property> <value> <proposed qualifier> <value>. Can you amend it? --- Jura17:22, 5 October 2015 (UTC)[reply]
Oppose the Quantity data type already stores an Upper and Lower bound (as can be seen on any diff with quantity changes). The user interface needs to expose it better – currently, we just get a single ± variance – but that’s not solved by a property proposal. —Galaktos (talk) 17:46, 5 October 2015 (UTC)[reply]
I only included the upper bound in this proposal to indicate the upper bound; the lower bound is included in the lower bound proposal. It would be a good idea to require both an upper and lower bound, even if there is no known upper or lower bound. For example, an lower bound of 25 with no upper bound would represent the range [25, inf). James Hare (NIOSH) (talk) 19:04, 5 October 2015 (UTC)[reply]
Actually, you raise a good point. If upper and lower bounds are qualifiers, what does that leave as the "main" answer? I admittedly don't have a good answer to that question. Someone else might. In the meantime, I have a test case on Test Wikidata. James Hare (NIOSH) (talk) 19:11, 5 October 2015 (UTC)[reply]
earliest date (P1319) and latest date (P1326) work in a similar way. It's something that the datatype is said to be doing, but hasn't made its way into the GUI.
Comment As an alternative we could also have an item-datatype qualifier, that links to "lower bound" and "upper bound" and would qualify values that are ranges. I think, if worded correclty, it could also be useful in other places. The has characteristic (P1552) solution is for my sense too far away from what a qualifier should be (not a new statement, but a further description of the value. And if the numeric value is the qualifier we have no way of experessing measurement-conditions. --Tobias1984 (talk) 20:44, 5 October 2015 (UTC)[reply]
Comment one might as well go with the following solution:
@Jura1: But "is a" would be used similar to "instance of" and would generate quite some confusion. Ranges are quite common and would deserve a more explicit qualifier. How about "part of range measured". --Tobias1984 (talk) 13:08, 6 October 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Sometimes for a measurement there will be a range of accepted values rather than just a single value. Being able to qualify upper and lower bounds reduces our need to create specialized properties. See also the proposal for an upper bound qualifier property. James Hare (NIOSH) (talk) 17:06, 5 October 2015 (UTC)[reply]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Within ceiling exposure limits there are "maximum peaks" where exposure above the usual limit is permitted for five minutes within a certain time window. To facilitate this, I would like a generic "time interval" property to specify lengths of time. (The permissible exposure limit property included in the example does not yet exist; I am working with WikiProject Chemistry to determine how exactly we should model this information.) James Hare (NIOSH) (talk) 02:00, 17 October 2015 (UTC)[reply]
Discussion
Oppose with this name. James: A property called "Time Interval" is too likely to be abused for things that need a start time and an end time. Can we change the label to Duration? Joe Filceolaire (talk) 18:34, 19 October 2015 (UTC)[reply]
At its creation this property was called "duration" but some contributors modified it for their own purpose. We should see if this is a problem to keep a more general definition for this property. Snipre (talk) 15:42, 29 October 2015 (UTC)[reply]
@Snipre, James Hare (NIOSH): I can see extending the use of duration (P2047) for the duration of tracks on LPs but using it for exposure limits seems a step too far so I would be in favour of a separate property for this. The question then is if we have a specialist property for 'exposure limit time intervals' or if we have a generic 'duration' property used for exposure limits and other places where we need a qualifier to specify duration (then duration (P2047) probably gets classified as a 'subproperty of' such a generic property, along with some specialist property for race times). Personally I would go with using a generic 'duration' property for exposure limits since it is a qualifier to the important info - the dose in mg. Joe Filceolaire (talk) 22:12, 29 October 2015 (UTC)[reply]
@Filceolaire: Please look at the translated labels for duration (P2047): Dauer in German, duración in Spanish, durata in Italian. Only English has a special definition for this property. I can understand to have specific properties when you use the generic property several times in the same item and if you need then to use qualifiers to distinguish who is who. I can understand specific properties if you want to track errors by using a tight range for values or only one unit. But in the current property this is not the case. Right now I asked the extension of the application of duration (P2047) to all field using the label "duration"~on the talk page of duration (P2047). I propose to discuss this case there. Snipre (talk) 12:40, 2 November 2015 (UTC)[reply]
homoglyph of
Documentation
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
Gherkin 1Gherkin 2
The property would be good to generate better search results. For example "Letters that look similar to H". I guess we could also make the property more general and call it "has very similar appearance". Although that is always a matter of judgement or opinion it could be used for things like 30 St Mary Axe (Q191161) and Torre Glòries (Q336246). --Tobias1984 (talk) 11:01, 24 October 2015 (UTC)[reply]
Discussion
Support also useful to fight domain name squatting. Also OK to generalize, the classes of the elements are enough to filter the results. author TomT0m / talk page11:06, 24 October 2015 (UTC)[reply]
Support but the example structure won't allow for further qualifiers. I would instead simply set up VAC and VDC as their own items and use them as units for quantities under this property:
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
This would be a generalisation of applies to part (P518) to cover cases where the statement-value applies not to part of the subject, but in connection with an aspect of it.
For example, with located in the administrative territorial entity (P131), one could indicate that some area was a subdivision of one area in respect of one scheme (eg current administration), but a subdivision of a different area in respect of a different scheme (eg a scheme of traditional subdivisions), or another area again in respect of further schemes (eg police areas, ambulance areas, fire service areas).
This is a different thing to P518, which would would indicate that the statement only applied to part of a geographical area.
Also, where we have an item that is covering multiple roles, it can be useful to indicate which role for that item a statement applies to -- for example if the same item is covering two different types of administrative areas that cover the same ground, there may be different values of head of government (P6) in relation to the different roles.
This is not to preclude the items later being split into different items for the different roles; or more specific properties later being invented to cover particular types of relationships. But I think it is useful, at the very least, to have a generic property to allow information to be untangled in the structures we have, while discussions as to how those structures might be refined may be ongoing. Jheald (talk) 11:11, 28 October 2015 (UTC)[reply]
Discussion
Comment normally, the value of P31 wouldn't be repeated systematically as qualifier when an item is being used. If handeling two parallel hierarchies in P131 is difficult, maybe it's worth creating a distinct property for ceremonial counties. BTW there is a generic qualifier P794 (P794). --- Jura10:11, 31 October 2015 (UTC)[reply]
It's not just a P131 problem, and it's not just ceremonial counties. For example, this could equally arise with identifiers, where different contexts of the same item might have different identifiers, sometimes even in the same database. This may occur where an item has more than one P31 -- there needs to be a way to say which one which identifier applies to.
But even for the P131 case, it's not just the present ceremonial counties. There are other old administrative structures, and one would want to record in relation to which structure the hierarchical relationship existed. Jheald (talk) 18:26, 31 October 2015 (UTC)[reply]
In general, I think this suggests you'd need separate items. We would really need samples to discuss this. --- Jura23:43, 31 October 2015 (UTC)[reply]
I agree. I'd say if an administrative unit is replaced by a new one we also should use "replaced by" to link the items old/new unit. author TomT0m / talk page09:55, 1 November 2015 (UTC)[reply]
I think we should have a property like "located in the (exact) same territory" to link an administrative unit to the main (by convention) teritory of the administration of the country. author TomT0m / talk page12:42, 2 November 2015 (UTC)[reply]
"Contains, Contained by, Contains major portion of, Primarily contained by, Partially contains, Partially contains, Partially contained by" might work better than P131.
located in the administrative territorial entity (P131) is ill defined, if defined at all :) There is a least two things countained in it, locality and political organisation : american states depends on the general state who define some federal rules, and they are geographically contained (and they covers taken together) in the US territory/. More than Partially contains / Partially contained by I'd use a single symmetric property geographically overlaps with. I'd tend to be OK with Contains / Contained by, but we lack the covers property This is a similar case with class covering by subclasses in
Under discussion
Description
MISSING
Data type
MISSING
Example 1
MISSING
Example 2
MISSING
Example 3
MISSING
, I'd propose a similar solution, for the same reason. Yet we would have to solve the political hierarchies/relationships beetween entities. author TomT0m / talk page14:10, 2 November 2015 (UTC)[reply]
Oh, and I still think we need a property to say the territory is shared because there might be several division (state, religious or whatever) with different administration but who aligns with state administration division for convenience. author TomT0m / talk page14:13, 2 November 2015 (UTC)[reply]
Comment. I have mostly held off from creating new items so far working on administrative entities in the UK. User:Danrok originally raised the concern that we were sometimes combining onto one item various different aspects of an entity, that were regarded as different things by the Ordnance Survey. He raised the case of Aberdeen (Q36405), which we have as both a city and a unitary authority. I haven't looked at the Scottish structures yet, but I think an analogue is eg Cambridge (Q350) which on WIkidata (and Wikipedia) we currently have as both a city and a non-metropolitan district. The OS has two records, one for the administrative district and one as a named place. In this case I think we probably are right to keep one record, as Cambridge the place for most purposes equals Cambridge the city, the boundaries of which are currently defined by the boundaries of the district. But as one gets down to the 'Civil Parish' level there may be questions when we have ABCD as both a village and a civil parish, does a stated area correspond to the area of the parish, or the area of the core settlement. The "co-classes" links at Wikidata:WikiProject_UK_and_Ireland/adm/England#Items_by_subdivision_type give counts of what other classes the administrative entities are also listed as instances of. On the other hand, until we have properties we want to hang off these items, I am loath to break them up -- for one thing, which item would the en-wiki article link to, and how would its infobox also find and extract statistics from the related item?
One set of items I have started to break up is Ceremonial Counties, where the area administered by the County Council is now smaller than the full ceremonial county. So I have started creating the new items returned by this query. But even here, where we do have two different areas on the ground, I am wondering whether this is the right thing. The infobox for en:Lancashire or en:County Durham currently lists both (but not eg any of the other unitary authorities that are part of County Durham). Is it right to split the item? Or should one have area relating to the Ceremonial County and area relating to the Unitary Authority on the same item?
For counties, I think there may be a case to split. For civil parishes there may be a case to keep together. Either way, I think there is a case to have the functional ability to be able to model the data both ways, whether for long-term purposes, or whether for short-term purposes, to clarify the data in the immediate term, while the long-term structure is being debated/discussed.
(And this is without prejudice to other cases where one might want to make suitable qualifications -- eg the entities bordering the ceremonial county of Lancashire now, as opposed to the entities bordering its historical form. Yes, one can sometimes denote historic data with start & end dates; but it's nice also to be able to identify it with a particular structural arrangement, that may have been revised at different times in different places). Jheald (talk) 17:22, 1 November 2015 (UTC)[reply]
I don't think you need to model items symmetric to enwiki articles. If one article includes two concepts, they can draw data with random access from two items. --- Jura13:13, 2 November 2015 (UTC)[reply]
The usual approach I use is to split things which contain multiple things (e.g. Lincolnshire (the ceremonial county) versus Lincolnshire (the administrative county)) but not split things which don't contain multiple things (e.g. a civil parish which contains only one settlement). Basically, if they didn't have the same name, what would we do? In the former case, it would be a ridiculous idea to merge two things with different names which contain different things (imagine merging England with the UK!). In the latter case, they're not clearly distinct items even with different names (I could imagine having different items, but I could also imagine having one item and saying "the village is called X but the civil parish is officially called Y").
Another way to look at it: When you want to use the item, if you merge the items in the former case, it becomes far more awkward to link to the item, e.g. how do you distinguish someone born in the ceremonial county of Lincolnshire from the administrative county? You would need to keep adding qualifiers to the statements linking to the item to clarify which of the two you mean and it would be more sensible to just have separate items. On the other hand, if the civil parish only contains one settlement, it's far less of a problem, villages often don't have well-defined borders, so even if we know the exact coordinates of something, we might still have no idea whether it counts as being in the village or not, so for those it's easier to have a single item.
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
[createCreate a translatable help page (preferably in English) for this property to be included here]
The ID "Property proposal" is unknown to the system. Please use a valid entity ID.
Motivation
This is necessary for completeness for any criminal or civil conviction. I'm not sure if the "period of time" or "quantity" qualifiers exist yet or if they need to be proposed separately. This will need English aliases "sentence", "criminal penalty", "prison sentence", "jail sentence", "jail time", "fined", and possibly others. The label I've chosen as the primary one may not be the best. Thryduulf (talk: local | en.wp | en.wikt) 15:51, 1 November 2015 (UTC)[reply]
Comment P:P364 used to have the label "language". To match more closely its description, it's now labelled "language of the original work". This leaves a gap for cases like the above. --- Jura 04:52, 12 December 2014 (UTC)
Support --- Jura 04:52, 12 December 2014 (UTC)
On hold per Pasleim. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:02, 18 April 2015 (UTC)
Oppose. We don't need specific properties, even two is too much. Single "language" property is enough. P364 shall be merged with P407 to such single property. -- Vlsergey (talk) 16:08, 26 June 2015 (UTC)
⟨ Researcher ⟩
Question I definitely don't understand the second example. Can someone clarify ? author TomT0m / talk page 11:38, 1 September 2015 (UTC)
Weak oppose as is, this may be a little clearer to contributors and a little more easy to enforce good practices, at the cost of complicating the model a little more, and to make a little more unnatural statements like "Porshe 911" instance of "car model". Would it imply a second version of instance of (P31) as well ? I'd like to hear a little more explanations from the proposer. author TomT0m / talk page 10:12, 23 October 2015 (UTC)
