FI-WARE Data-Context Management July 2011

1. High-level description FI-WAREData-Context ManagementJuly 2011

2. Conceptual Model: Data • Data in FI-WARE has associated a data type and a value. • FI-WARE will support a set of built-in basic data types similar to those existing in most programming languages. • A data element refers to data whose value is defined as consisting of: • a sequence of one or more data element attributes (<name, type, value> triplets) • Optional meta-data/semantic data linked to attributes (also <name, type, value> triplets) Meta-data Data Element Data Elementattributes • Name • Type • Value “has” “has” • DataType • Name • Type • Value 1 n 1 n

3. Conceptual Model: Context data • Context in FI-WARE is represented through context elements defined as special case of data where: • There is an associated an EntityId and EntityType, uniquely identifying the entity in the FI-WARE system to which the context element information refers. • Some of the data element attributes, as well as meta-data associated to attributes, that may be mandatory for any context element in the system. • As an example, a measured temperature is a data element but in order to become a context element, has to refer to some entity on which that temperature has been measured (a particular room, person or building, etc.). We may also establish that the time at which it was generated should be present. Meta-data ContextElement ContextElementattributes • Name • Type • Value “has” “has” • EntityId • EntityType • Name • Type • Value 1 n 1 n

4. Conceptual Model: Data and Context representation • A cornerstone concept in FI-WARE is that data elements are not bound to a specific formar representation. As an example, they can be represented as: • an XML document (sensorML, contextML, or whatever) • a binary buffer being transferred • as an entry in RDBMS table (or a number of entries in different tables), • as a number of entries in a RDF Repository • as entries in a noSQL data base like MongoDB • ... • It should be possible infer the data type of a given data element based on info explicitly or implicitly included in the format. As an example, can be inferred from: • Type of the XML document used to represent the data/context value • A component in the XML document used to represent it the data/context value • Name of the table in a RDBMS where data/context value attributes are stored • …

5. Conceptual model: events • In FI-WARE, event objects are created internally to some GEs like the Complex Event Processing GE or the Publish/Subscribe GE. It is common to refer to event objects simply as events. • Event objects are defined as: • a data element (or a context element) • a number of standard event object properties (similar to a header) associated internally by the GE for applying them to processing. • The concrete set of standard event object properties in FI-WARE is still to be defined but it is anticipated that one of these properties would be the time at which the event object arrives at the GE. Another one could be lifetime. • Event objects wrapping a data element can be referred as data events • Event objects wrapping a context element can be referred as context events • Note that event objects only exist while they are being processed in an event-oriented GE: data elements or Context elements are unwrapped when they leave an event-oriented GE.

6. Conceptual model: advantages • Not linked to a particular data/context format representation: • Neither for transferring • Nor storing • Can work with a standard IoT formats (SensorML) but at the same time allows to overcome the limitations derived from the adoption of a single standard format • It is compliant with OMA specs but interfaces and operations would be valid for any type of data (not just context)

7. Overallarchitecture

8. Publish/Subscribe Broker GE • Producers publish data/context elements by invoking the update operation on the Publish/Subscribe GE. When used to publish context elements, only the context element attributes that have changed may be passed. • Consumers can retrieve data/context elements by invoking the query operation on the Publish/Subscribe GE update query consumer producer Publish/Subscribe GE Publish/Subscribe GE

9. Publish/Subscribe Broker GE • Consumers can be subscribed to reception of data/context elements which comply with certain conditions. Subscribed consumers spontaneously receive data/context elements compliant with that subscription through the notify operation that the Publish/Subscribe GE will invoke on Consumers • Subscriptions may have a duration • Note that the actor which subscribes a particular consumer may or may not be the consumer itself application subscription_id = subscribe (consumer, expr, duration) notify (subscription_id, data/context) Publish/Subscribe GE consumer

10. Handling multiple subscriptions • A single Publish/Subscribe GE may handle several subscriptions • A consumer may be subscribed through more than one subscription Publish/Subscribe GE consumers subscriptions producers subscription ports Producers port Producers publish data/context Consumers subscribe to data/context

11. Complex Event Processing (CPE) GE • The Real-time Complex Event Processing Generic Enabler provides: • toolsto define eventprocessingapplications on data interpreted as events, either manually or programmatically • execution of the event processing application on events as they occur and generation of derived events accordingly • management of the runtime • the Real-time Complex Event Processing GE in FI-WARE implements event processing functions based on the design and execution of Event Processing Networks (EPN). • Processing nodes that make up this network are called Event Processing Agent (EPA)

12. EPA programming: introduction • In FI-WARE, behavior of an Event Processing Agent (EPA) is specified using a rule-oriented language that is inspired by the ECA (Event-Condition-Action) concept. Rules in this language will consist in three parts: • A pattern detection that makes a rule of relevance • A set of conditions (logicaltests) formulatedonevents as well as external data • A set of actionstobecarriedoutwhenall the established conditions aresatisfied

13. EPA programming: Patterndetection • In the pattern detection part the user may program patterns over selected events within context (such as a time window or segmentation) and only if the pattern is matched the rule is of relevance and according to conditions, the action part is executed. The patterns may include: • Sequence, meaning events need to occur in a specified order for the pattern to be matched • Count, a number of events need to occur for the pattern to be matched

14. EPA programming: Conditions • The user of the GE may program the following kind of conditions in a given rule: • Simple conditions, which are established as predicates defined over single events of a certain type • Complex conditions, which are established as logical operations on predicates defined over a set of events of a certain type: • All (conjunction) meaning that all defined predicates must be true • Any (disjunction) meaning that at least one of the defined predicates must be true • Absence (negation) meaning that none of the defined predicates can be true • Predicates defined on events can be expressed based on a number of predefined operators applicable over: • values of event data fields • values of other properties inherent to an event (e.g., lifetime of the event) • external functions the GE can invoke and to which event data field values or event property values can be passed

15. EPA programming: Actions • The user of the GE may program the following kind of actions in a given rule: • Transformations, defined over events satisfying the rule, which may consist in generating a new event whose data is the result of: • Projecting a subset of the data fields from one or several of the events satisfying the rule • Translating values of projected data fields into new values as a result of applying some programmed function • Enriching data of the new event with data not present originally • Forwarding actions, which would consist in forwarding one or several of the events satisfying the rule • Execution of external processesthat allow achieving some desired effect in the overall system. • Note that several transformations can be programmed in the same rule. This allows an event or set of events to be split in multiple derived events. • In addition, external processes being executed as the result of an action may lead to updates of variables based on which certain functions used in predicates of rule conditions are formulated.

16. Actorsaroundthe CPE GE

17. Multimedia metada extraction GE • This GE enables to extract meaningful information from multimedia content (image, audio, video, etc.) • The GE can work for previously stored multimedia data as well as for multimedia data streams (e.g., received from a camera in real time).

18. Multimedia metada extraction GE • The Media Interface receives the media data through different formats. Several streams/files can be accessed in parallel (e.g., different RTP sessions can be handled). Different interchange formats for streaming and file access can be realized, e.g.: • Real-time Transport Protocol (RTP) as standardized in RFC 3550 • ISO Base Media File Format as standardized in ISO/IEC 14496-12 • HTTP-based interfaces (e.g., REST-like APIs). URLs/URIs could be used to identify the relevant media resources. • Etc. • The Media (Stream) Analysiscomponent perform algorithms on received streams/files to extract relevant data. • The Metadata Interface can be used for subsequent processing of data extracted from the media analysis.

19. BigDataAnalysis • This GE willbeabletoprocess data at largescale, applyingalgorithmsdevelopedbytheapplicationdevelopers in ordertoobtain new relevant data (insights) that are the base for development of Intelligent Services • Twokind of BigDataAnalysisscenarios are supported: • BigDataCrunching • BigDataStreamAnalysis • This GE will present a unified set of tools and APIs allowing developers to perform analysis on large amount of data and extract relevant insights in both scenarios • The GE will be based on the map&reduce paradigm

20. BigDataAnalysis

21. Query Access (Broker) • This GE provides an intelligent, abstracting interface for retrieval of data from the FI-WARE data management layer. • This is provided in addition to the publish/subscribe interface as a parallel access modality. • Principal users of the Query-access GE include applications that require a selective, on-demand view on the content/context data in the FI-WARE data management platform via a single, unified API, without taking care about the specifics of the internal data storage and DB implementations and interfaces. • At the same time its API offers an abstraction from the distributed and heterogeneous nature of the underlying storage, retrieval and DB / metadata schema implementations. • The Query-access GE also provides support for specific search and query functions required in (metadata based) multimedia content search (e.g., image similarity search using feature descriptors).

22. SemanticApplicationSupport • This GE comprises: • A Semantic Infrastructure supporting services and APIs providing core functionalities for both Semantic Engineering and External components • A set of tools and services built on top of the Semantic Infrastructure functionality that support Ontology Management and Semantic Engineering • TheSemanticInfrastructurecomprises: • A storage layer based on components providing storage for semantic based metadata. • Arepository for storage of RDF triplets • A registry for storage of ontologies • An utility layer containing components providing business logic that allows applications exploit RDF plus ontologiessemantic: • Querying component, that allows the execution of SPARQL queries • Publishing component, that allows the publication of RDF data to a repository. • Subscribing component, that allows the subscription for specific data. • Reasoning component, that allows the generation of new knowledge

23. SemanticApplicationSupport • Regarding tools, Semantic Application Support in FI-WARE would comprise: • A service layers offering services related with ontology and data engineering such us ontology modularization, ontology translation, ontology search, inconsistency resolutions, etc. • A set of tools supporting ontology engineering processes and ontology development methodologies in an integrated way. As methodologies and engineering processes are continually evolving, the tools layer should provide mechanisms to integrate new tools into the current framework. An initial set of tools has been identified: • The ontology browser, that allows users to navigate and visualize through ontology networks. • The ontology editor, that allows users to edit ontologies stored in the system. • The repository management, that allows users to interact with the repository in the Semantic Infrastructure area.

24. SemanticApplicationSupport

25. Thank You !!