Bonjour, pourriez vous me dire si il y a un moyen simple de créer un item wikidata via l'import d'une notice IdRef (exemple) sachant qu'Idref permet l'export en XML et en RDF. Merci
Wikidata:Bistro
Bonjour, l existe un outil qui permet l'import direct d'autorités de la Bnf https://tools.dicare.org/bnf/
mais à ma connaissance, il n'y a pas d'équivalent pour IdRef (autorités du Sudoc)
@Envlh sais-tu si ça serait compliqué de faire l'équivalent ?
Bonjour. Je vais regarder ça. Le fait qu'il y ait un export XML pourrait bien aider à créer une interface similaire.
Super ! ça me faciliterait bien la vie
Effectivement, j'utilise cet outil Bnf qui est bien utile. A défaut d'outil similaire, si vous avez des trucs pour exporter sur Quickstatements via l'export XML ou RDF, je suis preneur
Bonsoir. J'ai codé un équivalent de BnF To Wikidata pour IdRef : IdRef To Wikidata (ça se base sur l'export RDF). Je n'ai fait que des tests sommaires, n'hésitez pas à signaler les éventuels problèmes.
Salut @Envlh
- pour https://www.idref.fr/237214520 (que je n'ai pas créé pour pouvoir tester plus), je vois que le genre (P21) n'est pas importé, alors qu'il est renseigné dans IDRef... ou oubli ? ou un problème ?
- autre point qui pourrait peut-être être vérifié avant création : IDref fournit souvent un id Bnf et un ISNI - penses-tu qu'il serait possible de vérifier leur existence préalable dans WD, afin d'éviter la création d'éléments comme Véronique Sarrazin (Q85934412), qui est un doublon de Q64079950... et proposer l'ajout sur l'élément correspondant (après vérification, bien sûr) ?
Coucou !
- Pour le genre, c'est parce que je ne l'ai pas trouvé dans l'export RDF (exemple).
- J'ai amélioré la détection des doublons. Ça regarde maintenant dans cet ordre :
- si la notice IdRef est liée à un item Wikidata ;
- si l'identifiant IdRef existe déjà dans Wikidata ;
- si l'identifiant BnF renseigné dans la notice IdRef existe déjà dans Wikidata ;
- si l'identifiant ISNI renseigné dans la notice IdRef existe déjà dans Wikidata.
Effectivement, je n'avais pas vu à quoi ressemblait les formats /rdf ou /xml...
Pour les dédoublonnage, Super ! Merci beaucoup... ça va vraiment faciliter la création d'auteurs/chercheurs, qui sont loin de toujours avoir une notice à la Bnf, tout en évitant les doublons ; je n'ai constaté celui de ma soeur qu'après la création ; j'ignorais qu'elle avait déjà un élément :D
si je repère d'autres pbs, je te les signalerai, mais c'est déjà très utile comme ça...
Bonjour,
Suite à des discussions sur fr.wikipedia.org sur Agnès Cerighelli (Q78498877), j'ai complété son entrée en utilisant convicted of (P1399). Mais après réflexion, je me demande si l'usage de homophobia (Q33487) est correct vis à vis de la précision et par rapports aux concepts en droit français. Les journaux rapportent largement l'affaire, et utilisent clairement le mot "homophobe", et de mon point de vue, c'est une information utile et notoire. Mais je me demande si il faut plus de précision, vu que le tribunal parle d'"injures homophobes" (cf ici). Est ce que du coup, il faut rajouter Slander (Q3086119) quelque part, ou insulte, ou autre ?
Wikidata a déjà détecté que les valeurs saisies ne sont pas des valeurs possibles pour P1399 (voir le message d'erreur sur la déclaration). Mieux vaut regarder la description de la propriété et ses exemples. Ce n'est pas prévu pour des condamnations par des journalistes.
@Jura1, il s'agit bien d'une condamnation par le TC de Versailles...
mais le terme employé par les journalistes n'est évidemment pas le nom officiel de l'infraction dans le code pénal... qui doit être quelque chose comme "injure publique en raison de l'orientation sexuelle" - les propos reprochés ont été tenus sur Twitter, et elle a aussi été condamnée à des DI.
et elle est aussi poursuivie pour "provocation à la haine"
pour le moment, pour autant que j'ai bien vérifié, elle n'a pas encore procédé à la publication sur son compte Twitter pour laquelle elle dispose de 10 jours.
pour renseigner cette condamnation sur wikidata, le problème est évidemment qu'il n'y a pas d'élément pour chacune des qualifications délictuelles ou criminelles existantes... PAS le fait que les journalistes la "condamnent"...
@Misc il existe déjà racist insult (Q3151342) - on pourrait peut-être créer parallèlement "injure homophobe", qu'en dis-tu ?
il s'agit des articles 29 et 33 de la loi du 29 juillet 1881 sur la liberté de la presse... de ce point de vue, les réseaux sociaux, dès lors que les propos sont publics (et non en MP) sont considérés comme "presse", car la diffusion est largement aussi importante...
le fait que l'injure soit "publique" alourdit les sanctions...
Donc c'est son extension à l'identité de genre et l'orientation sexuelle qui est récente ? J'ai tenté de chercher un peu mais du coup, je pige pas trop pourquoi cet article parle de première condamnation.
Le lien que tu donnes liste aussi les types d'insulte (Raciste, Sexiste, Homophobe, Portant atteinte aux personnes handicapées (j'aurais tendance à dire "Validiste") et "autre"), est ce que ça ne serait pas un début de classification pour différent type d'injure en droit français ?
Il peut s'écouler pas mal de temps entre le moment où une qualification est créée dans les codes et celui où la justice l'utilise pour condamner effectivement (et définitivement, puisqu'il s'agit d'une confirmation en Cassation). Cette décision (Cass. crim., 7 janv. 2020, n° 19-80.796), est donc effectivement, la toute première condamnation *définitive* au titre de cette qualification spécifique, après la modification de "identité sexuelle" à "identité ou orientation sexuelle", ce qui est plutôt important...
La condamnation d'A. Cerighelli est une condamnation en première instance, ce qui est très différent... :)
Bonjour. Pourquoi ne pas créer un élément pour le délit en droit français, avec son intitulé exact ?
Tu peux préciser un peu plus, je suis pas sur de voir la différence avec la proposition de Hsarrazin (talk • contribs • logs) ?
oui, c'est ce que je proposais...
on m'a aussi suggéré, hier soir, d'entreprendre la création systématique de toutes les qualifications délictuelles en droit français (un élément par délit) avec des regroupement en sous-classe de..., avec lien vers les articles de code concerné, et les éléments permettant d'apprécier la constitution du délit...
ça serait sans doute passionnant, mais il faudrait l'implication d'au moins un.e juriste compétent pour éviter les bêtises :)
perso, je n'aurais pas cette ambition - donc, en attendant, un élément par qualification d'injure me semblerait déjà pas mal ;)
"Pour renseigner cette condamnation sur wikidata, le problème est évidemment qu'il n'y a pas d'élément pour chacune des qualifications délictuelles ou criminelles existantes" : je suis d'accord, mais je ne l'ai pas vu proposer de créer des éléments pour lesdites qualifications (mais peut-être était-ce implicite ?)
ça l'était, effectivement :)
(Désolé, j'ai du mal avec ça 🤣)
Hi, does MAHG ID (P6877) still relevant ? The links are broken since the museum site changed https://collections.geneve.ch/mah/ ; its use the inventory now in links. Example : https://collections.geneve.ch/mah/oeuvre/masque-de-momie/007059 Before it was : http://www.ville-ge.ch/musinfo/bd/mah/collections/detail.php?id=380845 (broken) How can we fix that ? V!v£ l@ Rosière /Murmurer…/ 23:39, 6 February 2020 (UTC)
Salut, tu est sur le Bristro franco ici. ;) Sinon, j'ai posé la même question (ici) à rapport à Ontario MPP ID (P3054) et il semble pas avoir de réponse ou de protocole face à un identifiant remplacé/désuet. Dommage.
Oups, mince j'avais oublié que le flux de discussion était localisé (et aussi qu'il n'y même plus besoin de signer avec ce système). Mince, effectivement, parce que je pense qu'il faudrait au moins les marquer comme désuet et les lister quelque part pour pouvoir ensuite les corriger/remplacer.
Bonjour,
Il semblerait que cet identifiant soit très peu utilisé (ou il a été retiré au vu du problème...) et la liste (une vingtaine)
un changement de l'url suivi d'une mise à jour des ID me semble gérable... à discuter sur la pdd de la propriété en pingant les contributeurs initiaux, de la proposition de création (@Rama, @Jneubert, @ديفيد عادل وهبة خليل 2, et @Eihel) me semble-t-il... ;)
et @Nono314 qui figure parmi les utilisateurs de cette propriété sur des tableaux...
La démarche correcte est de créer une nouvelle propriété pour le nouveau identifiant.
Si effectivement l'ancien identifiant s'est avéré inutile ou instable, on pourrait supprimer la propriété.
Non @Jura1, la démarche correcte est d'en discuter d'abord. Tant que le datatype est identique, il n'y a pas à se précipiter pour une suppression ou faire une nouvelle proposition. C'est ce qui est décrit sous Help:Properties. Les Libellés, Descriptions et aliases sont identiques.
Je ne vois pas à quelle partie on se réfère?
Si on ne peut pas avoir des libellés identiques pour deux propriétés, ça veut juste dire qu'il faut les ajuster ..
Je pense qu'il faut commencer par contacter le Musée pour leur signaler le problème et voir ce qu'ils proposent pour y remédier soit de leur côté (en mettant en place des redirections qui marchent et rendent les URI pérennes), soit en nous communicant des listes de correspondances entre anciens et nouveaux identifiants.
Salut @Rama :)
effectivement, il n'y a actuellement que 20 usages de cet id, donc faire un changement ne devrait pas être bien méchant (je me souviens d'un musée néerlandais où on a passé collectivement un week-end à reprendre plusieurs centaines d'ID...)
par contre, il faudrait s'assurer que leurs nouveaux ID soient pérennes...
d'autre part, actuellement, il semblerait que l'ID devrait comprendre le nom de l'oeuvre "masque-de-momie/007059", car le simple n° d'inventaire est insuffisant pour un lien... à moins qu'il y ait un permalink que je n'ai pas vu, planqué quelque part dans un coin ^^
Je pense qu'il faut se méfier des indications trouvées dans Wikidata sur l'utilisation des propriétés. Les chiffres ne tiennent pas compte de l'utilisation hors Wikidata et ça commence déjà sur Commons.
en l'occurrence, je pense que @Rama est bien placé pour savoir ce qu'il en est ;)
Ça ne concerne plus P6877 en particulier mais il y a aussi également le cas des liens apposés en brut comme référence dans certaines entités.
effectivement, un total de 337 liens (y compris en tête de cette page) et surtout, des utilisations de described at URL (P973)
On dirait que l'on a oublié de les faire convertir .. c'est fait.
ça a fini par convertir .. si vous changez d'avis, faites un "revert"
de quelle "conversion" parles-tu ?
Les 19 Éléments concernés par cette Propriété contiennent aussi tous inventory number (P217). Les numéros d'inventaire, Libellés, Descriptions et image (P18) sur ces Éléments ont été vérifiés, voire corrigés. Tous les objets du catalogue semblent commencer par https://collections.geneve.ch/mah/oeuvre/ (les auteurs ne sont pas répertoriés par cet identifiant). Je vous propose :
- un nouveau RegEx :
[-\w]+(\/[-\w]+)?(\/[-\w]+)? - d'enlever single value constraint (Q19474404), à cause de et par exemple (et bien d'autres).
- formatter URL (P1630) :
https://collections.geneve.ch/mah/oeuvre/$1
Pour les described at URL (P973) et reference URL (P854), faudrait un bot. Qu'en pensez-vous @Vive la Rosière,@Hsarrazin et @Rama ?
Ça me parait très bien, mais attendons peut-être un peu de voir si le Musée répond ; s'ils mettent des redirections en place ou qu'ils nous communiquent une liste de correspondances, ça pourrait nous simplifier le travail, voire nous l'éviter.
J'ai envoyé un courriel ce matin au musée pour savoir si leur URI était stable, je pense qu'il devrait répondre dans la semaine... ou pas.
J'ai remarqué aussi que la partie censé correspondre au nom de l’œuvre peut ne pas correspondre de facto au titre de l’œuvre. Ainsi Q67787631 est désomais titré Portrait de Jean-Jacques Rousseau (1712-1778) sur le site du musée ; du coup le (1712-1778) ajouté au titre se retrouve donc également dans l'URI : portrait-de-jean-jacques-rousseau-1712-1778. Que fait-on dans ces cas-là ? On change le libellé de l'entité, on l'ajoute en alias ou bien ce serait une autre propriété de l'objet (genre une déclaration "titre musée MAHG") ?
Je pense qu'il y a des vrais titres d'artistes sur certaines pages, comme Q67807639, avec une indication supplémentaire sur le site : "Autres titres Nu au flacon". On voit que le titre est visible sur la page de l’œuvre, mais l'URL est transformé en "nu-la-lumiere". De même, on ne va pas mettre un libellé "Statue ?, fragment" ou "statue-fragment" pour Head of a goddess or priest-MAHG 012704 (Q64764978) et on ne répétera pas figurine des centaines de fois. On pourrait bien libeller cet Élément pastel de Jean-Jacques Rousseau, c'est un choix du MAHG. Avec un sitelink, on a plus de chance pour mettre le bon Libellé. En réponse, le libellé me semble bon et c'est la date de création qu'on rencontre le plus souvent. Cordialement.
D'acc, je posais la question surtout car si le nouveau ReGex du lien se générera semi-automatiquement il ne pourra pas reprendre le libellé comme source pour la partie "nom d’œuvre" de l'URI.
Du coup, toutes les réf commençant par http://www.grandpalais.fr/fr/ et en lien avec les Éléments de MAHG ID (P6877) sont obsolètes "Page non trouvée - 404".
Bonsoir,
@Hsarrazin : Avant l'intervention de Jura1, nous en étions à 19 Éléments à modifier. Il a chargé KrBot de convertir tous les described at URL (P973) faux (avec l'ancien ID) en identifiant de P6877 à l'aide de Template:Autofix (ici). Il précise que si on change d'avis, on a qu'à faire un revert. Mes questions seraient plutôt : Reverter quoi ? Reverter qui ? KrBot ? (soupirs)...
@Jura1 : J'aimerais aussi savoir ce qu'il y a d'intéressant ici ou ici ou dans pratiquement 251 autres IDs ? Au cas où, si vous n'avez pas archivé toutes ces pages, on en est au même point !
Pour ma part, j'attends une réponse de @Vive la Rosière pour une marche à suivre, c'est préférable à la précipitation, Jura1, et c'est la 2e fois que vous court-circuitez une discussion pour en faire à votre guise.
@Eihel Merci pour l'explication... je n'avais pas compris de quelle "conversion" il s'agissait...
@Jura1 procéder à cette conversion alors que nous sommes en train de discuter de la solution à appliquer est non seulement précipité, mais accentue le problème... en effet, les infos (fausses) contenues dans described at URL (P973) pouvaient, une fois une solution trouvée, servir à repérer les éléments restant à reprendre... maintenant, c'est impossible :( cette solution n'aurait été appropriée QUE si les ID étaient restés identiques, ce qui est justement à l'origine du problème discuté ici...
tant que nous n'aurons pas obtenu une réponses du MAHG sur la pérennité de leurs adresses, tout travail de modification est absurde
quant à reverter un Autofix, j'aimerais bien savoir comment on fait...
Merci de ne plus prendre d'initiatives sur ce problème sans en discuter d'abord avec les personnes concernées, ici même.
Eihel, cessez de traiter les contributions des autres participants d'aberrantes.
Tenez-vous aux propriétés telles que proposées (Wikidata:Property proposal/MAHG ID).
Etrangement, vous avez même émis un 
Jura, vous prenez des données obsolètes d'une propriété pour les mettre dans une autre propriété, comment appelez-vous ça ? Quand à votre deuxième phrase, c'est le sujet de ce topic : on ne peut plus s'en tenir à la proposition initiale de cette propriété. Comme une proposition de propriété, une discussion menant à un consensus est prévue par les règles que vous n'avez pas suivies. Pour les règles, il s'agit du même lien que j'ai donné le 7 courant, ci-dessus. Le fait que des utilisateurs aient émis un avis lors de la proposition n'y change rien et imposer votre point de vue par des modifications hors-sujet n'est du goût de personne. Et ce n'est pas non plus une foire d'empoigne : tous les avis sont bons à prendre, pas seulement le votre. Discourir sur la proposition initial ou supprimer la propriété et en créer une autre sont hors-sujet. Pour le comprendre, il suffit de lire ce qui est écrit dans ce topic et dans les règles. Hsarrazin est du même avis concernant une discussion (voir ici).
Tant que l'on n'a pas de nouveau consensus .. en principe, on se tient au consensus existant. Apparemment, il avait votre
Ceci dit, il ne faut pas confondre Wikidata avec Wikipédia: on ne révise pas le site à chaque changement. On rajoute les nouvelles sources.
il ne s'agit pas d'une "nouvelle" source, mais d'une source (le Musée) qui a changé ses adresses URL...
ça n'est ni la première institution GLAM (ni la dernière malheureusement!) à qui ça arrive...
Correction: nouvelle "référence".
Toujours pas. Je voterais 
La proposition a été acceptée.
Il y a une autre question sur la réutilisation d'entités posée à Wikidata:Project_chat#Items_deletion_request. Apparemment, les entités en question ne sont plus d'actualité.
quel rapport avec le Shmilblick ? ceci concerne-t-il, à quelque titre que ce soit, le MAHG ?
T'cho chère @Hsarrazin Je crois qu'il s'est trompé et voulait écrire Wikidata:Project_chat#Versionize property definitions ? (ce qui est plus en rapport avec ce Schmili SChemali... avec ce Topic). En bref sur Chat, ce qu'on fait ici est maaaaal. J'y donnerai une réponse un de ces 4. À+
effectivement :)
par contre, j'aimerais comprendre en quoi la "suppression" d'une propriété (pour la remplacer par une autre), faciliterait le "suivi" (tracking) aux personnes ayant d'anciens IDs ^^
Beh whoui, moi non plus j'comprends pô. Surtout que les sister projects WM sont bénéficiaires, car leurs données changent automatiquement. Les tiers qui récupèrent les données WD doivent aussi s'adapter à un changement des identifiants et autres. Les Qs sont récupérés et accessibles via une Prop. Si cette dernière change, ça ressemble plus à planned obsolescence (Q1967458). Si la Prop est gardée, on obtient un historique des IDs, d'où un suivi. CQFD.
Toujours pas de courriel de réponse. Après je n'en ai envoyé qu'à mah(at)ville-ge.ch (pas à collections.mah(at)ville-ge.ch, je l'ai transféré aujourd'hui sur cette dernière on ne sait jamais). Mais je viens de remarquer que l'adresse courriel est similaire à l'ancien site, si ça se trouve leur adresse courriel n'est plus la même non plus.
ce sont bien les adresses figurant sur leur page "nous contacter" https://collections.geneve.ch/mah/nous-contacter ^^
espérons qu'ils ne seront pas trop occupés par leur "déménagement" pour prendre la peine de répondre...
@Rama, Eihel, Hsarrazin, Jura1: Bon toujours pas de réponse du musée, tant pis pour eux j'ai envie de dire. On fait comment du coup ? On présuppose que les adresses ne bougeront pas ? Je mets les liens vers les articles du musée en brut ? ou bien l'on fait en sorte que l'URI soit partiellement déduite (même si du coup je ne vois plus trop l'intérêt de la chose) ?
perso (!), je mettrais, à la main vu qu'il n'y en a pas beaucoup, un ID du genre "masque-de-momie/007059", avec une url "https://collections.geneve.ch/mah/oeuvre/$1"
normalement, ça devrait fonctionner... même si c'est un peu long à faire ;)
et si jamais le musée s'amuse à re-modifier ses adresses, on kill la propriété :( - et tant pis pour eux...
Ok ça marche, je vais faire comme ça alors. Je m'en occuperais.
Sinon pour la référence à Wikidata:Property proposal/MAHG ID, comment ça se passe ? J'édite la proposition ? J'ajoute un commentaire quelque part là-bas ? Ou l'on doit repasser par un processus de vote ?
Avant de se lancer dans des trucs difficiles à défaire, je propose qu'on écrive à l'Office cantonal de la culture et du sport de Genève, dont dépendent les musées. Les contacts que j'ai eus à ce niveau nous étaient favorables, ceux que j'ai observés au MAHG, pas autant. Je vous redis dès que je trouve quelque chose.
Ça marche, je ne touche pas aux liens pour le moment du coup.
Bonjour tt le monde @Vive la Rosière @Rama,
J'ai plutôt changé les rangs (obsolète) des anciennes données. Les anciens IDs pourront côtoyer les nouveaux, @Hsarrazin. Pour les nouveaux objets, la réf est ce topic avec Wikimedia import URL (P4656). Pour le RegeX, j'ai fait de même. Pour l'exemple uniquement, j'ai modifié Greek girl weeping on Byron's grave (Q62587934).
Vous pouvez aussi donner votre avis sur Property talk:P3054, il s'agit d'un problème identique à ici. À+.
alors, en fait, je viens de constater qu'on a des IDs pour les oeuvres (commençant par https://collections.geneve.ch/mah/oeuvre/) et d'autres pour les auteurs (commençant par https://collections.geneve.ch/mah/auteur/)
voir par ex https://collections.geneve.ch/mah/auteur/chaponniere
du coup, si on n'intègre pas cette racine à l'url ou à l'ID, le lien est incorrect...
Du coup, ceci pourrait justifier une division en 2 de l'ID , avec un ID pour les oeuvres et un pour les auteurs (comme le cas existe pour d'autres institutions GLAM) ?
@Hsarrazin En fait, d'après la proposition, seul le catalogue est recensé : il n'y a jamais eu de personne (voir domaine : type constraint (Q21503250) = item of collection or exhibition (Q18593264), archaeological artifact (Q220659), work (Q386724)). Les liens vers ces personnes (auteur) ne couvrent que peu d'informations : ils sont là pour regrouper les œuvres de ceux-ci. Cordialement.
Je viens d'ajouter les reason for deprecation (P2241) sur P6877. Dans l'attente de Rama (et on remercie chaleureusement Gaëlle et Sarah du SEC), sinon les changements de P6877 semblent corrects. Vos avis...
Bonjour, Je viens de créer Q85903489 (oeuvre gravé), sous-classe de Q17489659 (groupe d'oeuvres). Pour info, l'"oeuvre gravé" est l'ensemble des oeuvres d'art d'un artiste résultant d'un processus de l'estampe (plus communément appelée gravure). Quand j'associe cet élément en tant que sous-classe aux éléments Q4340318 (gravures de Rembrandt) Q85853345 (gravures de William Hogarth) ou encore Q5883870 (gravures de Goya), j'ai un warning sur le créateur (l'artiste), qui me dit : "Les entités utilisant la propriété créateur doivent être des instances de une des classes suivantes de (ou d’une de leurs sous-classes), mais Gravures de William Hogarth ne l’est pas actuellement :
- œuvre
- élément d'une collection ou d'une exposition
- projet
- affirmation logique
- événement
- accord
- groupe d'œuvres
- ..."
Est-ce que je suis obligé de mettre "groupe d'oeuvres" comme sous-classe de "gravures de William Hogarth", alors que "oeuvre gravé" est lui-même un "groupe d'oeuvre" ?
Merci !
Bonjour,
Un petit message pour parler de ce que Wikimedia France (Q8423370) prévoit de faire autour de Wikidata dans les prochains mois.
J'ai pour cette année deux missions qui se complètent :
- la première est d'établir un plan de formations autour de Wikidata.
- La seconde (et la plus ambitieuse) est, dans la continuité, de réaliser un Mooc sur Wikidata, dans le même style que le WikiMOOC .
Si participer à l'une ou à l'autre vous intéresse, n'hésitez pas à me contacter ! Dans l'idéal, j'aimerais que le Mooc soit prêt pour l'anniversaire de Wikidata, fin octobre (oui c'est court !)
Enfin, en parlant de l'anniversaire de Wikidata : avez-vous déjà des idées de choses que vous aimeriez faire à cette occasion ? Si oui, c'est le moment de les mentionner ici, afin qu'on puisse les inclure dans le budget de cette année.
cool
Quelques suggestions à ce sujet: Wikidata:Project_chat/Archive/2020/02#Wikidata_step-by-step
Bonjour,
Nous faisons régulièrement la même requête, qui 1 fois sur 2 ou 3 peut aboutir à un timeout.
Nous avons essayé 2 requêtes différentes:
Dans un premier temps:
SELECT
DISTINCT ?bnfid ?frurl WHERE {
?wikiid wdt:P268 ?bnfid.
?frurl schema:about ?wikiid.
?frurl schema:isPartOf <https://fr.wikipedia.org/>.}
Puis pour limiter le nombre de triplet dans la réponse intermédiaire:
SELECT DISTINCT ?bnfid ?frurl WHERE {
?wikiid wdt:P268 ?bnfid.
?frurl schema:about ?wikiid.
SERVICE wikibase:label {bd:serviceParam wikibase:language "fr" .}
FILTER(STRSTARTS(STR(?frurl), "<nowiki>https://fr.wikipedia.org</nowiki>")).
}
Mis le comportement est le même.
Y a-t-il moyen de contourner le problème: améliorer la requête, un mécanisme asynchrone...?
en utilisant OFFSET?
p.e. ORDER BY ?bnfid OFFSET 0 LIMIT 10000