---
tags: phn, ontologie, communes
---
# Préparation de la séance PHN sur les communes historiques

## Notes du 15 janvier 2021

Dans le schéma mis à jour, le sliens en pointillés représentent des liens qui "zappent" quelques classes intermédiaires pour simplifier la lecture.

Abstract individual = individu abstrait, qui n'a pas d'existence physique et dont l'existence est admise par un nombre très restreint de gens. Ex: le 'monstre sous le lit' pour un enfant.

Un personnage de roman est un individu abstrait inclus dans les représentations d'une communauté. Roman = informationnal object qui comporte deux aspects: les signes (textural surface) et le contenu sémantique (propositionnal object).

Social connotation = concept qui s'applique bien aux objets qui existent déjà mais moins pour un territoire qui est créé par décret du jour au lendemain. Comment une chose est connotée par quelqu'un ou un groupe, à comprendre comme une interprétation. Par exemple, un menhir est connoté comme 'totem' pour ceux qui l'ont érigé, comme artefact archéologique pour nous, et comme rocher pour d'autres.

Legal Entity = un territoire administratif est une legal entity. A une existence légale qui est une qualité. La social connotation aussi est une qualité (c'est le fait d'être interprété d'une certaine façon).

Territory = portion de la croûte terrestre ET legal entity.

Il faut expliciter la classe territory parce que ça permet d'y associer les types de territoire (commune, canton, etc.)

E53 Place = region dans un espace métrique, cad une géométrie (un polygon, une bbox exprimés dans un système de coordonnées). C'est un objet informationnel qui sert à repréenter la forme et la localisation d'un objet non informationnel comme "Paris" par exemple.

Comment souhaite-t-on diffuser les données: sur triplestore (pas de contrainte) ou sur geovistory (! contraintes de modlisation à prévoir)?

NB: Sur OntoMe: si on crée des classes nouvelles, c'est dans un namespace, si on réutilise des classes existentes, c'est un profil. **Il vaut mieux travailler "sur papier" et implémenter le vocabulaire sur OntoMe seulement une fois qu'il est stabilisé.** Créer un espace de nom "deprecated" pour les classes que l'on veut effacer.

Ontologie Factoïd est une modèle générique: il y a un événement et tout est fait par les types et les roles et les types de roles. Il n'y a aucune analyse ontologique. Il faut prendre la notion de factoïde au sens épistémologique: c'est l'information prise au niveau des sources. Ce n'est pas la même chose que l'information prise au niveau factuel.

Nos informations (insee, cassini, etc .) sont des factoïdes.

Pour implémenter ça, si on prend un système pur graphes, il vaut mieux utiliser le même vocab pour les différents niveaux épistémologiques (= utiliser des espaces de noms différents pour les sources et pour le niveau des faits).Utiliser Prov pour lier les faits aux factoides.

La population peut-être traitée comme une measurement: un territoire a comme qualité à une date t d'avoir comme population X hab. Pour sourcer cette information, il y a deux possibilités. On peut ajouter une valeur de confiance sur les infos extraites des sources.

Classe presence du cidoc: qui dit qu'un lieu a une présence dans l'espace qui peut changer dans le temps. Reprends l'idée de space-time cube.

On a des entités dont l'identité résiste à de nombreux changements: changement de lieu, de limites etc. Pour modéliser ça, "Presence" fait l'affaire.

## Réunion du 13 janvier 2021

### Ordre du jour
- point sur l'ontologie des communes.
- présentation à Francesco Beretta
- question de modélisation : factoïds, intentional collectives
- calendrier et contenu de la séance du PHN
- format et organisation de la séance : commune PHN/AP GCGH?

### Notes
CIDOC CRM - HistDMI HistSoc

### Présentation de l'ontlogie en cours de création
**Classe centrale = Circonscription.**
A l'origine, nous avions fait un premier modèle fondé sur le modèle Pleiades, centré sur les notions de Place/Name/Location. Mais cette notion de "Place" est relativement vague et nous semblait difficile à définir clairement. Donc on s'est concentrés sur les types de lieux qu'on souhaitait représenter pour notre cas d'application. Ce qu'on veut représenter: les communes, vues commes des territoires, et leurs évolutions au cours du temps. Une unité administrative c'est une collectivité territoriale (= une administration)+ une circonscription territoriale (= un territoire). C'est donc cette dernière notion que l'on a conservée, la notion de collectivité territoriale nous paraissant plutôt du ressors d'un ontologie du droit (d'où le lien avec la communauté qui travaille plutôt sur ce domaine.)

**Une circonscription peut avoir différentes "Qualities":**
- Limite conventionnelle qui a comme dimension "Position". Cette Position est une Place Appellation (= des coordonnées ou du texte).
- Population: le nombre d'individus recensés sur la circonscription, selon des règles de dénombrement qui veuvent varier selon le type de circonscription ou l'objectif du recensement.
- Nom: la dénomination de la circonscription.
- Rôle: désigne la fonction attribuée à une circonscription par une autorité, définie par un ensemble de réglementations, et qui définit les compétences qui lui sont déléguées.

### Réutilisation de l'ontologie des factoïdes:
Nous avons créé un espace de nom à part pour y importer des classes de l'ontologie des factoïdes pour nous permettre de représenter des assertions extraites de sources historiques et utilisables pour peupler les ressources du noyaux de notre ontologie (circonscription et qualities).

Ontologies de deux types: centrées ressources ou centrées événements.Ex. DBPedia est centrée ressources. Tout le problème pour représenter le passé est de pouvoir représenter les deux.

**Méthodologie à suivre:** on modélise le domaine puis on essaie de voir comment le modèle du domaine peut se raccrocher au modèle CIDOC et à HistDMI.

**Point sur les modèles de gazetiers type "World historical gazetteer":** Carmen: le but est de fournir un modèle très simple pour encourager les gens à partager/lier/publier des données sur les lieux nommés sur le Web. Francesco: la question c'est toujours celle de l'objectif que l'on vise. Un gazetier n'a pas le même objectif et pas le même niveau de complexité qu'une base de connaissances sur l'évolution des lieux au cours du temps. La communauté Linked Past crée des outils communs et des bonnes pratiques communes et parvient à durer dans le temps.

La partie "noyau" est une sorte de conceptualisation du monde tel qu'il est.
La partie "factoides" c'est l'ensemble des mentions aux entités du monde réel que l'on trouve dans dess sources.
Le CIDOC CRM modélise le monde tel qu'il est. Donc la partie fatoide est juste hors du champs du CIDOC CRM.
Dans la partie "noyau", le coeur est la notion de circonscription. Unité admin = une portion de la croûte terrestre + des limites
Dolce modélise le discours de base le CIDOC modélise une perception physique indiscutable de la réalité. Il a une perspective constructiviste.
Site = la scope note précise : on peut en faire une photo. Donc en fait une portion de la surface terrestre est un Site dans CIDOC, pas une Place.

Une circonscription est à la fois un objet social et un objet physique. Les limites sont construites socialement.
CIDOC Groupe = ensemble d'humain qui partagent une certaine conception des chosess qui leur permet d'agir ensemble.
Right = objet propositionnel.
Legal object = associe les objets d'un certain type à un droit (Right) qui est dans les mains (heldBy) d'un Actor.
Commune = acteur social, pas groupe de personnes. Le gouvernement de la commune est incarné par les humains qui constituent le conseil municipal à un instant t. C'est l'acteur social qui a le pouvoir d'exercer des actions sur la commune. Il faut modéliser le fait que la commune a un certain type de juridiction sur un territoire. Ce territoire est construit par une loi qui est promulguée et exprime le vote d'un parlement ou une décision politique ou administrative d'un gouvernement. Il y a un droit qui décrit l'action de la juridiction sur un territoire. Quelle est la substance ontologique de la classe circonscription? C'est un lieu géographique de HistDMI (GeographicalPlace). Ca fait le point de jointure avec les gazetteers. Où va l'objet social? Il va dans la limite conventionnelle. Sur un même territoire s'exercent différents types de droits et obligations de différentes personnes. C'est au niveau du type qu'on définit l'identitié du territoire, avec des typologies de type gazetteer. Le territoire est projeté dans la classe Place du CIDOC. La limite conventionnelle est un objet social décrit quelque part (PV de circonscription). Pendant un temps donné, il est convenu socialement que ce territoire a le slimites définies par ce place qui est un lieu géographique. Place dans CIDOC = limites conventionnelles.
Limites = Place au sens du CRM avec sa Place Appellation.
Geométrie est une approximation de Phenomenal Place.
Declarative Place = approximation de la Phenomenal Place.
Etendue de la commune de Paris en 1850 est une Place. La perception de la limite est différente de la limite qui est un lieu social.

Questions de Bertrand: si la circoncription est uniquement une geographical place, elle n'est pas temporelle. Comment on fait pour représenter le fait qu'elle subit des événements au cours du temps (fusion, scission, absorption, etc.)?

Le phénomène qu'on veut modéliser comprend différente conceptualisations:
- il y a des objets physiques (portions de la surface terrestre)
- il y a des limites qui changent avec le temps
- il y a la question de qui exerce le pouvoir sur le territoire

Comment représenter l'identité? Dans le CRM le type fixe l'identité de l'objet. Si on met plusieurs types, c'est une classification. Si on applique le conceptualisation de différentes disciplines, leurs conceptualisations seront différentes et concurrentes. Si on prend le CRM comme référentiel conceptuel, il faut utiliser physical feature pour les portions de l'espace terrestre. Le type à utiliser pour le décrire est "circonscription".

Conclusion: remplacer la classe Circoncription la classe Geographical Place + un lien vers une typologie (thesaurus SKOS ou autre) pour préciser le type de circonscription territoriale que représente cette portion de la croûte terrestre. Geographical Place = Lieu nommé.

Limites à telle date de la circonscription administrative

La circonscription existe le jour ou un social event intervient pour décider de sa création (= publication au JORF). Notre territoire communal est-il un objet physique seulement ou aussi un objet social?

Commune = objet propositionnel?
Social connotation =
Créer une sous-classe "Création de Territoire"?
Question de Bertrand: Le territoire communal est-il le produit d'une décision légale ou bien est-ce que le CIDOC considère qu'il préexiste et que des événements s'y appliquent et décident de l'affecter à la commune?

Prochaine réunion: vendredi 15 janvier 10h-12h.

## Ressources
#### Schéma de l'ontologie des évolutions communales en cours de construction : https://app.diagrams.net/#G1DVyYHFNeCKA_6njmwZS_d5t9SGmqZ9S6
#### Ontologie Factoïds : https://www.kcl.ac.uk/factoid-prosopography/ontology
#### Historique des communes 1793-2000 (schéma INSEE, évènements seulement) : https://docs.google.com/spreadsheets/d/1gJLhpiF5WG3yUX5aN5nFLUgN3ZSH7idH_uYovfBxwzY/edit?usp=sharing

#### Données communales EHESS originales : http://filez.ehess.fr/y439wbi

### Questions de Nathalie, 27/11/2020
- Pour lier nos circonscriptions à leurs qualités (nom, localisation, population etc.), nous souhaitons utiliser directement la propriété "P22 has quality". Or celle-ci est prévue pour lier une "CRM Entity" à une "Quantifiable quality". Mais dans notre cas, toutes les propriétés dont nous avons besoin ne sont pas des "Quantifiable quality". Y a-t-il une raison particulière qui justifie le choix de ce "range" restreint, plutôt que "Entity Quality"?

**[FRANCESCO]** Si on adopte la méthodologie appliquée également dans le développement du CIDOC CRM par Martin Doerr et le SIG (et que je considère pour ma part très robuste) il faut éviter le top down au sens de créer des classes de haut-niveau fourre-tout avec des propriétés très génériques qui sont héritées de partout sans qu'on ait vérifié si elles s'appliquent vraiment partout. Le nom, la localisation, la population ont une substance ontologique différente, il vaut mieux avoir des classes explicites dans leur intension, avec les bonnes propriétés, bien vérifiées, pour éviter que des objets conceptuels, par ex. soient directement localisés dans l'espace géographique, ce qui est absurde. Est-ce que associer à tout 'Entity quality' au sens 'qualitatif' a du sens ? Pas sûr du tout, d'où la cardinalité proposée.

La classe hist:C28 Quantifiable Quality ne fait que ajouter la temporalité à la propriété crm:P39 measured (was measured by) – une mesure est ponctuelle, la qualité quantitative exprime une stabilité de la valeur pour une durée, la substance est la même dans le fonds, sauf la temporalité.

- Nous avons repris des classes de l'ontologie des factoïdes pour la prosopographie (https://www.kcl.ac.uk/factoid-prosopography/ontology) et, en guise de mécanisme d'import, les avons implémentées dans un projet à part. Pour les lier à nos propre classes, nous avons besoin de créer une propriété dont le domaine serait "Entity Quality" et le range "Reference". Mais nous n'arrivons pas à créer cette propriété dans notre namespace car la classe "Entity Quality" n'est pas définie là... Y a-t-il un moyen de contourner cette contrainte?

**[FRANCESCO]** Je crois que Vincent vous a déjà répondu sur ce point. Concernant les factoïdes, la différence avec l'information factuelle est épistémologique. C'est la distinction entre la mention de l'événement par la source (factoid) et le fait comme tel, dérivé de plusieurs sources. Ceci étant dit, on n'a pas besoin à mon avis de récupérer l'ontologie londonienne car elle ne contient que le modèle général, non l'application au domaine. On peut à mon avis utiliser directement le CRM et ses extensions mais avec un mécanisme de 'relecture' qui indique clairement qu'il y a une seule source pour un 'factoïde', i.e. un named graph par ex. On peut souligner le statut épistémologique de l'entrepôt sans introduire des patchworks.

- Nous avons fait quelques erreurs dans notre ontologie que nous souhaiterions supprimer mais nous n'avons pas trouvé comment: y a-t-il un moyen sous OntoMe de supprimer des classes ou des propriétés?

### Réponse de Francesco, 17/12/2020

- Pour expliquer l'importance de ce travail permettez-moi de citer les auteurs d'une récente synthèse des développements dans le domaine des ontologies du droit: "However, despite the general acceptance of these good practices for the release of resources [the adoption of RDF and OWL], the overall objective of a shared representation of legal knowledge has not been reached yet. The reuse of legal knowledge in fact requires a wide awareness of the already available resources which model the domain of interest. In order to evaluate a possible reuse, all the actors involved in the ontology building process, i.e. legal experts as well as developers, need to be constantly up-to-date about the state-of-the-art and they are expected to deepen the ontological commitment and the methodological choices adopted by each resource. If not, the risk is to create and release on the Web redundant representations of knowledge, which obstruct the economy of information promoted by the Semantic Web." Valentina Leone, Luigi Di Caro, et Serena Villata, « Taking stock of legal ontologies: a feature-based comparative analysis. », Artif. Intell. Law 28, no 2 (2020): 207‑35, https://doi.org/10.1007/s10506-019-09252-1 (souligné par moi).

- Il est évident que nous nous trouvons dans la même situation du côté des disciplines géo-historiques. On constate souvent que les projets s'inspirent plus ou moins librement de l'une ou de l'autre ontologie, vingt ans de publications dans ce domaine sont souvent ignorés, on fait ensuite des patchworks de classes et propriétés en prenant ce qui paraît utile —à la lecture des labels et sans s'intéresser à l'intension— ou alors on invente de nouvelles approches sans avoir d'abord vérifié ce qui existe déjà et on propose comme ontologie (conceptualisation partagée par un vaste communauté et formalisée) ce qui n'est en réalité qu'un modèle local, fût-il bien fait et exprimé en OWL. Comme le disent les auteurs cités, l'interopérabilité ne peut pas exister si on procède ainsi. Car elle n'est pas seulement technique mais elle doit être conceptuelle, intensionnelle. Du moins pour une discipline scientifique comme l'histoire, et si on souhaite que les données soient réellement réutilisables.

- Ce que j'écris s'applique avant tout au projet symogih.org et c'est bien à cause du fait que j'ai pris conscience de ce problème majeur de "l'ontologie" de symogih.org que depuis 2015 je m'efforce d'apporter ma contribution scientifique dans ce domaine, en participant aux SIG du CIDOC CRM pour comprendre le CRM, en lisant, en essayant de proposer une conceptualisation qui tient compte des travaux publiés et de l'approche des sciences historiques et sociales, en essayant d'animer une communauté dans le projet dataforhistory.org. Le futur dira si cette contribution aura eu quelque utilité.

- J'ai souhaité partager ces réflexions avec vous pour situer mon propos et mes efforts. Et pour vous inviter, si vous le souhaitez, à participer à ce processus et à approfondir ensemble la réflexion par rapport à votre domaine.

### Réponse de Vincent, 30/11/2020
Bonjour à toutes et à tous,

dans OntoME, vous pouvez créer une propriété associée à votre espace de noms dont les domain et range appartiennent à un autre espace de noms.

Pour cela plusieurs étapes :

- En premier lieu, activez le projet qui gère l'espace de noms ongoing qui va accueillir la propriété. Vérifiez que vous avez bien défini le ou les espaces de noms avec lesquels votre espace ongoing sera en relation. Dans la fiche de votre espace ongoing, onglet "Identification" sélectionnez un ou plusieurs espaces de référence. Les classes et propriétés de ces espaces de référence vous seront alors proposés dans les différents menus des propriétés et relations. Actuellement, le fait d'ajouter un espace de noms dans vos "Current namespaces" vous permet de sélectionner les classes et propriétés d'un autre espace de noms pour vos relations mais nous avons convenu qu'il s'agissait d'une mauvaise pratique et cela ne sera plus possible lors de la prochaine mise à jour d'OntoME. Je vous invite donc dès aujourd'hui à veiller à bien utiliser les espaces de référence pour vos relations. Un espace de noms de référence est automatiquement associé à l'espace qui l'a sélectionné. Sélectionnez enfin la classe domain de la propriété que vous souhaitez créer puis dans l'onglet "Properties" de la classe, procédez de la manière habituelle. La propriété créée sera associée à votre espace ongoing.

- Concernant la suppression des classes et propriétés, cette fonctionnalité n'est pour l'instant pas implémentée. Vous pouvez en revanche réutiliser une classe ou une propriété déjà existante. Dans l'importante mise à jour que nous sommes en train de préparer, et qui devrait être mise en ligne en janvier, il vous sera possible de valider des classes et des propriétés en vue de leur publication dans un espace de noms fermé. Ainsi les classes et propriétés non validées n’apparaîtront pas dans cet espace publié.

- Comme la suppression est cependant une demande récurrente des utilisateurs, nous allons en reparler et envisagerons peut-être d'introduire cette fonctionnalité dans une mise à jour future.

- Sinon, par rapport à Factoïd, nous sommes en contact avec John Bradely et avions le projet d'importer l'ontologie dans OntoME. Nous pourrons en reparler.

- Enfin, pour vos questions plus ontologiques et sur la pertinence d'utiliser Factoïd, Francesco vous répondra dans les prochains jours.