User talk:VIGNERON

Previous discussion was archived at User talk:VIGNERON/Archive 1 on 2015-09-01.

Bonjour,

Je souhaite savoir si la soirée Wikidata ce soir est toujours d'actualité.

Bonjour,

Oui la soirée aura bien lieu au Mille Potes (4 bd de la Liberté à Rennes) ce soir à 19 h.

Le quiz et le gâteau sont prêts ;)

À ce soir !

Example change

As stated in tweet Wikidata database model with depict is not a good match as you can have more pictures for an WD object etc.... so this will be better when the depict functionality is moved to Wikicommons.....

User case I see: As an user I would like to see all pictures with a depict near my current location ==> search all Wikidata objects with a pictures that has a depict to an WD object that has a coordinate near me example query

Hi Salgo,

I've already seen these tweets but I'm not sure to understand the relation with my revert or your user case (self depiction are not taken into account in your query).

Anyhow, a work (whatever the medium) is almost never self-depicting (except by droste effect (Q1766263), but this doesn't seems to be the case here).

Linked data is a moving target and now we start seeing that depict combined with relative position within image (P2677) is useful My point is that as depict today is connected to a Wikidata object that has a image (P18) it make sense to mark what part of the picture is about the Wikidata object using depict with relative position within image (P2677)

Mhh, ok I think I see better now ; though it's still very strange to do a self link (or more exactly that you mix-up the work and the image of a work) and you should avoid it. Plus, the whole image in P18 is supposed to be about the work, no need to explicitely store this information.

I think when Wikicommon supports depict and relative position within image (P2677) then this is maybe a non issue for this user case....

I have spent too much time ;-) connecting Dictionary of Swedish National Biography (P3217) to Wıkidata and feel my small test with relative position within image (P2677) is pointing in an very interesting direction.

A picture as used on The Coronation of Napoleon (Q1231009) could be the image (P18) for many articles and all those articles could have different needs for marking what part of this picture is of interest in this article..... ==> maybe having depict in common will not solve all needs from different user stories ;-) example of how the picture is depicted today see https://tools.wmflabs.org/wd-image-positions/item/Q1231009 which has focus identifying people in the picture....

I'm sorry but I don't understand, what does it that to do with putting a wrong selfreferencing value?

Selfreferencing in the depict field tells you what part of the picture is of interest of the WD object..... e.g. Q18332787

https://tools.wmflabs.org/wd-image-positions/item/Q18332787

Sorry, I'm missing something apparently. If it's selferencing, then there is no "part", the whole work should depict the work itself.

Sotes castle (Q18332787) is very wrong, the image (P18) could and should be changed for a better picture and depicts (P180) should be removed (this property is for picturing works, a castle doesn't represent anything). "Häringes slott Sotes borg 1825.jpg" depicts "Sotes borg" but "Sotes borg" doesn't depict "Sotes borg". The first is not possible yet, still waiting for Structured data Commons but meanwhile we shouldn't force it on Wikidata.

Yes we are waiting for Structured data Commons

I think the problem is when we start combining depicts (P180) and relative position within image (P2677)

• When adding relative position within image (P2677) we will always speak about the object in a specific picture ==> it could make sense to explain were in the picture all objects are also the object itself
• When having "just" depicts (P180) then often "self referencing" makes no sense

Yes, let's wait and see.

For me the main problem is the self referencing (no matter what property, I'm checking a lot of self referencing). An secondary problem is with relative position within image (P2677) where sometimes there is confusion between the object and its picture (for a 2D work, it's usually not really problematic but for others works it can create difficulties).

But in some case, there is a simple solution: create a specific item for the picture itself, for example I created no label (Q57998740) (to be improved). It doesn't work for photo taken by wikimedians - here we need Structured data Commons - but for an old engraving like this one, it works well.

I feel lesson learned is that Linked Data is not easy at least if you should start link with another domain....

I think Wikidata also should have a better linking model e.g. so that you can explain that 2 min 3 sec into a video object xxx depicts yyyy ... 15 years ago I worked with SGML and a standard called en:HyTime that supported things like that but I guess never was a success.... maybe now with Linked Data and Wikidata we can start move into that direction....

Salut,

Merci pour ta réponse sur le Bistro. L'autre lien donnait tellement de réponses que j'étais incapable de trouver les pages dédiées sur Wikidata.

Je me demandais si tu savais comment enlever avec QS2 (ou PetScan) une image en particulier ? Quand j'essaie quelque chose comme -Q935561 P18 P vip.svg, ça ne marche évidemment pas.

Hmmm, les images (et les fichiers en général) c'est particulier, j'avais tenté de trouver avec Query mais je n'ai pas trouvé la bonne syntaxe (je crois me souvenir qu'il faut l'URL complète du fichier par juste le nom mais même ça ne marche pas...). Même pas sûr que ce soit possible en fait.

Je notifie @Maxlath: qui aura peut-être une solution (avec Wikidata-CLI ?).

Ok. Merci pour la réponse. Au pire, je le ferai à la main.
Est-ce que mon ajout te semble ok ? Harvest Template le gère bien, mais puisque c'est un nouveau type de manip pour moi, avoir ton avis sur le sujet me semble pertinent.

Encore une question : penses-tu que nous devrions, tout comme c'est fait pour "tomb", rajouter les mots "armoiries", "plaque" et "blason" pour éviter les importations de ce genre : , ?

Oui, bonne idée l'ajout de cette image placeholder dans la contrainte et oui aussi pour "armoiries" et "blason".

 Done

@VIGNERON ça peut effectivement se faire avec wikidata-cli :

claim_guid=$(wd data Q935561 | jq .claims.P18[0].id --raw-output)

wd remove-claim $claim_guid

Vous parlez bien de https://www.npmjs.com/package/wikidata-cli ? Est-ce un outil que je peux utiliser sous Windows ?

Oui, c'est bien cet outil (que je n'ai pas encore eu l'occasion de tester, je vais déjà finir Wiki Loves Monuments :P )

@Maxlath: Rebonjour,

Puisque ni moi ni VIGNERON ne maîtrisons cet outil, pensez-vous que vous pourriez retirer les images des éléments recensés sur les pages suivantes ?

• Special:WhatLinksHere/File:P_vip.svg
• Special:WhatLinksHere/File:Cricket_no_pic.png

Ah, on dirait que les éléments de P_vip.svg ont été nettoyés à partir de Wikidata:WikiProject Q5/reports/identical P18 par user:KrBot. Je vais voir si je peux joindre les autres à cette page.

@Simon Villeneuve je viens de le faire pour File:Cricket_no_pic.png

Pour info, les étapes suivies :

- récupérer tous les identifiants de claim avec cette requête (on peut récupérer la liste générée en JSON en mettant le SPARQL dans un fichier et en utilisant wd sparql : wd sparql ./sparql --json

- construire les commandes wd remove-claim à exécuter sur le modèle wd remove-claim 'Q3350114$0C02BB69-D189-4148-BC47-50CC1E6CD2E6'

Bonjour,

Peux tu m'aider à fusionner Q4240411 et Q17016217 qui sont deux données distinctes sur wikidata mais la même église orthodoxe à Genève.

Merci

Bonjour,

Il y a deux pages sur cette cathédrale sur la Wikipédia en italien. Pour le moment la fusion sur Wikidata est donc impossible, il faut attendre la fusion là-bas. J'ai mis le modèle de demande de fusion sur les deux pages là-bas. Je surveillerais et ferais ensuite la fusion ici.

Merci pour ton aide. Je ne comprenais pas pourquoi le gadget merge ne fonctionnait pas.

LMV

Bonjour Vigneron,

Your edit is probably superfuous since there is already River Kova (Q2425962) however without French description.

Hi,

Maybe it the same river or not, I don't know ; it wouldn't be the only duo of rivers with the same in the same area, there is Frémur Ouest (Q15111030) and Frémur Est (Q52149213).

I let you check and do the merge if needed.

Hi VIGNERON,

I think your initiative about months gave some interesting results. As it's archived since, how about a new one?

Good idea. Do you have any suggestion ? (days is a probably too obvious choice)

What about zodiac (Q40540)?

Probably too western and 12 can already be a lot for people not used to create lexemes.

But it gave me an idea: what do you think of the 8 planets?

yes

good idea

Months was a great choice as there are a 12 (but not too many) and there is no definition problem (at least, if one doesn't dig too much).

• Maybe colors? But it's tricky to get a clear subset.
• Or some fruit and vegetables

(I don't think I added any of the later yet. Basic colors might be complete in French).

Colors are quite complicated (defining the set but also the lexical category is not always clear).

Food and meal could be a good idea but for latter.

Here we go with the planets : Wikidata_talk:Lexicographical_data#Lexemes_about_Planets (I check very quickly on Ordia but didn't find any results and with Wiki Loves Monuments, I don't have much time... I let you check and complete the list ;) ).

Here is a summary list Wikidata:WikiProject Astronomy/names/planets

Good day! Is fr:Projet:Anatomie referring to Human anatomy, as its Wikidata project sister links, or is it referring to Anatomy in general? In the latter case, I guess the French project should be separated from WikiProject Anatomy (Q8487304) and assigned to no label (Q32768635) (this Russian project is for Anatomy regardless if human or animal), but then there is WikiProject Animal anatomy (Q21829301) which messes up everything... Could you help?

Salut VIGNERON,

En cette période de WLM j'ai finalement mis Mérimée sur Mix'n'Match, en commençant par les MH (identifiants PA*). Le contenu est à jour des tous derniers ajouts (août 2018) et j'espère que l'option scraper mermettra de suivre les ajouts futurs. On peut voir ainsi exactement ceux qui nous manquent encore.

J'ai l'intention d'ajouter un second catalogue pour l'inventaire comme on en avait discuté avant l'été, mais il faut d'abord que j'améliore les libellés pour espèrer avoir un taux correct d'automatches (sur les MH c'était à peine plus de 5%). Le but étant de complèter avec un IA les éléments qui ont déjà un PA ou qui ont été créés à partir d'autres bases comme les églises d'Ayack. Je me souviens que tu n'étais pas très chaud pour MnM, qu'en penses-tu ?

Bonjour,

Excellente nouvelle. Je te donne ma bénédiction pour y aller pour les IA ; les libellés seront de toute façon imparfait (bien souvent on trouve des bâtiments qui n'ont pas vraiment de noms, ou plusieurs noms, ou l'adresse comme nom, voir le nom comme adresse :/ ), inutile de perdre trop de temps là-dessus.

Ce n'est pas que je « n'étais pas très chaud » c'est surtout que c'est un énorme travail et un travail cmoplexe qui plus est (dieux savent combien certaines notices peuvent être obscures, voire même fausse parfois !). Et je me demandais si MnM est vraiment le meilleur outil. Ou plutôt si il n'y avait pas un gros travail de préparation à faire.

Peut-être y a-t-il quelque chose à faire pour commencer par matcher les notices IA correspondants à des notices PA (souvent ces notices IA ont un champs "protection MH" qui devrait permettre de les repérer facilement, reste ensuite à trouver l'alignement - pas facile mais déjà plus simple). Idem pour les notices dont le titre finit par "également sur commune de", je viens d'associer Special:Diff/738759954 mais je me dis que cela aurait sans doute pû être fait automatiquement (surtout qu'il arrive que dans ce cas, les identifiants se suivent PA14000040 et PA14000041 en l'occurrence).

Bonsoir, VIGNERON. Pourrais-je STP te contacter par courriel ?

Hi, VIGNERON. I do not know how it happened, could you please check the problem is fixed, please?

Regarding WLM, thank you for your kindness. I have a lot of questions but very few time to discuss now. For sure I will ask for your help soon! ;) Do you talk Italian, too?

Hi,

I guess this is a strange version of edit conflict but not sure what happened... I'll look into it.

For WLM, it could be later whenever you want, I'm quite available in daytime. Dispiace, parlo un pessimo italiano :(

It is happening something strange again: https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_deletions&oldid=prev&diff=729479204 o.O