Property talk:P5869

Documentation

model item
defines which item is a best practice example of modelling a subject, which is described by the value of this property, usage instructions at Wikidata:Model items

Represents

Wikidata model item (Q57312861)

Data type

Item

Usage notes

Wikidata:Model item

Example

human (Q5) → Douglas Adams (Q42)
politician (Q82955) → Nelson Mandela (Q8023)
animated film (Q202866) → Zootopia (Q15270647)

Tracking: usage

Category:Pages using Wikidata property P5869 (Q118210266)

Allowed entity types[edit]

Please see Wikidata:Project_chat#Model_item_(Property:P5869). --- Jura 14:15, 13 December 2018 (UTC)[reply]

Thanks @Jura1:, I think its probably sensible to have the discussion here as the project chat will get archived, I've copied your message on project chat as a quote above and left a message there to come discuss here. I have one comment and two questions:

Comment: @NavinoEvans: has kindly pointed to Property_talk:P463#Only_persons? which shows that properties have previously expanded in scope so it seems as though there is no restriction to expanding the use of a property beyond people's agreement (e.g you don't have to do the property proposal again).

Two questions

I don't understand why you say that the proposed invese property would not be usable on properties, can you explain further?

when you say if selection is mainly done by the number of statements on an item, the query links on the property talk page are better than a static link to one item Im not sure I understand, could you use an example?

Thanks again

--John Cummings (talk) 12:08, 18 December 2018 (UTC)[reply]

I'd rather comment there. Please don't repost my comment. --- Jura 12:16, 18 December 2018 (UTC)[reply]

Quality of model items[edit]

I see that this issue has been mentioned before in the project chat, but I doubt this is going to be resolved in a hurry, so I'm leaving this comment here, hoping to find out where to conduct a long-term discussion (if not here as well).

There are currently some 1,200 model items defined in Wikidata, representing around 700 classes.

I see a number of systematic problems with various items and subject areas all across Wikidata, such as constraint violations, subject conflation, misunderstood properties etc. This is true also for items referred to as model items for their class. This may have happened after they were designated model items, or perhaps the initial choice of model item wasn't too carefully prepared.

In order not to waste everybody's time duplicating bad model items that later will have to be redone, I'd like the ability to suspend individual model items due to low quality, at least temporarily until the issues have been addressed and rectified. This could be done either by adding a qualifier to the model item (P5869) statement indicating the quality level, or by deprecating it with an informative reason, perhaps even adding a pointer to an ongoing discussion of the issues. I'd prefer the latter as probably being more efficient; those using simple SPARQL queries to search for model items won't normally find the deprecated ones.

This is not meant to prohibit editors from continuing to work on any problematic items of their choice, but rather to give them an idea of how to best prioritize their efforts. Say, if art genres are currently in a mess and most model items suspended, perhaps working in the mathematics or zoology areas would be time better spent? Or, those who really want to work with the art genres could be encouraged to participate in solving the problems instead of copying them.

Does this way of steering attention towards areas in need make sense, do you think? --SM5POR (talk) 12:42, 12 December 2022 (UTC)[reply]

The property Wikimedia community discussion URL (P7930) seems like an obvious choice for the pointer I suggest above. Could thus be added alongside reason for deprecated rank (P2241). --SM5POR (talk) 10:23, 28 December 2022 (UTC)[reply]

If an item has low quality, it per definition not a model item as model items demonstrate best practice. In many cases, removing the items in question makes more sense to me than deprecating them. We might add a "outdated model" as deprecation reason along with a autogenered. I create a list for the deprecated model items we have right now: https://www.wikidata.org/wiki/Wikidata%3AWikiProject_Properties%2Fdeprecated_model_items ChristianKl ❪✉❫ 10:18, 3 January 2023 (UTC)[reply]

Thank you for the list, that will be helpful! My rationale for putting the model items in a deprecated state rather than just removing them is so that they can be restored to non-deprecated state once the issues those items had have been addressed. The model item I deprecated last year, for software, remains a very well-developed item, and there were only two technical (but important) issues with it. Also, a model item statement removed rather than deprecated suffers from the same problem as any other properties handled inn a similar way; they does not dissuade future editors from reinstating the same property another time without fixing the issues.

While there are only some 700 classes having model items designated today, I believe the model item concept has potential far beyond that. With almost all items being accompanied by at least one model item for its class, they could be automatically monitored for structural deficiencies not easily detected without a model item for comparison, say, finding property values with unusual and therefore potentially mistaken types. The model items themselves could be monitored for unexpected changes affecting their continued usefulness as models and alerting human editors for review of said items.

In Help talk:Deprecation#Item of insufficient quality I suggested a reason for deprecation with a slightly different label; I intentionally avoided the word "model" in order to make the reason applicable also to other deprecated statements than model item (P5869) (although I have no specific examples in mind right now; could be a future property not yet created).

The deficiencies I have in mind that might be reason for (or merely contribute towards) deprecation of a model item may belong to either of a set of categories that could be described in Wikidata documentation:

Lack of labels and/or descriptions in expected languages
Significant constraint violations
Essential properties missing
Lack of essential references
Too many deprecated statements
Structural problems in related items such as those implied using instance of (P31), subclass of (P279), part of (P361) etc
Excessive and unexpected use of unusual properties (not an error as such, but undesirable on a model item for making it difficult to use, say dozens of images or other WikiMedia Commons files)
Substantial problems with related WikiMedia project pages or categories
Missing or poorly used corresponding Talk page
Long and complicated edit history suggesting that the item is subject to frequent editing
Item related to a living person or a controversial/sensitive political issue undesirable as showcase item, protected item

I also have a couple of property proposals in the works, namely similar model properties aimed at lexemes, senses and forms, but before formally proposing them I would like to find out whether there is potential interest among Wikidata editors to make better use of model items as a systematic means of quality control. Wikidata is way too big for manual quality assessment, so I regard this a priority area of work right now. --SM5POR (talk) 15:58, 4 January 2023 (UTC)[reply]

I created https://www.wikidata.org/wiki/Wikidata:Model_items/worklist as a place to gather worklists for model items so that people who want to improve them have a good place to find work. If you can think of other ways to list improvements, how about creating worklists for that as well? ChristianKl ❪✉❫ 21:16, 5 January 2023 (UTC)[reply]

@ChristianKl: Thank you! I have trouble creating such a list (I haven't made those before); when I include a VALUES list of one item, that item is tested for selection, but when I remove the VALUES list, the manual update gets "killed by OS for overloading memory" and I get no output. Am I doing something wrong, or should I just wait for the robot to update the list according to its normal schedule? --SM5POR (talk) 12:17, 6 January 2023 (UTC)[reply]

I'm myself no SPARQL expert. If you have a good idea of how the list should look like https://www.wikidata.org/wiki/Wikidata:Request_a_query is the place to go. ChatGPT can also be helpful.

When it comes to the list "Worklist for model items that are not instances of the subject class", it conflicts with the current way this property works. One of the examples of model item (P5869) is politician (Q82955) model item (P5869) Nelson Mandela (Q8023). While it might make sense to have a different property for that, currently that use case is also covered by this property. ChristianKl ❪✉❫ 14:14, 6 January 2023 (UTC)[reply]

I see, but since politician (Q82955) is one of Mandela's listed occupations I suppose I could make occupation (P106) an alternate condition in place of instance of (P31), as it's an express policy not to have multiple instance of (P31) claims for humans.

The reason I want to be restrictive here is so that specialized classes get their own sets of model items, apart from those selected for broader classes, such as Android (Q94) being a model item for software (Q7397) when it would be better compared to other instances of mobile operating system (Q920890).

I recently added a constraint to model item (P5869) requiring the subject items to be classes (indicated by having a statement subclass of (P279)), but I suppose all occupations are classes already, so that shouldn't be a problem. That however led to the discovery of a number of non-class items for extinct species having assigned model items that are instances of fossil of (P642) said species. Since we are right now busy phasing out of (P642) we'll have to wait and see how these instance of (P31) statements may change. Or maybe we could have the same model items apply to all fossils regardless of species, from plants to Neanderthals... --SM5POR (talk) 22:44, 6 January 2023 (UTC)[reply]

@ChristianKl, @Emw: For a brief moment I considered making occupation (P106) and position held (P39) subproperty of (P1647) instance of (P31) and use this to generalize the relationship between the model item and the item the model item (P5869) claim is attached to, but then I read in the property specification that this would be a no-no with respect to instance of (P31) in particular (as I almost suspected). Interestingly, I find that the following properties are currently declared as subproperty of (P1647) instance of (P31) anyway:

Are those statements thus problematic to Wikidata right now, or have they somehow been disabled internally for the reasons given in the discussion back in 2014? I still find this list useful; maybe we can include these properties in the model item (P5869) relationships without using subproperty of (P1647) then? --SM5POR (talk) 03:18, 7 January 2023 (UTC)[reply]

individual of taxon (P10241) is a good example of a property that seems to have been created by people misunderstanding how our ontology works and the fact that we have metaclasses. All the cases where it's used could be easily solved by instance of (P31).

I proposed a qualifier to solve this problem: https://www.wikidata.org/wiki/Wikidata:Property_proposal/applies_to_property ChristianKl ❪✉❫ 15:03, 7 January 2023 (UTC)[reply]

Allowed entity types[edit]

@Tokrkbot: This one I don't understand. In 2020, Wikibase property was included in the allowed-entity-types constraint (Q52004125), with a reference to the property constraint (P2302) references section on number of seats (P1342). Could anyone please explain this? Otherwise I'll remove it. The model item (P5869) property is meant to sit on class item only, and properties don't have classes. --SM5POR (talk) 13:42, 6 January 2023 (UTC)[reply]

@SM5POR: I've tried to help solve property errors, always fairly with clear references, and could come with no idea but to do thisway at that time, which now I do not think so goodway, however the problem with Property:P1342&Q3154693 is today already solved. As long as no needed in other cases, I agree with removal and thank you for SM5POR --Tokrkbot (talk) 23:59, 6 January 2023 (UTC)[reply]

Property talk:P5869

Contents

Documentation

Allowed entity types[edit]

Quality of model items[edit]

Allowed entity types[edit]

Navigation menu

Property talk:P5869

Documentation

Allowed entity types[edit]

Quality of model items[edit]

Allowed entity types[edit]

Navigation menu

Search