Help:Conflation/da
Conflation is the state of an entity representing more than one thing.
For example, if an item such as Google (Q95) has instance of (P31)website (Q35127)and instance of (P31)company (Q783794), then it is considered conflated because the entity represents both a website (Q35127) and a company (Q783794) when they are in-reality two separate things and should have two separate items (Google (Q95) and Google Search (Q9366)).
All types of Wikidata entities can be considered conflated, including items, properties, and lexemes.
Managing conflation
Because many concepts as described below are naturally conflated, Wikidata needs to support and has solutions for managing conflated entities. Conflated entities are not entirely bad and should exist where-needed, but they should always be tried to be separated into their distinct concepts where-possible and notable.
Emner
Items are unconflated by splitting them or creating new items. See Help:Split an item for how to do this.
To make a conflated item like for an external identifier, you can use union of (P2737) or disjoint union of (P2738) to state the individual concepts a conflated concept joins together. Then add instance of (P31)conflation (Q14946528) to notify editors that it is conflated.
Wikipedia artikler
Conflation on Wikidata most-often arises from editors linking Wikipedia articles that describe multiple things to a single item and then proceeding to describe the multiple concepts described in that article on that one item. For example, the most-famous conflated item on Wikidata, JPEG (Q2195), exists because the sitelinked articles describe the many types of JPEG things there are.
Conflation can be further-complicated when conflated articles talk about different things. Because Wikidata must keep the articles that explain similar things linked on one item so that they all link to each other, this can result in an extremely conflated items with imprecise sitelinks and little tracking about what the articles actually talk about. Examples of these problems have been discussed here.
Løsning
Proposed complete solutions
- Allow use of sitelink on multiple items. A usecase for this solution is documented in WikiProject Cultural venues, as it is a common conflation problem in the GLAM sector. In this usecase, Wikidata items that conflate a building and an organization are sitelinked to one Wikipedia article that covers both concepts, using an intentional sitelink to redirect (Q70894304).
- Allow multiple articles to link to one Wikidata item (inverse solution)
External identifiers
Concepts external identifiers link to can be conflated so it is important that item it is used on is also conflated in the same way. For example, if an external identifier property links to a forum topic that is often conflated like Quora topic ID (P3417) might do, then it should be used on a conflated item.
Lexemes
Words or lexemes in languages are often conflated, or in other words, "a word has more than one meaning". For example, the word bark (L16129) in English can mean a "dog bark" or "bark from a tree". Therefore, the word "bark" can be considered conflated.
Løsning
Lexemes are separated into senses in order to distinguish different definitions and thus concepts a word can mean. In order to link the correct definition (sense) with the correct concept (Wikidata item) one uses item for this sense (P5137) on the sense.
However if multiple words are mere homograph and have different etymologies (such as plane have four different etymologies), separate lexemes should be created.
Egenskaber
Properties can be conflated when they are used for multiple purposes, do not define a strict relationship, or their domain (Q112036279) and range (Q112036270) is not strict. For example, a property called "related to" that is used to relate people with anything is considered to be conflated because its range is unconstrained and the property is used to specify many different types of relationships.
See Wikidata:WikiProject Properties for a list some properties that are currently conflated.
Løsning
Unconflating properties can take place different ways:
- Create new subproperties to define more-specific relationships.
- Create a new data model that involves creating multiple new properties that better describe the relationship.
- Create a new property and redefine the current conflated property.
All of these methods involve migrating old usages of the conflated property to the new systems. However, method 3 requires property usages to be migrated since the property is being completely redefined whereas 1 and 2 can take place over time. Therefore, methods 1 and 2 are generally preferred.
Remember when unconflating properties that templates that externally use the property should not be affected by the change.