Property talk:P1659
Documentation
used to indicate another property that might provide additional information about the subject
List of violations of this constraint: Database reports/Constraint violations/P1659#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1659#Entity types
This property is being used by: Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
|
broaden domain to include any item? edit
Should be broaden the domain of this property to include any kind of item? It often makes sense to reference or contrast other items. --Srittau (talk) 19:50, 21 March 2016 (UTC)
- Hi @Srittau, did you ever find a solution? Photocyte (talk) 23:38, 12 March 2023 (UTC)
I suggest to clarify either description or property title, to indicate that this property can only be used for internet-links as defined by the constraints. --Pixtur (talk) 14:28, 29 October 2016 (UTC)
Adding this to incomplete properties edit
To make sure properties are reasonably described before "see also" is added, I think the current constraint on sample and subject are helpful.
--- Jura 06:03, 29 April 2017 (UTC)
- @Jura1:Why do you think that it's useful to enforce the order in which information is added to a property?
- The idea of separation of concerns is for me the main motivation to say that "see also" has nothing to do with "subject item" and "property examples". It's good to have both of those but they aren't directly related to "see also". Maybe we need an automatically generated list of properties that lack "subject item"/"property examples" that can be used to fill them when they are missing? I don't see why that task should be tangled up with "see also". ChristianKl (talk) 19:29, 30 April 2017 (UTC)
- What problem are you trying to fix by removing it?
--- Jura 19:33, 30 April 2017 (UTC)- Oh .. they are target constraints, not item constraints .. the other way round, this would make more sense if this property was only used on properties.
--- Jura 19:42, 30 April 2017 (UTC)
- Oh .. they are target constraints, not item constraints .. the other way round, this would make more sense if this property was only used on properties.
- What problem are you trying to fix by removing it?
Single value edit
Why single value? Sometime many properties may "...provide additional information about the Wikidata-property..." --Pierpao (talk) 06:38, 3 September 2019 (UTC)
- The problem is more complex, I try to explain it: this property has property constraint (P2302)value-requires-statement constraint (Q21510864) with the qualifier
property constraint (P2302)property (P2306) having two values, Wikidata property example (P1855) and Wikidata property example for properties (P2271); according to the constraint formulated in this way, "each property having related property (P1659) should have both Wikidata property example (P1855) and Wikidata property example for properties (P2271)", which is false; the constraint should be formulated in a way according to which "each property having related property (P1659) should have either Wikidata property example (P1855) or Wikidata property example for properties (P2271)", which is true. I don't know if value-requires-statement constraint (Q21510864) allows in some way this solution. @Lucas Werkmeister (WMDE): could you have a look, please? Thank you very much, --Epìdosis 08:08, 4 September 2019 (UTC)- @Epìdosis: (first of all, I assume you mean the qualifier property (P2306), not property constraint (P2302)?)
- Something like that was discussed (for a different constraint type) at Help talk:Property constraints portal/Mandatory qualifiers, but not implemented (yet). --Lucas Werkmeister (WMDE) (talk) 09:49, 4 September 2019 (UTC)
- @Lucas Werkmeister (WMDE): OK, thank you! Yes, property (P2306), of course. In your opinion which is the best solution at the moment? Simply removing the constraint? --Epìdosis 10:02, 4 September 2019 (UTC)
- @Epìdosis: for now, I would remove it (or set the rank of the constraint statement to deprecated, to disable it), yeah. --Lucas Werkmeister (WMDE) (talk) 10:58, 4 September 2019 (UTC)
- @Lucas Werkmeister (WMDE): Done, deprecated. Now let's wait ;-) Thank you again, --Epìdosis 11:49, 4 September 2019 (UTC)
- @Epìdosis: for now, I would remove it (or set the rank of the constraint statement to deprecated, to disable it), yeah. --Lucas Werkmeister (WMDE) (talk) 10:58, 4 September 2019 (UTC)
- @Lucas Werkmeister (WMDE): OK, thank you! Yes, property (P2306), of course. In your opinion which is the best solution at the moment? Simply removing the constraint? --Epìdosis 10:02, 4 September 2019 (UTC)
Use for Wikidata property usage tracking categories edit
Notified participants of WikiProject Categories Hi all! Items about Wikidata property usage tracking category (Q24514938) (e.g. Category:Pages using Wikidata property P1082 (Q20990019)) - see also previous discussion - usually use this property to link to the object-property (e.g. Category:Pages using Wikidata property P1082 (Q20990019)related property (P1659)population (P1082)). However, after recent modifications in constraints of this property, this results in a constraint violation. I'm not sure which is the best way for tracking categories to link to their properties, but if it's not through this property, how? Thank you, --Epìdosis 14:17, 12 August 2020 (UTC)
- I'd remove the (new) constraint. --- Jura 16:19, 15 August 2020 (UTC)
- Removed. Romaine (talk) 14:03, 22 August 2020 (UTC)
- @Epìdosis, Jura1, Romaine: Wouldn't Wikidata property (P1687) be a better property to use for linking categories to properties? --Dhx1 (talk) 14:54, 22 August 2020 (UTC)
- Maybe, in any case it would require editing the qualifiers of Wikidata property (P1687). --Epìdosis 14:59, 22 August 2020 (UTC)
- To me it seems that Wikidata property (P1687) is doing the same as related property (P1659), however the first one is used as part of a pair: property - subject of property, and has a inverse constraint (Q21510855). For this pair Wikidata property (P1687) is used, for all other usage related property (P1659) is used. So I think that broadening the usage of Wikidata property (P1687) would cause some conflicts/constraints. I can imagine that it can be useful to restrict the usage of related property (P1659) (also the name of this property is not optimal for Wikidata items), but then we are missing a property to indicate what the property belongs to a tracking category. Romaine (talk) 15:05, 22 August 2020 (UTC)
- @Epìdosis, Jura1, Romaine: Wouldn't Wikidata property (P1687) be a better property to use for linking categories to properties? --Dhx1 (talk) 14:54, 22 August 2020 (UTC)
- Removed. Romaine (talk) 14:03, 22 August 2020 (UTC)
Debate: Should there be a back-link Bot for see-also's ? edit
It would seems to me if you are linking to another property as a see-also, they should back-link back to you.
So should there be a bot that makes sure that is the case and keeps all the interlinked see-also's in sync?
For example, my father just passed so when looking at the "Online Begraafplaatsen cemetery ID " (P9884) I saw nine other similar ID's linked, however they don't all link-back, so anyone looking at those will miss out useful research information and of course to do it manually could be up to seventy-two edits!