Talk:Entities - Entités

Prepare your arguments/proposal here	Préparez vos arguments/propositions ici
NOTA BENE: The document used as a common thread during general conferences is available HERE	NOTA BENE : Le document qui sert de fil conducteur lors des conférences générales est disponible ICI.

Topics 1 to 3 -- Sujets 1 à 3

Topic 1 : Objects "cave" & "mine"	Sujet 1 : Objets "cavité" et "mine"
"Cave", "mine" are in the same proposal A. It will be necessary to add other objects. If this proposition is not suitable, it's possible to formulate another (B), possibly with the same objects described otherwise, or with other objects. Frédéric Urien (talk) 01:58, 1 March 2020 (CST)	"Cave", "mine" sont dans la même proposition A. Il faudra ajouter d'autres objets. Si cette proposition ne convient pas, il est possible d'en formuler un autre (B) éventuellement avec les mêmes objets décrits autrement, ou avec d'autres objets. [Traduction by Google and BTH ; May 8th, 2020]
Topic 2 : Object "Module"	Sujet 2 : Objet "Module"
We propose object "Module" because it seems more appropriate to group the observations related to themes such as, bio-speleo, archaeology, geology, hydrology (tracing), rescue, environment, bibliographic references, etc. [Traduction by Google and BTH ; May 8th, 2020]	Nous proposons l'objet "Module" car il nous semble plus opportun de regrouper les observations liées à des thèmes comme, la bio-spéléo, archéo, géologie, hydrologie (traçages), secours, environnement, références biblio, etc. [Patrick Degouve et François Ichas]
Topic 3 : Super-type "Observations"	Sujet 3 : Super-type "Observations"
On suggestion from my Semantic Web colleagues, I Introduced "Observations" as a "super type" for various observations and measurements. It simplifies the ontology, and make extensions easier. I think that it is a bit more specific than what Patrick and Francois call "modules", because I want observations to have many common relations with other objects, which may not be the case with e.g. bib-refs, or rescue information. [Eric Madelaine, April 11]	À la suggestion de mes collègues du Web sémantique, j'ai présenté les « Observations » comme un « super type » pour diverses observations et mesures. Cela simplifie l'ontologie et facilite les extensions. Je pense que c'est un peu plus spécifique que ce que Patrick et François appellent des "modules", parce que je veux que les observations aient de nombreuses relations communes avec d'autres objets, ce n'est peut-être pas le cas par exemple pour les bib-refs, ou les secours. [Eric Madelaine, April 11]

Topics 4 to ... -- Sujets 4 à ...

Topic 4 : Methodology	Sujet 4 : Méthodologie
In fact each object is different and will therefore be represented by different properties and relationships. It is therefore essential to list the elements you wish to describe. Biblio references are already in place with the document object that is already in the list. for the others it is necessary to arrive to describe them and then we will seek if ontologies already exist. It will be necessary to ask whether they are specific objects or only properties of the cavities. We will make a specific object if we need to have a specific URI, as if we had a specific database which could exist without the others independently. Frédéric Urien (talk)	En fait chaque objet est différent et sera donc représenté par des propriétés et des relations différentes. Il est donc indispensable de faire la liste des éléments que vous souhaitez décrire. Les références biblio sont déjà en place avec l'objet document qui est déjà dans la liste. pour les autres il faut arriver à les décrire et ensuite nous rechercherons si des ontologies existent déjà. Il faudra se demander si ce sont des objets spécifiques ou seulement des propriétés des cavités. on va faire un objet spécifique si on a besoin de disposer d'une URI spécifique, comme si nous avions une base de donnée spécifique qui pourrait exister sans les autres de manière indépendante. Frédéric Urien (talk)
Food for thought From my experience, it seems necessary to me to separate 2 (pseudo-)karst objects: Surface objects SURF OBJ (cave entrance, sump, spring, opening, ouvala, dolina, canyon, borehole, shafts, cenote, tiankeng, tsingy, etc). Underground voids VOID (can be called: cave passage, mine, quarry, lave tube... but are basically the same) Regarding their relations: a POINT is an abstract geographic object. It can have coordinates, positionning error, confidentiality properties (and almost only that). a SURF OBJ can be linked to a POINT, can have properties according to their type (i.e: diameter, length, height, depth, polygon, etc), DOCUMENTS (pictures) a VOID can be linked to one or many SURF OBJ. A VOID is NOT linked to a POINT (VOIDs do not have intrinsic coordinates).*Note 1 an OBSERVATION can be linked to one POINT, can be linked to one VOID or SURF OBJ, people, organization) Generally, from reading the object descriptions presented on this wiki (Apr. 21, 2020), it seems like the links proposed under each object could be refined to be more usable, structured and meaningful. Some examples (non exhaustive): - I really don't see the underlying reality in directly linking a VOID and a PEOPLE. PEOPLE may be linked to organisations, to documents, to explorations, to observations. - The reasons to link a VOID or a SURF OBJ to an organisation would be if the organisation is the owner or is in charge of protecting the VOID, or granting access to the SURF OBJ. - I don't see the underlying reality in linking a point to an organisation or a document. An organisation has an adress. A document can be linked to a VOID or an observation, not to a point. - it is written "An underground cavity can be made up of underground cavity parts". "Cavity parts" haven't been described and I think seem unnecessary. _*note 1: in case of a VOID not linked to a SURF OBJ, the VOID could be either of unknown position, or remote detected. in the latter case, a SURF OBJ called 'virtual' could be linked to the VOID for positioning --Olivier Testa (talk) 11:57, 21 April 2020 (CDT) Some elements to answer to Olivier Testa We have a link between void and person or organization like "visited", "explored", "discovered". About the relations between point and person or organisation they can be similar to those which I propose between void and person or organization. About the relationships between point and document: the csv temperature measurement file is a document which can be associated with the point where these measurements were made. --Frédéric Urien (talk) 01:16, 22 April 2020 (CDT)	Nourrir les réflexions D'après mon expérience, il me semble nécessaire de distinguer deux objets concernant le (pseudo-)karst : les objets suface "SURF OBJ" (entrée de cavité, siphon, source, ouverture, ouvala, doline, canyon, forage, puits, cenote, tiankeng, tsingy, etc.) les vides souterrains" "VOID" (qui peuvent s'appeler : grotte, mine, carrière, tube de lave... mais sont en base de même nature) Concernant leurs relations : Un "POINT" est un objet géographique abstrait. Il peut avoir des coordonnées, une erreur de positionnement, des propriétés de confidentialité (et c'est à peu près tout). Un "SURF OBJ" peut être lié à un "POINT", peut avoir des propriétés selon son type (par exemple : diamètre, longueur, hauteur, profondeur, polygone, etc), "DOCUMENTS" (images) Un "VOID" peut être lié à un ou plusieurs "SURF OBJ". Un "VOID" n'est pas lié à un "POINT" (les "VOID"s n'ont pas de coordonnées intrinsèques)_Note 1 Une "OBSERVATION" peut être liée à un "POINT", peut être liée à un "VOID" ou à un "SURF OBJ", un "PEOPLE", une "ORGANIZATION". En général, en lisant les descriptions d'objets présentées dans la page wiki (Apr. 21, 2020), il semble que les liens proposés sous chaque entité pourraient être affinés afin d'être plus utilisable, structurés et porteurs de sens. Quelques exemples (non exhaustif) : - Je ne vois pas la réalité sous-jacente au fait de lier directement un "VOID" avec un "PEOPLE". "PEOPLE" peut être lié avec des organisations, des documents, des explorations, des observations. - Les raisons de lier un "VOID" ou un "SURF OBJ" à une organisations seraient que l'organisation est propriétaire ou bien est en charge de protéger le "VOID" ou de fournir l'accès au SURF OBJ. - Je ne vois pas la réalité sous-jacente au fait de lier un point à une organisation ou à un document. Une organisation a une adresse. Un document peut être lié à un VOID ou à une organisation, pas à un point. - Il est écrit "Une cavité peut être constituée de parties de cavités". La notion de "partie de cavité" n'a pas été définie et me paraît inutile. _Note 1 : En cas de VOID non lié à un SURF OBJ, le VOID peut être de position inconnue ou détecté à distance. Dans ce dernier cas, un SURF OBJ dit "virtuel" pourrait être lié au VOID pour le positionner. [Translated by BTH le 8 mai 2020 - Traduit par BTH le 8 mai 2020] Quelques éléments de réponse à Olivier Testa Nous avons une relation entre "Vide" et "Personne" ou "Organisation", du type "visité" ou "exploré" ou "découvert". A propos des relations entre "Point" et "Personne" ou "Organisation", elles peuvent être similaires à celles que je propose entre "Vide" et "Personne" ou "Organisation". A propos des relations entre "Point" et "Document" : le fichier CSV des mesures de température est un document qui peut être associé au point où ces mesures ont été faites. [Translated by BTH le 8 mai 2020 - Traduit par BTH le 8 mai 2020]
Agile mode The understanding of the web of objects, then its implementation, is obviously not simple. The perception of the level of abstraction of an ontology varies from one person to another. To converge more quickly towards a common global vision, we could adopt an agile mode which consists in defining an ontological core, a kind of "core of ontology", with a minimal number of entities, having a meaning as generic as possible. For example, with the following 3 entities, it seems to me that we can build a prototype 3.0 which would serve as POC ( proof of concept ) and then as a database kernel, allowing to guide the other partners in the progressive approach of their more specialized ontologies : Entity 1 = "Void - Vide" (which can be broken down into: crack, joint, room, gallery, well, sump, network, underground system, ..) Entity 2 = "Point - Point" (which can be broken down into: entrance, topo point, observation point, POI, ...) Entity 3 = "Zone - Area" (which can be broken down into: administrative entity, massif, geological layer, access restriction, submerged area, passage with spelothems ...) What do you think about it ? [Bernard THOMACHOT bth.grottocenter_at_orange.fr May 8th 2020]	Mode agile La compréhension du web des objets, puis sa mise en oeuvre, n'est visiblement pas simple. La perception du niveau d'abstraction d'une même ontologie varie d'une personne à l'autre. Pour converger plus vite vers une vision globale commune, nous pourrions adopter un mode agile qui consiste à définir un noyau ontologique, une sorte de "coeur d'ontologie", avec un nombre minimal d'entités, ayant un sens le plus générique possible. Par exemple, avec les 3 entités suivantes, il me semble que l'on peut construire un prototype 3.0 qui servirait de POC (proof of concept) puis de noyau de base de données, permettant de guider les autres partenaires dans l'accostage progressif de leurs ontologies plus spécialisées : Entité 1 = "Vide - Void" (qui peut se décliner en : fissure, diaclase, salle, galerie, puits, siphon, réseau, système souterrain, ..) Entité 2 = "Point - Point" (qui peut se décliner en : entrée, point topo, point d'observation, POI,...) Entité 3 = "Zone - Area" (qui peut se décliner en : entité administrative, massif, couche géologique, restriction d'accès, zone noyée, zone concrétionnée...) Qu'en pensez-vous ? [Bernard THOMACHOT bth.grottocenter_at_orange.fr le 6 mai 2020]
Topic 5 : none, so far	Sujet 5 : rien à ce jour
bla bla	bla bla
Topic 6 :	Sujet 6 :
etc.	etc.