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.

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"
Multichill (talkcontribs)
Nono314 (talkcontribs)

I just didn't know where you got if from... and hadn't yet seen the Commons category (P373) in the first place. That user is a common name for mismatches with Magnus' mobile games, so no surprise.

Multichill (talkcontribs)

Yup, one of the "regulars" :-(

Reply to "Hôtel des Roches Noires"
Hsarrazin (talkcontribs)

Désolée, c'était l'image que je voulais annuler : c'est une personne, pas un cratère ;)

apparemment, mon clic a glissé sur la mauvaise propriété. c'était bien sûr une erreur...

Reply to "Q324343 Scipione Breislack"
Yann (talkcontribs)

Hi, Regarding your revert, this is how it is used elsewhere (Q55437339). And it would be much better if you add the correct property instead of removing information. Regards,

Nono314 (talkcontribs)

HI,

"elsewhere" is also by you, so? Do you mean I should have tracked every single addition you did and revert each and every one? I don't want to be rude, I'm just trying to explain the semantic of the property, indeed because I noticed you started adding a number of historically significant photographs. I think that's very interesting, but it would be even better if you can in the future stay consistent with existing items as well as other domains in visual arts (paintings, sculpture, ...) instead of twisting the meaning of properties to your needs. So I just chose one example to convey the message (and especially this one, because the commons page was explicit about where the photograph can now be located, while for the Nagasaki one I can't know whether it may be on display at Nagasaki Atomic Bomb Museum (Q1099077)).

As for the correct property, I did not have it right under hand because I'm not used to work on photographs. But it seems you actually had it better ("elsewhere") just the day before, so why not re-add the information yourself with the correct one? I hope you can continue with appropriate properties, making your additions even more useful for the community.

Regards

Reply to "location"
Return to the user page of "Nono314".