Wikidata:Property proposal/close match
Obsolete proposal
close match[edit]
Originally proposed at Wikidata:Property proposal/Authority control
| Description | used to link two concepts, which are similar in meaning, but cannot be used interchangeably |
|---|---|
| Data type | URL |
| Allowed values | URI |
| Example | Lake Constance (Q4127) → http://zbw.eu/stw/descriptor/30083-1 (Lake Constance region) |
| Source | in analogy to skos:closeMatch (see also "inter-KOS mapping relationships" in SKOS Primer). ISO-25964-2:2013's "inexact equivalence" has the same meaning: "Sometimes the most closely matching concepts in two or more vocabularies are not exactly the same. The problem is particularly acute when the vocabularies have emerged from different cultural communities. ... The following cases commonly raise: - The concepts may be equivalent in some contexts but not in others. - The concepts may have overlapping scopes or small differences in connotation. ..." (clause 11.3, p. 27) |
| Planned use | mapping of STW Thesaurus for Economics (Q26903352) to Wikidata (already started in Mix-n-match) |
| See also | exact match (P2888) |
- Motivation
Exact mappings from an external vocabulary to Wikidata can be created via exact match (P2888) or via a property of type external id for that particular vocabulary, which means that the thing identified by that property is excactly the same as the given item. This works very well for persons, and to a lesser degree for organizations, but often fails for general (abstract) concepts, or even for geographic entities. (see discussion here) Even when it would be valueable or at least legitimate to create a new and exactly-matching Wikidata item, this often does not match a main purpose of a mapping from an external vocabulary (to link to existing Wikipedia pages in different languages). That leaves the user with the choice of either creating an inaccuarate not-really-exact mapping using the available means (which may cause harm later on, particularly in derived transitive relations), or skipping the external concept completely. A "close match" property would solve this. Jneubert (talk) 15:12, 10 August 2017 (UTC)
- Discussion
Comment @Jneubert: According to description, it looks like it's the same idea of different from (P1889) Or are they different?Thank you David (talk) 13:36, 16 November 2017 (UTC)
- Hi @ديفيد عادل وهبة خليل 2: Actually no - different from (P1889) is about the relation betwee two item, whereas this draft for an proposal was aimed at the relation between an item and an external resource, identified by its URL. However, the whole draft is a (completely forgotten) leftover from an approach, which finally resulted in mapping relation type (P4390) (using a qualifier for external ids with different allowed values), and probably should be deleted. Thanks for making me aware that its still lingering around. Jneubert (talk) 14:09, 16 November 2017 (UTC)
- @Jneubert: Do you mean that you are withdrawing the proposal? David (talk) 14:39, 16 November 2017 (UTC)
- @ديفيد عادل وهبة خليل 2: Yes (I actually did not submit it). I've added a note on top to make that more obvious. However, if you see a use case for such a property, I'm happy to discuss. Jneubert (talk) 14:55, 16 November 2017 (UTC)
- @Jneubert: Do you mean that you are withdrawing the proposal? David (talk) 14:39, 16 November 2017 (UTC)
- Hi @ديفيد عادل وهبة خليل 2: Actually no - different from (P1889) is about the relation betwee two item, whereas this draft for an proposal was aimed at the relation between an item and an external resource, identified by its URL. However, the whole draft is a (completely forgotten) leftover from an approach, which finally resulted in mapping relation type (P4390) (using a qualifier for external ids with different allowed values), and probably should be deleted. Thanks for making me aware that its still lingering around. Jneubert (talk) 14:09, 16 November 2017 (UTC)
