Difference between revisions of "Physical measurement - Mesure physique"

Revision as of 03:32, 8 June 2022

Step 1 / Étape 1
Choice of support ontology for physical measurement (en)	Choix d'une ontologie support pour les mesures physiques (fr)
State: draft	État : brouillon
Planned vote: date to be determined later	Vote prévu : date à déterminer ultérieurement

Propositions / Proposals	Remarks (en)	Remarques (fr)
A : SSN	The SOSA and SSN ontologies are proposed by the W3C. SOSA is the core subset of SSN, sufficient for our needs and easier to use than full SSN. They provide descriptions of Sensors, PropertyOfInterest, and Observations: a sensor observes some property of an object (FeatureOfInterest) and yields a Result. Actuators will not be used for us.	Les ontologies SOSA et SSN (Semantic Sensors Network, et Sensor, Observation, Sample, Actuator) sont proposées par le W3C. SOSA est le noyau de SSN, plus simple, et suffisant pour nos besoins. Il permet de décrire les capteurs (Sensor), les Observations (acte d'observer ou de mesurer), les valeurs (Results) de la grandeur ou propriété observée (ObservableProperty) d'un objet (FeatureOfInterest). Nous n'utiliserons pas les Actuators.
B : FIWARE	European consortium on smart city IOT open source productions	Consortium européen sur les smart city IdO productions open source

Sensor data: time series (en)	Données de capteurs: séries temporelles (fr)
For the large amount of data produced by our usual sensors (pressure, temperature, etc.) in long periods of measures, it is not realistic to encode each measure by a class instance. We propose to keep the data in a textual format close to the provider generated data (.cvs, .txt), with entities specificaly describing the metadata of each of these time series.	Pour les grandes quantités de données produites par nos capteurs (pression, température, etc.) sur de longues périodes, il n'est pas raisonnable d'encoder chaque mesure par une instance d'observation. Nous proposons de conserver les données dans un format texte proche de celui créé par les logiciels du fournisseur, et de fournir une entité "méta-données" associée à chacun de ces fichiers.
The time-series metadata class may look like:	Les méta-données d'une svrie temporelle devraient ressembler à :

@@ Line 38: / Line 38: @@
   |-
   | For the large amount of data produced by our usual sensors (pressure, temperature, etc.) in long periods of measures, it is not realistic to encode each measure by a class instance. We propose to keep the data in a textual format close to the provider generated data (.cvs, .txt), with entities specificaly describing the metadata of each of these time series.
+ | Pour les grandes quantités de données produites par nos capteurs (pression, température, etc.) sur de longues périodes, il n'est pas raisonnable d'encoder chaque mesure par une instance d'observation. Nous proposons de conserver les données dans un format texte proche de celui créé par les logiciels du fournisseur, et de fournir une entité "méta-données" associée à chacun de ces fichiers.
+ |-
   | The time-series metadata class may look like:
-  |-
+  | Les méta-données d'une svrie temporelle devraient ressembler à :
- |Pour les grandes quantites de donnees produites par nos capteurs (pression, temperature, etc.) sur de longues periodes, il n'est pas raisonnable d'encoder chaque mesure par une instance d'observation. Nous proposons de conserver les donnees dans un format texte proche de celui cree par les logiciels du fournisseur, et de fournir une entite "meta-donnees" associee a chacun de ces fichiers.
   |-
   |}