User talk:Shonagon/Archive 1

Welcome to Wikidata, Shonagon!

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:

• Wikidata:About – About the project.
• Wikidata:Introduction – Another introduction to the project.
• Help:Contents – The main help portal for editing and using the site.
• Wikidata:Project chat – Discussions about the project.
• Wikidata: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, —Theopolisme 21:55, 24 December 2012 (UTC)

--—Theopolisme 21:55, 24 December 2012 (UTC)}}

Peinture à l'huile

Bonjour, j'ai annulé ta modification sur la Joconde [1]. L'élément pour la matériau est bien oil paint (Q296955), oil painting (Q174705) concerne la technique. --Zolo (talk) 06:55, 12 August 2013 (UTC)

Ca ne paraît pas évident mais l'enjeu va être surtout d'harmoniser. Oui oil painting (Q174705) désigne autant un matériau qu'une technique ; c'est courant en documentarisation sur les œuvres d'art où bien souvent il n'y a qu'un champ "matériau et technique" (par exemple sur la base Joconde) en raison notamment des nombreux cas ambigus où un matériau désigne aussi une technique. On remarque au passage que les articles de oil painting (Q174705) sur WP sont illustrés par une image de... La Joconde.

D'ailleurs c'est tellement pas évident que pour une trentaine d'œuvres utilisant oil paint (Q296955), il y en a quasiment 200 qui utilisent oil painting (Q174705) [edit : c'est d'ailleurs uniquement par souci d'harmonisation que la modification avait été faite sur Mona Lisa (Q12418)].

Difficile de trancher hors du contexte général de structuration des notices d'œuvres. Si une propriété technique est utilisée par ailleurs, oui certainement alors oil paint (Q296955) serait clairement approprié ; mais pour le moment je n'ai vu aucune propriété technique ni dans les recommandations ni dans les usages. Si au contraire l'usage reste à ne pas utliser de propriété technique spécifique et à la confondre avec matériau, comme ça se fait généralement ailleurs et actuellement sur wikidata, alors amha c'est oil painting (Q174705) qui conviendrait. Néanmoins il semble a priori que la solution que tu suggères est plus conforme à la sémantique des propriétés et serait dans l'absolu préférable.

Bref, n'étant pas au fait des évolutions prévues, je ne sais pas honnêtement quel est le meilleur choix pour des raisons pratiques et même si me rangerais volontiers derrière ton avis, cela ne relève pas en tout cas de l'évidence. Peut-être d'autres avis ?

En revanche on remarque qu'il y a une un souci de cohérence comme évoqué précédement. Que ce soit l'un ou l'autre, il conviendrait d'harmoniser. --Shonagon (talk) 10:38, 12 August 2013 (UTC)

L'article français porte à la fois sur le matériau et la technique, et pourrait sans doute aller dans n'importe lequel des deux éléments, mais dans pas mal de langues (anglais, allemand, espagnol...), il existe deux articles séparés, et la Joconde relève des deux.

En ce qui concerne la distinction plus générale technique / matériau. On peut effectivement créer deux propriétés -ce qui a sûrement des avantages et des inconvénients- ou bien élargir la propriété en "technique/matériaux", comme sur Commons. Mais si on a une seule propriété, je dirais qu'il faut privilégier le matériau sur la technique. "Matériau" est une propriété clairement définie, et on peut faire une liste complète des matériaux utilisés dans une oeuvre. Technique parait plus flou, et plus ouvert (par exemple "marbre" vs "sculpture au ciseau" + "haut-relief" etc.). Pour l'harmonisation, on devrait pouvoir passer un bot sans risque. --Zolo (talk) 11:52, 12 August 2013 (UTC)

Ok, va pour oil paint (Q296955) et les matériaux strictement matériels ; je tâcherai de poursuivre cette approche plus généralement. En effet au moins c'est propre, rigoureux, cohérent, pourra sans doute être plus utile et utlisable ; puis la technique pourra toujours être ajoutée ensuite. J'espère que la technique viendra à l'avenir car il y a des domaines comme la photographie, où là, au contraire de la peinture, la technique est une information documentaire bien plus importante que le matériau. Pour le bot je sais pas (encore) faire, je vais regarder. --Shonagon (talk) 12:25, 12 August 2013 (UTC)

Je ne sais pas non plus comment utiliser les bots, je crois que ce n'est pas trop compliqué, mais de toute façon on peut faire une demande à un dresseur. Je pense qu'il faudra un bot spécialisé dans ce genre de tâches de maintenance.

Pour créer une nouvelle propriété, on peut faire une proposition sur Wikidata:Property proposal/Creative work (le processus est un peu longuet). Il faudrait essayer de réfléchir à comment la propriété peut-être utilisé pour autre chose que des oeuvres d'arts (peut-être des objets manufacturés ou je sais pas). --Zolo (talk) 15:03, 12 August 2013 (UTC)

J'ai fait la demande sur Wikidata:Bot_requests#Fix_value_item_in_property. Autre chose : avec la propriété collection, je pense qu'il vaut mieux mettre le département du Louvre (du genre "département des peinture du Louvre) plutôt que juste "musée du Louvre" vu que c'est plus précis. Si on met la valeur la plus précise, on n'a pas besoin de la plus générale (même s'il faudra veiller à ce que les outils comprennent ce genre d'implications). --Zolo (talk) 07:33, 14 August 2013 (UTC)

Merci pour la demande.

Pour la question des collections, là en revanche je ne suis vraiment pas convaincu pas le fait de ne pas indiquer l'institution de conservation mais juste le regroupement au sein de cette institution. Cela risque d'être assez difficilement gérable en particulier pour les algos. C'est la logique de Commons, qui avec les catégories est arrivé à un niveau de complexité d'emboîtement qui rend théoriquement le système quasi-inexploitable pour les algos. Certes avec widitata et sa typologie stricte des entrées, cela paraît a priori moins difficile mais pour le moment ça semble bien téméraire de présupposer que cela fonctionnera.

Cela ne veut évidemment pas dire qu'il ne faudrait pas indiquer la donnée de la collection, mais ne pas s'y limiter, oui.

D'autre part il y a une dimension socioculturelle à la notion de collection. C'est ainsi que sont organisées les institutions de conservation, en particulier les importantes, en terme de gestion des collections, de logique documentaire et d'activités diverses. Mais cette logique est particulière, ce n'est presque jamais celle du public hors instituions, qu'il soit visiteur, développeur, curieux ou amateur. Couper ce lien direct et espérer que les algos pourront par inférence retrouver et restituer l'institution, est un pari risqué, une hypothèse incertaine sur l'avenir. C'est d'autant plus gênant que ces recherches d'inférences deviendraient une nécessité pour ne pas imposer une vision particulière, compréhensible que par les connaisseurs du domaine.

Amha, il est essentiel que le lien entre l'institution de conservation et l'œuvre puisse être fait directement. Et s'il ne devait y avoir qu'une donnée, entre l'institution de conservation et le sous-regroupement au sein de cette institution, ça serait assurément l'institution.

S'il s'avère que la collection comme sous-regroupement suffit et est facilement gérable -et il faut penser à toutes les réutilisations possibles de ces données- hé bien alors ça sera très simple de supprimer éventuellement, la donnée parente de l'institution. Actuellement pour les ‘œuvres’, indiquer institution et collection comme sous-regroupement, ne mange pas de pain, n'est pas redondant et surtout on est certain que cela sera utilisable facilement.

Si l'on regarde dans d'autres domaines, comme en géographie, alors même que les logiques d'emboîtements sont systématiques et partagées quasi-unanimement au niveau socioculturel, on retrouve aussi - par exemple avec les communes - au niveau d'un élément des indications directes sur les différents niveaux de regroupements et non pas juste le niveau supérieur en se disant que par inférence on pourra retrouver les autres. Ainsi une commune est rattachée à sa région, à son pays ou à son département (en France).

Bref, le plus sage est amha d’indiquer « département des peinture du Louvre » ET « musée du Louvre ». --Shonagon (talk) 11:13, 14 August 2013 (UTC)

Pour les divisions administratives, il semble qu'on ait plutôt tendance à n'en mettre qu'une (plus le pays), mais c'est vrai que ça peut poser des problèmes, surtout quand la hiérachie n'est pas très claire, et on que c'est peut-être plus sage d'en mettre trop que pas assez pour l'instant.

En fait, je me demande s'il y a définition précise de "collection". Par exemple lorsqu'un tableau est déposé par le Louvre dans un musée de Province, doit-on considérer qu'il fait partie des collections du Louvre ? A noter qu'il existe aussi location (P276) et owned by (P127) --Zolo (talk) 14:52, 14 August 2013 (UTC)

Ouh là là, merci Zolo ! Tu m'apprends plein de choses. En France, dans le code du patrimoine, il y a bien une définition de ce qu'est une collection : [2]. Oui une œuvre d'un musée en dépôt ailleurs fait encore partie juridiquement des collections du musée déposant. Comme tu le sous-entends, l'utilisation de la propriété collection comme élément de localisation poserait alors problème et n'est en effet pas une bonne solution.

La propriété location (P276) convient bien pour la localisation des œuvres et après une petite recherche, elle est déjà massivement utilisée pour cela. Dont acte.

J'avais cru que cette propriété servait exclusivement à des données géographiques physiques (exemple "salle 6") et qu'elle se rapportait donc seulement à des bâtiments et non à des institutions (exemple : une œuvre serait dans le lieu "Palais du Louvre" pas dans l'institution "musée du Louvre"). En fait non, l'usage massif sur wikidata, comme dans les bases patrimoniales, est de confondre le lieu de l'institution et l'institution ; c'est certainement bien plus commode ainsi et fait consenus.--Shonagon (talk) 17:33, 14 August 2013 (UTC)

En fait, j'ai tendance à penser qu'il serait mieux de séparer institution et bâtiment, comme c'est déjà fait pour le Louvre. Ca donnerait sans doute quelque chose de plus cohérent, et ça éviterait des ambiguités potentiel (par exemple la date de fondation est-elle bien celle de l'institution, pas celle de la construction du bâtiment), mais si besoin est, un bot devrait pouvoir changer ça plus tard. Il vaut sans doute mieux attendre que Wikidata ait grandi avant de se lancer sur cette voie. --Zolo (talk) 18:38, 14 August 2013 (UTC)

Après rebelotte pour les questions de niveaux d'ensembre. Indiquer la salle et/ou l'institution de conservation ?

Indiquer l'ensemble "vedette", c'est-à-dire le lieu qui fait référence socialement, et éventuellement encore mieux avec une donnée plus précise comme la salle, est sans doute plus que souhaitable. Après oui que la salle 6 serait dans l'emplacment "1er étage Denon" qui est lieu dans l'emplacement "Aile Denon" n'a certainement pas sa place au niveau de l'entrée œuvre.

Dans le cas de Mona Lisa (Q12418) on remarque que l'œuvre a pour location (P276) Salle des États (Q10375063) qui fait part of (P361) la Salle des États (Q10292830) et ça s'arrête là. En d'autres termes la localisation de La Joconde au Louvre même par inférences n'est pas faite. Bien que cela pourra rectifié, c'est, pour le moment, franchement absurde.--Shonagon (talk) 17:33, 14 August 2013 (UTC)

Oui je pensais à faire une création massive de salles du Louvre, mais je n'étais pas sûr de la meilleure marche à suivre, et puis j'ai un peu laissé tomber, il faudrait m'y remettre...--Zolo (talk) 18:38, 14 August 2013 (UTC)

Pouvoir identifier directement les œuvres selon un référent largement partagé socioculturellement est essentiel. De la même façon que les villes ont une indication de lieu avec en plus le pays, les œuvres patrimoniales devraient pouvoir être localisées directement dans leur "lieu vedette" de conservation. Cela est souhaitable également dans un soucis d'harmonisation ; l'immense majorité des œuvres n'ont et n'auront encore longtemps que le lieu vedette de conservation.

Quand on se penche sur les question de l'utlisation de ces données on ressent d'autant plus la nécessité de pouvoir simplement retrouver des données simples. À quoi servent ces données ? À plein de choses, bien au-delà de ce que je pourrais imagnier mais notamment à :

• être restituées sous forme d'informations dans un contexte éditorial tierce. Exemple : un cartel d'informations sur la Joconde dans une page WP.
• bientôt à être rêquetées. Exemple : pouvoir répondre au mieux à la question : Quelles œuvres sont conservées au Louvre ?

Les deux exemples sont volontairement banals, et un des enjeux est de pouvoir y répondre au mieux et facilement. Et là on comprend très bien l'intérêt d'avoir les données vedetes facilement accessibles plutôt que de faire le pari de l'inférence, d'autant plus risqué si les granularités de structuration documenaire ne sont pas harmonisées. Dans ces deux exemples, les données actuelles de l'entrée "La Joconde", si riche soit-elle, posent problème et ne permettent actuellement pas de retrouver ou requêter une donnée aussi simple que l'entité musée où l'œuvre est localisée.--Shonagon (talk) 17:33, 14 August 2013 (UTC)

Pour les requêtes, il serait effectivement plus facile d'expliciter "Salle 6 du Louvre" - "musée de Louvre" etc. sur la page de la Joconde. Mais pour les infoboxes, c'est plus compliqué, parce qu'il faut que le modèle soit capable de savoir quelle est la valeur "vedette". Il sera dans quelques temps possible de marquer certaines valeurs comme "préférées", mais je crois que l'idée était d'utiliser ça pour dire quelle valeur était la plus fiable, pas laquelle est la plus intéressante.

Il y a eu pas mal de discussions à propos de la nature "web sémantique/linked data" de Wikidata. Logiquement, Wikidata devrait suivre en partie conventions adoptées sur les autres sites du web sémantique, et cela aiderait à utiliser les techniques d'inférences répandues. Clairement le côté collaboratif et évolutif du projet ne facilite pas les choses, mais je pense qu'à terme, il sera indispensable de faire d'avoir des capacités d'inférence. Ca me parait partucilièrement clair avec depicts (P180). Si on fait un recherche de portrait de roi, il faudrait trouver les portraits de Louis XIV. Mais doit-on écrire sur chaque potrait de Louis XIV: "sujet représenté: Louis XIV - roi de France - roi - souverain - hommme ?" Outre le côté lourdingue, ça risque d'induire en erreur : ça peut laisser entendre qu'il y a plusieurs personnages représentés. --Zolo (talk) 18:38, 14 August 2013 (UTC)

Amha indiquer au niveau de la ressource les données "vedettes" est gage de qualité et de simplicité pour les (ré)-utilisations. [PS Pardon pour la longueur] --Shonagon (talk) 17:33, 14 August 2013 (UTC)

Merci pour le message, clairement, il reste encore beaucoup de travail à faire. Peut-être vaut-il mieux poursuivre les discussions sur Wikidata:Artworks task force, pour que tout le monde puisse participer :). --Zolo (talk) 18:38, 14 August 2013 (UTC)

Property:P18

P18 sert à indiquer l'illustration présente dans l'infobox. Si t'as coché CommonsMedia dans tes préférences, tu peux visualiser l'image en cliquant sur l'icone située à droite du nom du fichier. Exemple : Q3235403.

Quand tu viens d'ajouter un fichier, faut recharger la page pour que l'icone apparaisse. Pyb (talk) 00:42, 16 August 2013 (UTC)

Ah oui en effet, je vois, c'est bien pratique. Merci User talk:Pyb

Au passage je remarque que pour choisir une P18 sur wikidata il faut sytématiquement aller voir s'il n'y a pas meilleure version image que celle éventuelle de l'infobox sur une WP. Il arrive, souvent même sur les pages œuvres très anciennement crées, que le choix image soit aussi ancien alors que depuis une meilleures version est disponible sur Commons. Là aussi on voit l'intérêt de Wikidata qui va permettre de choisir une meilleure version sans avoir a rééditer toutes les pages de WP portant directement sur l'œuvre. --Shonagon (talk) 01:23, 16 August 2013 (UTC)

Plusieurs versions du même tableau

Il me semble qu'on a un problème sur Q3094657 : certaines informations (le sujet représenté) se réfèrent à toutes les versions de l'oeuvre, d'autres ne se réfèrent qu'à une des versions. En l'état, on ne sait pas que le numéro Joconde n'est valable que pour la version du Louvre. Le plus clair me parait de créer un élément pour chaque version, et de ne pas mettre les informations qui concernent les tableaux individuels que sur les éléments-tableau. depicts (P180) en revanche pourrait être utilisé dans les deux types d'éléments. Je peux changer ça ? (cc user:Poulpy)--Zolo (talk) 10:08, 16 August 2013 (UTC)

Finalement j'ai restreint l'élément à la première version, et créé deux autres pour les versions ultérieures. C'est peut-être plus simple comme ça, et puis c'est ce que fait Wikipédia en français (il faudrait réécrire l'article en anglais...). --~~

Oui dans le cas présent créer des entrée séparées paraît en effet la meilleure solution . Oui c'est un choix pas toujours facile avec les cas limites genre copies d'atelier, sculptures en plusieurs exemplaires, variantes de gravures...

Les nouveaux modèles documentaires, type FRBR, s'appuient sur la logique des objets conceptuels - qui est aussi celle de wikipédia mais pas forcément celle de WikiCommons. Une œuvre est alors d'abord considérée comme une idée qui peut avoir plusieurs matérialités ; exemple La Guerre des Gaules avec différentes versions, Melancholia de Duhrer, Bonaparte franchissant le Grand-Saint-Bernard de David.

On pourrait peut-être imaginer suivre une telle logique sur WD et avoir une entrée conceptuelle et ses matérialités, "Galerie de vues de la Rome antique : Série de peintures" avec les autres items s'y rapportant. Mais ça me semble lourd et dans l'état actuel inutilement complexe, les cas étant trop rares et la systématisation peu probable.

Bref tu as encore judiceusement levé un lièvre et encore sans doute fait au mieux :) . Merci ! --Shonagon (talk) 23:29, 18 August 2013 (UTC)

"type principal"

Bonjour, j'ai bloqué ton bot parce que P107 (P107) doit-être supprimée, et d'autres bots travaillent à l'enlever ;]. Il y a eu de longues discussions, notamment Wikidata:Requests for comment/Primary sorting property mais pour résumer, elles avaient tendance à s'imposer sournoisement comme une espèce de système de classement par défaut, ce qui posait pas mal de problèmes, surtout compte tenu du fait qu'elles ne correspondent pas aux grandes classes qui sembleraient les plus pertinentes pour l'origanisation de Wikidata. Pour l'instant, on fait avec juste instance of (P31) et subclass of (P279) qui semlent logiquement suffistantes et correspondent aux standards du web sémantique. Si cela pose des problèmes pratique, il est question de créer notre propre système, mais celui du GND posait des problèmes rédhibitoires ("personne" ne correspond pas exactement aux personnes au sens usuel, et les autres types sont trop vagues pour nos besoins). --Zolo (talk) 16:10, 1 November 2013 (UTC)

Bonjour Zolo,

Je comprends... même si à vrai dire, je regrette. La propriété P107 (P107) avec la valeur work (Q386724) est très largement utlisée, et reste pertinente et utile.

Sur le lot visé par le bot ~60%, l'ont déjà, ça aurait pu permettre de compléter et d'avoir un ensemble cohérent et lié. C'est dommage.

(Note : oui dans le futur, incertain, on pourra sans doute avoir un équivalent, au prix d'un système élaboré de classification et d'outils tout aussi élaborés ; on n'y est pas pour le moment et personnelement je reste dubitatif sur cette exclusivité d'approche, bien que ça ne m'empêche pas d'y contribuer.)

Avant de lancer le bot, j'avais regardé les discussions sur la P107 (P107). Les débats et "problèmes" soulevés ne portaient, me semble-t-il, pas sur la valeur work (Q386724). C'est pourquoi le bot a été lancé exclusivement vers des P107 (P107)/work (Q386724).

Mais j'avais pris soin de passer la Mona Lisa (Q12418), vu qu'il y a avait déjà eu conflit d'édition à ce sujet sur cet item.

Bref si tu n'es pas convaincu, le bot ne sera pas relancé pour éditer des P107 (P107)(œuvre ou autres) sauf contre-avis de la communauté.

Surtout je souhaiterais vraiment que la permission soit rendue au bot, en particulier pour publier des instance of (P31) que j'ai récupérées de DBPedia et affinées en local.

Enfin pour information j'ai décrit ma démarche par là : http://zone47.com/dozo/voyage-de-dbpedia-en-wikidata-a-bord-dun-bot

En te remerciant. --Shonagon (talk) 16:51, 1 November 2013 (UTC)

Oui, il sera peut-être nécessaire de récréer des grands "types" pour aider à la classification, mais ça parait préférable d'attendre de voir comment les choses se combinent. On a tout intérêt à essayer quelque chose de plus fin, quitte à se planter un peu. Au moins on verra mieux ce qui marche et ce qui ne marche pas, et il sera toujours temps d'ajouter quelque chose après (alors q'il rsique d'être un peu délicat d'enlever une propriété à partir du moment où Wikidata sera largement utilisé par d'autres sites). Pour la maintenance interne, de toute façon, les types GND sont bien trop vagues. Pour la valeur "oeuvre", le problème principal me parait être qu'il manque la distinction entre "work" et "edition" d'un texte, alors qu'il a été décidé qu'il fallait la faire au maximum sur Wikidata (voir Help:Sources). En tout cas, pour l'instant, p107 est en train d'être supprimé. Pour oeuvre, il n'a encore pas été décidé de ce qu'il fallait faire exactement et les bots se contentent de changer "p107: oeuvre" en "p31: oeuvre". Le principal problème concerne les textes. Pour les arts plastiques, je pense qu'on peut d'ores et déjà utiliser des types plus précis (peinture, sculpture). Si les choses sont bien structurées, et de toute façon il faut s'efforcer de bien structurer, il devrait être facile pour un bot d'ajouter une valeur plus générale par la suite. A ma connaissance, il n'existe pas encore d'outil permettant de vraiment visualiser l'arbre des types d'oeuvre. Mais on peut au moins avoir une liste sur http://208.80.153.172/wdq/?q=claim[107:618123]_AND_claim[31:(TREE[2221906][][279]).

Merci, pour le lien, ça a l'air intéressant, même si j'ai toujours la flemme de me mettre au bot (s'il faut faire un truc technique, je pense que je le ferais plutôt du côté des infobox sur Wikipédia :).

user:Marsupium a retrouvé le lien vers l'arbre des sous-classes : http://tools.wmflabs.org/wikidata-todo/tree.html?q=838948&rp=279&lang=fr Il y a du travail mais on devrait pouvoir s'en sortir. Voir aussi la conversation liée : Wikidata_talk:Artworks_task_force/Item_structure#Object_type. Après, lorsqu'on veut retrouver tous les éléments qui sont des oeuvres, on pourra trouver diverses solutions. On peut par exemple imaginer un bot qui mémorise la liste des sous-classes d'oeuvre pour les requêtes. --Zolo (talk) 15:47, 2 November 2013 (UTC)

Merci Zolo ! Je contribue aussi à cette liste en ajoutant des sous-classes d'œuvre d'art (de façon empririque à partir des données récoltées sur DBpedia). Justement je pensais que cela pourrait être utile pour récupérér les items "œuvres d'art" à partir de la instance of (P31). Oui comme tu le dis, on devra pouvoir requêter par inférence pour avoir les items des sous-classes ou alors requêter directement les sous-classes en les aggrégeant ; rien d'insurmontable. Ça prend forme. J'espère qu'il sera possible de requêter sans trop de difficultés mais vu comme le projet avance sur de bons rails, il y a de quoi être confiant.

Inférences

Ca a l'air de marcher pas mal :

• sculptures (instances directs)
• sculptures (avec sous-classes) (query)

Bien-sûr, ça demande pas mal de réflexion dans les détails, mais ça me parait quand même plus gérable que d'ajouter des dizaines de déclarations redondantes dans chaque élément. --Zolo (talk) 08:09, 14 November 2013 (UTC)

Classification des œuvre d'art

Excuse-moi! Je pense que l'état dernier de la discussion sur la classification des œuvre d'art sous Wikidata talk:WikiProject Visual arts/Item structure#Object type avec Zolo était de l'utiliser la classification de Art & Architecture Thesaurus (Q611299). Cf. "Hierarchical Position" sous AAT record 300178235 pour une classification systématique de polyptyques. En fait, il y a des polyptyques sans aucun panneau peint qui se composent que de la sculpture … J'ai commoncee de construire une classification systématique qui suit Art & Architecture Thesaurus (Q611299) sous Wikidata:WikiProject Visual arts/AAT Objects Facet Mapping. J'espère que la page est compréhensible … C'est déjà noté que polyptych (Q1278452) doit devenir subclass of (P279) de "visual work", mais je crois que work of art (Q838948) n'est pas une bonne choix. Son arbre de sous-classes [3] est trop divers … Excuse mon français mauvais, stp! Cordialement, --Marsupium (talk) 15:05, 1 January 2014 (UTC)

Hi Marsupium

Thanks for your post and for writing it in french, and in good french. It's ok to remove subclass of (P279)painting (Q3305213) from polyptych (Q1278452) ; you're right. Unfortunately the inference link with artwork entity was broken and it was no more possible to request those type of works ; so I hade subclass of (P279) work of art (Q838948). Maybe "visual art" instead of "artwork" could be better but this item does not currently exist. About the implentation of Art & Architecture Thesaurus, I have to admit that if I agree with the necessity of classifcation I am very skeptical for a strong and unique classification especially on visual arts. At this phase of the project I prefer to focus on putting a lot of data, especially in visual arts in which the lack is still big, and in making them relievable for reuse.

[...] In short, my decision is to not prioritize strong classification. Instead I will prioritize more data types, ranks, querying, and result formats. What we will deliver in Wikidata is a trade-off anyway, and it means prioritizing. Strong classification can be added later, together with other inferences (or syllogisms), once we start to understand how Wikidata works as a socio-technical system. [...]
—Denny Vrandečić http://blog.wikimedia.de/2013/09/12/a-categorical-imperative/

I do not think we need to always follow AAT classification exactly (we can add other subclasses, split items etc.) but I would think that when something in Wikidata appears to be incompatible with the AAT, we should look at it carefully, first because AAT is rather well thought out and relatively mature while Wikidata is still in infancy, and also because using AAT classification insures that we use precisely defined terms, which is not very easy to do on our own, as the meaning of words can vary, and the issue is made even more tricky by the multilinguality of Wikidata. -Zolo (talk) 14:51, 10 January 2014 (UTC)

Thanks a lot for your comments. I think much of what you said is right. We cannot simply adopt the AAT without changes (I have pointed out some special reasons here). It is of course not easy to make good classifications. It will take some while. That is clear. And I know Denny's blogpost and I really like it and agree with him. However, there are not big differences between subclass of (P279) and some other properties. To say it more precisely: <objectA> <subclass of> <things with valueX for propertyM>. and <objectA> <propertyM> <valueX>. are semantically equivalent. Anyway, the most important use of classification at the current state of Wikidata is group items for our work, so I am sorry I broke the inference you mentioned above. I am looking forward to end my Wikidata break (which I interrupt today) and rejoin you in spring! Cheers, --Marsupium (talk) 13:46, 19 January 2014 (UTC)

pywikibot

Salut,

Voici mon code pour ajouter une date. Je n'ai pas besoin d'insérer la date sous le format bizarre de Wikidata.

# -*- coding: utf-8  -*-
import pywikibot
site = pywikibot.Site("wikidata", "wikidata")
repo = site.data_repository()
item = pywikibot.ItemPage(repo, u"Q4115189")

DateDeces = pywikibot.Claim(repo, u'P570')
time = pywikibot.WbTime(year=1890, month=11, day=03, precision='day')
DateDeces.setTarget(time)
# Check if the property isn't already set
if DateDeces.getID() in item.get().get('claims'):
    pywikibot.output(
        u'A claim for %s already exists. Skipping'
        % DateDeces.getID())
else:
    item.addClaim(DateDeces)

Pyb (talk) 13:11, 19 March 2014 (UTC)

Génial, merci ! Grand Merci même. Et le format bizarre c'est juste la norme ISO 8601 ; c'est chouette cette souplesse d'édition. --Shonagon (talk) 21:10, 19 March 2014 (UTC)

Upper Rhenish Master (Q1567352)

Bonjour Shonagon, ton bot a mis inception (P571) pour le peintre. Je l'ai renversé ainsi que instance of (P31) work of art (Q838948). Cordialement --Oursana (talk) 01:53, 26 April 2014 (UTC)

Update gallery

Hi Shonagon, you might have noticed I started importing all Rijksmuseum (Q190804) paintings. I also made a second bot to automagically add the images from Commons. Could you update http://www.zone47.com/crotos/?p276=190804&mode=1 so I can see the progress of this work? I think I imported about 2000 paintings now. Multichill (talk) 13:51, 8 July 2014 (UTC)

Great Multichill! I'm on holidays and the server for updates is temporaly hosted by another wikimedian. It has worked two days ago and obviously there is problem now. We will try to fix it tomorrow.

For information concerning the Mauritshuis collection, images from this page of Commons https://commons.wikimedia.org/wiki/Mauritshuis have been indicated in Wikidata. But I saw that some images of Commons are still missing so I'm triyng to complete with lost paintings in Commons. Shonagon (talk) 01:35, 9 July 2014 (UTC)

Hi Shonagon! While supplying Wikidata items with Commons images you might consider to set the – unfortunately not yet documented – "Wikidata" parameter of c:Template:Artwork for the Commons files with the template if that is not too much work. I assume that could save us much work later while harmonising Commons and Wikidata. Cheers, --Marsupium (talk) 11:58, 9 July 2014 (UTC)

Hi Marsupium. Thanks for the idea, I didn't know this Commons property and I put it found for new Commons correspondance fot Mauritshuis artworks, even if I think it could be a good job for a bot.

@Multichill, update has been done for Crotos, but there is still a problem for daily update (we suppose it's an hardware bug with the Raspberry Pi with witch updates are done). Anyway I continue with the Mauristhuis, now to complete the missing creator (P170). Shonagon (talk) 20:44, 12 July 2014 (UTC)

Questions sur Crotos

Bonjour,

J'approfondi ma connaissance de Wikidata et dans le même temps, je commence à découvrir Crotos. Je travaille notamment sur les œuvres que l’on trouve à Rennes au Museum of Brittany (Q3329701) et au Museum of Fine Arts of Rennes (Q3098373). Pour le moment, j'ai crée ou amélioré :

• Barde à la lyre (Q17280144) et coin of Anne of Brittany (Q17280208) pour le premier
• The Tiger Hunt (Q544488), The Newborn (Q14940732) et Perseus Freeing Andromeda (Q17315193) pour le second

Or coin of Anne of Brittany (Q17280208) et The Newborn (Q14940732) n’apparaissent pas dans Crotos (respectivement [4] et [5]).

La première est une pièce de monnaie, ce « format » ne serait-il pas reconnu comme une œuvre ? Le Museum of Brittany (Q3329701) contient un grand nombre d’objets inhabituels pour un musée (des affiches, des morceaux de bois/pierres, des costumes bretons, des objets de la vie quotidienne, etc. voir ici : Commons:Category:Collections of the Musée de Bretagne pour avoir un aperçu), j'espère qu’ils pourront tout de même remonter dans Crotos.

Le second est un tableau tout ce qu’il y a de plus classique. Aurais-je oublié de mettre une affirmation ? (il ne me semble pas mais c'est toujours possible)

Si tu as des questions/commentaires/suggestions/conseils, je suis ouvert et disponible.

Cdlt, VIGNERON (talk) 10:14, 12 July 2014 (UTC)

Hello VIGNERON

Chouette. De mon côté je contribue en ce moment sur les collections du Mauritshuis.

Que The Newborn (Q14940732) n'apparaisse pas dans Crotos, m'a pas mal intrigué. Après vérification, il semblerait s'agir d'un bug aléatoire qui se produit parfois lors de la compilation. En fait l'œuvre était bien présente dans les précédentes versions (et elle y est toujours mais les propriétés n'ont pas été enregistrées). J'avais constaté le bug avant, mais dans une proportion tellement faible (0 généralement parfois 2-3 items sur plus de 10000) que je ne m'en étais pas plus préoccupé. En ce moment je suis en vacances et n'ai pas accès à la machine, Euphéné, qui semble avoir des soucis récurrents, au point qu'il faut régulièrement la redémarrer. Si à mon retour le problème persiste, je regarderais plus en détail et pourrais au moins mettre en place un système de notification si ça se produit à nouveau.

Que coin of Anne of Brittany (Q17280208) n'apparaisse pas dans Crotos est en revanche volontaire.

>> La première est une pièce de monnaie, ce « format » ne serait-il pas reconnu comme une œuvre ?

Oui c'est exactement cela.

Pour Crotos, il est nécessaire de définir un ensemble d'items qui va être utilisé (téléchargé, compilé, requêté). Et c'est un choix loin d'être simple. Dans le cas présent, on pourrait distinguer deux approches :

- les items appartenant à une collection de musée

La démarche permet de retrouver des œuvres au sens socio-culturel généralement admis. Mais peut-être n'a-t-on pas envie de mettre tout ce qu'il y a dans les musées : Crotos n'est pas centré sur les musées mais sur l'art visuel (visual artwork). En outre, si le musée est une institution privilégiée pour ce type d’œuvres, il n’en n'est pas exclusif pour autant ; il y a aussi d’autres instances de conservation, les collections particulières, les bibliothèques, d’autres organisations, l'espace public... Ainsi l'approche institutionnelle ne recouperait pas tout le périmètre visé et comprendrait en outre des objets pas nécessairement désirés.

C'est donc bien une limite éditoriale de Crotos, dont l'approche reste plutôt académique sur la notion d'œuvre. Par ailleurs une approche centrée musée (comme peut l'avoir le catalogue Joconde) peut être en effet autrement intéressante. À moins qu'un autre projet prenne cette approche, un fork de Crotos centrée Musées est possible à mettre en place. À réfléchir ; si ça t'intéresse on peut voir cela ensemble.

- les items correspondant à un ou plusieurs types d'item instance of (P31)

Là ça rejoint ta question sur ce qu'est une œuvre et c'est l'approche choisie pour Crotos. Il faut comprendre que Wikidata ne peut apporter qu'une réponse insatisfaisante à cette approche et qu'il en sera toujours ainsi (cf l'article très éclairant de Denny Vrandečić, A categorical imperative? http://blog.wikimedia.de/2013/09/12/a-categorical-imperative/ ).

Wikidata a bien une entité œuvre d'art work of art (Q838948) ; un rapide coup d'œil sur les actuellement ~5900 sous-classes http://tools.wmflabs.org/wikidata-todo/autolist.html?q=claim[279:%28tree[838948][][279]%29]&lang=fr laisse immédiatement comprendre que cela comprend un très vaste champ d'œuvres inexploitable en l'état pour Crotos ou alors ce ne plus le même projet.

On pourrait s'intéresser à une sous-classe particulière comme "œuvre d'art visuel" même si l'entité n'existe pas encore. Mais vraisemblablement le consensus ne sera jamais possible, en raison notamment du fait que ce sont les contextes de restitution qui souvent tendent à définir ce type de catégorisation culturelle, exactement comme tu suggères non sans raison d'intégrer d'autres types parce qu'ils sont présents dans un musée. En restant dans cette approche d ’ « art visuel » on pourrait raisonnablement y inclure d’autres types comme par exemple les robes de créateur.

Au final, comme le suggère Denny Vrandečić cette catégorisation en vue d'une réutilisation précise va se faire hors de wikidata. C'est pour ça que personnellement si je participe un peu à la classification de wikidata, j'ai aussi bien conscience que certains nœuds, resteront toujours des nœuds ; on aura un consensus de contributeurs à un moment donné mais il sera toujours fluctuant et culturellement relatif et discutable. Étant donné l'ambition universelle du projet Wikidata, la catégorisation ne saurait être unique, et elle sera en partie externe et plurielle. Et c'est bien à cette catégorisation externe, que je me suis consacré en définissant une "matrice" de ce qui constitue *pour moi* une œuvre d'art visuel. Elle correspond grosso modo aux types listés dans les gadgets wikidata de la task force Visual Arts, https://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Tools. On y trouve les types académiques plus quelques autres. coin (Q41207) me tenterait bien ; avec l'item que tu indiques cela correspond plutôt à l'approche éditoriale globale. Néanmoins ce type pose encore problème car il regroupe autant des expressions (des matérialités) de monnaies que des unités monétaires conceptuelles (le penny, la pièce de 1 centime d'euro) qui peuvent avoir plusieurs matérialités différentes, (voir la liste des items l’ayant en instance of (P31) http://tools.wmflabs.org/wikidata-todo/autolist.html?q=claim[31:%28tree[41207][][279]%29]&lang=fr ) et qui ne correspondent clairement pas au périmètre éditorial du projet. J'imagine que le problème est connu dans le domaine des monnaies et qu'une organisation des connaissances finira dans wikidata par faire un distinguo facilitant la réutilisation (comme c'est en phase d'être le cas, pour les livres et leurs éditions).

Il pourrait être envisagé une approche plus globale et sortir même de la notion d'œuvre pour une autre notion plus neutre d'objets, à laquelle on adjoindrait des filtres pour que l'utilisateur délimite lui-même ses champs d'exploration. Ça fait envie et ça serait un projet, mené à bien, extraodinnaire.

Cependant honnêtement, personnellement je n'en ai pas les compétences ni techniques, ni même de conception. Crotos, qui n'est qu'une facette de Wikidata, a été pensé pour être simple et cohérent, donc réducteur, mais aussi utilisable (si on connait le domaine on trouve et on s'y retrouve ; ce qui est bien difficile avec de très gros volumes) et son périmètre restreint correspond aussi à la taille de ce que je peux faire. Alors oui, mille fois oui, il y a plein d'autres choses à faire, différentes et sans doute mieux… ce qui n'empêche pas d'améliorer l'existant et d'être un peu moins borné.

Alors les affiches oui, elles y sont déjà. Pour les costumes j'aimerais bien ; à l'origine j'avais prévu les robes de créateur mais comme il n'y avait pas d'images libres (voir les 34 items en p31 http://tools.wmflabs.org/reasonator/?q=Q200539 ), j'avais laissé tomber. Toutefois comme pour les exemplaires de pièces de monnaie il y aurait sans doute une intégration pertinente à faire dans Crotos. En revanche pour les "objets de la vie quotidienne", cela me semble beaucoup trop vaste pour être gérable.

Enfin, il faut préciser aussi que pour Crotos il va y avoir un souci de volume, et que l'architecture devra être bientôt revue. C’est aussi sous cette contrainte, que le périmètre est réduit.

Il est possible que dans les prochains mois je fasse une refonte. Alors si tu as remarques, critiques, avis ou suggestions, n'hésite pas. C'est aujourd'hui plutôt un outil d'aperçu et d'aide à la contribution et si ça peut être utile, tant mieux.

Bon et sinon il est super le barde . Merci ! :) Bien à toi Shonagon (talk) 12:20, 13 July 2014 (UTC)

Bonjour,

Merci pour ces réponses et merci déjà pour tout ce que fais Crotos.

Je vais relire cela plus attentivement mais déjà j’ai une première remarque, pour la monnaie, il me semble qu'il devrait y avoir 3 niveaux : le concept global monnaie − l’euro −, le concept semi-global pièce de monnaie/valeur − la pièce de 1 euro − et le concept pièce de monnaie / exemplaire unique − la pièce de 1 euro de mon porte monnaie − (un peu comme les 4 niveaux de la norme/modélisation FRBR utilisée par la Wikidata:Books task force : œuvre, expression/manifestation, item).

Cdlt, VIGNERON (talk) 10:17, 14 July 2014 (UTC)

(incruste). La distinction entre les niveaux de signification de "est une pièce de monnaie" se fait par subclass of (P279) et instance of (P31). En gros p279 veut dire "type particulier de" et p31 "exemplaire unique de". Donc la pièce de 2 € est une sous-classe de pièce alors que coin of Anne of Brittany (Q17280208) est p31 pièce.

Concernant le choix des éléments à mettre sur Crotos, il n'y a sans doute pas de solution idéale mais le filtre suivant me paraitrait intuitivement sensé, quoique logiquement un peu brinquebalant : "doit être un objet physique travaillé par un humain et soit être une oeuvre d'art soit faire partie de la collection d'une institution." A l'heure actuelle ça donne environ 10 000 éléments [6]. --Zolo (talk) 16:53, 14 July 2014 (UTC)

Fusions

Bonjour Shonagon. Lorsqu'il y a des doublons d'éléments, on peut maintenance créer des redirections plutôt que de supprimer un élément. Cela a plusieurs avantages : d'une part tout le monde peut le faire, pas seulement les administrateurs (cliquer sur "créer une redirection dans merge.js), et d'autre part si pour une raison ou pour une autre, l'élément est utilisé sur un site externe, la redirection casse moins de choses qu'une suppression. --Zolo (talk) 07:25, 24 October 2014 (UTC)

Merci Zolo pour l'information. En fait j'ai toujours cru que cela fonctionait ainsi. En effet une suppression sans redirection suite à une fusion peut casser un lien. Quand je testais les items vidés après fusion, cela me semblait faire toujours redirection vers l'élément principal de fusion. Mais quelque chose m'avait échappé. En y retournant, bien après la fusion, je me rends compte que les items sont supprimés comme demandé dans le merge.js en même temps qu'une redirection. En fait ce sont les propriétés/valeur que je croyais supprimer. Je ferai attention à l'avenir en gardant en effet les redirections. Merci Shonagon (talk) 23:49, 26 October 2014 (UTC)

Backlinks

HI Shonagon, I noticed at Montmartre: mills and vegetable gardens (Q18689454) that you're importing artworks from Commons. Nice! You should add a backlink on the file (example). Makes it also easier for others to add even more information from Commons to the item here after you're done with the initial import. Multichill (talk) 21:20, 30 December 2014 (UTC)

Thanks for the information. Zolo has alredy talked to me about that and I added formelry some Qitem on Commons files. It will be surely easier to add this information automatically when Wikibase will be implemented on Commons. For now, we have backlinks -not perfect but automatic- on Commons with global usage. Shonagon (talk) 18:56, 1 January 2015 (UTC)

That's no proper replacement. It just indicates that an image is in use. It's pretty straightforward to, for example isn't very difficult to do. Just look for "{{Artwork" and replace it with "{{Artwork\n|wikidata=Q<your Q number" and you have a backlink. Multichill (talk) 20:01, 1 January 2015 (UTC)

Titres d'œuvres avec minuscules

Bonjour. je remarque que tu as changé plusieurs titres de peintures en remplaçant les majusculs initiales par des minuscules. C'est assez étonnant car l'usage de mettre une majuscule sur la lettre initiale d'un titre d'œuvre est très largement répandu, https://fr.wikipedia.org/wiki/Discussion_Wikip%C3%A9dia:Conventions_typographiques/Marche_des_titres , et adopté par tous les catalogues d'institutions que j'ai pu lire. À dire vrai même je n'ai aucune contre-exemple en tête, sauf les modification que tu viens de faire. Peut-être s'agit-il d'une erreur car il est vrai que pour de nombreux items de Wikidata il convient d'abaisser en minuscule la majuscule initiale du libellé, généralement provenant du titre de la page Wikipédia ; je le fais moi-même très souvent. Mais là, j'avoue je ne comprends pas et peut-être pourrais-tu éclairer ma lanterne. Bien à toi. Shonagon (talk) 11:23, 29 January 2015 (UTC)

Bonjour, désolé c'est une erreur de ma part. J'utilise l'outil autolist pour chercher des éléments qui commencent par un nom commun pour le mettre en minuscule. Desfois, je renomme un peu vite, mécaniquement sans top lire. Merci en tout cas de l'avoir remarqué. Cordialement, Gzen92 (talk) 11:36, 29 January 2015 (UTC)

Et ça continue... https://www.wikidata.org/w/index.php?title=Q18602490&diff=192041028&oldid=178950268 https://www.wikidata.org/w/index.php?title=Q18602444&diff=192041022&oldid=185895157 je remarque que d'autres t'ont signalé également ce type d'erreurs. Pardon mais il n'est vraiment pas acceptable de faire autant de mauvaises corrections sur des items déjà édités ; ça frise le vandalisme. C'est d'autant plus incompréhensible qu'il paraît évident qu'un libellé comme "Cimetière d'un cloître sous la neige" est un titre d'œuvre et cela dénote un manque manifeste d'attention à l'édition des données, là où justement d'autres ont largement pris la peine de bien les éditer. S'il-te-plaît fais l'effort de vérifier avant de modifier ou arrête. Merci Shonagon (talk) 16:05, 29 January 2015 (UTC)

Mille excuses, je vais revoir mon mode de fonctionnement, je pense qu'après la génération d'une liste via autolist, je vais faire un premier tri avec les libellés qui s'y affichent et ralentir la cadence, ce sera plus long pour moi mais plus juste. Gzen92 (talk) 09:21, 30 January 2015 (UTC)

Merci Gzen92 ! Au demeurant, le passage des initiales de libellés en minuscules est encore un vaste chantier et c'est chouette de contribuer à cette tâche fort utile au projet (faut juste pas être en mode bulldozer). Bien à toi Shonagon (talk) 09:29, 30 January 2015 (UTC)

Oui il y a parfois plus de paramètres à prendre en compte qu'on l'on ne croit sur Wikidata. Si ta priorité est la mise en forme des libellés affichés sur Wikipédia, tu peux utiliser fr:Catégorie:Page utilisant des données de Wikidata à traduire. Autre petite note : lorsque le libellé est sous la forme "Panthéon (Paris)", tu peux enlever le contenu de la parenthèse, qui n'a pas besoin d'être affiché dans les articles (avec là aussi quelques exceptions). -Zolo (talk) 12:20, 30 January 2015 (UTC)

Collection / inventory number

Hi Shonagon, if you import paintings from Commons could you see if you can also import the inventory number? That would save me quite a bit of work. It's quite messy so it won't always work but with paintings like A View near Volterra (Q18177946) you should be able to extract it from File:A View near Volterra-1838-Jean-Baptiste-Camille Corot.jpg and add it. By bot uses the combination of collection and inventory number to prevent duplicate items and to be able to update existing items. Thanks in advance, Multichill (talk) 12:07, 20 June 2015 (UTC)

Yes Multichill. It was a massive import of Corot's paintings (♥) not from Commons but from French Wikipedia and there was no acces numbers in the dataset. The irony is that I added the metadata on Commons file. If an access number is an essential element of ifentification especially in a GLAM approch, creator, title, date of creation, collection and image are others elements of identification and those where indicated. By the way with fantastics tools made by Poulpy, Joconde tool and Commons -> Wikidata, we can now provide massive creations with significant level of identification and description. Besides that, for a GLAM approch of visual artworks on Wikidata, I created last week a tool to have some statistics on collections http://www.zone47.com/crotos/lab/collections . Best regards. Shonagon (talk) 22:00, 21 June 2015 (UTC)

Hi, yes, made User:Multichill/Corot to get an easy overview. Looks really good! Amir grabbed some of the id's from Commons so one way or another they'll end up here. Those two tools look fantastic, now I understand how you guys have been importing things :-) The collections overview is really nice, much better than my crude attempt at Wikidata:WikiProject sum of all paintings/Top collections! When was it last updated? Maybe you could include a small updated date somewhere? If you update it now you'll notice I added quite a few paintings this weekend (Metropolitan Museum of Art (Q160236), National Gallery of Art (Q214867), J. Paul Getty Museum (Q731126) & Fine Arts Museums of San Francisco (Q1416890)). I'm probably adding more collections over the next couple of weeks. I'm working my way down on en:List of most visited art museums in the world for the US, probably doing Art Institute of Chicago (Q239303) next. I might do a small excursion to Australia or back to the Netherlands. Let's see what happens. Any suggestion for a collection I should focus on? Keep up the good work! Multichill (talk) 19:58, 22 June 2015 (UTC)

Oh yes! It's wonderful. Thanks Multichill ! The collection overview is incomplete and partially biased by Crotos ; it was just to have an idea and a good suprise to see that the quantity and quality have been so much improved everywhere. Some small collections are very well documented and big ones have in minimum good informations of identification and often more. I'm currently on the musée du Louvre with corrections on classifications in Commons and creating items on Wikidata. Occasionally, I created artworks of a creators or subjects, with the Commons->Wikidata tool. And yes that's the tool we use a lot now. The import of Corot's paintings would have been really better with it. Nice to see you travelling over the world and bringing back all these wonders :). It's one of big pleasure on this project, to discover new collections with great artworks. Recently I continue imports on Tretyakov Gallery and I saw that there are still great artworks collections in East Europe, surely like in others parts of the world, that are waiting to be highlighted. Best regards Shonagon (talk) 23:07, 22 June 2015 (UTC)

format des ISNI (P213)

Salut ! Juste pour te dire que, sur Wikidata, les ISNI sont formates avec un espace entre chaque groupe de 4 caracteres comme "1234 1234 1234 123X". Ne t'en fait pas trop pour ceux deja importes, je crois qu'un bot passe derriere les modifs recentes pour corriger ce genre de choses. Merci pour ton bot ! Tpt (talk) 16:15, 14 July 2015 (UTC)

Merci du signalement Tpt ! Le script a été modifié pour être cohérent avec la forme utilisée dans Wikidata. Bien à toi --Shonagon (talk) 16:58, 14 July 2015 (UTC)

Re: https://www.wikidata.org/w/index.php?title=Property:P137&diff=prev&oldid=222871838

Hmm...yes, I suspect this is a problem of language. The two properties are indeed inverses; if item A has operator B, then B has A as an item operated. It is usually more natural to say that "B operates A" or "B operated A", but these constructions entail a statement about whether the relationship is active or not; the label "item operated" is generic. The inverse property will often be absent, as operators generally operate many items, which may not all be significant. Examples:

• Vehicle: Q25173 has operator Q320466 / Q320466 has item operated Q25173 (among others)
• Facility: Q46280 has operator Q794563 / Q794563 has item operated Q46280 (among others)
• Service: Q860447 has operator Q570755 / Q570755 has item operated Q860447 (among others)

Swpb (talk) 18:30, 14 July 2015 (UTC)

Unicode character (P487) en série

Salut,

Je vois que tu as ajouté tout un tas de Unicode character (P487) sur Moon (Q405) mais du coup, cela contrevient à une contrainte de ladite propriété, cf. Wikidata:Database reports/Constraint violations/P487. Je te laisse voir quoi faire (retirer le doublon et déclarer une exception).

Cdlt, VIGNERON (talk) 16:12, 27 July 2015 (UTC)

Hello VIGNERON ! Il s'avère de façon assez surprenante qu'il n'y a aucun caractère Unicode désignant seulement l'objet Lune (à la différence de ☿,♀,♁,♂,♃,♄,♅,♆) mais seulemet des caractères sur ses phases, dont certaines ont déjà leur propre item (exemple full moon (Q104641)) et donc leur(s) propre(s) caractère(s) unicode (premier et dernier quartier de Lune ont chacun 2 caractères Unicode), sans parler des versions avec visage. Bref, j'ai tout viré ; d'autres feront sans doute mieux et peut-être qu'un jour un caractère Unicode strictement "Lune" sortira. Bien à toi. --Shonagon (talk) 23:30, 29 July 2015 (UTC)

Salut,

Oui, je sais douloureusement bien qu'il n'y a aucun caractère spécifique à la Lune de façon générale (pour le moment et sans doute pour longtemps vu qu'il n'existe pas un symbole unique que ce soit dans ou hors d'Unicode).

Du coup, je ne sais pas trop comment faire. Sur le projet Astronomie, j'ai fait une proposition pour ne pas indiquer le caractère Unicode sur l'élément de l'objet astronomique mais sur l'élément du symbole dudit objet. Cela simplifie un peu la structure mais dans le cas de la Lune, cela ne fait que repousser le problème. Je pense que la seule solution à peu près correcte sera de déclarer une exception (comme je l'ai fait pour heart (Q826930) et heart (Q3419242).

Cdlt, VIGNERON (talk) 07:04, 30 July 2015 (UTC)

First names data?

Bonjour Shonagon,

A regarder les contributions de ton bot, je vois que tu partages pas mal de données de la BnF. Parmis ces données, serait-ce possible de rajouter des informations sur les prénoms des personnes (P735)? En fonction de ce qui disponible, je peux essayer de voir la meilleure manière de les intégrer, p.e. comme ceci ou en créant des prénoms manquants (liste actuelle). --- Jura 14:38, 12 October 2015 (UTC)

Bonjour Jura. Oui, c'est une très bonne idée. On pourrait même ajouter family name (P734) qui est souvent renseigné avec foaf:familyName.

Dans l'Endpoint SparQL de data.bnf.fr on peut retrouver (et exporter) ces données avec une requête du type :

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?auteur ?prenom ?nom

WHERE {

OPTIONAL {

?auteur foaf:givenName ?prenom.

}

OPTIONAL {

?auteur foaf:familyName ?nom.

}

}

LIMIT 1000

Un rapide coup d'œil sur tous les résultats montre qu'il conviendrait, comme d'habitude, de filtrer les données avant publication, même si dans l'ensemble, il n'y a vraiment pas trop de bruit.

La contribution en cours devrait être assez longue, je l'ajoute dans la pile des choses à faire après. Si cela te dit, tu peux bien sûr lancer un bot pour réutiliser ces données et si je peux peut-être être utile à ce sujet, n'hésite pas à me solliciter. Bien à toi. --Shonagon (talk) 18:20, 12 October 2015 (UTC)

La principale différence est peut-être que deux prénoms font deux entrées sur Wikidata.

J'imagine que ton bot tournera encore pour un moment. Si besoin, tu pourrais lancer un deuxième en parallèle. Je pense que l'approche choisie fonctionnerait également pour les prénoms (création des déclarations manquantes sur les personnes et ajout d'une référence aux déclarations).

Si tu veux, je peux créer les items des prénoms manquants. Pour le faire, un fichier avec nom et fréquences (total, hommes, femmes) serait utile.

Le problème des noms de famille, c'est que ce n'est pas encore très cohérent sur Wikidata. Si on en rajoute, ça risque de compliquer. --- Jura 12:14, 13 October 2015 (UTC)

Bonjour Jura. Pour le deuxième bot en parallèle je ne ne vais pas me lancer tout de suite, histoire de ne pas trop surcharger. Entendu pour les noms de famille, c'est noté. Pour les prénoms, oui je devrais pouvoir sortir une liste de prénoms dédoublonnés et avoir une proposition d'alignement avec des éléments Wikidata dont le libellé en français correspond et donc aussi une liste de prénoms sans éléments Wikidata avec le même libellé en français. Je tâche de faire cela un soir de cette semaine. Bien à toi. --Shonagon (talk) 18:00, 13 October 2015 (UTC)

Pas de souci. Au gré des dates rajoutées par le bot, on a découvert des nouveaux doublons sur Database reports/identical birth and death dates.

Pour la partie statistique, ça serait intéressant d'avoir une liste comme celle-ci, si possible séparée par sexe et par lien avec la France (oui - autres). --- Jura 10:27, 22 October 2015 (UTC)

Bonjour Jura. Pardon pour le retard mais je n'avais pas oublié. J'ai fait une extraction des prénoms indiqués comme tels dans data.bnf ; le résultat est téléchargeable à cette adresse : http://zone47.com/t/prenoms_data_bnf.zip avec un dossier zippé (33 Mo) contenant les données au format csv et xslx. Deux tableaux l'un avec tous les prénoms et toutes les personnes (_complet) , l'autre avec tous les prénoms et un exemple pour chaque prénom (_exemple). À chaque prénom est associé une entrée de data.bnf avec un nom, et quand les données respectives étaient renseignées, le genre et le pays associé à la personne. Un aperçu rapide sur les tableaux permet de se rendre compte qu'il y a beaucoup de bruit et que les données ne sont vraiment pas directement exploitables en bloc et demanderaient un très gros travail de réédition. En revanche cela donne une large liste de prénoms avec une ou plusieurs références de personnes et des indications sur le genre et l'origine, avec toutes les réserves que tu connais certainement mieux que moi. J'espère que cela pourra t'être utile. Bien à toi. --Shonagon (talk) 23:16, 25 November 2015 (UTC)

ShonagonBot adding references to ambiguous dates

I notice that ShonagonBot is adding references to many birth dates and death dates between 1583 and 1923. In order to add a reference in this range, it is necessary to confirm that the calendar used for the date in Wikidata, Gregorian or Julian, is the same as the calendar used in the reference. Please explain how this bot performs this verification before adding the reference. Jc3s5h (talk) 13:43, 15 October 2015 (UTC)

Hello,

Yes I am aware of this issue with Gregorian and Julian calendars. That's the main reason the bot is not adding different dates with same precision.

When there is no date or less precise date (just year for example), date is added from data.bnf with linked reference in Gregorian calendar; so we have a better information with reference. If there is a similar date, reference is added; so the date is more qualified with another reference from an anthority. When the date is different, nothing is eddited (I put a flag on local); so no new cases with issue on calendar. Best regards --Shonagon (talk) 18:10, 15 October 2015 (UTC)

Take Isaac Newton (Q935) as an example. It contains both Julian and Gregorian dates for birth and death. Since your bot doesn't know if the source is stating a Julian or Gregorian date, you can't tell if it agrees with Wikidata or not. Jc3s5h (talk) 19:20, 18 October 2015 (UTC)

ShonagonBot is adding wrong century!

Hello. In Nicholas Strogers (Q3339679), your bot wrongly attributed birth and death time to 15th century (1401-1500), which is wrong (he was active in the 16th century). The problem lies in your date conversion from the source: 15.. means 15?? , not 15th century. Please revise all items that have received dates in that format. Capmo (talk) 20:33, 17 October 2015 (UTC)

Hello Capmo. Thanks for the report. My bad. I have stopped the bot and will fix this. Best regards --Shonagon (talk) 20:40, 17 October 2015 (UTC)

Thanks for taking action promptly! Capmo (talk) 21:43, 17 October 2015 (UTC)

Hello Capmo. It's fixed. As data of edition are stored in local, it was possible to find concerned cases and ~700 dates of birth or death with century precision added to Wikidata have been fixed. Two examples of correction: example 1, example 2. Data have been changed for still non eddited dates and the bot has been relaunched. For example, two new edits : Bartolomeo Barbarino (Q4865504) Gerhard Diessener (Q1511482). Thanks again to have alerted me for this error. Best regards --Shonagon (talk) 09:08, 18 October 2015 (UTC)

Great work! I fixed a couple of them but couldn't imagine there were so many in the queue. Regards, Capmo (talk) 10:31, 18 October 2015 (UTC)

Question sur les bots

Bonjour,

Je m'adresse à toi car tu possèdes un bot écrit en python, tu utilise Windows et tu parles français.

Je suis en train de développer un bot, et il me manque quelques informations dans la doc : J'ai téléchargé pywikibot ou plutôt un fichier nommé 'core_stable.zip' et je ne sais pas dans quel répertoire le dézipper. dans le C:\Python27\Lib ? ou dans un autre répertoire perso ('c:\compat\', si j'en crois les lignes suivantes) ? et dans ce dernier cas comment signaler à Python l'emplacement de ce répertoire ?

Sur ton site web, je vois les instructions :

c:\compat\python login.py c:\compat\python db_wikidata.py

Ne serait-ce pas plutôt ?

c:\compat>python login.py c:\compat>python db_wikidata.py

Ma question subsidiaire : dans quel répertoire mets-tu les scripts qui constituent ton robot ?

Je te remercie par avance de tes réponses -- Odejea (talk) 12:29, 19 October 2015 (UTC)

Bonjour Odejea,

>Je suis en train de développer un bot

Chouette

>Dans quel répertoire core ?

Peu importe. Personnellement, c'est C:\core\

Pareil pour les dossiers de scripts, peu importe. Personnellement, c'est C:\core\_myscripts\

En revanche il conviendra de veiller au bon adressage pour l'exécution. Exemple dans le dossier c:\core\_myscript\, je lance la commande :

python ../pwb.py edit_date.py

Pour les histoires de "\" et ">", c'est juste une histoire d'affichage de prompt sur la console de commande. Sur la mienne c'est "\", sans doute que sur la tienne c'est ">"

! Attention le script sur la page concernée reposait sur la version compat, celle-ci est caduque. Il convient d'utiliser la version core, que tu as bien téléchargée. Mais le code n'est pas bon. Pour créer ou éditer des items tu peux t'inspirer de Créer un nouvel item Wikidata sans lien avec une page Wikipédia ou d'autres scripts. C'est pas toujours facile, la doc est largement lacunaire. Si tu bloques, n'hésite pas à demander de l'aide.

Si au début, tu rencontres des problèmes d'encodage à s'arracher les cheveux, c'est normal :) ; assez étrangement tout le monde semble y passer et tout aussi étrangement ça finit toujours par marcher (les réponses en ligne sur le sujet sont *très* nombreuses). Et puis bon, n'oublions pas que, If AI ever gets out of control, I think a Python UnicodeEncodingError might save humanity. [Denny Vrandečić]

Enfin, comme tu le sais sans doute, les comptes bots doivent être validés après qu'une demande ait été faite en bonne et due forme : page de demande de permission. La réponse prend parfois plusieurs jours, n'hésite pas à la faire au plus tôt, surtout que les tests doivent être faits avant la demande (cf page sur les bots à lire).

Enjoy! --Shonagon (talk) 20:22, 19 October 2015 (UTC)

Merci de ces réponses et désolé de ne pas avoir répondu plus tôt. Je commence à manipuler, actuellement en mode lecture. J'ai quelques soucis pour accéder aux qualifiers et aux sources d'un statement. Par exemple, lorsque j'appelle item.claims['P31'][0].sources[0], j'ai bien dans la chaîne retournée (OrderedDict([(u'P248', [<pywikibot.page.Claim instance at 0x03801F30>]), (u'P854', [<pywikibot.page.Claim instance at 0x03801F58>])])) la propriété, mais je n'ai pas sa valeur. Je n'ai pas encore trouvé le champ qui me permettra d'accéder aux qualifiers.

Je suis également perplexe avec la commande python login.py. Je n'ai évidemment pas de fichier login.py dans mon dossier c:\core\_myscript\. J'ai vu qu'il y avait C:\core\pywikibot\login.py et C:\core\scripts\login.py. Je ne sais pas lequel des deux est le bon, si je doit en recopier un des deux dans c:\core\_myscript\ ou si je dois l'appeler en précisant le chemin.

Cordialement --Odejea (talk) 10:59, 23 October 2015 (UTC)

Bonsoir Odejea. Difficile de répondre, je n'ai jamais manipulé des références et ne peux que te renvoyer pour la structure vers ce que tu connais sans doute déjà, la version en jsonfm d'un item : https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q855&format=jsonfm.

Concernant login.py, à une époque je devais l'exécuter dans un premier temps mais ce n'est plus nécessaire aujourd'hui. Mon fichier user_config.py est dans C:\Users\B\AppData\Roaming\pywikibot et pour une raison étrange, ça fonctionne de ce côté. Ma version est par là. Je dois juste mettre mon mot de passe quand le script essaye d'éditer. Bien à toi --Shonagon (talk) 20:55, 2 November 2015 (UTC)

Merci de tes réponses. J'ai trouvé la réponse à mes questions sur les qualifiers en fouillant le code de pywikibot. J'ai aussi résolu la question du login, j'ai tout simplement recopié celui de 'script' dans le répertoire de mes scripts. J'ai eu quelques soucis, car quand j'ai tenté de faire des essais sur http://test.wikidata.org ou sur Wikidata Sandbox (Q4115189), j'ai des messages d'erreurs que je n'ai pas en modifiant un autre item de wikidata. Mais le problème n'est pas bloquant, donc je laisse de côté. Cordialement Odejea (talk) 13:13, 3 November 2015 (UTC)

Hosea

This edit appears to be incorrect. The SUDOC item links seems to be a modern French author writing under a pseudonym about marriage. --EncycloPetey (talk) 23:54, 21 October 2015 (UTC)

Hello EncycloPetey. Yes this edit was incorrect. This came from an edit of one VIAF identifier, which was incorrect too. The image was incorrect too. And... oh!... This icon is beatufitul. Let's make an item of it : Hosea (Q21168554) Best regards --Shonagon (talk) 07:15, 22 October 2015 (UTC)

possible creator

Hi Shonagon, please don't remove the creator like you did on Lucrezia Borgia, Duchess of Ferrara (Q20419317), but instead qualify it with possible creator (P1779). See also User:Multichill#Anonymous for other options. The source for this paintings is confusing. I believe they intention is to say that the painting was painted by Dosso Dossi (Q356777), but his brother Battista Dossi (Q2706669) might have helped out. What do you think? Multichill (talk) 20:51, 31 October 2015 (UTC)

IMHO, it's a strange approach, never seen in any catalog, to qualify an anonymous person with a non-anonymous person and a possible source of confusion in edition and reuse. The common approach (for example in Joconde (Q809825) http://www.culture.gouv.fr/documentation/joconde/fr/partenaires/AIDEMUSEES/methode.htm#AUTR ) is to qualify as presumed (or attributed to) the relation between a creator property and a value, and it seems to be possible in Wikidata. For the creator, I have just stated for Dino Rossi because it was attributed only to him in an article on the museum's website: https://www.ngv.vic.gov.au/media_release/ngv-solves-mystery-of-renaissance-portrait/ . By the way, I have finished to complete image (P18) for paintings items from National Gallery of Victoria (Q1464509) with images already in Wikimedia Commons. Best regards --Shonagon (talk) 15:21, 1 November 2015 (UTC)

Callisto

Bonjour Shonagon,

Sympa comme outil, à vrai dire, j'espérais que quelqu'un ferait ça un jour ! Je ne sais pas si tu connais la propriété coordinates of the point of view (P1259), qui n'est peut-être pas très facile à intégrer dedans. --Zolo (talk) 16:20, 16 November 2015 (UTC)

Merci Zolo. Oui j'ai vu cette propriété hier soir en tombant sur Café Terrace at Night (Q1025704). Bon j'ai vu aussi que malheureusement elle était encore très peu utilisée mais en effet ça serait bien de l'intégrer (je t'avouerais que le truc a été fait à l'arrache en 2 jours avec pas mal de trucs nouveaux pour moi). Oui ça serait bien de l'utiliser d'autant plus que parfois c'est la propriété coordinate location (P625) qui est improprement utilisée à la place (elle était présente dans Café Terrace at Night (Q1025704)). Plus globalement j'ai constaté qu'il y avait eu import massif de coordinate location (P625) depuis Wikipédia [en] dans Wikidata avec, semble-t-il, quelques erreurs côté œuvres d'art (import très positif dans l'ensemble, permettant d'ailleurs de faire Callisto). Y a encore de quoi faire :) ! Bien à toi --Shonagon (talk) 23:35, 16 November 2015 (UTC)

Effectivement, "coordonnées du point de vue" est encore assez confidentielle. Par ailleurs, il lui faudrait sans doute un qualificatif du genre "direction de la prise de vue", un peu comme ce qu'il y a sur Commons, mais je ne sais pas trop la forme que ça devrait prendre. Je viens de me souvenir qu'il y avait aussi location of creation (P1071), peut-être plus facile à intégrer à Callisto étant donné que le type de données est le même que "depeint" et "collection". --Zolo (talk) 06:07, 17 November 2015 (UTC)

J'ai fait de la pub pour ton outil. Du coup il est mentionné dans Wikidata:Project chat#Wikidata weekly summary #184. Si tu cherches des idées pour éviter que l'outil freeze, je pense qu'un message à la suite de la newsletter ou sur la liste de discussions doit faire l'affaire. Pyb (talk) 17:40, 16 November 2015 (UTC)

Merci Pyb. Pour le freeze, déjà, j'ai supprimé le chargement simultané des dépeints/collections/œuvres qui allège pas mal le chargement de la page. Ça reste quand même lourd mais je ne suis pas sûr de le développer beaucoup plus ; ça a été fait à la truelle côté code et le mieux serait sans doute de rebooter le tout, ce que d'autres feront bien mieux. Surtout ça permet d'apercevoir des trucs nouveaux et quand même chouettes, possibles avec Wikidata+Commons+OSM+... Au passage je crois que c'est la carte que tu avais faites avec une requête SparQL qui m'a révélé qu'on pouvait déjà envisager de faire des trucs avec la géolocalisation. Enfin sur la carte œuvres d'art, la petit forêt de tuiles rouges dans un cimetière de l'Est parisien ne m'a pas échappé. Bien joué ;-) --Shonagon (talk) 23:35, 16 November 2015 (UTC)

Q21593026

I just noticed a bunch of items like Victor Cochot (Q21593026). Started something and forgot about it? ;-) Multichill (talk) 22:18, 2 December 2015 (UTC)

Hello Multichill . Oh, thanks for the alert! I didn't notice that mix-n-match creates automaticly items when "No Wikidata entry" is chosen. I tought that they were just excluded of the Game and I just understand now how it works. "N/A" was the choice to make for those kind of entries which can maybe be relevant one day but not now. I think I created something like ~70 items, without noticing :/. I will make a list and ask for deletetion. Thanks again. Best regards Shonagon (talk) 22:58, 2 December 2015 (UTC)

Creating items rather than adding "N/A" has been the behaviour of Mix'n'match for a week or so. I think it makes a lot of sense to create these items rather than classifyin the artist as "N/A". This way we can have more complete mappings and cross-reference catalogues. In this case, we do not have works by Victor Cochot yet but we might one day, and it may be relevant to crosslink the Agorha entry with than of the Orsay Museum ([7]), so I do not think those entries should be deleted. --Zolo (talk) 06:37, 3 December 2015 (UTC)

Hmm, I don't think these items should be deleted. This messes up the whole system. I'll request undeletion. Multichill (talk) 07:30, 3 December 2015 (UTC)

Those items were created without intention. They are maybe relevant, but I thought that it needs more information to be useful and my to-do list is already so much long; I thought too that they could be created later with more information. That's why I asked for the deletion but it was indeed maybe not the best option. So sorry for the mess. Best regards Shonagon (talk) 10:33, 3 December 2015 (UTC)

No worries, I'm sure others will help to improve it. Multichill (talk) 17:29, 3 December 2015 (UTC)

Ok. Thank you Shonagon (talk) 21:52, 4 December 2015 (UTC)