Property talk:P642

Documentation

• Start a query
• Properties using this qualifier (statistics)
• Count

of
(This property is being deprecated, see details at WD:P642) qualifier stating that a statement applies within the scope of a particular item

Data type	Item
Usage notes	The English word "of" has many different meanings and other languages like Chinese often don't have words that directly correspond to the English meaning. In most cases it's desirable to use more specific properties than this. For alternative properties, see Wikidata:WikiProject Data Quality/Issues/P642
Robot and gadget jobs	DeltaBot does the following jobs: Move source to qualifier
Tracking: usage	Category:Pages using Wikidata property P642 (Q35489153)
See also	facet of (P1269), applies to part (P518), relative to (P2210), has part(s) of the class (P2670), closest approach (P6354), applies to work (P10663), valid in place (P3005), applies to people (P6001), applies to jurisdiction (P1001), valid in period (P1264), subject form (P5830), applies to name of subject (P5168), subject sense (P6072), applies to name of object (P8338), applies to taxon (P2352), identity of object in context (P4626), identity of subject in context (P4649), part of (P361), object has role (P3831)
Lists	<search Commons for files with depicts-statement and this property as qualifier> Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Database reports/Complex constraint violations/P642 Database reports/Constraint violations/P642
Proposal discussion	Proposal discussion
Current uses	Total 896,541 Main statement 5,061 0.6% of uses Qualifier 891,357 99.4% of uses Reference 123 <0.1% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Allowed entity types are Wikibase item (Q29934200), Wikibase MediaInfo (Q59712033), Wikibase lexeme (Q51885771), Wikibase property (Q29934218): 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/P642#Entity types

Conflicts with “instance of (P31): cuisine (Q1778821)”: 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/P642#Conflicts with P31, search, SPARQL

Conflicts with “instance of (P31): culture (Q11042)”: 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/P642#Conflicts with P31, search, SPARQL

Scope is 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/P642#Scope, SPARQL

Deprecate use case x3
If the value is a part of the parent item, applies to part (P518) should be used instead. (Use case x3 on Wikidata:WikiProject Data Quality/Issues/P642.) (Help)
Violations query: SELECT DISTINCT ?item ?itemLabel WHERE { ?item wdt:P527 ?part. ?item ?property [pq:P642 ?part] FILTER (?property != p:P31) FILTER (?property != p:P279) FILTER (?property != p:P2868) }
List of this constraint violations: Database reports/Complex constraint violations/P642#Deprecate use case x3

This property is being used by: es:Plantilla:Ficha de persona, it:Template:Epidemia, ja:Template:道の駅 ca:Plantilla:Esdeveniments, ca:Plantilla:Infotaula de Pokémon, ca:Plantilla:Infotaula de cançó, ca:Plantilla:Infotaula personatge, ca:Plantilla:Infotaula vaixell/base, ca:Plantilla:Infotaula d'estel, ca:Plantilla:Infotaula d'objecte astronòmic eu:Txantiloi:Etapa emaitza, eu:Txantiloi:Pertsonaia infotaula ha:Template:Databox kab:Talɣa:Databox ig:Àtụ:Databox ary:موضيل:معلومات كائن ga:Teimpléad:WD Bosca Sonraí Amhrán Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Related properties

applies to part (P518) when the restriction applies to a part of the item itself

Translation

Just saying that this is very hard to translate, at least in Finnish because we don't have many prepositions in the language. --Stryn (talk) 19:14, 30 December 2014 (UTC)

Totally agree, in Lithuanian language we use Genitive case for this „of“ purpose.--Zygimantus (talk) 07:56, 17 January 2017 (UTC)

Totally agree here that it's impossible to translate this into East Asian languages, where it's impossible to put a genitive after the noun being modified. Chinese (all variants) and Japanese can only do "A's B", not "B of A". Deryck Chan (talk) 23:26, 7 March 2017 (UTC)

Scope?...

This property lacks a proper definition. —Tinm (d) 19:37, 19 January 2016 (UTC)

Agreed. When it was still called "of", people were using it for everything and nothing. The label "within the scope of" does not seem to make sense in most cases. Is this qualifier really providing useful information in a situation where you do not already know what the proper relationship between the items involved should be? If not, then one should probably go for more specific solutions with a more narrow definition. --Markus Krötzsch (talk) 15:07, 26 January 2016 (UTC)

Confusing. In case this helps, here's some statistics: This property is used as a qualifier for some 147 properties, the most common ones being instance of (P31) (9746 uses), position held (P39) (4428 uses), P1112 (P1112) (2927 uses), winner (P1346) (1694 uses), postal code (P281) (1107 uses), Pokémon index (P1685) (1010 uses), occupation (P106) (904 uses), subclass of (P279) (768 uses), has use (P366) (308 uses), is a list of (P360) (249 uses), and symptoms and signs (P780) (240 uses). This is going to take some cleaning up. --Yair rand (talk) 01:55, 28 January 2016 (UTC)

• @Tinm, Markus Krötzsch, Yair rand: Only English (and "Canadian" and "British" English) has the lengthy "within the scope" attached to the preposition; every other language that I can read seems to just label this as a simple preposition. In English it was also originally simply "of" as the archive of the proposal shows. It was changed a few months ago - why? While the change did pull in content from the description, it does NOT seem to me to be an improvement on the simple 'of'. I believe it should be changed back to 'of' for English to match how it is expressed in other languages. Perhaps the description needs to be improved also. ArthurPSmith (talk) 13:19, 24 March 2016 (UTC)

While changing the label to 'of' the English description also ought to be changed - maybe 'qualifier to add context regarding where or what the statement applies to'? ArthurPSmith (talk) 14:03, 24 March 2016 (UTC)

@Swpb: any reason why you changed the en label ? I guess the qualifier was used as a "meaningless" multi-purpose qualifier that had any sense only in the context of a statement. With the change of label, this changes everything. Should'nt we go back instead ? author  TomT0m / talk page 17:36, 24 March 2016 (UTC)

While the issue is not resolved, I cancelled the change of label. Non concerted and not explained as far as I know. author  TomT0m / talk page 15:53, 25 March 2016 (UTC)

Classes where this is used

The most common property this is used to qualify is instance of (P31)

Here's a query for the most common P31 classes that P642 is used on, together with an example item and an example value:

tinyurl.com/k6hwfba

Jheald (talk) 01:53, 24 March 2017 (UTC)

Proper use?

Is this an acceptable use of this property? Q6259215#P527 --Valerio Bozzolan (talk) 17:57, 29 June 2017 (UTC)

No, usually such statements are not used at category items at all. --Infovarius (talk) 11:40, 30 June 2017 (UTC)

used as a qualifier in reference record

@ChristianKl: This could be used as a qualifier in reference record, as the examples in, Q43977122#P577 and Q43977130#P577. It is used to scope the indirect reference entity, stated in (P248):Q44287862, to a specific item. --Ans (talk) 07:28, 4 December 2017 (UTC)

Those references are problematic in a way that goes beyond the usage of "of". The semantics of stated in (P248) assert that two items with the same value are referring to the same source. Your constraint violations break that promise that's valuable for linked data.

Changing our data model in such a way that breaks guarantees on which data reusers can hope to rely is not something should be donewithout seeking consensus beforehand.

In addition, Wikipedia url's aren't valid values for reference URL (P854). Everything that gets imported from from Wikipedia is supposed to use imported from Wikimedia project (P143). This allows Wikipedias to make a decision not to import data from Wikidata that only has Wikipedia sources. ChristianKl (✉) 11:59, 4 December 2017 (UTC)

@ChristianKl:

1. The propose of this discussion here is to seek for consensus?
2. I use imported from Wikimedia project (P143) only when it is imported from the same wikipedia item (the wikipedia article is linked to sitelink on the same wikidata item that it is imported to). I use reference URL (P854) with a Wikipedia url, if it is imported from Wikipedia item that is not the same as wikidata item, since merely using "imported from" does not give provenance from which specific wikipedia article it is imported. Or we need to use of (P642) as a qualifier to "imported from" to give provenance of a specific Wikipedia article? I prefer to use "imported from":"wikipedia article" - "of":<item> pair rather than Wikipedia url, since its semantic is more well-defined than the Wikipedia url. I use Wikipedia url as just an interim solution. I've thought that it should later be converted to a more well-defined concept without loss of provenance information.
3. This allows Wikipedias to make a decision not to import data from Wikidata that only has Wikipedia sources. <-- I know that, but I've already thought that Wikipedian can also parse the url to know that it is imported from Wikipedia (also, just for interim solution).

--Ans (talk) 17:24, 12 December 2017 (UTC)

You didn't ping any Wikiprojects for input or list this discussion on the project chat to get input, so it's not likely to get substantial input. But even if you had that wouldn't lead to anybody supporting your proposal just as nobody did in the deletion discussion.

There's no parsing of the URL when Wikipedia imports data and Wikipedia currently filters out references that use imported from Wikimedia project (P143) to prevent Wikipedia references. While I do consider it valuable to provide exact reference to where data from Wikipedia comes from, the inability to do so is partly by design to discourage the usage of Wikipedia as source (eg. in https://www.wikidata.org/wiki/Wikidata:Property_proposal/wikimedia_revision_identifier there was the argument that "Wikipedia is not a source"). ChristianKl (✉) 22:28, 12 December 2017 (UTC)

It seems that the latest attempt at https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#Wikimedia_import_URL will be successful.

Discussion elsewhere

There's a discussion relating to the appropriate use of of (P642) at Property talk:P1435#Allowed qualifiers - P642 vs. P361. Comments welcome. — Ipoellet (talk) 20:03, 31 January 2018 (UTC)

Usages on Japanese expressways' interchanges/junctions...

Well I only ask for usages as "main statements", the usages as qualifiers are not affected.

I would love to know if there's ways to replace those usages, which over-filled this SPARQL Query. --Liuxinyu970226 (talk) 00:30, 18 January 2019 (UTC)

@B.O.B. jp, フォット, Ennpitsu, Raimei BT, 新幹線:@アストロニクル, 610CH-405: which I more or less know that they edited such items. --Liuxinyu970226 (talk) 00:33, 18 January 2019 (UTC)

@Okkn: How do you think about this? --2409:8902:9002:11FF:A782:9881:88C6:78CB 06:20, 18 January 2019 (UTC)

We may need a new property similar to connecting line (P81). --Okkn (talk) 10:38, 20 January 2019 (UTC)

Essay: P642 considered harmful

User:Lucas Werkmeister/P642 considered harmful is an essay advising against the use of this property. Comments are welcome on the talk page. Lucas Werkmeister (talk) 15:38, 17 April 2021 (UTC)

This topic has been raised as an issue for discussion at Wikidata:WikiProject Data Quality/Issues. - PKM (talk) 20:40, 13 November 2021 (UTC)

of (P642)

@Swpb Why can't we have the constraints?

The purpose of them is to discourage people from using the property and use alternative properties or propose new ones. Without the constraints, people will keep using of (P642) and may not use the alternatives - increasing its wrong usage. We need to stop the usage, decrease the usage, use alternatives, and propose alternatives if we're ever going to get to the point of deleting this property.

If there's any relationship you absolutely need of (P642) for, go propose a property right now. It's not like we're deleting the property. We're instead allowing for its continued usage, but encouraging editors to find alternatives by notifying them with constraints. Lectrician1 (talk) 18:40, 8 February 2022 (UTC)

We should not have these broad constraints yet because we don't have viable alternatives identified yet, and we want some sort of consistency in how P642 uses are migrated. We are working on identifying use cases here, but we have barely begun (help is appreciated!). I know from personal experience that there are dozens of use cases for which there is no appropriate existing alternative, and property creations don't happen overnight. The smoothest, least disruptive way to do this is to identify and create alternatives on a use-case basis, migrate uses and set narrow constraints against those uses as we go, not to announce to the world that this property is soon to be dead when we still have no idea what is to become of its tens of thousands of uses. We did a very similar thing several years ago with the nebulous "as" property, and it was a very effective approach. P642 has similarly been around for years, and is even more widely and variously used than "as" was. The new uses that appear during this process are not going to make a significant impact on effort – but doing things without proper planning will. Swpb (talk) 15:10, 9 February 2022 (UTC)

• Can we see some numbers before doing large scale changes?

There are currently 11,228,761 uses of this as qualifier.

• Changing the constraint as done generates the same number of constraint violations.
• There is a risk that changing millions of statements to a different existing property deteriorates data quality for these properties, while many of the current uses of this qualifier are harmless.

What would help are the number of uses per property. We don't really know how relevant the samples in the essay above are (it doesn't supply any numbers).

Some pointers:

• Most of my queries timed out
• There are 62 properties that have it as "allowed qualifier": [1]
• Other properties may not have such a constraint.
• [[2]] has 197165 uses for P31. Maybe Ivan could generate them?

Once available, a plan per property would probably be best. Wikidata:WikiProject_Data_Quality/Issues/P642 is a good start, but e.g. for P31 covers currently 10% or so (per given quantity). --- Jura 23:58, 9 February 2022 (UTC)

I suspect that in 11 million uses, there will be large use cases of possibly several million usages each. It would be good to identify those and start any migration with them. I think P31 and P279 may be the last in line. Vojtěch Dostál (talk) 14:35, 10 February 2022 (UTC)

@Jura1 So I delved deeper, using Harej's custom query service. I can confirm there are 197,000 statements with P642 qualifiers of instance of (P31). it seems there are only 18,811 such uses in subclass of (P279). According to an (incomplete) query, a huge number of usages is in P2215 (P2215). A further query indicates there is actually 10,443,919 usages in P2215 (P2215). Resolving those might make further querying and filtering possibly simpler. Vojtěch Dostál (talk) 15:09, 10 February 2022 (UTC)

Thanks. Nice query. Should have thought of that.

So after P2215 (P2215) and instance of (P31) just about >500,000 remain. I found:

• 174,385 for subject has role (P2868)
• 108,891 for winner (P1346)
• 74,107 for position held (P39)

Seems the generic qualifier is being used in a too generic way ;) --- Jura 15:45, 10 February 2022 (UTC)

@Jura1 We'll have to go property-by-property and discover patterns of usage. I'll try to propose a solution for P2215 because there the usage of P642 seems particularly unnecessary. Vojtěch Dostál (talk) 17:08, 10 February 2022 (UTC)

@Vojtěch Dostál: I've found (see Wikidata:WikiProject Data Quality/Issues/P642) that use cases depend on the classes of items involved, as much if not more than on the property in the main statement. Some uses are very ideosyncratic. This may be a nearly asymptotic effort - it will take some effort to resolve 90% of uses, then a similar effort to resolve the next 9%, and the next 0.9%... Swpb (talk) 20:26, 14 February 2022 (UTC)

@Swpb Yep, you are completely right. I am just looking for the low-hanging fruit now, as a proof-of-concept that things like this can be changed. There may not even be consensus for removal of P642 in some other cases, so I'd start with a use case which is quite clearly wrong to me. I think object has role (P3831) or applies to part (P518) might make more sense but I need to check it with the astronomy community here. Vojtěch Dostál (talk) 13:54, 15 February 2022 (UTC)

It's not clear to me either what the added value would be to change the qualifier of properties that have a clearly defined use for it (e.g. P2215 (P2215)).

The essay seems mainly about P31 (and P279). Personally, I think there are 3 types of uses:

• uses that should be with another qualifier or property (possibly created afterwards), but was never migrated
• uses that help (human) editors understand the items (harmless, I think)
• uses that should be with a different property, but that doesn't exist yet

For P279, I added some Krbot stats to its talk page (see Property talk:P279). Hope these are better than some I got for P642, but couldn't match with others. --- Jura 14:12, 15 February 2022 (UTC)

Too bad I didn't bother to check this talk page before doing the statistics myself, as you apparently had done them just three weeks prior... Anyway, as I point out at Wikidata talk:WikiProject Data Quality/Issues/P642#Performance and database design I believe that using of (P642) (or actually any Wikidata qualifier) the way it has been used for P2215 (P2215) is a pretty sub-optimal way of representing what would normally be a single entry in a database of stellar objects. Mathematically, proper motion is a single property, a spherical vector consisting of two scalar values (or possibly three, if you were to combine it with radial velocity (P2216) to which it's physically related, though I would recommend against doing so for other reasons), much like latitude and longitude (optionally combined with altitude).

Applying a qualifier to a property value is to me a kind of irregular exception, such as when the value changes under particular circumstances or at a specific point in time. But right ascension (Q13442) and declination (Q76287) are in no way "particular circumstances"; they are the inseparable axes by which you indicate a point in a two-dimensional coordinate system. You can't have one without the other and still identify the point, much like you can't locate an airplane by stating its latitude at one point and its longitude at another, maybe 15 minutes later; they always come in pairs.

So, for each star you will need two property claims, separated by this (or some other) qualifier. This is no big deal to Wikidata; a single item may have two values for the same property, or 20, or 200, or three... See where I'm getting at? Unless you have some strict rules about in what order the components of a pair of values may appear in Wikidata, you cannot tell for sure which two claims belong together. Now, for a constant vector there would be only two claims, but what if you have several, like for Barnard's Star (Q14268)? Granted, as all but two are deprecated, this isn't a significant problem, but what if you have multiple values of equal rank, say because the proper motion has actually changed over time? You can add more qualifiers to identify those pairs, but it seems like a pretty non-intuitive way of structuring your data, like first taking a series of timestamps and separating them with hours in one bag, minutes in another, and seconds in a third, but only after putting a label on each number to tell which originate from the same timestamp.

And what is the performance cost of looking up these values, with the fairly complicated data structure required just to represent a single value with a qualifier? This is where I begin comparing it with mailing a small airplane.

Therefore I'd prefer seeing a new datatype, similar to geographic location, but relative rather than absolute. If Wikidata is expected to list millions of stellar objects, maybe it could warrant a phabricator ticket? --SM5POR (talk) 09:09, 16 March 2022 (UTC)

@Vojtěch Dostál: Maybe a spherical vector datatype (two scalars) like the one I suggest is the solution you are looking for? --SM5POR (talk) 14:03, 16 March 2022 (UTC)

Alleged discouragement or deprecation

I can read that the use of this property is discouraged, but I can't see why; it is enormously useful.

One use of this property is to say, e.g. "X is a list of Y"; thus, I say "X is a list, then use "of" as a qualifier, and then "Y" as a parameter.

I would also like to see "for" as a separate property.

Generic properties are actually very useful. Like in natural language, it is often useful to say something broader or generic rather than laboring about the more specific concept to pick.

--Dan Polansky (talk) 09:08, 22 December 2022 (UTC)

If this property should be discouraged, there should probably be an easy to use guide on how to translate from English to Wikidatese. There should be example sentences in English for common uses of "of" and then example markups in Wikidatese. Since, it is vital that users have it easy to translate from English to Wikidatese and that is currently often rather difficult.

--Dan Polansky (talk) 09:12, 22 December 2022 (UTC)

I see this was discussed at User_talk:Lucas_Werkmeister/P642_considered_harmful, but one of the most natural places to discuss this is on the property talk page or in some public venue, not on a user's talk page.

Let those who want to deprecate the property describe for use how to translate the following:

• X is a list of Y
• X is a set of Y

And I also propose "for" as a separate propery:

• X is a tool for Y"

And if not a dedicated property, then a translation guide from English to Wikidatese (where Wikidatese is the language of Wikidata). Maybe Wikidata:Translating from English to Wikidatese, and there could be similar guides for other languages. Do such guides already exist? --Dan Polansky (talk) 09:17, 22 December 2022 (UTC)

@Dan Polansky: What do you think about these suggestions?

1. Xinstance of (P31)list + Xis a list of (P360)Y - note, that this is a subproperty of has part(s) of the class (P2670)
2. Xinstance of (P31)set + Xhas part(s) of the class (P2670)Y - though the scope of this property is somewhat restricted
3. Xinstance of (P31)tool + Xhas use (P366)Y --Nw520 (talk) 11:07, 22 December 2022 (UTC)

@Nw520: Thank you; excellent. There should also be "is a set of". My point would be that "of" enables a generic class of these expressions and that, from a certain standpoint, these properties are artificial: I do not need isAListOf if I have X-isA-List-of, and then I can plug any container type instead of List into the position, whether list, set, mapping or multiset. Also of note is that "isA" is ambiguous between isInstanceOf and isSubclassOf, so properly, there would have to be isInstanceOfListOf and isSubclassOfListOf. It seems preferable to make generic tools available ("of") rather than making specific compound tools ("is an instance of list of"), and this is indeed what natural language does. In any case, thanks again. --Dan Polansky (talk) 11:17, 22 December 2022 (UTC)

If I'm understanding you correctly, you are describing a property like for example “is a collection of” (this might be already covered by has part(s) of the class (P2670), but I'm not a member of WikiProject Onthology ;) ). The problem with of (P642) however is that its de-facto-scope was and is much broader. In most instances “of” is interpreted as “I can somehow narrow my statement down, but I don't know what the relationship between the statement's value and the refinement is.”
For instance: Let's assume I'm developing a template for Wikivoyage that displays the type of cuisine served by a restaurant. Xinstance of (P31)restaurantof (P642)Italian cuisine (Q192786) works fine, but due to the unrestrained nature of “of” some people also used it for statements like Xinstance of (P31)restaurantof (P642)McDonald’s (Q38076). Thus, I'd have to walk through the qualifier value's class hierarchy to reason whether the item is in fact about a cuisine. With dedicated properties like cuisine (P2012) querying becomes a piece of cake since all reasoning had to be done at the time the data was added to Wikidata, with the added benefit that tighter constraints can be enforced (and better value suggestions provided). --Nw520 (talk) 11:51, 22 December 2022 (UTC)

I see. But the problem with avoiding generics is that using Wikidata gets rather hard. Maybe an easy-to-use guide would help, or good example entities where one can see how things can be done. --Dan Polansky (talk) 12:00, 22 December 2022 (UTC)

What about me starting a translation guide and see how far we can get with that? --Dan Polansky (talk) 11:19, 22 December 2022 (UTC)

Later: I misunderstood a bit. It is now possible to say X isSubclassOf List isListOf Y or X isInstanceOf List isListOf Y. But the point about genericity of containers stands: I want to connect any container to its concent. Then, instead of isListOf, there could be isContainerOf. I still see value in the generic "of"; I cannot think about the range of all its applications. It would perhaps be profitable to figure out how to best translate "of" into inflected languages such as German and Czech rather than trying to get rid of this generic tool. Admittedly, I am looking at it from the point of view of English and the appearance of the resulting structures from the point of view of German or Czech may be rather suboptimal, leading to phrasing that is not natural in these languages. --Dan Polansky (talk) 11:40, 22 December 2022 (UTC)

X is a mapping of Y to Z

How do I say this? I can currently do it with "of", and I have to make a workaround for "to", but I can do it.

For instance, how do I say that "my concept" is "a mapping from positive integers to real numbers"? (I would actually like to see "from" from a natural language perspective.) --Dan Polansky (talk) 11:58, 22 December 2022 (UTC)

There are definition domain (P1568), image of function (P2396), codomain (P1571) and input set (P1851) for this :) --Infovarius (talk) 15:29, 27 December 2022 (UTC)

X is a set of Z

I am slowly starting to understand the ontology business. To say the above, we say two things:

• X subclass-of set
• Y has-part(s) Z

We do not need qualifiers. We do not need to say this:

• X sublass-of set of Z; "of" as a qualifier is essentially a workaround.

The key ontological questions are: what are the superclasses, qualities, parts? We want to see candidate hypotheses about these questions listed next to each other, ready to be accepted or deprecated, and ready to lead to a fork of a concept when it turns out sources differ. We do not need explicitly say "X of Y". Or so I think; some ontologist can correct me. This should all be clearly explained somewhere in Wikidata, but apparently it isn't. --Dan Polansky (talk) 16:51, 25 December 2022 (UTC)

Can we mark this property as deprecated in its description?

@Swpb @SM5POR @Push-f It not being deprecated tells people it's still okay to use it. It should not be okay to use it. Lectrician1 (talk) 10:21, 31 January 2023 (UTC)

@Lectrician1: I agree that we should strongly discourage further use, as the current language ("will be deprecated") seems a bit weak and unspecific in time. However, it would be wrong to say it is or has been deprecated already, or add prohibitive constraints, before we have all the replacement properties created and documented. Maybe is (currently / in the process of) being deprecated would be a strong enough hint? By bugging editors about current use too early (say, by adding constraints), we will only be bugged ourselves in return about future use not being decided yet.

We may want to speed up the process by working on several (non-overlapping) groups of use cases simultaneously, but each group will take its time, as we will have to consolidate the changes in whatever templates, modules, Wikipedia infoboxes and Help pages that keep referring to them (in my opinion, for each use case the Wikidata documentation statements, Help pages and their translations ought to be fixed first, then the functional applications, and finally the actual claims). --SM5POR (talk) 20:13, 31 January 2023 (UTC)

Absolutely not, the property is not and should not be deprecated yet. Where replacements for specific use cases have been identified, we can and do create constraints to discourage P642 from being used in those cases. But if we just tell everyone "don't use this property for anything" before we identify all its replacements, we will have chaos as different editors make up their own work-arounds, and we'll never be able to track down all the weird statements that result. The work must be done first. Swpb (talk) 20:59, 31 January 2023 (UTC)

Agree 100% with @Swpb - we can deprecate for specific cases, and chip away at using "of" as time goes along, but simply saying "don't use this for anything" will mess things up a lot - especially since some situations, like the one that prompted this (position held (P39)) simply don't have a good widely-agreed replacement yet. This report gives an idea of how complicated it would be to unpick for the different groups, though there are a few potential easy wins there. Andrew Gray (talk) 22:16, 31 January 2023 (UTC)

@Andrew Gray, @Nassauer27, @ChristianKl, @TomT0m, @Infovarius, @TheAafi, @GZWDer: Speaking of position held (P39) (and some similar properties), I'm currently considering two distinct qualifiers tentatively labeled in service of and assigned to, but before writing the formal proposals I'd like to hear from editors working in different languages how well they would translate without ambiguities or significantly changed connotations. Based on that input, we could consider additional qualifiers to use in different contexts (such as whether to use the same assigned to qualifier or different ones in a political vs a business context, or whatever distinction is important in languages other than English). Please add your comments on these labels (or introduce alternative labels) in the subsections at Wikidata talk:WikiProject Data Quality/Issues/P642/Property labels#Seeking language advice on future qualifier proposals. --SM5POR (talk) 09:04, 1 February 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘It appears it's been disabled for use with "position held". So those of us who are trying to build entries can either fuck off or be subjected to an undue burden? Help me out here.Scratch that, I used it after searching for it. For those of us using the property in this context, are we supposed to create values for every individual position or pretend that those positions somehow aren't important enough to include? That's what I could really use help with.RadioKAOS (talk) 12:24, 2 March 2023 (UTC)

@RadioKAOS: Having to create items that combine generic positions with different administrative entities (such as "mayor of Dillingham") is precisely what I want to avoid by introducing multiple qualifiers to replace of (P642). In the case you were working on I would write it pretty mcuh as you did, with Joe McGill (Q104828795)position held (P39)mayor (Q30185)in service ofDillingham (Q79383). But before I put forward this proposal, I'd like to see comments from various language communities, including the English one, to determine an appropriate scope that doesn't make translating this property label unnecessarily burdensome, such as whether you can use the same "in service of" expression whether this person has been elected by the inhabitants or appointed by the executive branch of the local government. Would you say that a member of the House of Representatives representing California does so "in service of" California's 23rd congressional district (Q525805) and "assigned to" United States House of Representatives (Q11701), or would you prefer represents (P1268) California's 23rd congressional district (Q525805) (with the same "assigned to" qualifier) in that particular case? --SM5POR (talk) 10:04, 20 March 2023 (UTC)

Replace "of" in depicts beheaded head of John the Baptist

See Q116966881#P180: Salome (Fragment) (Q116966881)depicts (P180)beheaded head (Q101195208)of (P642)John the Baptist (Q40662). What would be a good replacement for of (P642) here? Multichill (talk) 17:47, 4 March 2023 (UTC)

part of (P361) would be accurate, if a little stilted. Swpb (talk) 06:55, 5 March 2023 (UTC)

@Multichill: Could Head of Saint John the Baptist (Q1698963) be used there, or would that have to be restricted to uses of the motif in heraldry? It would be a shame for it not to cover all uses of the motif, in my opinion. Ham II (talk) 17:44, 24 January 2024 (UTC)

P642 needed for taxonomy synonyms

Often old species names become superseded, especially in the case of fungi, and when this happens it is important to have a convenient link from the non-current taxon item to the current taxon item. According to the WikiData taxonomy tutorial, this can be done by adding a "instance of (P31)" = "synonym (Q1040689)" statement (in addition to the normal "instance of = taxon" value) and adding the qualifier "of (P642)" with a value equal to the preferred taxon item. I see from a SPARQL query that there are currently 9920 such uses of P642 and at present all the proposals would use P642. This is also being discussed at Wikidata_talk:WikiProject_Taxonomy#Property_"of"_(P642)_deprecated_but_needed_for_synonyms

Could P642 continue to be used just in the context of taxon items? How could we solve this? Strobilomyces (talk) 14:58, 17 October 2023 (UTC)

• In some languages there is no equivalent of 'of'. As a result, this qualifier may not be unambiguous because translations do not always perfectly convey its meaning. In the WikiProject you have been given a different solution, I think even creating a new property for this would be better than the use of 'of' qualifier. Wostr (talk) 17:43, 17 October 2023 (UTC)

@Wostr: Thank you for answering. Please can you say specifically where the different solution given in the Wikiproject is? I agree that a new property could solve the problem and I wondered whether there might be an existing one which we could use in this context. Strobilomyces (talk) 18:11, 18 October 2023 (UTC)

@Strobilomyces: I was writing about the creating of a new property. Biological taxonomy is not my field of interest, but I think it would be reasonable to consider whether the main value with the qualifier should be reversed (in a new property or an existing one, if such property exists), i.e. the taxon name used as the main value and the taxon function (basonym, etc.) as the qualifier, e.g. by object has role (P3831). From a layman's point of view, this seems more logical, but I don't know how this data is most often queried and this should affect the data model. What's more, this discussion should take place on one page, Wikidata talk:WikiProject Taxonomy seems to be better for this. Wostr (talk) 21:52, 18 October 2023 (UTC)

I think that would be more logical, but it would also be more difficult to bring about in Wikidata given the current status, so I prefer not to propose it. OK, I will stop posting on this page. Strobilomyces (talk) 09:52, 19 October 2023 (UTC)

On Wikidata:WikiProject_Taxonomy under "Optional properties"/"General", it mentions that "of (P642)" can be used with "subject has role (P2868)" and I know that it is used with roles protonym (Q10640897), correct name (Q3342920) and basionym (Q810198) amongst others as well as "synonym (Q1040689)". In fact it is logical to do this for most of the roles which are listed below in section "Related Items" - actually they are all types of synonyms more or less. I think it would be best to have one new or existing property to replace P642, rather than creating new properties "is protonym of", "is synonym of", "is basionym of", etc. I see that there is a property "relative to (P2210)"; could we simply replace P642 by P2210 everywhere? Is that property also liable to be deprecated? Strobilomyces (talk) 19:32, 18 October 2023 (UTC)

Chairperson

Since this property is being deprecated please give an example for chairpersons:

• Heinrich Böll, position held: chairperson of P.E.N

None of the alternatives listed under related property (P1659) seem to fit. --Kolja21 (talk) 04:16, 1 February 2024 (UTC)

The same problem applies for, say, 'chancellor of [insert university here]'.

Or I guess any sort of '[position] of [organization]' use cases. 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 (talk) 23:48, 8 February 2024 (UTC)