Property talk:P2315

Latest comment: 1 year ago by SM5POR in topic Useful property




The WD community has agreed to delete this property. PLEASE NO LONGER USE IT.

See the full discussion here.

Please rather use properties listed under field related property (P1659) on the main property page.




Documentation

comment (DEPRECATED)
to be deleted: replace with "syntax clarification" (P2916) or add the usage note in the items description.
Data typeMonolingual text
Domainproperties (note: this should be moved to the property statements)
Examplestring ==> [explanation of usage/meaning of this constraint] (note: this information should be moved to a property statement; use property Wikidata property example (P1855), Wikidata property example for properties (P2271), Wikidata property example for lexemes (P5192), Wikidata property example for forms (P5193) or Wikidata property example for senses (P5977))
Robot and gadget jobsMigrate constraints from property talk pages.
See alsoWikidata usage instructions (P2559), sourcing circumstances (P1480), statement disputed by (P1310), reason for deprecated rank (P2241), syntax clarification (P2916), criterion used (P1013), quotation (P1683), reference URL (P854), object has role (P3831), subject named as (P1810)
Lists
Proposal discussionProposal discussion
Current uses
Total282
Main statement165.7% of uses
Qualifier20472.3% of uses
Reference6222% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
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/P2315#Scope, SPARQL
Allowed entity types are 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/P2315#Entity types
Title ID Data type Description Examples Inverse
property constraintP2302Itemproperty constraint: constraint applicable to a Wikidata propertyIMDb ID <property constraint> distinct-values constraint-
exception to constraintP2303Itemitem that is an exception to the constraint, qualifier to define a property constraint in combination with P2302IUCN conservation status <exception to constraint> Varia jamoerensis-
group byP2304PropertyGROUP BY: qualifier to define a property constraint in combination with P2302 (Wikidata property constraint) that is used to group constraint violations in constraint violation reportsProperty talk:P2304-
item of property constraintP2305Itemallowed-entity-types constraint: qualifier to define a property constraint in combination with "property constraint" (P2302)mass <item of property constraint> kilogram-
propertyP2306PropertyWikidata property: qualifier to define a property constraint in combination with P2302 (property constraint), or to limit the scope of Q44292881 (wikidata statement)Property talk:P2306-
Wikimedia Commons namespaceP2307Stringqualifier used with the Commons link property constraint (Q21510852) to specify acceptable Wikimedia Commons namespaces that a property value can link toProperty talk:P2307-
classP2308Itemclass: qualifier to define a property constraint in combination with "property constraint" (P2302)Property talk:P2308-
relationP2309Itemrelation and relation: qualifier to define a property constraint in combination with P2302. Possibly values are: "instance of", "subclass of" or "instance or subclass of". The qualifier to use with the property "relative" is "type of kinship" (P1039), not thisProperty talk:P2309-
minimum date (property constraint)P2310Point in timequalifier to define a property constraint in combination with "property constraint" (P2302)Property talk:P2310-
maximum date (property constraint)P2311Point in timequalifier to define a property constraint in combination with "property constraint" (P2302). Use "unknown value" for current date.Property talk:P2311-
maximum valueP2312Quantitymaximum: qualifier to define a property constraint in combination with P2302. "no value" can be used to specify no upper boundrange constraint <maximum value> 1,234-
minimum valueP2313Quantityminimum: qualifier to define a property constraint in combination with P2302range constraint <minimum value> 0-
format as a regular expressionP1793Stringregular expression: regex describing an identifier or a Wikidata property. When using on property constraints, ensure syntax is a PCREISO 639-3 <format as a regular expression> [a-z]{3} and IMDb ID <format as a regular expression> ev\d{7}\/\d{4}(-\d)?|(ch|co|ev|nm|tt)\d{7}-
constraint statusP2316ItemWikidata constraint status: qualifier to define a property constraint in combination with P2302. Use values "mandatory constraint" or "suggestion constraint"property scope constraint <constraint status> mandatory constraint-
syntax clarificationP2916Monolingual textsyntax: qualifier for P1793 (regular expression): to provide a textual description of the regex syntax of a value. Should be displayable after the text "The value for the property should match" and be followed by the regex.Yandex Music artist ID <syntax clarification> numerisk streng, 1 til 7 tall-

Purpose of this property edit

Could someone explain how this property is supposed to be used? The proposal does not explain it very well (it seems to be something to do with property constraints?). The label is very vague, "comment" could mean anything at all - what I'm writing now is a comment. The description sounds like it should be used as an instruction field like requested on phab:T97566 but that's nothing to do with property constraints. Then there are already uses which don't seem like anything to do with property constraints or usage instructions, e.g. the references on David Rockefeller (Q11239) and View of the wharf at Nyholm with the crane and some warships (Q22137795). @Ivan A. Krestinin, Jonas.keutel, Mbch331: - Nikki (talk) 14:13, 24 January 2016 (UTC)Reply

It should not be used yet. It's meant to be used when we switch to statement based constraint, so comments can be added to constraint definitions (as now done with hidden text in the source code). Mbch331 (talk) 14:33, 24 January 2016 (UTC)Reply
Do you have an example? - Nikki (talk) 14:17, 2 February 2016 (UTC)Reply
I guess I should have pinged you to get an answer, so @Mbch331: :) I'm also curious what you think should be done about the mess here. I think it might make sense to propose two new properties for property usage notes and generic comments. Then, if the properties are approved, migrate the current uses, if they're rejected, delete the current uses. Then we could fix all the labels and descriptions, or even delete this property and recreate it (so that people can't continue using this one incorrectly). What do you think? - Nikki (talk) 15:50, 19 February 2016 (UTC)Reply
An example of how I interpret what this property is meant for: Property talk:P2437, check the sourcecode and see the range constraints. And to solve the mess, I think new properties are the best solution. 1 for property usage noted, 1 for comments on constraint and 1 for general comments. And indeed delete this one. Mbch331 (talk) 16:01, 19 February 2016 (UTC)Reply
Actually it should also be used for property usage notes, per Wikidata:Property_proposal/Archive/44#property_usage.
Personally, I don't see why it couldn't be used for usage notes in general, as at some point we should stop including them in descriptions.
--- Jura 14:42, 24 January 2016 (UTC)Reply
To avoid that it gets used for anything, maybe the label should be changed to something more explicit. How about "Wikidata usage note"?
--- Jura 10:29, 1 February 2016 (UTC)Reply
"Wikidata usage note" would work for property usage notes, but I don't think it would work for what property constraint comments. Looking at the proposal you linked, it seems it only says to use this property because you had changed this property's description to say it's for property usage notes, not because people felt that property usage notes should use the same property as property constraint comments. I don't think they should be the same property and I don't think the proposal should have been rejected, since it was rejected based on incorrect assumptions (that we had already created a property for it). - Nikki (talk) 14:17, 2 February 2016 (UTC)Reply
What else property should I use to add a source as a free textual bibliographical citation? Like "McKenna, Bell: Classification of Mammal: Above the Species Level. — Columbia University Press, 2000" --Infovarius (talk) 09:55, 29 March 2018 (UTC)Reply

Deletion discussion edit

Clarify purpose in descriptions edit

@Mbch331, Nikki, Jura1: Now that property Wikidata usage instructions (P2559) exists to describe "how to use a property or item", could anyone familiar with earlier debates indicate what is the expected purpose, so that we can all fix its description translations? thanks -- LaddΩ chat ;) 23:06, 7 March 2016 (UTC)Reply

Until this property has been integrated in the system, we can't fix any descriptions. When adding a property (or item) to an item (or other property), the comment (DEPRECATED) (P2315) should be shown, so people know how to use it. Mbch331 (talk) 06:49, 8 March 2016 (UTC)Reply
I think they were asking what to do with this property's descriptions. The answer to that is, it depends on the outcome of the deletion request (linked from the section above). - Nikki (talk) 08:10, 8 March 2016 (UTC)Reply
I gave it a try, at least to describe its relation to P2559 and most other properties (like sex or gender (P21)/country of citizenship (P27) etc).
--- Jura 09:05, 8 March 2016 (UTC)Reply
Wikidata usage instructions (P2559) is too restrictive : it is useful to add note about why a property value is set, or not completed by another property, for example where one would expect a change after some date, but the reference listing new changes applicable to lists of items reuses the same value. It is also useful to detail why some properties are kept (e.g. with a given date longer than initially expected, or because there's been some legal decision to maintain a value whose change was contested and cancelled).
So we need more some general notes that are not just for Wikidata itself but for the actual data, to signal that this is not an error or omission. May be it will be read only in Wikidata by Wikidata contributors, but it allows also to temporarily submit data which is still not representable (e.g. missing property type, or the existing property type is not strictly inapplicable but further modelisation is needed). Wikidata usage instructions (P2559) is proably applicable only to the Wikidata ontology modelisation only, but not to actual data items that frequently need precisions not covered by the provided data (especially when it is exact and there's no error or omissions). Verdy p (talk) 13:39, 5 October 2018 (UTC)Reply

P2315 was used instead of quote P1683 in references edit

Other options are possible to describe Help:Sources. d1g (talk) 01:15, 11 August 2017 (UTC)Reply

Can we undepriciate this property? edit

We could use this property for adding clarification to copyright statements. See Help:Copyrights. Sometimes we have important piece of info that does not fit other properties, than a generic text "comment" is what is needed. --Jarekt (talk) 05:18, 2 February 2019 (UTC)Reply

no more P2315 edit

seems there is no items with comment (DEPRECATED) (P2315) Bouzinac💬✒️💛 19:34, 29 September 2020 (UTC)Reply

Useful property edit

I need a property like this, for a generic comment that can be traced to sources. Sure, this is not in the spirit of the ontology since statement should be composed from structured items and not from free text, but sometimes that just seems too hard to do. Another useful property would be "textual assertion" or the like. --Dan Polansky (talk) 23:12, 21 December 2022 (UTC)Reply

I can use this property also for commenting on sources traced to. For instance, I trace to a dictionary and want to comment on which sense I picked, or what else did I see in that dictionary. The name of the property can be "comment" or "note"; either is fine. "note" is better since it is shorter. --Dan Polansky (talk) 07:06, 22 December 2022 (UTC)Reply

Avoiding unstructured content is a noble ideal but very impractical:

  • When adding a source (reference URL), I often need to make some remark about the source. I am doing this again and again, and this is immensely useful.
  • I sometimes need to make a free pronouncement about an entity. Not too often, but still.

Experts in Wikidatese can convert these unstructured text items into Wikidatese if and when they know how; I find it often very challenging. --Dan Polansky (talk) 09:53, 23 December 2022 (UTC)Reply

I have read Wikidata:Properties_for_deletion/Archive/2017#comment_.28DEPRECATED.29_.28P2315.29 from 2017:

  • The number of participants was fairly low, 13.
  • Most participants limited their comment to some brief dismissive statement, not solid reasoning and analysis of pros and cons, or link to external sources where pros and cons are being discussed.
  • Re: "Even if in some cases can be useful for editors, it's too tempting for introducing unstructured data, which is totally useless for users": that is a plainly untrue. Textual comments can provide e.g. rationales or temporary epistemic states. It is in fact useful for viewers. And its being useful for editors is of no small significance: the project has to do all that it can to help editors since they, not users, are creating and updating the data.
  • The key question: does allowing unstructured claims and supplementary notes do more harm than good for the project? Where is the proof? Where is solid analysis? Which ontologist has analyzed the question and provided an answer?

I also read this: Wikidata:Property_proposal/Archive/45#comment. There were mere two participants. One said: "Anything that might be written in here would be better expressed through a more specific property": clearly untrue: when commenting on a provided reference, I cannot use structured data to note significant observations about it. In general, I cannot translate a general sentence into structured data, given the data model strictures. Even fairly simple sentences are hard to translate, let alone those using existential or universal quantifiers.

As for "Talk: page would suffice": not true. It is hugely inconvenient to add a comment about a particular reference to a talk page: in that talk page, I would need to somehow identify which item in the mainspace the comment applies to: in the mainspace, the location of the comment node does all that job. And switching between mainspace and talk page to find salient information is nearly useless. --Dan Polansky (talk) 10:26, 23 December 2022 (UTC)Reply

You may also want to read Wikidata:Property proposal/see talk page discussion at (from 2020). While I don't mind using Talk pages myself, comments made there (such as here, case in point) seem to remain unnoticed forever. Also, some issues are preferably discussed in the context of a WikiProject or similar, rather than on a specific item (or its Talk page). Comments should form part of the sources used to create the final product (the item) and remain available forever (like the edit history), not be a part of the product itself (where they risk being arbitrarily deleted or edited by others, like this very discussion will probably disappear alongside comment (DEPRECATED) (P2315) when it's eventually gone).
I think my own needs are covered by reason for deprecated rank (P2241) and Wikimedia community discussion URL (P7930) for the time being, though I understand you may have additional uses in mind. Considering the "structured data" argument, I don't think the problem is that the comment is written in plain English, but that it's not semantically tagged in any way whatsoever: Is it a comment supporting or disputing the statement it's attached to, does it provide advice to future editors, or what? For things like quality of sources we have nature of statement (P5102), sourcing circumstances (P1480), statement disputed by (P1310), statement supported by (P3680) etc, but they require prepared value items; they don't accept arbitrary text. --SM5POR (talk) 11:37, 28 December 2022 (UTC)Reply
Thank you. I think we need a way to mark defects. When one notices a defect, it seems worthwhile to mark it without being forced to resolve it immediately. This is also useful for users to know that the ontology is broken in some location (and the ontology is broken a lot, in the upper part). This should ideally be in the mainspace, not talk page, so the user immediately sees something's wrong. One example of a defect I have in mind is when the right word is used as an object, but not the right concept/entity; thus, the unsuspecting user seems to think all is fine until they click on the entity and find out that it is for a different concept. --Dan Polansky (talk) 16:33, 29 December 2022 (UTC)Reply
If a statement is of poor quality, I think it's okay to deprecate it even if you can't immediately come up with a better solution. Just add a hint at what's wrong with it using reason for deprecated rank (P2241) (follow the links to list of Wikidata reasons for deprecation (Q52105174) a pick a suitable one), and maybe somebody else will discover the broken statement and resolve it somehow. By retaining the bad statement in deprecated mode you discourage editors from reinstating the same unacceptable solution again.
There are some properties that deserve extra care however, and those are the transitive properties, especially subclass of (P279) since removing that link may result in numerous downstream constraint violations. If the only valid subclass of (P279) statement is bad, it should be left in operation until a replacement subclass statement has been added, or the item is deemed to be an instance only with no downstream instances or subclasses of its own. You may still add a reason for deprecated rank (P2241) to indicate your intention to deprecate it.
I also want to monitor model items more closely to detect deteriorating quality and deprecate those model item pointers that no longer contribute to continuous improvement. A model item designation is a badge of merit, but if a single statement has a minor defect, that badge should be suspended immediately pending rectification. This is primarily what I want the Wikimedia community discussion URL (P7930) property for, to link to a discussion of the type of defect and how it should be resolved. I'm trying to initiate a long-term discussion about this approach in some appropriate forum. --SM5POR (talk) 20:39, 30 December 2022 (UTC)Reply

Substitute properties edit

Properties that act as a substitute for some purposes:

--Dan Polansky (talk) 16:37, 29 December 2022 (UTC)Reply

Return to "P2315" page.