Property talk:P1629

Latest comment: 1 month ago by Vicarage in topic Mark this property as deprecated

Documentation

Wikidata item of this property
item corresponding to the concept represented by the property
RepresentsWikidata item (Q16222597)
Data typeItem
Template parameter|subject item= in Wikidata's {{Property documentation}}
DomainWikidata property (Q18616576)
Usage notesFor external identifier properties, use a more specific property: If the object describes the identifier itself, use P10726 (class of non-item property value); if the object is a database, use P9073 (applicable 'stated in' value); if the object is an organization that issues the identifier, use P2378 (issued by).
Examplenot applicable
father (P22)father (Q7565)
owned by (P127)proprietor (Q12794619)
SourceInitially from subject item of {{Property documentation}} on the talk page of each property (note: this information should be moved to a property statement; use property source website for the property (P1896))
Tracking: usageCategory:Pages using Wikidata property P1629 (Q98131385)
See alsoclass of non-item property value (P10726), applicable 'stated in' value (P9073), issued by (P2378)
Lists
Proposal discussionProposal discussion
Current uses
Total4,468
Main statement4,33897.1% of uses
Qualifier541.2% of uses
Reference761.7% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Type “Wikidata property (Q18616576): item must contain property “instance of (P31)” with classes “Wikidata property (Q18616576)” or their subclasses (defined using subclass of (P279)). (Help)
List of violations of this constraint: Database reports/Constraint violations/P1629#Type Q18616576, hourly updated report, SPARQL
Inverse property of “Wikidata property (P1687):
if [item A] has this property (Wikidata item of this property (P1629)) linked to [item B],
then [item B] should also have property “Wikidata property (P1687)” linked to [item A]. (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/P1629#inverse, SPARQL
Qualifiers “of (P642), reason for deprecated rank (P2241), reason for preferred rank (P7452): this property should be used only with the listed qualifiers. (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/P1629#allowed qualifiers, SPARQL
Allowed entity types are Wikibase property (Q29934218): the property may only be used on a certain entity type (Help)
List of violations of this constraint: Database reports/Constraint violations/P1629#Entity types, hourly updated report
Scope is as main value (Q54828448): 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/P1629#Scope, SPARQL
Item “property constraint (P2302): Items with this property should also have “property constraint (P2302)”. (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/P1629#Item P2302, search, SPARQL
Single value: this property generally contains a single value. (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/P1629#Single value, SPARQL
Distinct values: this property likely contains a value that is different from all other items. (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/P1629#Unique value, SPARQL (every item), SPARQL (by value)
 

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Polish label edit

First I proposed 'dedykowana kategoria' (dedicated category) to reflect the meaning 'kategoria' is a general type indicator has in Polish. However 'kategoria' (category) in the context of Wikipedia is biased towards Wikipedia categories. Thus I changed that for 'dedykowany typ' (dedicated type). Generally I think whenever we are refering to Wikidata classes in Polish, we should use 'typ' (rather than 'klasa' - 'class'), since 'klasa' is only well known in the computer sience society. -- User:apohllo

Description improvement edit

Assuming that I understand P1629's description correctly, perhaps it might be clearer if it said something like

"P1629's use as a property in a statement indicate's that the statement's value or object exactly represents the concept of the statement's item."

Currently, the description reads "item corresponding exactly to the concept represented by the property (use in statements on properties)". It wasn't immediately clear to me what "item" referred to. Now I believe it refers to the value/object of the triple in which P1629 is the property, however for a long time I was confused and thought it referred to the items that hold properties that hold P1629 as a property.

For example, on the page of the "cast member" entity (https://www.wikidata.org/wiki/Property:P161), there is the claim

<cast member><subject item of this property><actor>

The definition of P1629 (and its own label) made me think that whenever <cast member> is the property in a given triple Z, then the item of triple Z should be an <actor> entity or a subclass of the <actor> entity, which is not the case (<cast member> often appears in statements where the item is the film, and the value/object is an actor).

Now I believe the description means that if statement Z is <cast member><subject item of this property><actor>, then <subject item of this property> indicates <actor> "represents the concept of" <cast member>.

I checked the Help:Properties page and did not find any guidelines that say descriptions should in general be read backwards like in the above example, so perhaps P1629's description can be clarified by making it more explicit as to what "item" and "property" specifically refers to.

 – The preceding unsigned comment was added by Godfreyyeung (talk • contribs).

Proposal to stretch definition edit

Proposal: Stretch Wikidata item of this property (P1629): for external ID and database properties Wikidata item of this property (P1629) may point to the database. A seperate item on the ID's is not necessary. Lymantria (talk) 10:27, 28 December 2016 (UTC)Reply

@Laddo, Paperoastro, GZWDer: from the proposal discussion/ creation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 28 December 2016 (UTC)Reply
@Lymantria: to be more specific I suggest we remove the word "exactly" from the description of the property, and add Wikidata usage instructions that state "for external identifiers, the linked item should preferably be an item about the identifier itself; alternatively the linked item can be the database that defines the identifier". ArthurPSmith (talk) 20:01, 28 December 2016 (UTC)Reply
@ArthurPSmith: I agree with that. Lymantria (talk) 21:35, 28 December 2016 (UTC)Reply

Votes and opinions edit

I don't see the problem. Databases with multiple identifiers have links to multiple properties. Sounds about right to me. --Azertus (talk) 15:17, 28 December 2016 (UTC)Reply
They should have multiple links to a single item about each identifier. Those items should then have 1:1 links to the respective properties. Contrary to your remarkable earlier assertion, "The exact matching of items to concepts is not that important", matching items to concepts is core to what Wikidata is about. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:44, 28 December 2016 (UTC)Reply
Duh, I'm talking about item and concept in the absolute narrowest sense, i.e. their use in this property's current description and original property proposal, which you quoted on this page. --Azertus (talk) 16:01, 28 December 2016 (UTC)Reply

Conclusion edit

Grade is subject item of "maximum gradient"? edit

Maximum gradient doesn't correspond exactly to grade but is related to it, as well as many other similar properties. From what I see, "subject item of this property" is always invoked in such cases, is it right? --Malore (talk) 19:10, 26 March 2018 (UTC)Reply

German description: Please add a comma edit

Hello, please add a comma in german description: „Objekt, das mit den Aussagen ...“ Thanks, Eryakaas (talk) 17:26, 30 September 2018 (UTC)Reply

Template:Tun warum können Sie selbst nicht? --Infovarius (talk) 13:22, 1 October 2018 (UTC)Reply
Ich weiß nicht :-) vielleicht bin ich zu neu. Die Seite ist im Modus "Nur Lesen". Ich habe keine "Bearbeiten"-Links. Aber vielen Dank für die Korrektur! Eryakaas (talk) 18:31, 1 October 2018 (UTC)Reply

Generalizing this property to "Wikidata item" edit

In the greater Wikibase federation, some Wikibases use "federated properties," meaning they use only properties from Wikidata and no local ones. One of the properties that would be useful for us would be a property for "Wikidata item," i.e., Wikidata item corresponding to this thing. Wikidata itself doesn't really have a use for this property, except in this particular instance where we are mapping properties to items. My question is, would it be possible to generalize this property to refer to any associated Wikidata items, or would that stretch the boundaries of this property too much? Harej (talk) 20:54, 28 September 2021 (UTC)Reply

  Oppose Contrast to OP states, this property is being used. There are currently almost 9k statements using it. It is a great property to navigate the many properties in Wikidata. Stretching the semantics of this would create noise. Having said that, nothing stands in the way to any Wikibase operator to mimic the behaviour of this property in their Wikibase, by minting a property with more or less the same semantics, even using Wikidata items. --Andrawaag (talk) 13:46, 11 October 2021 (UTC)Reply
  Comment I think the context here (per Andrawaag's suggestion) is that wikibases using federated properties cannot create their own properties, but must use the ones Wikidata provides (for now). However, I would suppose there's nothing preventing them from using a property more widely in their own system than as it is used by Wikidata. ArthurPSmith (talk) 15:29, 11 October 2021 (UTC)Reply

Mark this property as deprecated edit

This property often describes multiple different relationships such as the domain of the property, the range, the issuer of the external identifier, or what the property identifies - as seen in above discussion.

This is bad because it makes identifying the true domain, range, or issuer of an EID more-difficult and can lead to conflicts in statements on properties. Additionally, it encourages people to use this more-general property instead of adding more-specific and useful statements. It decreases the quality of Wikidata.

All of these issues this property causes have been resolved with the introduction of the more-specific replacement property class of non-item property value (P10726), identifies (P10476), and the decision to Create items for all external identifier identifers.

For this reason, I'm proposing this property be marked as deprecated and noted that users should switch to using value-type constraint (Q21510865), subject type constraint (Q21503250), class of non-item property value (P10726), and identifies (P10476) instead.

The reason it should be marked as deprecated and not put up for deletion (yet) is to encourage users to continue to not use the property and help transfer all the current uses to the alternative properties.

Thoughts? Lectrician1 (talk) 00:11, 10 January 2024 (UTC)Reply

  Support People also use this property for the same concept as applicable 'stated in' value (P9073) and issued by (P2378). I see no reason to keep using this property if there are clearer ones for each use case. -wd-Ryan (Talk/Edits) 01:32, 10 January 2024 (UTC)Reply
  Support Agree with the given above. Sjoerd de Bruin (talk) 08:30, 10 January 2024 (UTC)Reply
  Question @Lectrician1@Sjoerddebruin@Wd-Ryan Do we have something to link properties with their databases ? For example we have an item for VIAF Virtual International Authority File (Q54919)      that should be either linked to the property item or the database/knowledge base item.
I see facet of (P1269)   seems to has been used for that :/ not my favorite property, as it’s also very catch all. author  TomT0m / talk page 09:50, 10 January 2024 (UTC)Reply
(arguably this is the important stuff, the database to link, because if we need an id for the property why not use the property entity for this ? I can’t remember why we would want it in the main namespace for this. There are still cases where this make sense like spouse (P26)   to link with marriage (Q8445)     . Does identifies (P10476)   would work for that ? author  TomT0m / talk page 09:57, 10 January 2024 (UTC)Reply
@TomT0m Uh I don't see facet of (P1269) on that item? Did you link the wrong item or property? What your asking is a bit confusing. Lectrician1 (talk) 15:24, 10 January 2024 (UTC)Reply
@Lectrician1 It was not for this particular example, sorry for the confusion.
author  TomT0m / talk page 16:10, 10 January 2024 (UTC)Reply
  Oppose even if we just look at the examples of the property the link from father (P22) to father father (Q7565) is not captured by either class of non-item property value (P10726) or identifies (P10476). ChristianKl13:29, 10 January 2024 (UTC)Reply
@ChristianKl father (P22) can be linked to father (Q7565) using class of non-item property value (P10726).
class of non-item property value (P10726) can be used on Item properties when class of the property value is narrower than the permitted range of the property that is described with "value-type constraint" (Q21510865). Lectrician1 (talk) 15:07, 10 January 2024 (UTC)Reply
@Lectrician1 To me father (P22) seems to have quite obviously an item property value. ChristianKl23:02, 10 January 2024 (UTC)Reply
@ChristianKl yeah that's a conflict we're trying to resolve. Came at the wronggg time. Lectrician1 (talk) 23:41, 10 January 2024 (UTC)Reply
  Oppose it can be put up for deletion first, and if decided so, then mark as deprecated but not delete before all values have been transferred. This seems like a deletion request in disguise, because if you put it up for deletion only after it has been made unused, it will almost certainly pass. Ainali (talk) 15:42, 10 January 2024 (UTC)Reply
@Ainali I admit, yes, this is a deletion request in disguise, but how does this proposal differ from the decision to deprecate of (P642)? Do you believe of (P642) should have been put up for deletion? Lectrician1 (talk) 15:55, 10 January 2024 (UTC)Reply
I don't know, I haven't looked into that discussion closely. Either way, it sounds like a w:en:WP:GOFISHING argument. Ainali (talk) 22:24, 10 January 2024 (UTC)Reply
Well, it's being put up for the same reasons so it's not like one has any difference to the other. Lectrician1 (talk) 22:38, 10 January 2024 (UTC)Reply
  Oppose I think it's far too soon for that. The new properties are nowhere near well-established enough. The people who want to change the data model need to do a significant portion of the initial work themselves because they are the ones who understand what the new model should be. Telling everyone else to not use a property when almost every other property they look at is using it is confusing.
I don't see any clear information on this page that explains how to describe things using the new properties, for people not familiar with the data model you want them to use, nor any queries for finding which of these statements are not yet expressed using the intended replacement properties, tracking progress, etc, for people who want to help.
This property is in use in various places (see the "This property is being used by:" box above and the bottom of the "Page information" page), those places need to be contacted and their templates/modules updated.
- Nikki (talk) 16:10, 10 January 2024 (UTC)Reply
I think it's far too soon for that. The new properties are nowhere near well-established enough. The people who want to change the data model need to do a significant portion of the initial work themselves because they are the ones who understand what the new model should be. Telling everyone else to not use a property when almost every other property they look at is using it is confusing.
There are 11,613 uses of the property. I and anyone else who is aware of the alternatives do not have the time to go through all of these and switch them over. Switching them over is not a complicated process. I will make an informational page on how to do this, however I want to make sure with the community that they agree this should be done in the first place.
I don't see any clear information on this page that explains how to describe things using the new properties, for people not familiar with the data model you want them to use, nor any queries for finding which of these statements are not yet expressed using the intended replacement properties, tracking progress, etc, for people who want to help.
class of non-item property value (P10726) and identifies (P10476) provide easily-understandable property examples on how to use them.
I haven't made any queries or tracking yet because I am first aiming to establish the premise/policy that phasing out this property is okay. That is the purpose of this proposal.
This property is in use in various places (see the "This property is being used by:" box above and the bottom of the "Page information" page), those places need to be contacted and their templates/modules updated.
I would do that if this proposal passes declaring that this property should in-fact be phased-out. Lectrician1 (talk) 19:10, 10 January 2024 (UTC)Reply
  Oppose New properties need to be proposed and created to take its place, and uses migrated. class of non-item property value (P10726) in particular was never meant for this role. Swpb (talk) 19:23, 10 January 2024 (UTC)Reply
  Oppose This is what happens when people misuse properties for supposed convenience, and the community is happy to let it slide. This property was only every supposed to be about the "item corresponding exactly to the concept represented by the property", (note: exactly; e.g. ORCID iD (Q51044) for ORCID iD (P496), as seen here), not some nearby concept: as I pointed out above, in December 2016. What a farce. We should return to that purpose, and clear out the other junk. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:27, 12 January 2024 (UTC)Reply
Agree, P1629 should be limited to exact correspondence. Just want to point of that when that exact correspondence is between an external ID property and its item, like ORCID iD (P496), class of non-item property value (P10726) should be used instead. It's a sub-property of P1629, so it entails P1629 while being more specific. I've been working to migrate those statements, as well as some other use cases that fall afoul of exact correspondence, namely: 1) relationships between ID properties and databases, to applicable 'stated in' value (P9073), and 2) relationships between ID properties and organizations, to issued by (P2378). In terms of clearing out junk, we should look for other use cases that can be migrated, so we don't lose potentially valuable data when we remove all P1629 statements that fall afoul of "exact correspondence". For that matter, if P1629 is truly meant to be a 1:1 relationship, it should have a single-value constraint (Q19474404) and a distinct-values constraint (Q21502410). Right now, tons of properties violate those constraints. Swpb (talk) 17:52, 12 January 2024 (UTC)Reply
You seem to be jumping the gun by removing statements before this thread has come to a conclusion. https://www.wikidata.org/wiki/Special:Contributions/Swpb Vicarage (talk) 19:18, 12 January 2024 (UTC)Reply
I'm not doing anything that depends on the conclusion of this thread. I'm moving statements that have been using the wrong property to the properties they should have been using all along, and which similar statements already used. This does help clear out uses of P1629, but it in no way needs to be preceded by an agreement to deprecate or descope P1629. Swpb (talk) 19:51, 12 January 2024 (UTC)Reply
I guess that depends if it's really meant to be a 1:1 property, and that would mean being clear on what's the use cases of this property are. There is not necessarily a purpose into having exact match items for identifiers, are they ? author  TomT0m / talk page 07:35, 13 January 2024 (UTC)Reply
  Oppose per what many people have said above. PKM (talk) 21:59, 12 January 2024 (UTC)Reply
Also, User:Bargioni/UseAsRef.js uses this property to construct a "stated in" reference. I rely on that script heavily, and would be unhappy to see it made useless. - PKM (talk) 01:00, 13 January 2024 (UTC)Reply
@PKM I can create a fix and an admin can apply it. Lectrician1 (talk) 01:07, 13 January 2024 (UTC)Reply
Which of your new properties would you use instead? Would it make sense as the value of “stated in”? I find the new properties very confusing. “Stated in” should refer the Wikidata item of a database or controlled vocabulary or some other source, with the associated link pointing to the specific entry in the database. That’s how this works now, and I don’t see anything wrong with it. PKM (talk) 08:02, 13 January 2024 (UTC)Reply
I'm confused by this comment, because none of the target properties are new, or being used in a new way. The value of "stated in" is as it has always been, a database, controlled vocabulary, or the like. Swpb (talk) 18:06, 13 January 2024 (UTC)Reply
My question was should a property connect to its database using P1629 or something else? PKM (talk) 22:54, 13 January 2024 (UTC)Reply
I believe the one appropriate property to link ID-valued properties to their corresponding databases is applicable 'stated in' value (P9073). The item best corresponding to an ID-valued property would be an item for the ID type itself, rather than the database listing it; but in that case, class of non-item property value (P10726) (a subproperty of P1629) is the correct property. Swpb (talk) 23:29, 13 January 2024 (UTC)Reply
@PKM: (forgot to ping you in my reply immediately above this.) Swpb (talk) 18:08, 13 January 2024 (UTC)Reply
I am concerned that even though this discussion doesn't seem to have reached a consensus, Wikidata item of this property (P1629) values are being deleted in favour of applicable 'stated in' value (P9073) rather than being deprecated. See Gatehouse Gazetteer place ID (P4141), where I've had to restore the former. Vicarage (talk) 21:25, 18 February 2024 (UTC)Reply
  Oppose this property is easy to understand for the simple case of which organisation produces this content. applicable 'stated in' value (P9073) is vaguely labelled and issued by (P2378) seems more for identifiers issued as standards in a field than parts of an internal documentation url. We need a clear linking property for all url generating properties. Vicarage (talk) 06:05, 19 February 2024 (UTC)Reply
I picked one of our newest properties, Dongqiudi.com team ID (P12416). Not only does it only have this property, not its proposed replacements, it has a unique value warning against Dongqiudi.com player ID (P11379), which seems inappropriate. Any changes here need to be integrated with the property creation process for external identifiers. Vicarage (talk) 06:36, 19 February 2024 (UTC)Reply
Return to "P1629" page.