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.
Topic 1 : objects "cave" & "mine"	Sujet 1 : objets "cavité" et "mine"
"Cave", "mine" are in the same proposition 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)
Topic 2 : object "module"	Sujet 2 : objet "module"
	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]
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 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).* 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 the 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)
	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'objets, ayant un sens le plus générique possible. Par exemple, avec les 3 objets suivants, 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 : Objet 1 = "Vide - Void" (qui peut se décliner en : fissure, diaclase, salle, galerie, puits, siphon, réseau, système souterrain, ..) Objet 2 = "Point - Point" (qui peut se décliner en : entrée, point topo, point d'observation, POI,...) Objet 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.