Wikidata:Property proposal/dialect of

From Wikidata
Jump to navigation Jump to search

dialect of[edit]

Originally proposed at Wikidata:Property proposal/Generic

   Done: dialect of (P4913) (Talk and documentation)
Descriptionlanguage of which an item with this property is a dialect. Use in addition to "subclass of" (P279) if a languoid is also considered a dialect.
Data typeItem
Domaindialects
Allowed valueslanguoid
ExampleCocopah (Q32008315) is a dialect of Cocopah (Q33044)
Planned useFor any item which is a dialect of a language, conversion from P134
See alsoProperty:P134 (likely to be deleted)
Motivation

'Part of' Property:P361 is not specific enough, the property 'has dialect' Property:P134 has already been created to make this more clear but only links from the language to the dialect, not the other way around. John Cummings (talk) 14:56, 6 July 2017 (UTC)[reply]

Discussion
 Support in general we've been discouraging new inverse properties as the reverse direction is easily retrieved via the query service and the redundancy isn't helpful. However, in this case it seems to me this is the more useful direction, and perhaps we should consider even deleting P134 (P134) if this gets created. ArthurPSmith (talk) 17:28, 6 July 2017 (UTC)[reply]
 Support per ArthurPSmith Hsarrazin (talk) 17:55, 6 July 2017 (UTC)[reply]
 Support - PKM (talk) 19:09, 6 July 2017 (UTC)[reply]
 Support - very sensical. A good idea. -- BrillLyle (talk) 01:47, 7 July 2017 (UTC)[reply]
 Support - would be good. Charles Matthews (talk) 05:52, 7 July 2017 (UTC)[reply]
 Oppose I don't think this is a good idea. The distinction between "language" and "dialect" is a very very grey area with many things being described both ways depending on which source you look at, so I don't think it makes sense to add more properties specific to whether something is a dialect, language, language family, etc. I also don't think this is necessary. We already use instance of (P31) to store the fact that someone considers something a dialect and we currently use subclass of (P279) (which is way more common than part of (P361) on items marked as dialects) to create a tree. I don't think we should remove P279 statements (since that would break the tree) and we definitely shouldn't remove P31 statements, therefore this property would duplicate existing statements. I wouldn't be particularly opposed to replacing P279 with a new property (in the same way we have parent taxon (P171) for taxonomy) if people really wanted to, but that would need to be a property broader than "dialect of". - Nikki (talk) 07:07, 7 July 2017 (UTC)[reply]
Nikki, thanks very much for your reply, you are correct about the fuzziness of what is a language and what is a dialect. I feel like it may be possible to have something like 'parent taxon' and 'child taxon' but for languages, do you have suggestions of what these could be called? --John Cummings (talk) 12:39, 7 July 2017 (UTC)[reply]
The "fuzziness" should be addressed by sources: If source A says Foobar is a language, but source B says it is a dialect, add both statements, duly cited (and ranked if applicable). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 7 July 2017 (UTC)[reply]
Finding names which aren't too specific or too weird is hard. :( The best I can think of right now is "linguistic subdivision of" and "has linguistic subdivisions". - Nikki (talk) 13:03, 7 July 2017 (UTC)[reply]
 Oppose as an inverse for an exiting property (neutral on replacing that existing property). Also, could those supporting this as the inverse of another property (@John Cummings, PKM, BrillLyle, Charles Matthews:) please explain why we need both? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:44, 7 July 2017 (UTC)[reply]
@Pigsonthewing: It is actually not generally accepted that inverse properties are undesirable. I believe that theoretical reasons for opposition, and practical reasons of convenience for creation, should be seen as a trade-off. In other words, I prefer to think of the situation now as case-by-case. A case in point is contributed to creative work (P3919), where I had felt for a long time that the property was needed. The argument you present had a chilling effect on my bringing it up. Therefore, going forward, I don't think there should be such an onus placed on proposers, beyond the usual ones of utility. Charles Matthews (talk) 13:57, 7 July 2017 (UTC)[reply]
@Charles Matthews: My reasons for opposition are far from being merely "theoretical", so please do not try to dismiss them as such. Your accusation that I chilled a discussion in which I did not participate is, frankly, bizarre. It is indeed "not generally accepted that inverse properties are undesirable", but then nor is it "generally accepted that inverse properties are desirable"; hence my request for an explanation of why we need both in this case. You haven't answered the question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 7 July 2017 (UTC)[reply]
Andy, slow down. There is indeed a "theoretical" argument against inverse properties. It is endemic here. I got it, for example, from Magnus, in personal conversation, in the case of contributed to creative work (P3919). I neither was dismissing it, nor saying that in that case you had raised it with me, since we two never discussed that matter.
So, in this case, I think "is a dialect of" would be a fine property. I think it should be created. As you point out above, it involves statements that can and should be referenced. What I would argue is that simply blocking its creation on the grounds of the current existence of an inverse property is a procedural view that does Wikidata no favours.
Where a property and inverse both exist, it can be argued, if required, that one should be deleted. How else would one go about replacing a property by its inverse where just one is needed? Charles Matthews (talk) 05:10, 10 July 2017 (UTC)[reply]
And again you open with a trite effort to dismiss what I say, by telling me to "slow down". And still you offer no actual reason why the property is needed (since references can also be attached to the existing inverse; or the item itself). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 10 July 2017 (UTC)[reply]
You know, being adversarial in this style leads you (often enough) into false positions. My language was impersonal: you took it personally. For heaven's sake. I was making a procedural point, also. We may have a cart-before-the-horse situation, where the existing property is less popular than its inverse might be. For those who dislike having both, there remains the issue of which would be more desirable. Do we have all dialects of English listed on the page English (Q1860)? Isn't it more maintainable for each dialect as added to be marked as "dialect of"? I don't see the difficulty with having both, but the analogy with contributed to creative work (P3919) is fairly close. Charles Matthews (talk) 04:10, 11 July 2017 (UTC)[reply]
@Pigsonthewing, Charles Matthews: I also like inverse properties conceptually. I want more of them. But aside from that, I don't think <subclass of> is the right way to model a dialect or small language community. In the case of an endangered dialect spoken by ~120 people, how is this a "class"? What would be the hypothetical members of this class, each speaker's idiolect? As far as names for new relationship properties, "parent language or language group" and "child language or language group" might work. I agree that we should mark a language as a dialect if a source says it's a dialect, citing the source, and not otherwise.- PKM (talk) 19:51, 7 July 2017 (UTC)[reply]
 Comment Thanks very much for your comments. @Pigsonthewing:. I think you are correct this isn't the right term. Having looked at Glottolog it appears the correct language to use is 'child language' and 'parent language' to describe this. If 'dialect of' is not correct then 'has dialect' is also incorrect. Do we simply rename the 'has dialect' property to child language? My reasoning for having properties on both the parent and child properties are fairly universal. In my experience not having a property on the item is causing many people to fill in the gaps incorrectly based on a lack of understanding of the subject. World Heritage sites are a good example where people are adding World Heritage status to all the items which are part of a World Heritage site rather than 'part of'. This leads to a lot of visualisations looking very odd indeed. Having only child taxon statements only makes sense when running queries and looking at the items individually if you know that this is the system, otherwise it just looks like data is missing. It also means that people can only travel from the language to the dialect and not the other way around. Thanks --John Cummings (talk) 16:10, 10 July 2017 (UTC)[reply]
The naming issue was not my concern. I suggest that we can deal with the "gap filling" by using a complex, "conflicts with", constraint. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 10 July 2017 (UTC)[reply]
@Pigsonthewing:, can you link to something that would help me understand what you mean? Thanks --John Cummings (talk) 21:06, 10 July 2017 (UTC)[reply]
Lots of examples, using {{Complex constraint}}, via [1]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:13, 11 July 2017 (UTC)[reply]
@Pigsonthewing:, I think I'm being thick... as far as I understood the complex constraint function (not sure what to call it) flags when someone puts to conflicting statements on the same item or if someone puts a clearly wrong value to a property. I don't understand how this links languages together or why this would be a better solution than inverse properties. My understanding is using inverse properties is a simple way to help people move between items and run queries. --John Cummings (talk) 22:08, 13 July 2017 (UTC)[reply]
@John Cummings: No, constraints do that. @complex constraints allow us to specify more detailed conditions ("not for people born on a Wednesday, unless they have a wooden leg", or whatever. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 12 February 2018 (UTC)[reply]

@Jura1, Pigsonthewing, Pintoch, PKM, ArthurPSmith, Giovanni Alfredo Garciliano Diaz: @Visite fortuitement prolongée, Yair rand, Charles Matthews, ديفيد عادل وهبة خليل 2, Pasleim, John Cummings: @BrillLyle, Nikki, Hsarrazin: ✓ Done: dialect of (P4913). − Pintoch (talk) 19:31, 4 March 2018 (UTC)[reply]

I am adding an inverse constraint to help with the migration (but it is of course meant to disappear once the other property is gone). − Pintoch (talk) 19:33, 4 March 2018 (UTC)[reply]
Hmm actually no, we just need one on P134 (P134), not on dialect of (P4913)Pintoch (talk) 19:37, 4 March 2018 (UTC)[reply]