Open main menu

User talk:Nono314

About this board

Logo of Wikidata

Welcome to Wikidata, Nono314!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

  • Introduction – An introduction to the project.
  • Wikidata tours – Interactive tutorials to show you how Wikidata works.
  • Community portal – The portal for community members.
  • Contents – The main help page for editing and using the site.
  • Project chat – Discussions about the project.
  • Tools – A collection of user-developed JavaScript tools to allow for easier completion of some tasks.

If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards! Liuxinyu970226 (talk) 00:07, 20 May 2015 (UTC)

Previous discussion was archived at User talk:Nono314/Archive 1 on 2016-01-17.

Reminder: Community Insights Survey

1
MediaWiki message delivery (talkcontribs)

RMaung (WMF) 19:53, 20 September 2019 (UTC)

Reply to "Reminder: Community Insights Survey"
MediaWiki message delivery (talkcontribs)

RMaung (WMF) 17:37, 10 September 2019 (UTC)

Reply to "Community Insights Survey"
Nomen ad hoc (talkcontribs)

Bonsoir Nono,

je préfère te répondre ici (et en français du coup), pour ne pas trop gonfler la page de proposition.

Je pense que vu ce que tu dis, on peut admettre que ta troisième réticence n'est pas rédhibitoire ?

Pour le reste :

  1. je n'en suis pas si certain, rien qu'en prenant toutes les grandes écoles françaises qui ont un grand nombre d'anciens élèves célèbres, multiplié par le nombre de leurs promotions, ça doit déjà faire un millier ; et il y a l'évidence beaucoup d'établissements célèbres dans ce cas ailleurs dans le monde francophone et dans le monde (cf. ton exemple de West Point)
  2. en fait, dans un certain nombre de cas, indiquer que X et Y ont étudié à A durant l'année B ne suffit pas à savoir s'ils ont étudié ensemble. Par exemple, dans le cas de l'École normale supérieure, A peut être élève et B étudiant : ils ne feront pas partie de la même promotion. Indiquer leurs dates d'études et leur promotion ne sera donc pas redondant. J'ajoute que membre de n'est pas accepté comme qualificatif de scolarité, et que nous avons bien des propriétés dédiées pour les partis politiques ou les équipes sportives. La propriété me semble donc utile pour parvenir à une granularité satisfaisante
Nono314 (talkcontribs)

Oui rien de rédhibitoire dans tout ça, c'est juste histoire de cerner un peu la proposition ;-)

J'avais vu passer ton sujet sur le bistro que je ne suis que très épisodiquement, et c'est là que j'avais trouvé l'exemple de West Point en cherchant des cas hors France, mais j'étais passé à autre chose sans te répondre...

Bien sûr on a des tas d'écoles et d'élèves ! Quand je parlais de peu de cas, je parlais bien des promos qui valant le coup d'avoir un item dédié (avec quelques déclarations). Pour West Point justement, on en a une seule qui a eu un élément, pour plus de 200 qui ne sont désignées que par l'année de sortie et où on multiplierait donc les éléments un peu en vain AMHA. Créer un élément "promotion Voltaire de l'ENA" c'est glamour, créer un élément H.65 pour la promo 1965 de HEC c'est déjà plus aride.

Je ne suis pas suffisamment pointu sur l'ENS pour saisir exactement la subtilité (l'article WP parle de "normaliens étudiants" et d'"étudiants normaliens" en disant qu'ils suivent les mêmes cours et ont le même diplôme...). Mais en gros il me semble que ce qu'il te manque c'est une meilleure granularité dans le cursus et que ce n'est pas franchement lié à une année précisément ? Est-ce que dans ce cas, il ne faudrait pas essayer de travailler sur la notion de cursus, filière, etc et laisser l'année en qualificatif ? Ca permettrait de ne pas trop démultiplier les éléments un peu vides de sens, et ça ne s'appliquerait du coup que là où c'est nécessaire, aors que l'année démultiplie les éléments pour tous les établissements ?

En fait ce qui me gêne pas mal c'est le fait d'avoir des éléments combinatoires (école x année) : c'est l'esprit des catégories WP mais pas du tout celui de wikdata où on a un élément par concept et on les croise avec d'autres en qualificatif pour obtenir la combinaison désirée. Oui on a {{P|54}} mais en face on ne met pas Barça de 2017 parce que les joueurs n'ont pas tous côtoyé dans les vestiaires ceux de 2019... Et au besoin on doit pouvoir préciser si c'est l'équipe féminine, junior, etc sans créer des éléments pour chacune chaque année. Tu vois l'idée je pense ?

Ton idée est intéressante (voire séduisante sur les quelques exemples que tu donnes) mais je me demande si c'est la meilleure façon de la mettre en œuvre et si ça ne va pas surtout faire une usine à gaz (et à créer des éléments peu intéressants). C'est aussi le rôle du débat de proposition de challenger le modèle proposé pour voir s'il est pertinent sur la durée, ou si on ne peut pas trouver une autre façon qui "collera" mieux en dehors de quelques cas particuliers.

Qu'en penses-tu ?

Nomen ad hoc (talkcontribs)

"Glamour" :D tu m'as fait ma soirée là.

Plus sérieusement, je comprends tout à fait le sens de tes remarques, et elles sont bienvenues. Je vois aussi très bien l'idée d'éviter les doublons. Alors admettons qu'il faille travailler plutôt sur les filières, mais comment ? Je suis preneur de toute idée en ce sens. Pour filer l'exemple des normaliens, il est vrai que affilié à permettrait d'indiquer la section (L ou S). (Et en résumé la différence tient à ce que les "élèves" ont été admis par concours, les "normaliens" sur dossier", que les seconds ne sont pas payés, que leur scolarité ne dure qu'un an dans le cadre du master, et que leur promotion correspond à l'année d'obtention du diplôme et non d'entrée.) Après, je ne vois pas trop.

Concernant les éléments qui valent le coup, j'ai vu qu'Ayack avait fait un travail sur les promos de Saint-Cyr et l'ENA, c'est ça qui m'a amené à lancer la proposition. Et Vahurzpu s'est dit intéressé pour les universités américaines. Donc je pense qu'on serait déjà assurés d'un certain nombre d'usages.

Nomen ad hoc (talkcontribs)

Bon, si tu n'as pas de meilleure idée, je vais quand même marquer la proposition comme prête. Si elle aboutit, on pourra toujours en discuter après, voire, si on trouve mieux, labpproposer à la suppression ; ce n'est pas gravé à tout jamais dans le marbre ^^

Nono314 (talkcontribs)

Oui, voyons ce que ça donne. Commencer par l'utiliser avec les éléments créés par Ayack est un bon début : fr:Liste d'élèves de l'École nationale d'administration n'attend que ça.

Après, je sais que tu es souvent prolifique, c'est pour ça que je préférais en discuter avant que tu te lances, mais si tu es convaincu que cette solution est celle qui convient le mieux, on verra à l'usage.

Et content de t'avoir fait marrer avec mon précédent message, c'est vrai que ce n'est pas forcément l'adjectif qu'on accolle à certains de ses membres ;-)

Reply to "Proposition de propriété, suite"

Wikidata:WikiProject sum of all paintings/Imprecise location

5
Multichill (talkcontribs)
Nono314 (talkcontribs)

Sure, no problem. For a large part of them, it's just a matter of reverting one single contributor...

I've been going down the missing inventory numbers those days but am currently reaching the end of what I can reasonably retrieve. So, will be available for some other lists.

Multichill (talkcontribs)

Appreciated. I usually switch between relatively easy tasks so I can stay productive and won't get bored.

Multichill (talkcontribs)

He is really testing the patience with edits like . Would be good if someone else not involved in the conversation would comment.

Multichill (talkcontribs)
Reply to "Wikidata:WikiProject sum of all paintings/Imprecise location"
Jarekt (talkcontribs)

Thanks for correcting some issues with data imported from Commons. It seems like occasionally people use incorrect dimension names to describe artworks on Commons, like in File:Épisode de la campagne de Russie - Nicolas-Toussaint Charlet.jpg where we have height by length instead of height by width. Those issues are very hard to detect on Commons which does not use Structured data that much yet, but it should be easy to detect on Wikidata.

Nono314 (talkcontribs)

OK, so this one actually came from Commons...

I had found other cases (Solomon Receiving the Queen of Sheba (Q19947682), Madonna and Child with Angels (Q24929980)) were you also imported to wikidata using length (P2043) while commons had the correct dimension (and thus correct QS code generated by Artwork template) which got me a bit puzzled... Any idea how it happened?

It's the first time I see it from the many you imported and those were from the same date, that's why I suspected there may have been a flaw in your script at some point in time.

Jarekt (talkcontribs)
Nono314 (talkcontribs)

which both had that bogus Size template added by JarektBot through AWB ;-)

So I suppose it was actually an ill setup job. Data at the source was still initially good. But I guess it should me more limited in scope than if it were a script. Any chance you can autofix this on commons too? There are risks of them being imported again otherwise I fear.

Jarekt (talkcontribs)

My bot adding Size template with length parameter just converted text version of "length" to template version as in this edit. Length is not uncommon when referring to sculptures, just not paintings.

Nono314 (talkcontribs)

What makes you think 'L.' is "the text version of length"? "H. / L." is standard for Hauteur / Largeur, french for Height / Width. Maybe you overlooked that?

Making assumptions on single letters without language context is dangerous, and the file being classified as painting, length is probably not a good guess for 'L'.

Anyway, now it happened, could this be fixed, so that it's both correct on commons and not at risk to be re-imported to Wikidata?

Jarekt (talkcontribs)

You are right. I will look for paintings using "length" and see if I can correct it.

Nono314 (talkcontribs)

Ok, thank you very much.

Reply to "length of paintings"
VIGNERON (talkcontribs)
Nono314 (talkcontribs)

Probablement pas à mon avis. C'est un titre purement descriptif et qui semble d'ailleurs avoir été créé de toutes pièces (l'ENSBA en donne d'ailleurs une version beaucoup plus concise). À mon avis, on utiliserait une description équivalente mais dans ces langues. Prends tous les tableaux flamands, on leur trouve toujours un titre en français. Ça marche dans l'autre sens aussi.

VIGNERON (talkcontribs)

Mh, pas entièrement convaincu (les titres qui restent dans leur langue d'"origine" sont aussi nombreux) mais pas entièrement on-convaincu non plus donc je me suis ré-annulé.

Nono314 (talkcontribs)

D'une manière générale, je suis assez réticent sur les duplications de libellés pour les œuvres, a fortiori dans des langues dont on ne connaît pas les usages : je te fais totalement confiance pour le breton, mais je pense que pour l'indonésien nous ne sommes compétents ni l'un ni l'autre...

Dans le cas de représentations de scènes classiques (bibliques, mythologiques...) comme c'est le cas ici, ces épisodes sont connus en tant que tels dans toutes les langues européennes qui vont logiquement réutiliser leurs prpres mots pour désigner le tableau. Achilles in his Tent with Patroclus, Playing a Lyre, surprised by Ulysses and Nestor (Q18573844) me semble ainsi bien plus fidèle aux usages. Mais bon, je n'étais pas prêt à déclencher une guerre d'édition pour ça ;-)

Nono314 (talkcontribs)

Et pour achever de te convaincre, extrait d'un "véritable" catalogue d'expo ayant eu lieu à Princeton (pp. 129 et 300) puisque l'ENSBA donnait des références précises.

VIGNERON (talkcontribs)

Je n'ai pas accès au livre sur Google (ah Google...) mais oui je suis maintenant convaincu (j'appliquais la même méthode que pour les éditions mais un tableau est effectivement une œuvre plus qu'une édition).

Reply to "Annulation sur Q62618838"
Jane023 (talkcontribs)

Hi Nono314, see the Commons file - I uploaded it from Joconde, so you need to complain to them, not me.

Nono314 (talkcontribs)

Both references you had mentioned (Joconde and RKD) agree the painting is in Strasbourg (at least now). Either they both changed their mind during the 3.5 years elapsed, or you may have mixed two entries back then, that had quite similar titles.

Jane023 (talkcontribs)

Well that is of course possible too. I doubt the databases are wrong, but I also doubt that I mixed up the data if I uploaded the painting from the database. Odd indeed, and of course a lot can happen in 3.5 years.

Nono314 (talkcontribs)

Sure. Didn't realise when I reverted on WD that you took everything from that old commons upload. I just found odd that your collection/inv# didn't match what was stated in the external ids.

Jane023 (talkcontribs)

I wasn't as active on Wikidata then and didn't have the tools I have now, but I was working mostly on Commons and the old workflows I did then don't translate well to Wikidata. Ruisdael was one of my earliest projects.

Reply to "Q61134681"
Jane023 (talkcontribs)

What is your specific question about Q36536099? Are you unfamiliar with engraved copies of paintings?

Nono314 (talkcontribs)

I am wondering about the use of followed by (P156), which implies there is a series in which there is a successor. Thus asking, what would be the series here? In a series, elements play a similar role which is not the case for an engraving of a painting. Use of followed by (P156) as a direct property implies belonging to a self-evident series like days of week, but a painting could potentially be part of a number of series, and the first to come to mind would probably be the one of works by its creator. I have never seen this use for any kind of derived artwork... Do you have any other examples where it has been used?

On the other side Using based on (P144) on the engravings seems perfectly ok, but was never meant to be the reciprocal property of followed by (P156): that actually raises 2 constraint violations as both are seen missing their opposite statement.

Jane023 (talkcontribs)

Strange. I don't see why "series" means it must be more than two. Possibly a translation problem then!

Nono314 (talkcontribs)

Even if you accept a series of two it is still odd and I note you didn't use follows (P155), acknowledging it is a different relationship than succession. Would you mean asking someone else's advice, as I find it a quite awkward modelling?

Jane023 (talkcontribs)

Well I think it would not be incorrect to use follows for the engraving in this case, but I am somewhat reluctant to do so, since important paintings were often engraved more than once (due to the plate wearing out or being unavailable to the publisher) and sometimes the engraving was ordered from a previous engraving. I suppose you could use all of these properties to make it a more complete relationship, but since there are so many "not so close copies", partial copies, and other types of derivatives, I don't think excluding the followed by property is the best way to go.

Reply to "Followed by"

Please do not remove "described at URL"

3
DarwIn (talkcontribs)

As you have done here. We are running a GLAM here with the National Library, and by removing that property you're damaging the integrity of the data we are importing from there. Please don't do that any more.

Nono314 (talkcontribs)

May I know what integrity I would have been damaging, since it's using the specific property you yourself promoted to replace the generic url, deeming it essential to your GLAM? And, just after restoring this property whose absence you claim would be so damageable you changed it to a totally different value? Why not just add that new one? I value very much each and every effort put in various GLAMs, but I must say here your workflow is at best very obscure...

Not to mention that the property proposal was using a bogus example resulting in a wrong id association that I fixed. Surely mixing up entries is more damaging for the integrity of the source's data? And I hope the initial confusion for just two sample values doesn't preclude anything about the upcoming project...

Wish you the best for your project, but keep in mind that it will work better if you stay consistent with how things work and accept external input instead of trying to stay in isolation.

DarwIn (talkcontribs)

Hello Nono,

We are beginning this GLAM, and still at a stage where we are defining and testing the workflow that we would apply to it. At BNP (the National Library) there are two possible values for described at URL, one shorter and another more complete. Initially we were using the shorter. Then it was made into that new ID for the Digital library of BNP, and the value of that property was used for the URL with the more complete description. When I went there to fix that value, I was confused when looking at the item and not finding the property I had added before, and then I found you had removed it. Seems to have been a misunderstanding, then.

Reply to "Please do not remove "described at URL""
Rama (talkcontribs)

Please do not remove "described at URL" properties, they are used to link back to source URLs in Commons information templates.

Nono314 (talkcontribs)

No, duplicating this is as nonsensical as using the {{Joconde}} template and then inserting the full link as wikitext beside! The commons Artwork template should generate a link to Joconde from the id (and I've seen it in many occurrences for paintings). There are more than 10000 occurrences of Joconde id, how many do have the url repeated beside yours?? even those were not consistent with that pattern...

Nono314 (talkcontribs)

Answer: there are in total 36, less than 0.4%! Looks like an error rate... So saying they are used as a generic statement seems more tha overstated.

Rama (talkcontribs)

I do not recall making such a strong statement. I am simply trying to convey the notion that when you see something that you do not understand, you might first think about the issue, or ask, rather than jump into action.

Yes, the Artwork template should generate a link to Joconde, good thinking! And it eventually will. But it does not yet. In the meantime, displaying sources for the information entails explicitly giving the reference URL. Incidentally, dismissing the sourcing issue with the notion that Artwork will be perfected in the future works both ways: the duplication of information in Wikidata is an unfortunate necessity at the moment, that will be easily remedied when Artwork grows in capability.

The question is not whether one of the alternative is ideal, since none of the two is, but whether you place abstract notions of database purity in Wikidata above real-world sourcing considerations on Commons. None of the projects is inferior to the others, and they have to work together with a degree to pragmatism to produce actual results.

Nono314 (talkcontribs)

Now you are just being dismissive and showing contempt, saying I "don't understand"... I'm not the kind of guy to talk about any kind of "purity", be it db or anything else, and I always consider practical issues and find middle solutions that can fit different needs.

I understand so much that I have been following newly created artwork items for more than a year, completing them, adding a good number of Joconde ids. I also remember pretty well that after doing so they were showing in the Artwork template as well as Atlas for Louvre objects. I remember it was a dedicated "authority control" section, not the usual reference one from the non wikidata enabled template. It was also much cleaner than your solution, displaying just the id, not the ugly mistral url. I can still find in the lua code of module Artwork calls to that Authority control which is building links for Joconde and Atlas among others. I will ask Jarekt if something has changed about this, as I think it was working in a recent past, not in a distant future.

So when I stumbled upon described at URL (P973), I had very good reasons to think it had been added mistakenly and remove the duplicate. The very fact that there are indeed only less than 3 dozen occurrences of such redundant data out of more than 10,000 uses of Joconde proves it is not so necessary as you claim. It's merely messing with data to fix a very small part of a temporary display issue.

You can even see it working on which uses the {{Category Defintion: Object}} template, said to be identical to Artwork. Everything displays well there without any need to duplicate anything. So it should be possible to have it on Artwork too without doing too many stunts or traveling to a parallel "ideal" world. And what about ? This one is even based on template Artwork. So it's probably just a question of finding the right person with knowledge of the arcanes of the Artwork module instead of wanting to fill a gap that has no reason to be.

Rama (talkcontribs)

I wrote support for Joconde and Atlas myself for my draft model https://commons.wikimedia.org/wiki/User:Rama/Catdef

The problem is not writing something. It is writing something clean and reliable enough to be included in official templates and put into production.

Rama (talkcontribs)

PS: Sorry about "not understand", I meant that in the sense of "if you have doubts". In any case, deleting information should always trigger some questioning. The duplication of certain information may be for a reason (indeed, labels are practically always duplicated information).

Rama (talkcontribs)

Also, if you absolutely have to remove the author and inventory numbers from labels, at least please do move the name of the author to the description, lest you would make things harder to find with search engines.

Nono314 (talkcontribs)

I do not "absolutely" have to, but a title is... just a title. If you make a list of artworks by an artist, you won't repeat unnecessary things. That's why there are properties for specific things, so that you can choose what you want to display. An item title's use is not the same as an image name on commons. You could have used more useful descriptions if you care so much, but don't worry about the search engine, it's smart enough to index relevant fields.

Rama (talkcontribs)

This is not a title, it is a label. The title is Property P1476 — of which there can be several, incidentally. The label is arbitrary, which you should have realised from instances when you have to chose one particular title over the others; copying information that belongs to P1476 there is just a convention, and I am unconvinced that this particular convention is superior to Title+Author+ID, for instance.

The convention that Labels should parrot Title P1476 yields issues similar to what you can see athttps://commons.wikimedia.org/wiki/Category:Fugitive_Love_by_Auguste_Rodin with a mess of distinct objects clammed together in one single Category. The Wikidata version would amount to getting a long list of item with the same label, whose descriptions will in all likelihood be absent or unhelpful, and no convenient mean to distinguish the various Q-Items nor chose the relevant one. There is even the risk that some cretin decide to merge distinct Q-Item because they will not immediately understand the difference between one copy of the work, another copy of the work, and possibly the Q-Item describing the work as an abstraction that yields the various copies.

TL;DR: Labels are arbitrary, putting a title in a label is just a convention, it is not a very good convention, and the subject warrants more thinking than acting reflexively.

Nono314 (talkcontribs)

What happened to your claimed inclination toward pragmatism? Everyone is using label as a title so you should take that into consideration, even if it's just a convention yes. Several of your arguments are totally valid and would be worth more thinking yes, but community thinking not just you claiming to know better and doing your own way without trying to accommodate other items around yours.

I'm also not the one reflexively reverting things before starting a discussion...

And I will just stop keeping up arguing forever and continue admiring the great artwork photos you upload, while forgetting the unfriendly interaction.

Reply to "described at URL"
Return to the user page of "Nono314".