1 / 35

UPM – Project Meeting Innsbruck - Feb/March 2011

UPM – Project Meeting Innsbruck - Feb/March 2011. WP1 – D1.1 - TOC. Introduction (UPM) Characterization Mechanisms for Single-Modality Unknown or Changing Data Sources Characterization Mechanisms for Multi-Modality Combinations of Unknown or Changing Data Sources Conclusion (UPM).

kory
Download Presentation

UPM – Project Meeting Innsbruck - Feb/March 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. UPM – Project MeetingInnsbruck - Feb/March 2011

  2. WP1 – D1.1 - TOC • Introduction (UPM) • Characterization Mechanisms for Single-Modality Unknown or Changing Data Sources • Characterization Mechanisms for Multi-Modality Combinations of Unknown or Changing Data Sources • Conclusion (UPM)

  3. WP1 – D1.1 – Single Modality • 1. Characterization Mechanisms for Single-Modality Unknown or Changing Data Sources • 1.1 Sensor Data Streams: Semantic Model Generation (UPM + JSI + EPFL) • Obtain domain ontologies based on metadata about sensors + numeric values obtained from them --- UPM • Relate these sensor data sources with other external knowledge sources (e.g., from tags to Cyc/DBPedia) --- JSI • In all cases, overarching usage of SSN Ontology for sensor sources description (demonstrated with various platforms, like GSN, Pachube, ad-hoc deployments, etc.) --- JSI, EPFL, UPM • 1.2 Text Streams: data analysis (JSI) • e.g., Twitter

  4. WP1 – D1.1 – Multi Modality • 2. Characterization Mechanisms for Multi-Modality Combinations of Unknown or Changing Data Sources • 2.1 Near Real Time Mapping between Textual Sources and Social Networks (JSI) • 2.2 Ontology-based Data Integration for Multi-Modality Data Sources (UPM) • Integration of sensors with relational databases (e.g., current continuous temperature values with average (normal) values for a region)

  5. Background • Previous work at UPM: • Mapping data streams to ontologies • Use ontological schemas to write queries over streaming data sources • Rewriting SPARQL-Stream queries into declarative stream queries (e.g. SNEEql) • Experience in Flood environmental sensor data. Calbimonte, J-P., Corcho O., Gray, A. Enabling Ontology-based Access to Streaming Data Sources. In ISWC 2010.

  6. Ontology-based Data Access SPARQLStream algebra(S1 S2 Sm) Query translation q SNEEql Sensor Network (S1) SPARQLStream (Og) Relational DB (S2) Query Evaluator Stream-to-Ontology mappings Client Stream Engine (S3) RDF Store (Sm) Data translation [tuples] [triples] Ontology-based Streaming Data Access Service

  7. EPFL GSN • Deployment for SwissEx • Distributed environment: GSN Davos, GSN Zurich, etc. • In each site, a number of sensors available • Each one with different schema • However overlapping concepts in the schemas, e.g. temperature • Metadata stored in wiki • Federated metadata management: • Jeung H., Sarni, S., Paparrizos, I., Sathe, S., Aberer, K., Dawes, N., Papaioannus, T., Lehning, M.Effective Metadata Management in federated Sensor Networks.  in SUTC, 2010

  8. Initial look at GSN SwissEx data • Mirror data available. • Web service interface: planetdata.epfl.ch:22001/services/GSNWebService?wsdl • ListVirtualSensorNames • wannengrat_gupf_unten • wannengrat_unterhalb_felsen • wan2 • wan_sen7_2008 • wan_sen4_2008 • etc • Each one has a schema (attributes and types, etc)

  9. GSN getting data • getMultiData • Can request for a specific virtual sensor • Can request data from ALL sensors • Queries configured (can add new queries as well) • Sample query: • select pk, air_temperature, relative_humidity, incoming_shortwave_radiation, outgoing_shortwave_radiation, net_shortwave_radiation, wind_speed_50cm, wind_speed_100cm, wind_speed_200cm, wind_speed_max_50cm, wind_speed_max_100cm, wind_speed_max_200cm, wind_direction, precipitation, battery_voltage, timed from wannengrat_tib3 where timed > 1271638922851 and timed <= 1298473500346 and pk < 9223372036854775807 order by timed desc (size: 20 offset: 0)

  10. Enabling Semantic Integration of Streaming Data Sources GSN getting data • The web service parameters allow basic query configuration: • Include all/some fields (fieldNames) • Add basic selection conditions • Add aggregations • Indicate lower/upper time (time-based selection)

  11. Idea • Add Ontology-based distributed query processing: • provide me all temperature sensors that have shown higher than 30 degrees • Use ontological schemas fro queries, internally map to the appropriate sensors • Query rewritten and dispatched to the appropriate GSN instances • Return query results URL query Wiki GSN Davos Metadata Distributed QP GSN Zurich GSN Chur

  12. WP1 – SSN Ontology • Status : Stable • http://www.w3.org/2005/Incubator/ssn/wiki/images/3/36/Ssn.xml • Usage : • Data Discovery and Linking • Device Discovery and Selection • Provenance and Diagnosis • Device Operation Tasking and Programming • http://www.w3.org/2005/Incubator/ssn/wiki/Report_Motivating_Use_cases#Use_cases

  13. Ontologies overview Upper DOLCE UltraLite SWEET SSG4Env infrastructure SSN Schema Service External FOAF OrdnanceSurvey Flood domain Role CoastalDefences AdditionalRegions 17

  14. Ontologies Infrastucture • Core sensor network ontology • Service and schema ontologies Domain • Flood use case ontology network 18

  15. Legend Module Class Individual property Class = objectProperty only | some Class objectProperty only | some Class

  16. Overview of the SSN ontology modules Deployment System OperatingRestriction Process Device PlatformSite Data Skeleton MeasuringCapability ConstraintBlock

  17. Overview of the SSN ontologies deploymentProcesPart only Deployment System OperatingRestriction hasSubsystem only, some hasSurvivalRange only SurvivalRange DeploymentRelatedProcess hasDeployment only System OperatingRange Deployment hasOperatingRange only deployedSystem only deployedOnPlatform only Process hasInput only inDeployment only Device Input Device Process onPlatform only PlatformSite Output Platform hasOutput only, some attachedSystem only Data Skeleton implements some isProducedBy some Sensor Sensing hasValue some SensorOutput sensingMethodUsed only detects only SensingDevice observes only ObservationValue SensorInput isProxyFor only Property isPropertyOf some includesEvent some observedProperty only observationResult only hasProperty only, some observedBy only Observation FeatureOfInterest featureOfInterest only MeasuringCapability ConstraintBlock hasMeasurementCapability only forProperty only inCondition only inCondition only MeasurementCapability Condition

  18. Sensor and environmental properties Skeleton Property MeasuringCapability Communication hasMeasurementProperty only MeasurementCapability MeasurementProperty Accuracy Resolution Selectivity Frequency Precision Latency DetectionLimit Drift ResponseTime Sensitivity MeasurementRange OperatingRestriction EnergyRestriction hasOperatingProperty only OperatingProperty OperatingRange EnvironmentalOperatingProperty MaintenanceSchedule OperatingPowerRange hasSurvivalProperty only SurvivalRange SurvivalProperty EnvironmentalSurvivalProperty SystemLifetime BatteryLifetime

  19. Alignment to DOLCE UltraLite DOLCE UltraLite PhysicalObject InformationObject or Event DesignedArtifact Object Process Situation Method Event Quality Region Process PlatformSite System Deployment Process Platform System DeploymentRelated Process Device Deployment Device Skeleton Data Observation Sensor Sensing Property ObservationValue SensorOutput SensingDevice SensorInput FeatureOfInterest

  20. Ontologies Infrastucture • Core sensor network ontology • Service and schema ontologies Domain • Flood use case ontology network 24

  21. Service ontology XSD SWEET hasSpatialExtent coversRegion hasStyleURL sw:Region sw:SpatialExtent xsd:string xsd:anyURI hasTemporalExtent sw:Dataset sw:TemporalExtent hasEndpointReference hasDataset SSN ssn:Property Schema Metadata includesProperty WebService hasSchema sm:Schema ssn:FeatureOfInterest includesFeature StatefulWebService ISO 19119 containsOperation hasParameter Interface Operation Parameter hasInterface hasServiceType DataAccessInterface … ServiceType OGCS.T. SSG4EnvS.T. GeoJSONS.T. XMLS.T. RSSXMLS.T. 25

  22. Schema Metadata ontology hasPrimaryKey Extent PrimaryKey SSN ssn:Property hasExtent hasAttribute or equivalentToProperty Relation Stream hasSQLType Schema Attribute SQLType hasTimestampAttribute DatabaseSchema DataStreamSchema TimestampAttribute 26

  23. Ontologies Infrastucture • Core sensor network ontology • Service and schema ontologies Domain • Flood use case ontology network 27

  24. Coastal Defences ontology SSN SWEET ssn:hasProperty locatedInRegion ssn:Property ssn:FeatureOfInterest sw:Region OS Asset … os:TopographicObject hasOceanRegionProperty AssetProperty … OceanRegionProperty OceanRegion TideHeight WaveHeight 28

  25. Features and properties • Physical atmosphere • Air temperature • Wind speed • Wind direction • Visibility • Asset • Height • Condition • Class • Width • Inspection date • Maintainer • Location • Mastermap Id • Flood plain • Water depth • Flood zone • Flood zone type • Flood defence policy • Strategic defence option • Ocean region • Wave height • Tide height • Vessel • Location • Name • Bearing • Type • Size • Callsign • Speed • ETA • Road problem • Location • Road identifier • Description • Event time 29

  26. Additional Regions ontology • Coastal Defence Partnership • Coastal Defence Partnership (Modelled area) • Solent • Solent (Modelled area) • South East England • South East England (BRANCH) • South East England (CCO) • Southern Coastal England (CCO) • Solent (AIS live) • South East England (Highways Agency) • South West England (Highways Agency) sw:Region gz:NamedPlace 30

  27. Role ontology SWEET sw:Region operatesWithin appliesTo hasRegionOfResponsibility Duty hasSubOrganization isAssignedTo defines FOAF hasResponsibility foaf:Organization Responsibility foaf:member foaf:Person isFulfilledBy hasPosition occupies Position SSN hasRelatedProperty assumesRole ssn:Property undertakesTask ssn:hasProperty Role Task ssn:FeatureOfInterest hasRelatedFeature 31

  28. WP2 – Contribution Plan • Tools for transforming geography objects (GML, Oracle Spatial, etc) to RDF • http://mccarthy.dia.fi.upm.es/geometry2rdf/ • Geometry2rdf presentation for more detail

  29. WP4 – PlanetData Vocabulary • Documentuploadedon wiki WP4 page (Jan 2011) • Feedback and comments? • Analysis of existingvocabularies • Identifyprominentfeatures of analyzedvocabularies • General PurposeVocabularies • DC • DatasetPurposeVocabularies • Dcat • Void • StreamPurposeVocabularies • Pachube InformationModel • Sstream • SSN

  30. WP4 – PlanetData VocabularySome Examples - SStream • Pollution sensor measuring CO2 emission • Continuous • Valid for 1 hour • :COSensor1 a ss:Sensor. :COSensor1Stream a ss:ContinuosStream; ss:expires P1H; contains :COSensor1StreamContent.

  31. WP4 – PlanetData VocabularySome Examples - Pachube • Notclearlydefined • Basedonits API • Environmentproperties • Static vs dynamic • Outdoor vs indoor • Live vs frozen • : MadridStreet1 a pachube:Environment; pachube:location_lat 40.26; pachube:location_long 3.42; pachube:environment_disposition "Static"; pachube:environment_exposure "Outdoor"; pachube:environment_domain "Physical"; pachube:feed_status "Live"; pachube:hasDatastream :COSensor1. :COSensor1 a pachube:DataStream.

  32. WP4 – PlanetData VocabularySome Examples – Sstream+Pachube • Sensor on Fred • Heartrate • Private data • Restrictionto hospital • Every 5 minutes • :Fred a foaf:Person; ss:sensor :HeartSensor. :HeartSensor a ss:Sensor; ss:attachedTo :Fred. dc:description "Heartrate sensor". dc:publisher _:bnode1. _:bnode1 a ss:PeriodicStream; ss:publishedBy :HeartSensor. ss:dataTypexs:decimal. ss:contains _:bnode2. dc:accrualPeriodicity _:bnode3. _:bnode2 a ss:StreamContent; rdfs:about <http://fredHospital.org/fred/heartRate.trdf>; pachube:ip_restriction :HOSPITAL_IP. _:bnode3 a ss:Frequency;} ss:duration P0Y0M0DT0H5M.

  33. WP4 – PlanetData vocabularySome Proposals • Dynamic dataset properties • Expiration properties • Continuous/periodic • Feed status (live/frozen) • Subjective/Objective properties • dcat:dataQuality • ssn:precision • Location properties beyond standard geographic features • mobile or static location • indoor or outdoor • Access Control • Public sensors: pollution sensors • Private sensors: heart-rate sensors • Allowed/blocked sources • Access duration • Frequency limit

  34. WP4 – Relevant Data sets • Channel Coastal Observatory • Pending final confirmation that it can be used • AEMET (Agencia Española de Meteorología) • Currently working on its transformation. Demonstrator soon • InfoTerre : In/Out? • PSA : In/Out? • Sensorbase : In/Out

  35. WP6 - curriculum • Motivation • Comparison with Relational DB storage • Streaming data models • Unbounded streams • Tuples, Windows • Timestamps • K-constraints • Query Languages • Relational operatorsWindow operators, temporal operators • Aggregators • Joins • Semantic streaming data • RDF Stream data models • SPARQL extensions for RDF Streams • Reasoning with Streams • Complex event processing • Linked Streaming Data • Query processing • Continuous queries • Window evaluation • Aggregates evaluation, approximative queries • Static optimization • Query optimization, statistics • Load shedding • Sampling

More Related