Property talk:P1629
Documentation
item corresponding to the concept represented by the property
Represents | Wikidata item (Q16222597) | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Data type | Item | ||||||||||||
Template parameter | |subject item= in Wikidata's {{Property documentation}} | ||||||||||||
Domain | Wikidata property (Q18616576) | ||||||||||||
Usage notes | For 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). | ||||||||||||
Example | not applicable father (P22) → father (Q7565) owned by (P127) → proprietor (Q12794619) | ||||||||||||
Source | Initially 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: usage | Category:Pages using Wikidata property P1629 (Q98131385) | ||||||||||||
See also | class of non-item property value (P10726), applicable 'stated in' value (P9073), issued by (P2378) | ||||||||||||
Lists |
| ||||||||||||
Proposal discussion | Proposal discussion | ||||||||||||
Current uses |
| ||||||||||||
Search for values |
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)
List of violations of this constraint: Database reports/Constraint violations/P1629#inverse, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1629#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1629#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1629#Item P2302, search, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1629#Single value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1629#Unique value, SPARQL (every item), SPARQL (by value)
![]() |
This property is being used by: 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)
- @Laddo, Paperoastro, GZWDer: from the proposal discussion/ creation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 28 December 2016 (UTC)
- @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)
- @ArthurPSmith: I agree with that. Lymantria (talk) 21:35, 28 December 2016 (UTC)
- @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)
- given the overwhelming support below I plan to make this change later today. ArthurPSmith (talk) 14:43, 4 January 2017 (UTC)
- @Lymantria: I have made this change. I removed "exact" in English and a few other languages I can read, you might want to check others. Also usage instructions can be translated to other languages too. ArthurPSmith (talk) 19:12, 4 January 2017 (UTC)
- @ArthurPSmith: Thank you, The below vote is with very clear support. I will try to translate some languages - other users may do so as well. Lymantria (talk) 07:54, 5 January 2017 (UTC)
Votes and opinions
[edit]Support as proposer. I don't see how a seperate item on ID's can be helpful. Lymantria (talk) 10:27, 28 December 2016 (UTC)
Support corresponds to the initial usage. --Succu (talk) 10:33, 28 December 2016 (UTC)
Oppose. This is an ill-conceived proposal. Several databases use more than one iD. The current description and the original property proposal each explicitly state "item corresponding exactly to the concept represented by the property". That's "corresponding exactly". Furthermore, properties which can be used to describe an identifier cannot be used on an item about a database. We should aim to increase, not decrease, the precision of our data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:48, 28 December 2016 (UTC)
Comment PubChem and ChEMBL are example databases which have multiple identifiers. I guess this proposal includes explicitly the drop of the word "exact" from the definition? --Egon Willighagen (talk) 18:17, 28 December 2016 (UTC)
- @Egon Willighagen: So it would seem. No cogent reason for doing so has been given. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 28 December 2016 (UTC)
Support. Thierry Caro (talk) 12:48, 28 December 2016 (UTC)
Support this has been the de facto usage of this property for well over a thousand properties now; most identifiers do not have their own wikidata item (most of them are not really named as "identifiers" outside of wikidata anyway), and I see no improvement resulting from creating them. An alternate approach would be a new property "source database for this property" similar to source website for the property (P1896) and to move most instances of Wikidata item of this property (P1629) to that. ArthurPSmith (talk) 14:40, 28 December 2016 (UTC)
- It is most certainly not the de facto usage; many external ID properties use the value of an item about the identifier, as I showed with a sample in the aforesaid discussion. (I would support the separate property which you propose.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:49, 28 December 2016 (UTC)
- An example proves nothing about the general usage for external ids. --Succu (talk) 15:27, 28 December 2016 (UTC)
- The examples, plural, I gave - each of which was for an external ID - disprove the claim of "de facto usage" that was made in the comment to which I replied. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 28 December 2016 (UTC)
- (edit conflict) de facto. Fact is: less than 70 usages (out of 935) are tagged as unique identifier (Q6545185). --Succu (talk) 15:48, 28 December 2016 (UTC)
- disprove. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 28 December 2016 (UTC)
- Please do not make substantive edits to your comments, after others have replied to them, as you did here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 28 December 2016 (UTC)
- ...twice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 28 December 2016 (UTC)
- Thank you Succu for establishing that 92.5% of the usages of this property for identifiers are not actually linking to an item for the identifier. So given this de facto status, what should we do? I strongly oppose creating items for the identifiers as Andy seems to be suggesting. I also oppose just deleting these relationships. If we had a suitable database relationship property I think it would be reasonable to change these statements to use that instead of Wikidata item of this property (P1629). But I don't actually see a compelling reason to require such a change. Given that instance of (P31) clearly shows which of these relationships correspond to identifiers and which to something else, use of the property with that element of ambiguity doesn't seem to be a serious problem to me. Perhaps Andy can spell out in more detail what real significant problem he foresees from not being pedantic on this point here? ArthurPSmith (talk) 18:04, 28 December 2016 (UTC)
- " I strongly oppose creating items for the identifier" This is Wikidata. They undoubtedly meet our notability criteria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:20, 28 December 2016 (UTC)
- I doubt a database field is usually notable enough. Would be funny to construct a database table that way. --Succu (talk) 18:26, 28 December 2016 (UTC)
- Our notability policy allows an item if it "fulfills some structural need". Since the items in question link an external ID property to the item describing the corresponding database, they are inherently and indisputably notable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:53, 28 December 2016 (UTC)
- Probably you can explain in more detail what kind of structural need those items fullfil and which properties should they have? --Succu (talk) 20:08, 28 December 2016 (UTC)
- "the items in question link an external ID property to the item describing the corresponding database" - and furthermore, they do so without making the false claim that the database is the "subject item" of the property. As to their properties, you're already familiar with the example I gave in earlier discussion, ORCID iD (Q51044). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 28 December 2016 (UTC)
- Maybe you didn't noticed: items with sitelinks representing external ids too are of course notable, but we are talking about the rest. --Succu (talk) 20:17, 28 December 2016 (UTC)
- I noticed; so am I. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 28 December 2016 (UTC)
- @Pigsonthewing: "the items in question link an external ID property to the item describing the corresponding database" - do they? I haven't seen this, can you provide an example? What property is used for that link? ArthurPSmith (talk) 21:34, 28 December 2016 (UTC)
- An example created by him is MarineTraffic Port ID (Q18572216). Note the second statement. --Succu (talk) 22:08, 28 December 2016 (UTC)
- So it is ok for @Pigsonthewing: to violate the constraints and description of operator (P137) by calling a service an "operator" of an identifier, but not ok for us to slightly modify the meaning of Wikidata item of this property (P1629) to capture its de facto usage for linking identifier properties to databases/services? I am having a hard time here. Please Andy, at least respond to the substantive questions that have been asked you instead of arguing with straw men (for example I did NOT raise the issue of notability as my reasoning for opposing the creation of these items). ArthurPSmith (talk) 14:54, 29 December 2016 (UTC)
- Bad constraints can, of course, be fixed. But if you feel there is a better property, please feel free to use it; or if not, to propose a new one. The only straw man here is your accusation that I have used one. Furthermore, neither you or anyone else has refuted my original point: "The current description and the original property proposal each explicitly state 'item corresponding exactly to the concept represented by the property'. That's 'corresponding exactly'". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 29 December 2016 (UTC)
- And we are proposing to remove the word "exactly" - see my comment in the preceding section on the precise change requested. And how is your "They undoubtedly meet our notability criteria." above not a straw man attack responding to my comment that said nothing about notability? Once again you have NOT responded to the actual questions I have asked you, though you seem to now acknowledge that operator (P137) may not be the natural property to link an identifier item with its database or service. Other than the fact that we have the word "exactly" in the description of this property, what precisely is the significant problem you envision by the proposed change? ArthurPSmith (talk) 17:04, 29 December 2016 (UTC)
- If you think your questions are not answered, then you haven't read what I have written. You ask, for example "what precisely is the significant problem you envision by the proposed change". I have already written, above, both "properties which can be used to describe an identifier cannot be used on an item about a database" and about "the false claim that the database is the "subject item" of the property". My comment about notability was not an "attack" of any form. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 29 December 2016 (UTC)
- Andy, I have read every word you have written here and I do not understand what specifically you see as being a problem. Thank you for restating what you think are the salient points, but I do not see the problem they cause. In other languages and among its English aliases, the label of this property is more "associated item" than "subject item" - if "subject" is the cause of your concern, then we can change the English label; I think "associated item" would work. As to "properties which can be used to describe an identifier cannot be used on an item about a database" - I think I agree, but I don't see the relevance of this statement to the problem at hand. Can you provide a specific example that you think illustrates why this is a problem here? ArthurPSmith (talk) 18:42, 29 December 2016 (UTC)
- The proposal was made and discussed in English, and the words "Subject item" and "corresponding exactly" were part of that proposal, and so canonical. If there are errors (or malfeasance) in translation(s), then it's no wonder it has been ms-applied. This should be corrected. I oppose diluting the meaning and usefulness of the property by removing either phrase. I have already given an example of a well-modelled item. Several of its properties would be inappropriate on the related property, or the parent item. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:09, 29 December 2016 (UTC)
- You mean ORCID iD (P496)? There is no wikidata item for the ORCID database or service, so I don't think that is a relevant example at all. In addition we've already established that some identifiers (such as ORCID) really are important in themselves, have sitelinks, etc. so yes they certainly should have a corresponding item. Most do not follow this pattern. As to "diluting the meaning and usefulness of the property" it has ALREADY changed from the proposal, as established above, by its de facto use for hundreds of existing properties. We have two choices: (A) modify the property definition to match its current de facto use, which, other than your hypothetical complaint of changing a definition doesn't seem to have caused any substantive problem for anybody, or (B) replace the property where it has been used in most cases for external identifiers by another property, or replace the targets by new items which themselves need a new property to link to the database/service. To my mind (A) is the simplest choice, but given this whole lengthy discussion here I'm willing to go with B if you can come up with ANY concrete explanation of why the current use is actually problematic - other than it differs from the original proposal. ArthurPSmith (talk) 20:51, 29 December 2016 (UTC)
- The proposal was made and discussed in English, and the words "Subject item" and "corresponding exactly" were part of that proposal, and so canonical. If there are errors (or malfeasance) in translation(s), then it's no wonder it has been ms-applied. This should be corrected. I oppose diluting the meaning and usefulness of the property by removing either phrase. I have already given an example of a well-modelled item. Several of its properties would be inappropriate on the related property, or the parent item. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:09, 29 December 2016 (UTC)
- Andy, I have read every word you have written here and I do not understand what specifically you see as being a problem. Thank you for restating what you think are the salient points, but I do not see the problem they cause. In other languages and among its English aliases, the label of this property is more "associated item" than "subject item" - if "subject" is the cause of your concern, then we can change the English label; I think "associated item" would work. As to "properties which can be used to describe an identifier cannot be used on an item about a database" - I think I agree, but I don't see the relevance of this statement to the problem at hand. Can you provide a specific example that you think illustrates why this is a problem here? ArthurPSmith (talk) 18:42, 29 December 2016 (UTC)
- If you think your questions are not answered, then you haven't read what I have written. You ask, for example "what precisely is the significant problem you envision by the proposed change". I have already written, above, both "properties which can be used to describe an identifier cannot be used on an item about a database" and about "the false claim that the database is the "subject item" of the property". My comment about notability was not an "attack" of any form. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 29 December 2016 (UTC)
- And we are proposing to remove the word "exactly" - see my comment in the preceding section on the precise change requested. And how is your "They undoubtedly meet our notability criteria." above not a straw man attack responding to my comment that said nothing about notability? Once again you have NOT responded to the actual questions I have asked you, though you seem to now acknowledge that operator (P137) may not be the natural property to link an identifier item with its database or service. Other than the fact that we have the word "exactly" in the description of this property, what precisely is the significant problem you envision by the proposed change? ArthurPSmith (talk) 17:04, 29 December 2016 (UTC)
- Bad constraints can, of course, be fixed. But if you feel there is a better property, please feel free to use it; or if not, to propose a new one. The only straw man here is your accusation that I have used one. Furthermore, neither you or anyone else has refuted my original point: "The current description and the original property proposal each explicitly state 'item corresponding exactly to the concept represented by the property'. That's 'corresponding exactly'". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 29 December 2016 (UTC)
- There is no need to remove the word "exactly". We just need to agree to read it sensibly. - Brya (talk) 17:56, 29 December 2016 (UTC)
- So it is ok for @Pigsonthewing: to violate the constraints and description of operator (P137) by calling a service an "operator" of an identifier, but not ok for us to slightly modify the meaning of Wikidata item of this property (P1629) to capture its de facto usage for linking identifier properties to databases/services? I am having a hard time here. Please Andy, at least respond to the substantive questions that have been asked you instead of arguing with straw men (for example I did NOT raise the issue of notability as my reasoning for opposing the creation of these items). ArthurPSmith (talk) 14:54, 29 December 2016 (UTC)
- An example created by him is MarineTraffic Port ID (Q18572216). Note the second statement. --Succu (talk) 22:08, 28 December 2016 (UTC)
- @Pigsonthewing: "the items in question link an external ID property to the item describing the corresponding database" - do they? I haven't seen this, can you provide an example? What property is used for that link? ArthurPSmith (talk) 21:34, 28 December 2016 (UTC)
- I noticed; so am I. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 28 December 2016 (UTC)
- Maybe you didn't noticed: items with sitelinks representing external ids too are of course notable, but we are talking about the rest. --Succu (talk) 20:17, 28 December 2016 (UTC)
- "the items in question link an external ID property to the item describing the corresponding database" - and furthermore, they do so without making the false claim that the database is the "subject item" of the property. As to their properties, you're already familiar with the example I gave in earlier discussion, ORCID iD (Q51044). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 28 December 2016 (UTC)
- Probably you can explain in more detail what kind of structural need those items fullfil and which properties should they have? --Succu (talk) 20:08, 28 December 2016 (UTC)
- Our notability policy allows an item if it "fulfills some structural need". Since the items in question link an external ID property to the item describing the corresponding database, they are inherently and indisputably notable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:53, 28 December 2016 (UTC)
- I doubt a database field is usually notable enough. Would be funny to construct a database table that way. --Succu (talk) 18:26, 28 December 2016 (UTC)
- @ArthurPSmith: @Succu: Why do you oppose creating items for identifiers? Identifiers have statements for themselves, like the type of the things they identify (see my comment below), but just look at International Chemical Identifier (Q203250) and how many translations, sitelinks, etc that has. Why would that not be a good thing? --Egon Willighagen (talk) 18:32, 28 December 2016 (UTC)
- @Egon Willighagen: Several reasons: (A) it still loses this particular relationship between the identifier and the database it is associated with. Let's take Treccani ID (P3365) for example, which currently links via Wikidata item of this property (P1629) to Enciclopedia Treccani (Q731361). Suppose we create a new item "Identifier for Enciclopedia Treccani website". What would be the relationship between that item and Enciclopedia Treccani (Q731361)? And even with that relation it becomes an indirect, not a direct relationship between Treccani ID (P3365) and Enciclopedia Treccani (Q731361). (B) I don't see how this actually adds anything useful to wikidata - if there are statements applicable to the identifier, why not set them on the property, I don't see how additional statements on an item for the identifier would be useful? (C) many of these "identifiers" are things that we in the wikidata community have invented based on the structure of a particular website so that formatter URL's work. I'm not even sure how you could argue these invented id's "correspond exactly" to a concept? ArthurPSmith (talk) 18:47, 28 December 2016 (UTC)
- Of course properties don't have sitelinks, so if there really are applicable sitelinks for an identifier, then by all means we need a wikidata item for it and Wikidata item of this property (P1629) should point straight to that item. ArthurPSmith (talk) 18:50, 28 December 2016 (UTC)
- " I strongly oppose creating items for the identifier" This is Wikidata. They undoubtedly meet our notability criteria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:20, 28 December 2016 (UTC)
- Thank you Succu for establishing that 92.5% of the usages of this property for identifiers are not actually linking to an item for the identifier. So given this de facto status, what should we do? I strongly oppose creating items for the identifiers as Andy seems to be suggesting. I also oppose just deleting these relationships. If we had a suitable database relationship property I think it would be reasonable to change these statements to use that instead of Wikidata item of this property (P1629). But I don't actually see a compelling reason to require such a change. Given that instance of (P31) clearly shows which of these relationships correspond to identifiers and which to something else, use of the property with that element of ambiguity doesn't seem to be a serious problem to me. Perhaps Andy can spell out in more detail what real significant problem he foresees from not being pedantic on this point here? ArthurPSmith (talk) 18:04, 28 December 2016 (UTC)
- (edit conflict) de facto. Fact is: less than 70 usages (out of 935) are tagged as unique identifier (Q6545185). --Succu (talk) 15:48, 28 December 2016 (UTC)
- The examples, plural, I gave - each of which was for an external ID - disprove the claim of "de facto usage" that was made in the comment to which I replied. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 28 December 2016 (UTC)
- An example proves nothing about the general usage for external ids. --Succu (talk) 15:27, 28 December 2016 (UTC)
- It is most certainly not the de facto usage; many external ID properties use the value of an item about the identifier, as I showed with a sample in the aforesaid discussion. (I would support the separate property which you propose.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:49, 28 December 2016 (UTC)
Comment I see clear advantages of having items for identifiers: it allows rich annotation, e.g. indicating what the type is of the things identified. For examples, PubChem has three identifiers, one for compounds, one for substances, one for assays. At the same time, this proposal does not disallow this, and it is important that using a database item as value of this property does not become the expected standard. --Egon Willighagen (talk) 18:25, 28 December 2016 (UTC)
Support. Thank you for this proposal, I've been wanting to propose the same widening/confirmation of scope. I had been adding Wikidata item of this property (P1629) statements but stopped after pushback by Succu related to this issue. With regards to the oppose vote, this proposal increases inter-linking and thus discovery of properties which can only be a good thing. --Azertus (talk) 14:42, 28 December 2016 (UTC)
- @Azertus: The correct statement was already there. --Succu (talk) 14:46, 28 December 2016 (UTC)
- The proposal does not increase interlinking, since every external ID property can be linked to an item about the identifier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:49, 28 December 2016 (UTC)
Comment. A lot of these are already linked in the opposite direction. This will allow us to create a lot of the inverse links for Wikidata property (P1687) (see its constraint report), which is defined as a symmetric property. The exact matching of items to concepts is not that important; e.g. why should sport (P641) not be linked to sport (Q349), while the reverse is true? The loose linking of items and concepts is already widespread, except on external-id properties where there is in only some cases an item for the exact ID. --Azertus (talk) 14:42, 28 December 2016 (UTC)
- The symmetrical link should be from the item about the identifier to the property for the identifier; again: consider databases with more than one identifier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:52, 28 December 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
Oppose For this moment, until the proposal is extended to make clear that 'exactly' is to be removed from the definition, and that using separate items for unique identifiers remain acceptable use (I value that use very much); however, there seems to be a tendency to disfavor separate items for unique identifiers at this moment, and I would welcome a clear proposal on that. --Egon Willighagen (talk) 18:42, 28 December 2016 (UTC)
- Egon, the word slightly was removed by Mr. Mabbett. --Succu (talk) 19:04, 28 December 2016 (UTC)
- There are identifiers which are notable and should have their own item, like DOI, ISBN and ISSN. However, an identifier in a database which is only used for internal purposes in that database is not by itself notable. - Brya (talk) 19:20, 28 December 2016 (UTC)
- Should an identifier that is only used for internal purposes even be used at all in Wikidata? --Egon Willighagen (talk) 21:16, 28 December 2016 (UTC)
- Only to link to the relevant entry in the database. - Brya (talk) 04:54, 29 December 2016 (UTC)
- Should an identifier that is only used for internal purposes even be used at all in Wikidata? --Egon Willighagen (talk) 21:16, 28 December 2016 (UTC)
- There are identifiers which are notable and should have their own item, like DOI, ISBN and ISSN. However, an identifier in a database which is only used for internal purposes in that database is not by itself notable. - Brya (talk) 19:20, 28 December 2016 (UTC)
- Egon Willighagen I don't see anybody arguing that separate items for unique identifiers is unacceptable where appropriate - and it is definitely appropriate whenever the identifier is sufficiently notable that one of the wikipedia's has a page on it (i.e. there's a sitelink). So everything that has such an item should stay that way, no change needed. ArthurPSmith (talk) 19:27, 28 December 2016 (UTC)
- To give an example: What properties should an item created for an external id related to FishBase species ID (P938) have? The only thing we know for sure is that this external id is somehow related to FishBase (Q837101). --Succu (talk) 19:39, 28 December 2016 (UTC)
- Egon, the word slightly was removed by Mr. Mabbett. --Succu (talk) 19:04, 28 December 2016 (UTC)
Support --Paperoastro (talk) 20:31, 29 December 2016 (UTC)
Support Liné1 (talk) 07:18, 4 January 2017 (UTC)
Support Brya (talk) 12:14, 4 January 2017 (UTC)
Conclusion
[edit]- 8 support, 2 oppose ==> supported. Lymantria (talk) 07:54, 5 January 2017 (UTC)
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)
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)
- Template:Tun warum können Sie selbst nicht? --Infovarius (talk) 13:22, 1 October 2018 (UTC)
- 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)
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)
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)
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)
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)
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)
Support Agree with the given above. Sjoerd de Bruin (talk) 08:30, 10 January 2024 (UTC)
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)
- (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)
- @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)
- @Lectrician1 It was not for this particular example, sorry for the confusion.
- here is a list of identifiers item that uses both "identifies" and "facet of". For example eAmbrosia ID (Q118975441)
is linked to eAmbrosia (Q97379904)
by « facet of »
- Marriage / spouse are unlinked right now but I feel that they should be somehow.
- here is a list of identifiers item that uses both "identifies" and "facet of". For example eAmbrosia ID (Q118975441)
- author TomT0m / talk page 16:10, 10 January 2024 (UTC)
- @Lectrician1 It was not for this particular example, sorry for the confusion.
- (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)
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). ChristianKl ❪✉❫ 13:29, 10 January 2024 (UTC)
- @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)
- @Lectrician1 To me father (P22) seems to have quite obviously an item property value. ChristianKl ❪✉❫ 23:02, 10 January 2024 (UTC)
- @ChristianKl yeah that's a conflict we're trying to resolve. Came at the wronggg time. Lectrician1 (talk) 23:41, 10 January 2024 (UTC)
- @Lectrician1 To me father (P22) seems to have quite obviously an item property value. ChristianKl ❪✉❫ 23:02, 10 January 2024 (UTC)
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)
- @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)
- 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)
- 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)
- 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)
- @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)
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)
- 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)
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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Oppose per what many people have said above. PKM (talk) 21:59, 12 January 2024 (UTC)
- 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)
- @PKM I can create a fix and an admin can apply it. Lectrician1 (talk) 01:07, 13 January 2024 (UTC)
- 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)
- 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)
- My question was should a property connect to its database using P1629 or something else? PKM (talk) 22:54, 13 January 2024 (UTC)
- 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)
- My question was should a property connect to its database using P1629 or something else? PKM (talk) 22:54, 13 January 2024 (UTC)
- @PKM: (forgot to ping you in my reply immediately above this.) Swpb (talk) 18:08, 13 January 2024 (UTC)
- 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)
- @PKM I can create a fix and an admin can apply it. Lectrician1 (talk) 01:07, 13 January 2024 (UTC)
- 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)
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)
- 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)
- All Properties
- Properties with wikibase-item-datatype
- Properties used on 1000+ items
- Properties with constraints on type
- Properties with inverse constraints
- Properties with qualifiers constraints
- Properties with entity type constraints
- Properties with scope constraints
- Properties with constraints on items using them
- Properties with single value constraints
- Properties with unique value constraints