Property talk:P2389
Add topicLatest comment: 1 year ago by Swpb in topic Why allow as qualifier?
Documentation
organization directed by the office or position
organization or project which is directed by this office
organization or project which is directed by this office
[create Create a translatable help page (preferably in English) for this property to be included here]
Inverse property of “position held by head of the organization (P2388)”:
if [item A] has this property (organization directed by the office or position (P2389)) linked to [item B],
then [item B] should also have property “position held by head of the organization (P2388)” linked to [item A]. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). if [item A] has this property (organization directed by the office or position (P2389)) linked to [item B],
then [item B] should also have property “position held by head of the organization (P2388)” linked to [item A]. (Help)
List of violations of this constraint: Database reports/Constraint violations/P2389#inverse, SPARQL
Value type “organization (Q43229), public service (Q161837), fictional organization (Q14623646), airport (Q1248784), military base (Q245016), ship (Q11446), sporting event (Q16510064), periodical (Q1002697), project (Q170584), editorial collection (Q20655472)”: This property should use items as value that contain property “instance of (P31), subclass of (P279)”. On these, the value for instance of (P31), subclass of (P279) should be an item that uses subclass of (P279) with value organization (Q43229), public service (Q161837), fictional organization (Q14623646), airport (Q1248784), military base (Q245016), ship (Q11446), sporting event (Q16510064), periodical (Q1002697), project (Q170584), editorial collection (Q20655472) (or a subclass thereof). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). List of violations of this constraint: Database reports/Constraint violations/P2389#Value type Q43229, Q161837, Q14623646, Q1248784, Q245016, Q11446, Q16510064, Q1002697, Q170584, Q20655472, SPARQL
Type “position (Q4164871), fictional office, position, or title (Q21451536), representative (Q11997597)”: item must contain property “instance of (P31), subclass of (P279)” with classes “position (Q4164871), fictional office, position, or title (Q21451536), representative (Q11997597)” or their subclasses (defined using subclass of (P279)). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). List of violations of this constraint: Database reports/Constraint violations/P2389#Type Q4164871, Q21451536, Q11997597, SPARQL
Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). List of violations of this constraint: Database reports/Constraint violations/P2389#Scope, SPARQL
Contemporaries:
if [item A] has this property (organization directed by the office or position (P2389)) linked to [item B],
then [item A] and [item B] have to coincide or coexist at some point of history. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). if [item A] has this property (organization directed by the office or position (P2389)) linked to [item B],
then [item A] and [item B] have to coincide or coexist at some point of history. (Help)
List of violations of this constraint: Database reports/Constraint violations/P2389#Contemporary, SPARQL
Conflicts with “instance of (P31): human (Q5)”: this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). List of violations of this constraint: Database reports/Constraint violations/P2389#Conflicts with P31, search, SPARQL
Allowed entity types are Wikibase item (Q29934200), Wikibase MediaInfo (Q59712033): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). List of violations of this constraint: Database reports/Constraint violations/P2389#Entity types
|
This property is being used by: Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
Contemporaries:
if [item A] has this property (P2389) linked to [item B],
then [item A] and [item B] have to coincide or coexist at some point of history.
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). if [item A] has this property (P2389) linked to [item B],
then [item A] and [item B] have to coincide or coexist at some point of history.
List of violations of this constraint: Database reports/Constraint violations/P2389#Contemporary, SPARQL
Organization constraint
[edit]I have a question regarding the constraint of this property. Should this be an actual instance of the position, e.g. Ministry of Culture (China) or it could be a subclass of a position.
For example, minister of culture (Q2621182) has this property set to ministry of culture (Q19973770) which is a subclass of organization. But the constraint is set to `instance of`.
My reasoning was that if a position is a subclass of a position (not an instance), that would mean that an organization is also a subclass of organization (not an instance)
I've changed the constraint to "instance or a subclass of". Please correct if this is a mistake.
--Vanuan (talk) 05:48, 12 March 2020 (UTC)
Reverse constraint can be two?
[edit]inverse constraint (Q21510855) should probably also have office held by the head of government (P1313), as that is used to point back. Is it possibel to add it here, or would it imply that it should have both? Ainali (talk) 13:48, 10 December 2023 (UTC)
Why allow as qualifier?
[edit]@Howard61313 you added the qualifier as allowed, which for instance causes this to not show a constraint violation. What is a good use of this property as a qualifier? Ainali (talk) 10:25, 18 October 2024 (UTC)
- Unfortunately I can’t recall why the edit 6 years ago was made. It’s welcome to revert the edit to what it should be. Howard61313 (talk) 10:35, 18 October 2024 (UTC)
- +1 on not allowing it as a qualifier. LydiaPintscher (talk) 08:45, 19 October 2024 (UTC)
Support on not alllowing it. @Ainali Maybe link this topic here Property_talk:P39 as well. Because it's "allowed" there too. RVA2869 (talk) 09:58, 19 October 2024 (UTC)
- Thanks for the pointer, I linked this discussion in my edit summary when removing it there. Ainali (talk) 18:21, 19 October 2024 (UTC)
Oppose This property is currently used as a qualifier on ~6,300 items, mostly on position held (P39) statements to represent in which organisation a person holds the given position. I think this usage is completely valid, so I suggest reverting this change. --C960657 (talk) 15:52, 23 October 2024 (UTC)
- Those statements are, in my opinion, just creative misuse of the property. All examples and the preceding discussion is about using this on items of offices, and not on items of humans. It may be a few thousand, but that is not too much to clean up. Ainali (talk) 17:21, 23 October 2024 (UTC)
- What makes it a misuse? In all cases, main and qualifier, the property links an office to an organization - the only difference is that the subject of a qualifier is the statement it qualifies or the value thereof, rather than the subject item of that statement. The key question in determining if a property scope should be expanded is whether the expanded scope will result in confusion or ambiguity. This does not. I support expanding the scope to qualifier (or in the rather odd way the question has been posed here, I Oppose removing qualifier from the scope constraint). Swpb (talk) 16:11, 24 October 2024 (UTC)
- It's a de facto misuse, as it wasn't the kind of usage discussed when voting to create the property, nor was it documented in the examples. The reason to why I don't like this is that it would be better modeled either by using a proper position/office item that (like Mayor of New York City (Q785304)) or to just using employer (P108) (or possibly even some other qualifier that would be better suited than this property). Ainali (talk) 16:41, 24 October 2024 (UTC)
- The (short) proposal discussion didn't mention scope at all, and certainly didn't reject use as a qualifier, and the "main" scope constraint didn't appear on the property for a further 2.5 years. So it is not accurate to call this a "misuse" of the property as proposed. Items like Mayor of New York City (Q785304) don't exist for most places, and would be silly to create just to avoid a qualifier. employer (P108) would also be accurate, but is less precise, to say nothing of the hopelessly vague P642 (P642) that we're trying to get rid of. Swpb (talk) 18:22, 24 October 2024 (UTC)
- It wouldn't be silly for anything that is actually an office. On the contrary, that would be an excellent strategy as it makes it easier to see the series of who was in office and enables the use of Template:PositionHolderHistory. Ainali (talk) 20:31, 24 October 2024 (UTC)
- Do you know how many positions we're talking about? For every tiny town in the world, you're going to make a "mayor of Whoville", "comptroller of Whoville", etc. It's beyond impractical. This kind of out-of-control multiplication of entities is exactly why qualifiers exist. Swpb (talk) 14:25, 25 October 2024 (UTC)
- Every little town in the world doesn't have a mayor. For example, in Sweden there are only 290, one for each municipality. If I would guess, it would be less than a million, probably just a couple of hundred thousands. The reason for doing it this way is exactly about control and practicality, to have just one way to model it. This would not only make it easier to query or reuse the data in other ways, it would also give epistemological justice to parts of the world where the mayor is not as famous as in New York City. Ainali (talk) 15:36, 25 October 2024 (UTC)
- We're not just talking about mayors, we're talking about every organization on the planet that has any sort of leadership position. You must see how that's impractical. Nor would it make querying in any way easier. Nor is "epistemological justice" a valid reason to create unnecessary Q-items. There simply must be a qualifier that connects leadership position titles to organizations – the only question is whether it will be the more generic employer (P108), or this property. Swpb (talk) 20:07, 25 October 2024 (UTC)
- I would argue that position held (P39) already assumes those items exist. If not, that property should have been named "class of position held". So even adding generic items that need qualifiers is unhelpful, and the two examples on that property that show such usage were added fairly recently. Ainali (talk) 09:03, 26 October 2024 (UTC)
- The property description of position held (P39) has explicitly allowed for generic values, with a qualifier specifying the organization, since this edit over ten years ago. You many not like this use of the property, but you cannot claim it is in any way new. Swpb (talk) 19:33, 28 October 2024 (UTC)
- I would argue that position held (P39) already assumes those items exist. If not, that property should have been named "class of position held". So even adding generic items that need qualifiers is unhelpful, and the two examples on that property that show such usage were added fairly recently. Ainali (talk) 09:03, 26 October 2024 (UTC)
- We're not just talking about mayors, we're talking about every organization on the planet that has any sort of leadership position. You must see how that's impractical. Nor would it make querying in any way easier. Nor is "epistemological justice" a valid reason to create unnecessary Q-items. There simply must be a qualifier that connects leadership position titles to organizations – the only question is whether it will be the more generic employer (P108), or this property. Swpb (talk) 20:07, 25 October 2024 (UTC)
- Every little town in the world doesn't have a mayor. For example, in Sweden there are only 290, one for each municipality. If I would guess, it would be less than a million, probably just a couple of hundred thousands. The reason for doing it this way is exactly about control and practicality, to have just one way to model it. This would not only make it easier to query or reuse the data in other ways, it would also give epistemological justice to parts of the world where the mayor is not as famous as in New York City. Ainali (talk) 15:36, 25 October 2024 (UTC)
- Do you know how many positions we're talking about? For every tiny town in the world, you're going to make a "mayor of Whoville", "comptroller of Whoville", etc. It's beyond impractical. This kind of out-of-control multiplication of entities is exactly why qualifiers exist. Swpb (talk) 14:25, 25 October 2024 (UTC)
- It wouldn't be silly for anything that is actually an office. On the contrary, that would be an excellent strategy as it makes it easier to see the series of who was in office and enables the use of Template:PositionHolderHistory. Ainali (talk) 20:31, 24 October 2024 (UTC)
- The (short) proposal discussion didn't mention scope at all, and certainly didn't reject use as a qualifier, and the "main" scope constraint didn't appear on the property for a further 2.5 years. So it is not accurate to call this a "misuse" of the property as proposed. Items like Mayor of New York City (Q785304) don't exist for most places, and would be silly to create just to avoid a qualifier. employer (P108) would also be accurate, but is less precise, to say nothing of the hopelessly vague P642 (P642) that we're trying to get rid of. Swpb (talk) 18:22, 24 October 2024 (UTC)
- It's a de facto misuse, as it wasn't the kind of usage discussed when voting to create the property, nor was it documented in the examples. The reason to why I don't like this is that it would be better modeled either by using a proper position/office item that (like Mayor of New York City (Q785304)) or to just using employer (P108) (or possibly even some other qualifier that would be better suited than this property). Ainali (talk) 16:41, 24 October 2024 (UTC)
- What makes it a misuse? In all cases, main and qualifier, the property links an office to an organization - the only difference is that the subject of a qualifier is the statement it qualifies or the value thereof, rather than the subject item of that statement. The key question in determining if a property scope should be expanded is whether the expanded scope will result in confusion or ambiguity. This does not. I support expanding the scope to qualifier (or in the rather odd way the question has been posed here, I
- Those statements are, in my opinion, just creative misuse of the property. All examples and the preceding discussion is about using this on items of offices, and not on items of humans. It may be a few thousand, but that is not too much to clean up. Ainali (talk) 17:21, 23 October 2024 (UTC)
@Ainali, Howard61313, LydiaPintscher, RVA2869, C960657: I sense a stalemate here, so I've opened an RfC. Swpb (talk) 19:51, 28 October 2024 (UTC)
Categories:
- All Properties
- Properties with wikibase-item-datatype
- Properties used on 100000+ items
- Properties with inverse constraints
- Properties with constraints on type
- Properties with scope constraints
- Properties with contemporary constraints
- Properties with conflicts with constraints
- Properties with entity type constraints
- Properties using constraint templates