Difference between revisions of "Physical measurement - Mesure physique"

From KarstLink
m
Line 30: Line 30:
 
  |-
 
  |-
 
  |}
 
  |}
 +
  
 
{| class="wikitable alternance center" width="90%"
 
{| class="wikitable alternance center" width="90%"
 
  |-
 
  |-
  ! scope="col" width="45%" | Sensor data: time series(en)
+
  | scope="col" width="45%" | Sensor data: time series(en)
  ! scope="col" width="45%" | Données de capteurs: séries temporelles(fr)
+
  | scope="col" width="45%" | Données de capteurs: séries temporelles(fr)
 
  |-
 
  |-
! KLS2 proposal
 
  For the large amount of data produced by our usual sensors (pressure, temperature, etc.) 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.
 
  The time-series class may look like:
 
  
 +
| KLS2 proposal
 +
  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.
 +
  The time-series metadata class may look like:
  
   
+
| proposition KSL2
 +
  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.
 
  |-
 
  |-
 
  |}
 
  |}

Revision as of 03:24, 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)
KLS2 proposal
 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.
 The time-series metadata class may look like:
proposition KSL2
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.