Process: Difference between revisions
No edit summary |
No edit summary |
||
Line 179: | Line 179: | ||
Manifest OpenRefine pour pouvoir alimenter en masse, sans forcément passer par QuickStatements ([https://docs.openrefine.org/fr/next/manual/wikibase/configuration doc OpenRefine] et [https://github.com/OpenRefine/OpenRefine/wiki/Write-a-Wikibase-manifest doc Github OpenRefine] | Manifest OpenRefine pour pouvoir alimenter en masse, sans forcément passer par QuickStatements ([https://docs.openrefine.org/fr/next/manual/wikibase/configuration doc OpenRefine] et [https://github.com/OpenRefine/OpenRefine/wiki/Write-a-Wikibase-manifest doc Github OpenRefine] | ||
== Liens utiles == | |||
* [https://adochs.arch.be/wiki/Main_Page DataCegeSoma], prototype de base de connaissance collaborative | |||
* [https://kbtestwikibase.wikibase.cloud Wikibase instance for the national library of The Netherlands] | |||
* [https://database.factgrid.de Factgrid], wikibase pour historiens |
Revision as of 14:09, 9 October 2022
Après le vertige de la base blanche, voici un aperçu des étapes suivies.
Au début...
Le but premier de cette base est de migrer ma photothèque généalogie (voir article sur ce projet initié en 2015, avec modèle de description proposé sur Google Forms / Framaforms).
Cette photothèque créée avec Fabrik (composant Joomla), quoi que très souple d'utilisation et d'administration, ne me satisfait que moyennement (la recherche avancée est peu opérante). Fabrik ne sera pas utilisable sous Joomla 4.0... et depuis plusieurs années je suis devenue addict à Wikidata. Restait la solution d'une wikibase personnelle. L'installation d'une instance perso me semblait trop complexe techniquement et chronophage (j'ai tenté Docker en vain)... jusqu'à ce qu'arrive [httpː//wikibase.cloud wikibase.cloud].
Par quoi commencer dans une wikibase vide ?
Après quelques tâtonnements (et quelques erreurs sur le choix du type de propriété ː la plupart des propriétés sont de type élément), j'ai créé les propriétés de base, avec en tête un maximum d'alignement sur Wikidata afin d'avoir un pivot permettant de lier les concepts, récupérer des données(coordonnées géographiques, article Wikipédia, etc.)
- propriété de base ː nature de l'élément, ID Wikidata, URI Wikidata.
- propriétés de type individu ː sexe, nom, prénom, date et lieu de naissance, etc. Modèles utilisés ː Wikidata bien sûr, DataCegeSoma et bien sûr un individu dans mon logiciel de généalogie
Une fois ceci fait, création de 2 items (un individu et une photographie, ensembles principaux attendus dans la wikibase) ː cela a permis d'ajuster et de créer des propriétés manquantes.
> ̼Item:Q26 (individu)
> Item:Q10 (photographie)
Premières requêtes
[...]
Import des termes d'indexation
Création en masse des éléments d'indexation (matière, lieu) avec OpenRefine (le contenu de photothèque existe en fichier csv) et Quickstatements
CREATE
LAST Lfr {{jsonize(cells["Lfr"].value)}}
LAST Dfr {{jsonize(cells["Dfr"].value)}}
LAST P18 Q18
LAST P56 {{jsonize(cells["image"].value)}}
LAST P17 {{jsonize(cells["id"].value)}}
LAST P55 {{jsonize(cells["url"].value)}}
Ajustements réguliers sur l'organisation et la hiérarchie des propriétés et des termes d'indexation (but ː pouvoir utiliser "sous-classe" / "partie de" pour plein de types de requêtes)
Echec sur l'import des coordonnées géographiques > à la main
[...]
Import d'une collection de la photothèque
Soyons honnête, j'ai un peu galéré (une demi journée), en tâtonnant entre QS version V1 ou CSV, notamment pour gérer les textes libres (bien penser à indiquer la langue) et les coordonnées géographiques. Sans compter les virgules dans le texte qui cassent du CSV si non échappées (\,)... Bref, en faisant un faux export QS depuis OpenRefine, j'ai finalement trouvé comment encodé
- les champs de type texte libre, en les faisant précéder de la langue : fr:"description"
- les coordonnées géographiques : @36.01312350000001/0.14013810000005833
Patron OpenRefine | Exemple de contenu |
---|---|
|
|
Tous les champs de la notice photographie n'ont pas été créés lors de cet import. J'ai mis de côté l'indexation (multivaluée) et les dates (souvent approximatives) pour les traiter ultérieurement.
Import des individus
[Individus nécessaires pour indexer les photographies dans un premier temps]
CREATE
LAST Lfr {{jsonize(cells["Lfr"].value)}}
LAST Dfr {{jsonize(cells["Dfr"].value)}}
LAST Afr {{jsonize(cells["Afr"].value)}}
LAST P18 Q3
LAST P23 +{{jsonize(cells["date_naissance"].value)}}T00:00:00Z/11
LAST P26 {{jsonize(cells["lieu_naissance"].value)}}
LAST P25 {{jsonize(cells["url"].value)}}T00:00:00Z/11
LAST P27 {{jsonize(cells["lieu_deces"].value)}}
LAST P59 {{jsonize(cells["numero_sosa"].value)}}
LAST P72 {{jsonize(cells["numero_ohmigene"].value)}}
LAST P19 {{jsonize(cells["generation"].value)}}
Particularités :
- les dates doivent être au format +AAAA-MM-JJT00:00:00Z/11 (granularité de la date : /9 = année, /10 = mois, /11 = jour)
To do list
- Création en masse des activités (liste consolidée phototheque.csv / logiciel de généalogie > Openrefine > alignement Wikidata > QuickStatements)
- Création en masse des personnes (uniquement personnes nécessaires dans la photothèque dans un premier temps)
- Création en masse des lieux > OK
- Création en masse des items photographies (par collection)
- Homogénéisation des lieux : vérifier à partir des requêtes SPARQL qu'il y a imageCommons, localisation administrative (rattachement commune / département / pays)
A creuser ː
Requêtes SPARQL
Médias (pas d'affichage des médias car hébergés ailleurs). Viewer ?
Modèle Entité
Manifest OpenRefine pour pouvoir alimenter en masse, sans forcément passer par QuickStatements (doc OpenRefine et doc Github OpenRefine
Liens utiles
- DataCegeSoma, prototype de base de connaissance collaborative
- Factgrid, wikibase pour historiens