Property talk:P1549

From Wikidata
Jump to navigation Jump to search

Documentation

demonym
Name (proper noun) for people or things associated with a given place, usually based off the place name; multiple entries with qualifiers to distinguish are used to list variant forms by reason of grammatical gender or plurality.
DescriptionDemonym. For English, the singular masculine adjective form is preferred. In English, this should start with a Capital letter. Add a qualifier if another form is added.
Representsdemonym (Q217438)
Data typeMonolingual text
Template parameter
Domain
According to this template: places
According to statements in the property:
geographic region (Q82794), fictional location (Q3895768), tribe (Q133311), planet (Q634), educational institution (Q2385804), ethnic group (Q41710), ethnoreligious group (Q11197007), geographic location (Q2221906) or toponym (Q7884789)
When possible, data should only be stored as statements
Allowed values
According to this template: demonym
According to statements in the property:
[^,;/()]+
When possible, data should only be stored as statements
ExampleMexico (Q96) → Mexicain
Mexikaner
meksikano
Mexicaan
Cuba (Q241) → Cuban
Calgary (Q36312) → Calgarian
Karnataka (Q1185) → ಕನ್ನಡಿಗ
Netherlands (Q55) → nederlandano
Nederlander
Nederlanner
Nedänan
Uzbekistan (Q265) → Uzbek
Uruguay (Q77) → Uruguayan
Bashkortostan (Q5710) → Bashqort
Michigan (Q1166) → Michigander
Tracking: usageCategory:Pages using Wikidata property P1549 (Q23909007)
Lists
Proposal discussionProposal discussion
Current uses
Total45,066
Main statement45,039>99.9% of uses
Qualifier25<0.1% of uses
Reference2<0.1% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
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/P1549#Type Q82794, Q3895768, Q133311, Q634, Q2385804, Q41710, Q11197007, Q2221906, Q7884789, SPARQL
Format “[^,;/()]+”: value must be formatted using this pattern (PCRE syntax). (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/P1549#Format, SPARQL
Allowed entity types are Wikibase item (Q29934200): 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/P1549#Entity types
Scope is as main value (Q54828448), 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/P1549#Scope, SPARQL
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Pomona College (Q7227384)
List of violations of this constraint: Database reports/Constraint violations/P1549#Single value, SPARQL
Statement appears to contain multiple values
If there are multiple values (e.g. male and female forms), they should be entered as separate statements. (Help)
Violations query: select * { ?item wdt:P1549 ?text filter (regex(str(?text), "[,/()]")) }
List of this constraint violations: Database reports/Complex constraint violations/P1549#Statement appears to contain multiple values
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

monolingual in stead?

[edit]

Is monoligual a misspelling?--Even Thorbergsen (talk) 06:15, 8 October 2014 (UTC)[reply]

how to add qualifier masculine/feminine

[edit]

How do I add a qualifier (e.g at item Japan) to indicate it is a masculine or feminine form? (I can not find the 'masculine' item to be applied) 139.63.61.23 09:28, 5 January 2015 (UTC)[reply]

I will use masculine (Q499327) and feminine (Q1775415) for now. 139.63.61.23 09:33, 5 January 2015 (UTC)[reply]

Insane

[edit]

Are you sure you want to have >6000 (number of languages) values? Or at least ~250 (number of Wikipedias)? There's something intrinsically wrong in this property... --Infovarius (talk) 04:32, 8 January 2015 (UTC)[reply]

And we can have some synonims in one language too (leads to 6 values for Russian, sometimes). Infovarius (talk) 05:12, 8 January 2015 (UTC)[reply]
The focus is to use this in items for localities rather than countries. For a given language, adding one value should be sufficient. This limits to just a few values per item. --- Jura 07:54, 8 January 2015 (UTC)[reply]
Let's see when the next "Too big Germany item-issue" comes. --Infovarius (talk) 07:49, 30 January 2015 (UTC)[reply]

for people or things associated

[edit]

Can anybody see if this property have been used for Swedish (sv) yet? I cannot figure out how I should be able to add anything in Swedish based on the description. -- Innocent bystander (talk) 10:29, 25 April 2015 (UTC)[reply]

User FocalPoint pov pushing

[edit]

Please be informed that user:focalPoint is trying to creat extended pov pushing by changing demonym to ethnonym zhich is false translation --Kalogeropoulos (talk) 20:26, 31 December 2015 (UTC)[reply]

Rename Russian translation

[edit]

@Александр Сигачёв, Infovarius, Vlsergey, Putnik: I'm going to redefine this property into "toponymic adjective" (топонимическое прилагательное). The change will be applied only for Russian label and description. There are two reasons for this:

  1. This property is used in other wikis/reasonator/autodesc for generating descriptions like "Douglas Adams was a British writer...". If we translate demonym as "этнохороним", we can't use it anywhere, except for Infoboxes (but now it is not used anywhere).
  2. In Russian demonym nouns could be easily mixed with ethnonyms (e. g. "немецкий композитор и композитор-немец, у кого из них чище кровь?").

There are 58 changes to be done, I'm going to handle them by myself. --Lockal (talk) 10:58, 14 January 2016 (UTC)[reply]

  • @Lockal: Первая причина понятна, но решение в корне неверное: если менять, то менять нужно именно для всех языков, а скорее даже вводить новое свойство. Потому что ситуация аналогична, как минимум, для большинства славянских языков, возможно и не только, но при этом почти все ориентируются на английское название и описание. То, что сейчас свойство используется неверно, — это проблема, но, опять же, глобальная. Вторую причину вообще не понял — да, этнонимы и этнохороними в русском зачастую звучат одинаково, только как это влияет на название свойства? —putnik 16:58, 14 January 2016 (UTC)[reply]
    @Putnik: Я думал над новым свойством, даже начал писать заявку, но потом понял, что никто из нерусскоязычных не поймёт различия. Для них свойство для топонимического прилагательного уже есть — это именно это свойство (P1549). Я пробежался по текущему использованию и понял, что везде используется прилагательные-существительные (частичная субстантивация). Кроме того, в английском описании уже написано: «Singular masculine adjective form is preferred. Add a qualifier if another form is added».
    По второй причине: этнохоронимы-существительные нельзя использовать в статьях из-за этнонимического окраса (см. пример с композитором-немцем).
    И всё-таки я придумал ещё один вариант:
    ⟨ France (Q142)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ французский ⟩
    has use (P366) View with SQID ⟨ adjective (Q34698)  View with Reasonator View with SQID ⟩
    , а этнохоронимы-существительные оставить как есть. Уже лучше? --Lockal (talk) 19:09, 14 January 2016 (UTC)[reply]
1) То, что нерусскоязычные не поймут - их проблема. Делаем, как удобнее.
2) Неплохо бы определиться, а где мы вообще будем использовать это свойство?
3) Этнохоронимы и этнонимы всё равно будут путаться - неважно, в виде прилагательного или существительного взяты. Кстати, для Германии нужно не "немецкий", а "германский". Возможно, для существительного придётся использовать "германец".
4) С квалификатором мне нравится - хоть какое-то продвижение и возможность различия. --Infovarius (talk) 05:16, 28 January 2016 (UTC)[reply]
2) Текущий сценарий использования — автогенерация описания ботами/веб-сервисами совместно с новым свойством female form of label (P2521). Ну и ещё одна правка к ru:Отто, Пауль с ориентиром на будущее.
3) Слово "германец" не используется в русском языке. Попытка внедрить такую форму на викиданных так же провальна, как и попытка переименовать категорию немецких писателей в германских писателей. --Lockal (talk) 08:42, 28 January 2016 (UTC)[reply]

Plural

[edit]

Hello everyone,

How can we specify that a statement is plural? Actually, it's not clear.

There are to properties use in qualifier:

applies to part (P518) and sex or gender (P21) [1]

There are two types of element use (in French and German):

sex of humans (Q4369513) grammatical gender (Q162378)
male (Q6581097) masculine (Q499327)
female (Q6581072) feminine (Q1775415)

I think that use sex of humans (Q4369513) is wrong, because we talk about grammar, so if you agree, we should change this this with a bot. Same for sex or gender (P21).

For plural, can we use female (Q6581072) + plural (Q146786) or should we create a new item "masculine plural"?

Tubezlob (🙋) 13:36, 27 February 2017 (UTC)[reply]

For the first part, I too think that applies to part (P518) = masculine (Q499327) is better than sex or gender (P21) = sex of humans (Q4369513).
For the second part, not sure at all I feel like it seems that female (Q6581072) + plural (Q146786) is enough.
For notification, the biggest user of this property : @Robin van der Vliet, Máté, Turbolent2, Dinsdagskind, Jon Harald Søby, AB-me:
PS: very strangely there is no constraint on this property! There should be at least a {{Constraint:Type}} = geographic location (Q2221906) and probably more constraints.
Cdlt, VIGNERON (talk) 14:24, 27 February 2017 (UTC)[reply]
  • I'd use a single item as value that describes the form that is being added. This makes it easier to select just these.
    --- Jura 15:57, 27 February 2017 (UTC)[reply]
    • Jura1 could you give an example? Both case seems to have pros and cons : in both case, we have a lot of items to create but with a single item value, there will be a lot more items to create. For the records, right now, we only have 5 grammatical gender (Q162378) and 9 grammatical number (Q104083). Cdlt, VIGNERON (talk) 10:27, 1 March 2017 (UTC)[reply]
      • Initially I asked for this to be created to import fields like "gentilé" from frwiki. These are generally m.pl. and sometimes include f.pl. Unfortunately it took forever for this to be created and then I noticed that the tools then didn't allow to import them easily .. anyways: in the meantime, I think it can be done and is still worth doing! You are up to it?
        --- Jura 10:32, 1 March 2017 (UTC)[reply]
Yes I'm « up to it » but probably not from frwiki (datas are too bad and inconsistent there, fr:wikt:Catégorie:Gentilés en français is probably better, to be checked though) and above all, that's not really the question here. It's impossible to import something if the structure is so unclear and the inconsistencies in the current structures should be fixed first. Can we make the structure clear? and can you give example? My point of view (which is apparently the most common use right now) :
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parisien@fr ⟩
applies to part (P518) View with SQID ⟨ masculine (Q499327)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ singular (Q110786)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parisienne@fr ⟩
applies to part (P518) View with SQID ⟨ feminine (Q1775415)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ singular (Q110786)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parisiens@fr ⟩
applies to part (P518) View with SQID ⟨ masculine (Q499327)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ plural (Q146786)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parisiennes@fr ⟩
applies to part (P518) View with SQID ⟨ feminine (Q1775415)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ plural (Q146786)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parigot@fr ⟩
applies to part (P518) View with SQID ⟨ masculine (Q499327)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ singular (Q110786)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ common name (Q502895)  View with Reasonator View with SQID ⟩
(maybe pejorative (Q545779) instead or in addition to common name (Q502895))
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parigote@fr ⟩
applies to part (P518) View with SQID ⟨ feminine (Q1775415)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ singular (Q110786)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ common name (Q502895)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parigots@fr ⟩
applies to part (P518) View with SQID ⟨ masculine (Q499327)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ plural (Q146786)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ common name (Q502895)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parigotes@fr ⟩
applies to part (P518) View with SQID ⟨ feminine (Q1775415)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ plural (Q146786)  View with Reasonator View with SQID ⟩
applies to part (P518) View with SQID ⟨ common name (Q502895)  View with Reasonator View with SQID ⟩
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parisian@en ⟩
applies to part (P518) View with SQID ⟨ singular (Q110786)  View with Reasonator View with SQID ⟩
(not sure if and how to precise that masculine (Q499327) and feminine (Q1775415) are the same, putting them both or maybe with epicene (Q3083701)?)
⟨ Paris (Q90)  View with Reasonator View with SQID ⟩ demonym (P1549) View with SQID ⟨ Parisian@en ⟩
applies to part (P518) View with SQID ⟨ plural (Q146786)  View with Reasonator View with SQID ⟩
By the way, these kind of thing will probably be much more simple the L items (but in the meantime we can still improve the structure).
Cdlt, VIGNERON (talk) 12:45, 1 March 2017 (UTC)[reply]
"Parisiens" would be m.pl. This if you need a sample for Q90, but I think the property is more useful for smallish places where it's actually hard to find the correct term. If plan to build this, feel free to proceed with whatever structured approach you prefer. As we don't know when and how L-items will come, the property would allow to build this now.
--- Jura 15:01, 1 March 2017 (UTC)[reply]
1 union (Q185359)
2 intersection (Q185837)
@VIGNERON, Jura1:
I have a question with the use of the property applies to part (P518). Example:
⟨ subject ⟩  Wikidata property  ⟨ X ⟩
applies to part (P518) View with SQID ⟨ A ⟩
applies to part (P518) View with SQID ⟨ B ⟩
Is it
1) applies to part (P518) for A and for B (no link between A and B)
or is it
2) applies to part (P518) for A and B (A and B are linked)?
I used so far this property with the first idea. In my opinion, the examples of VIGNERON are wrong. So I think we should create items for "masculine singluare", etc.
What do you think?
Tubezlob (🙋) 16:36, 1 March 2017 (UTC)[reply]
Jura1 uh ?!? this is a wiki and an ongoing discussion, there is absolutely no way that I import data right now (that would be borderline vandalism), especially when I don't have any preferences while others might and that I still have unanswered questions (this is why there is this discussion in the first place, it's the mere point of discussing).
Tubezlob oh… good question… no idea, what difference do you make between 1 and 2 ? For me they seems equivalent (like factorisation equivalent, A×(B+C) = A×B+A×C ) and I see you claim it's more something along « A and B for X » (X being the main value which is qualified and the link between all the qualifiers). But I think I see you're point, one single value would be less ambiguous.
Cdlt, VIGNERON (talk) 17:35, 1 March 2017 (UTC)[reply]
@VIGNERON: In think that is that in mathematics (if you prefer): 1) A ∪ B 2) A ∩ B
Tubezlob (🙋) 18:16, 1 March 2017 (UTC)[reply]
@Tubezlob: ok, I see (a better wording would have been « 1) for all [A] and all [B] 2) for all [A and B] ») but I'm not sure this logic works here. ∪ and ∩ are for ensembles, here A and B are just one item. Not sure though as there is the case of demonym who are the same for multiple genders (like Parisian@en in both masculine and feminine or Rennais@fr is both for singular and plural). I think we need someone more verse in logic to give a definitive answer. Cdlt, VIGNERON (talk) 20:34, 1 March 2017 (UTC)[reply]
@VIGNERON: In my mind, we can item as ensemble, because there could be have subclasses, etc. We should use something that can be use everywhere in Wikidata. We can't say: we use applies to part (P518) for demonyms in Wididata with this rule.
If we read what is written in our example, it's: "applies to part A and applies to part B", not "applies to part A and B". So with our topic: "applies to masculine and applies to plural", not "applies to masculine plural".
I ping other projects to have more opinion:
ping
user:Arlo Barnes user:Daniel Mietchen Finn Årup Nielsen (fnielsen) user:Infovarius user:Lore.mazza81 user:Middle river exports user:Nikki user:Popcorndude user:SM5POR user:SynConlanger

Notified participants of WikiProject Linguistics and geographical wikiprojects: WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

GeoO Tobias1984 Emptyfear Kareyac Xelgen ԱշոտՏՆՂ Beko

Notified participants of WikiProject Armenia The lles Balears WikiProject does not exist. Please correct the name. The Catalunya WikiProject does not exist. Please correct the name.

Tobias1984 Vojtěch Dostál YjM Jklamo Walter Klosse Sintakso Matěj Suchánek JAn Dudík Skim Frettie Jura1913 Mormegil Jedudedek marv1N Sapfan Daniel Baránek Draceane Michal Josef Špaček (WMCZ) The photonaut Hartasek Zelenymuzik Gumruch Shadster Dænča M.Rejha Janek Jan Kameníček Eva Vele Linda.jansova Lukša Packa Fukejs Hugo Xmorave2 J.Broukal Lenkakrizova Steam Flow Pavel Bednařík Sanqui

Notified participants of WikiProject Czech Republic

c960657 Fnielsen Steenth ProbabilityCollapse

Notified participants of WikiProject Danmark

VIGNERON
Ayack
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Alphos
GAllegre
Jean-Frédéric
Manu1400
Marianne Casamance
Nattes à chat
Pierre André
Bouzinac
Jsamwrites
Baidax
LearnKnowGive1
Mathieu Kappler
Daieuxetdailleurs
Archives nationales DJI
Jmax
LearnKnowGive1
Koxinga
Maxime
Framawiki
Legonin
Rémi sim

Notified participants of WikiProject France

Bigbossfarin Galaktos Labant M2k~dewiki Mathieu Kappler PantherStrix Wiljes jobu0101 cookroach Looniverse LockaPicker Printstream

Notified participants of WikiProject Germany

Gbeckmann

Notified participants of WikiProject Municipalities of Germany

Geraki Drspiros Sp!ros Cadm971 Epìdosis JBradyK Jimkats Magnus Manske (talk)

Notified participants of WikiProject Greece The Municipalities of Hungary WikiProject does not exist. Please correct the name. The Iranian Persian WikiProject does not exist. Please correct the name.

Edgars2007 Papuass MasterRus21thCentury Hellknowz Андрей Романенко Epìdosis CaptSolo

Notified participants of WikiProject Latvia The País Valencià WikiProject does not exist. Please correct the name.

Powerek38 Wostr Wiklol Witia Holek Pit rock Yarl Kpjas 99kerob Matlin masti Upior_polnocy Darellur Bogic

Notified participants of WikiProject Poland

Strakhov Tiberioclaudio99 Discasto Enladrillado Ivanhercaz Millars Rodelar Abián Tomukas Vanbasten_23 Maria zaos Olea Dandilero Davileci

Notified participants of WikiProject Spain The Suisse WikiProject does not exist. Please correct the name. The Infoboxes/places WikiProject does not exist. Please correct the name.

and I have done an ad for this in the project chat.
Tubezlob (🙋) 11:13, 2 March 2017 (UTC)[reply]
Tubezlob (🙋) 11:18, 2 March 2017 (UTC)[reply]

Change qualifier to "as" ?

[edit]

Shall we update the suggested qualifier to Property:P794 (as). It seems that the initial choice confuses people more than it helps.
--- Jura 07:07, 2 March 2017 (UTC)[reply]

@Jura1: Interesting idea; indeed, the current situation is very messy and quite fuzzy. But isn't P794 (P794) too generic ? and which and what « suggested qualifier » and « initial choice » are you talking about? I don't see any constraint or suggestion and I think this is the main root of the problem.
Analysis: right now, 12 qualifiers are in use: applies to part (P518), sex or gender (P21), of (P642), stated in (P248), statement is subject of (P805), demonym (P1549), instance of (P31), grammatical option indicates (P2591), P794 (P794), P2439 (P2439), name in kana (P1814), has use (P366), all for more or less for the same thing... P794 (P794) is used on Israel (Q801) but with the value noun (Q1084) so it's a different usage.
We definitely should put a constraint to accept only certain qualifiers (with {{Constraint:Qualifiers}}) but which one? On the other way round, I think we could all agree that some qualifiers are wrong (at least demonym (P1549) !! and probably sex or gender (P21) and P2439 (P2439) too, maybe has use (P366) and name in kana (P1814)), if there is no objection I would like to start removing them.
Cdlt, VIGNERON (talk) 10:28, 2 March 2017 (UTC)[reply]
Note that there's current discussion about P794, with a proposal to rename it "subject has role", if Wikidata:Property proposal/object has role is approved. I am not sure if that would make it more or less suited here. Jheald (talk) 13:29, 2 March 2017 (UTC)[reply]
Yeah, object has role would work even better than Property:P794 "as" (if it's created). Both are an improvement over the current applies to part (P518).
--- Jura 18:19, 3 March 2017 (UTC)[reply]

First constraint about the type

[edit]

Hi,

As a starter, I've added a first obvious constraint {{Constraint:Type|class=Q82794|relation=instance}}. I though it would be wide and general enough but there was 65 items (now 61) which violate this constraint. I can identify four different violations :

Any ideas, remarks, thoughts ? Cdlt, VIGNERON (talk) 11:15, 2 March 2017 (UTC)[reply]

@VIGNERON: For ethnic group (Q41710), I think that is appropriate. In the French Wiktionary, ethnonyme (ethnonym) is synonym of gentilé (demonym) and I add this alias in French to the property a few days ago. Tubezlob (🙋) 11:55, 2 March 2017 (UTC)[reply]
That would just repeat the label ..
--- Jura 18:30, 3 March 2017 (UTC)[reply]
Not necessary, for Italians (Q50001), it would be in French "Italien" for P1549 instead of "Italiens" in the label, and we can add feminine singular, plural, etc. Tubezlob (🙋) 18:57, 3 March 2017 (UTC)[reply]
🙋
--- Jura 19:10, 3 March 2017 (UTC)[reply]
I've add classes. Cdlt, VIGNERON (talk) 15:53, 10 March 2017 (UTC)[reply]
And Jura1 removed people (Q2472587) (whom ethnic group (Q41710) is a subclass), and I kind of agree, it would be a duplication of the label and most importantly of the date stored in the related item about the place). Tubezlob do you agree too? could we resolve the consequent violation? (and then we could move on to some others constraints and then to a mass import). Cdlt, VIGNERON (talk) 09:35, 11 March 2017 (UTC)[reply]
@VIGNERON: So how can we store ethnonyms if it's not with this property? Tubezlob (🙋) 10:57, 11 March 2017 (UTC)[reply]
@VIGNERON: true, good question... Jura1 do you have an idea? Cdlt, VIGNERON (talk) 11:03, 11 March 2017 (UTC)[reply]
The sample you gave for Q50001 doesn't meet the description for this property. Maybe name (P2561)?
If one believes in adding it to random string properties, I don't see why one would pick this one.
You are obviously free to propose the creation of a new one.
--- Jura 12:50, 11 March 2017 (UTC)[reply]

Proposal for deletion

[edit]

@Rodrigolopes, Amadalvarez, Jon Harald Søby, Robin van der Vliet, J budissin, Bouzinac: @Zorion, Memathieu, Fierodelveneto: (pinging top users of this property)

I'm wondering if we shouldn't delete this property. Thanks to Lexemes and the property demonym of (P6271) we now have a much better solution to store this data (and that solved most questions already asked on this very talk page).

What do you think? What should be the step going forward (data transfer to the other property and so on).

Cheers, VIGNERON (talk) 17:53, 3 January 2023 (UTC)[reply]

Hi, @VIGNERON. Sorry for my low know about Lexemes. What would be the equivalent solution to present use?. In cawiki we use P1549 to show it in the "administrative entities infobox", it is, countries, regions, municipalities, towns, etc.
What would these items have instead?. Thanks,
I understand that demonym of (P6271) is inverse property of P1549, but it is not oriented to this kind of items and, from WPs the backlinks are not available.
Thanks, Amadalvarez (talk) 22:29, 4 January 2023 (UTC)[reply]
Ah @Amadalvarez: good point, that's an interresting use case.
The equivalency is Qdemonym (P1549)name = Ldemonym of (P6271)Q + Lwikibase:lemmaname. The « WPs the backlinks are not available. » is problematic here (is there any hope that this will be solved any time soon?). So should we create a new property in the same direction as P1549 but with the Lexemes datatype instead of string? I don't really like this solution (it's better than the current situation, for instance it solve the #Plural section above by @Tubezlob: but doesn't solve the #Insane section by @Infovarius:), not sure it's the best trade-off but is there any better?
Cheers, VIGNERON (talk) 16:52, 6 January 2023 (UTC)[reply]
Hi, @VIGNERON. Due to architecture of WP pages, I think that backlink acces will never be possible. Sometimes in WD we don't accept inverse property because of possible inconsistences, without keep in mind that WP should be a preference customer.
I already tell that I know nothing about lexeme. In order to understand the P6271 function, As far as I know, properties of an item gives a value; but P6271 is a property for a lexeme -it is a value- that gives an item. Is it correct. ?
Why not to exchange data type from string to element and have the multi-language value in the labels of object items?. Usually, are one value for country/municipality,.. with tranlation or transcription to other languages (see https://w.wiki/6CHR: 30.000 values in 15.000 items). It is handeable with labels. In case of more than one value, multivalues should be accepted. The impact to the location item will be to reduce large string version to 1-4 Qids. The element pointed, in most of times, already exists, for instance, Americans (Q846570), Parisians (Q105740844), Americans (Q846570), etc.
With this change of data type the functionality of P1549 remains similar.
We need to keep the same functionality, not the same technical solution. The lexema proposal is a solution for another functionality.
Thanks, Amadalvarez (talk) 21:25, 6 January 2023 (UTC)[reply]
@Amadalvarez: I never say never, we might have some SPARQL access in Lua one day (thus allowing backlinks), but let's stay in the now.
« Why not to exchange data type from string to element and have the multi-language value in the labels of object items? » well an entity for words is exactly what a Lexeme is (and for better than item, since item only have one label per language which is often not enough for demonyms, plus the lexemes will exist anyway, so create new items will be redundant). So yes, I would suggest to exchange this property data type from "Monolingual text" to "Lexeme". I did a test on the Wikidata Sandbox: https://www.wikidata.org/w/index.php?oldid=1806443553&title=Q4115189#P1549 (current solution) https://www.wikidata.org/w/index.php?oldid=1806443553&title=Q4115189#P5188 (possible future solution). Using items about demonyms is also possible (and indeed reduce the #Insane problem) but I will it's quite complicated for low gain.
Cheers, VIGNERON (talk) 11:24, 8 January 2023 (UTC)[reply]
@VIGNERON
  • I wish you were right about SPARQL. By now we just have Listeriabot but don't give dynamic results; it's useful for "list of" articles and limited by time out. I'll be patient.
  • I need your help to understand just a bit about lexema. In your example, with P5188 we get Parisien (L26359), in french. So, how do I get its catalan version from here?, or else, the P5188 would have one value for each language?.
Thanks, Amadalvarez (talk) 11:54, 8 January 2023 (UTC)[reply]
This was already proposed in 2018 and was only closed last year (link). There were similar proposals for female form of label (P2521) (link) and male form of label (P3321) (link) in 2019.
The problem, as Amadalvarez points out, is that other projects have no way to access the data using demonym of (P6271).
There are over 27,000 statements for this property where the value does not exist as a lemma or form on any lexeme (query). The majority of the statements should have lexemes regardless of what happens with this property, so there's still quite a bit of work to do.
While I don't think we can delete the property until there is a way for other projects to access the data, my proposal would be to only keep these statements when they're actually in use by other projects. According to the "This property is being used by" box above, that would be limited to Catalan, Ukrainian, Ladino, French, Slovene, Spanish, Sardinian, Ligurian, Venetian, Arabic, Portuguese and Tarantino.
- Nikki (talk) 13:18, 8 January 2023 (UTC)[reply]

Single-value constraint

[edit]

Some items can have multiple demonyms without an obvious separation (see e.g. here), so I'm not sure if single-value constraint (Q19474404) is appropriate here, @Swpb. Sdkb talk 16:17, 29 February 2024 (UTC)[reply]

It's already a suggestion constraint, and I think it's valuable as such. Swpb (talk) 23:41, 29 February 2024 (UTC)[reply]
I'm not familiar with how widely applicable a rule needs to be in order for it to work well as a suggestion constraint. I added the example item as an exception, but if the exception list grows we might need to reconsider. Cheers, Sdkb talk 18:44, 1 March 2024 (UTC)[reply]
Sure; "if the exception list grows we might need to reconsider" is always a good policy. Swpb (talk) 16:33, 2 March 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P1549&oldid=2269598951"