“Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets”
Deliverable D3.2 OPENi Cloudlet Platform Design Document
Disclaimer:
The OPENi project is co-funded by the European Commission under the 7th Framework Programme. This document reflects only
authors’ views. EC is not liable for any use that may be done of the information contained therein.
Workpackage: WP3 – Design
Authors:
Dónal McCarthy (WIT), Eric Robson (WIT), Michael O'Brien (WIT), Stepan Ivanov (WIT), David Benson (WIT), Dylan
Conway (WIT), Robert Kleinfeld (FOKUS), Lukasz Radziwonowicz (FOKUS), Johannes Hange (FOKUS)
Status: Final Date: 20/09/2013 Version: 1.0
OPENi Project Profile
Contract No.: FP7-ICT-317883 Acronym: OPENi
Title: Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets
URL: www.openi-ict.eu Start Date: 01/10/2012
Duration: 30 months
Partners
Waterford Institute of Technology
Coordinator
Ireland
National Technical University of Athens (NTUA), Decision Support Systems Laboratory, DSSLab
Greece
Fraunhofer-Gesellschaft Zur Foerderung Der
Angewandten Forschung E.V Germany
INFORMATICA GESFOR SA (CGI) Spain
AMBIESENSE LTD UK
VELTI SA Greece
BETAPOND LIMITED Ireland
Version Date Author (Partner) Remarks
0.0 15-04-2013 John McGovern (WIT) Initial Document Structure.
0.1 18/07/13 Dónal McCarthy (WIT) Updated Document Structure.
0.1.1 18/07/2013 Dónal McCarthy (WIT) Added FOKUS alterations.
0.1.1 22/07/2013 Dónal McCarthy (WIT)
Added market analysis sections and updated preface.
0.2 02/08/2013
Dónal McCarthy (WIT), Michael O'Brien (WIT), Stepan Ivanov (WIT), David Benson (WIT), Dylan Conway (WIT), Robert Kleinfeld (FOKUS), Lukasz
Radziwonowicz (FOKUS), Johannes Hange (FOKUS)
First draft to be
circulated to all partners.
0.3 12/08/2013
Dónal McCarthy (WIT), Stepan Ivanov (WIT), David Benson (WIT), Dylan Conway (WIT), Robert Kleinfeld (FOKUS), Lukasz Radziwonowicz (FOKUS), Johannes Hange (FOKUS)
Second draft.
0.4 16/08/2013 Dónal McCarthy (WIT), Johannes Hange (FOKUS),
Dylan Conway(WIT) Third draft.
1.0 20/09/2013
Dónal McCarthy (WIT), Johannes Hange (FOKUS), Dylan Conway(WIT), David Benson (WIT), Stepan Ivanov (WIT), Robert Kleinfeld (FOKUS), Lukasz Radziwonowicz (FOKUS)
Executive Summary
As a research project OPENi’s primary objective is to produce an innovative solution that integrates personal data storage and cloud-based services. To reach this goal we will develop a solution composed of two distinct, independent, but interrelated components 1) an API Platform to enhance access to cloud based services and 2) a Cloudlet platform to store users’ data. Applications can access cloudlet data independent of the API platform, likewise applications can utilise the API platform without accessing Cloudlets.
There are many services available that offer personal data storage similar to OPENi’s Cloudlet. We profile and analyse a number of these services to ascertain the De facto industry standards with regard to data privacy, data control, and interoperability with 3rd party apps and services. Cognisant
of existing solutions in OPENi we allow users store any type of data in any schema (or object type). This dynamic data approach makes the Platform more appealing to 3rd party developers; however it
complicates matters with regard to the key OPENi goal of seamless interoperability between applications. To address this complication the OPENi Cloudlet Platform will apply a schema to the data retrospectively through the use of folksonomies with usage metrics dictating the global schemata in the OPENi registry.
The primary goal of OPENi is to give the user maximum control of their data. We address this through a number of technical solutions and privacy policies by:
implementing non-intrusive logging,
allowing users purge their data,
enabling users realise the monetary value of their data,
enabling them port their data to other platforms,
and giving them control over 3rd party access to their data through the use of intuitive GUIs.
We aim to give insight into OPENi’s research agenda by formulating a number of research questions which we will answer over the lifetime of the project. The questions cover a number of thematic areas such as: mobile application interoperability, meta-processing and data discovery, data monetisation, personal identity, and minimal exposure. Building on the research question and use-cases we identified the components required to create an OPENi compliant cloudlet platform. The list of requirements can be split into two sections, one to deal with the management of the overall platform (monitoring, data aggregation, platform administration, provider GUI, and communications) and the other deals with the individual cloudlets (data access, management, authentication notification, and Cloudlet GUIs).
The platform will be developed using some agile software techniques including: SCRUM an iterative software development process, and test driven development.
Table of Contents
1
Preface – OPENi High Level Architecture Overview ... 11
1.1 Introduction ... 11
1.2 API platform ... 11
1.3 Cloudlet platform ... 12
1.4 Mobile Client Library ... 14
1.5 Platform Interoperability ... 14
1.6 Service Enablers ... 15
2
Introduction ... 16
2.1 Purpose and Objectives ... 16
2.2 Methodological Approach ... 16
2.3 Document Structure... 17
3
Personal Data Storage Market Analysis ... 18
3.1 Personal Data Storage Solutions ... 18
3.1.1 CAYOVA ... 18 3.1.2 FreedomBox ... 19 3.1.3 Gigya ... 19 3.1.4 Personal ... 20 3.1.5 Mydex ... 20 3.1.6 OwnCloud ... 21 3.1.7 Pidder ... 21 3.1.8 Privowny ... 22 3.1.9 Qiy ... 22 3.2 OPENi’s Position ... 22
4
OPENi’s Personal Data Storage Research ... 25
4.1 Research Questions ... 25
4.2 Relevant Requirements and Use Cases ... 25
5
Cloudlet Platform Components ... 27
5.3.4 Provider GUI ... 29
5.3.5 Communications ... 29
5.4 Cloudlet Management ... 29
5.4.1 Data access ... 29
5.4.2 Management ... 30
5.4.3 Authentication, Authorisation, and Accounting ... 30
5.4.4 Notification ... 30
5.4.5 Cloudlet GUIs ... 30
5.5 Component Interaction... 31
5.6 Research to Component Mapping ... 31
5.7 Use Case to Component Mapping ... 32
7.2.1 Native vs. Web Mobile Development ... 51
7.2.2 Mobile Client Libraries ... 51
7.2.2.1 jQuery Mobile ... 51
7.2.2.2 Titanium Mobile ... 52
7.2.2.3 Xui ... 52
7.3 Cloudlet Platform ... 53
8
Cloudlet API ... 54
8.1 Authentication and Authorization API ... 54
8.2 Data API ... 54
8.3 Type API ... 54
8.4 Auditing API ... 55
8.5 Notification API ... 55
8.6 User Management API ... 55
8.7 Platform Management API ... 55
9
Workflows ... 56
9.1 Application Subscription ... 56
9.2 Alter or read cloudlet data ... 57
9.3 Application creation ... 57
9.4 User alter Cloudlet data automated... 58
9.5 3rd party access data (aggregator) ... 59
10
Techniques ... 61
10.1 SCRUM ... 61
10.2 Test Driven Development ... 61
11
Conclusions ... 63
12
Acronyms ... 65
13
References ... 67
14
Appendix I ... 74
15
Appendix II: Data Storage ... 77
15.1.2.6 RiakCS ... 83
15.1.3 Conclusion ... 84
16
Appendix III: Cloud Framework ... 86
16.1 Infrastructure as a Service (IaaS) ... 86
16.1.1 CloudSpaces ... 87 16.1.2 Eucalyptus ... 87 16.1.3 mOSAIC ... 88 16.1.4 Nimbus ... 88 16.1.5 OpenNebula... 89 16.1.6 OpenStack ... 89
16.2 Platform as a Service (PaaS) ... 90
List of Figures
Figure 1 Dual Platform Architecture ... 11
Figure 2 OPENi API Platform ... 12
Figure 3: The OPENi Cloudlet Platform ... 13
Figure 4: Cloudlet Platform Variations ... 13
Figure 5: Interactions between platforms hosted by different providers. ... 14
Figure 6: Personal data storage services similar to OPENi’s ... 23
Figure 7 The Cloudlet Platform components and external entities ... 27
Figure 8 A visualization of the OPENi’s components interconnection. ... 31
Figure 9 A single inheritance model with the ability to extend types ... 35
Figure 10 A single and multi-inheritance model. ... 36
Figure 11 Structural relations between types. ... 37
Figure 12 JSON-LD used for duck typing... 38
Figure 13 A depiction of scopes ... 39
Figure 14 Cloudlet and registry interaction ... 44
Figure 15 Cloudlet and registry interaction. ... 45
Figure 16 Cloudlet Platform components and the ZeroMQ topology. ... 53
Figure 17 Subscribing to Third Party Application. ... 56
Figure 18 Read/Update Cloudlet Data ... 57
Figure 19 Registering Third Party Applications. ... 58
Figure 20 Automatic Cloudlet Data Update ... 59
Figure 21 Third Party Data Access. ... 60
Figure 22 CAP theorem with real world examples. ... 78
Figure 23 Separation of Responsibilities [45] ... 86
1 Preface – OPENi High Level Architecture Overview
1.1 Introduction
OPENi will be composed of two distinct, independent, but interrelated components 1) an API Platform to enhance access to cloud based services and 2) a Cloudlet platform to store users’ data. Applications can access cloudlet data independent of the API platform, likewise applications can utilise the API platform without accessing Cloudlets. This section presents a high level view of each platform's architecture and details how together they create a powerful combined platform.
Figure 1 Dual Platform Architecture
1.2 API platform
Figure 2 OPENi API Platform
1.3 Cloudlet platform
Figure 3: The OPENi Cloudlet Platform
The architecture for the cloudlet is defined using a design-by-contract methodology, it acts as a contract defining features like authentication, authorisation, etc. that the platform must provide. As depicted in figure 4 the cloudlet platform can be realised using many different technological approaches. Leading from the diverse nature of the requirements specified in deliverable D2.5 we investigated and broadly specified four potential platforms that could fulfil this platform contract. It is envisaged that one of these platforms will be implemented in proceeding work-packages, however through the open-source nature of this project other platforms could be accommodated. The focus of the OPENi development will concentrate on a multi-tenancy platform with a single large datastore, see figure 4B multi-tenancy platform.
1.4 Mobile Client Library
To provide convenient access to the OPENi APIs and cloudlet storage we will provide a mobile client library. This library will abstract and simplify access to the OPENi services across multiple mobile platforms and will take the form of a lightweight developer SDK. This library will be designed to promote rapid application development and easy developer on-boarding.
1.5 Platform Interoperability
The combination of the open API and cloudlet concept creates a platform of user data and service connectivity making OPENi both powerful and beneficial for consumers, application developers and service providers. The vision for OPENi is to provide a platform that could be deployed and operated by many different application hosting or service providers looking to add value to their proposition. These ‘OPENi hosting providers’ will take advantage of various facets of the OPENi platform in ways that best suit their business model. To accommodate this we have structured OPENi as two discrete services. From the normal consumers perspective we envisage that they will be largely unaware of the OPENi platform, with only the technology and data aware consumers cognisant of cloudlet platform technologies.
To that effect we predict that consumers could have many applications provided by many ‘OPENi-hosting-providers’. In practice we are planning for consumers to have a single cloudlet that can be connected to multiple API platforms. Figure 5 shows how the platforms interact with each other and mobile apps deployed by another provider. More details of this can be found in this deliverable (D3.2).
This separation of concerns between the platforms is further emphasised in terms of their data models, with the API Platform presenting the Graph API's conceptual meta-model and the Cloudlet Platform's data schemas exposed through the standalone Registry. Application developers utilise this Registry; a component that servers both Platforms; to design the logical schemas that will model their applications' data. The registry 1) collates existing schemas and 2) allows developers discover new schemas for use in OPENi compliant mobile applications. The API Builder provides a mechanism for developers to access the registry to build enhanced features from existing schemas and models. The API platform presents its community managed Graph API meta-model to application developers to simplify the integration of Cloud Based Services and Cloudlet data; over time popular developer defined schemas may be incorporated into the Graph API's meta-model by the OPENi community. The Cloudlet Platform is responsible for storing the physical schemas. An application's physical schema consists of data objects composed of multiple data types. Schemas are dynamically augmented as developers extend objects with new data elements.
The platforms are independent; the Cloudlet Platform can serve mobile applications that do not utilise the Graph API or any other part of the API Platform; likewise the API Platform's integration with Cloud Based Services and Graph API can function just as well with another data storage mechanism. However, as the Graph API's schema will be the most widely used on the Cloudlet Platform, its meta-model will form the core of the Cloudlets folksonomy driven data meta-model.
1.6 Service Enablers
2 Introduction
2.1 Purpose and Objectives
Deliverable 3.2 will specify the OPENi cloudlet platform that will be utilised by users to create and deploy their cloudlets but also by developers to enable their applications to access stored user data. It outlines necessary components for secure storage of cloudlet data, regulating the operation of the entire cloud platform, and enabling user interaction (create, deploy, update, delete) and application communication. Additionally all readily available components and technologies will be identified for integration with the Cloudlet Platform.
2.2 Methodological Approach
With the main objective to define and specify the OPENi cloudlet platform, the work carried out for the present report is based on the WP2 results and particularly bears the following steps:
Baseline Analysis
Identifying the existing state of art through market analysis of OPENi competitors.
Evaluating suitable candidates from relevant technologies for the cloudlet platform in the context of its defined components.
Elaborating on research questions.
Preparatory Analysis
Ascertaining the essential concerns required to fulfill user requirements. Discussing the implementation of the platform and exploring all choices. Identifying actors, components and use cases.
Recognising key developments methods facilitating quality of components.
Iterative Specifications
Classifying the communication and connections between components. Defining the data storage mechanisms.
Defining the cloudlet management tools.
Specifying a suitable data model for persistence.
Implementation Directions
Charting the architecture of the OPENi cloudlet platform.
Recommending the most appropriate technologies as a foundation for the cloudlet components. Defining potential API endpoints for interacting with cloudlet platform.
Conclusions & Key Take-Aways
2.3 Document Structure
3 Personal Data Storage Market Analysis
There are many services available that offer personal data storage similar to OPENi’s Cloudlet. In this section we profile and analyse a number of these services to ascertain the De facto industry standards with regard to data privacy, data control, and interoperability with 3rd party apps and
services. We also gauge their accessibility and ease of use. The services that we analyse include: CAYOVA, FredomBox, Gigya, Personal, Mydex, OwnCloud, Pidder, Privowny, and Qiy. Later we outline OPENi’s position with regard to each of these standards. Additionally we outline OPENi’s key innovations and discuss its key points of differentiation.
3.1 Personal Data Storage Solutions
The following are high level descriptions and analyses of Personal Data Storage solutions in general terms. Security and privacy are mentioned, however for a more in depth security analysis please see section 5.1 in D3.3.
3.1.1 CAYOVA
Cayova [1], which stands for Capture Your Value, is an emerging social networking site. The site (beta) initially went live in April 2013. Cayova was established in Britain and is a commercial entity. Their stated main goal is to provide a new social platform that empowers its users in the context of data privacy and control. The ideology of Cayova is that our personal information is a valuable commodity that we should have full ownership and control over. Cayova is a centralised solution and their infrastructure is out sourced to Amazon's Web Services (AWS) [2].
Cayova's stated business model generates revenue through targeted advertising that user's must opt into. Cayova also commit to providing a financial incentive for their users to opt in. According to Cayova's terms of use, the company gives a user half of any payments it receives for ads "targeted at you or for access to your content and data," minus sales taxes and transaction costs, such as bank fees. Users then have the option of donating that money to charity, receiving a cheque or deducting that amount from their mobile phone bill. Users receive a bonus value for inviting a new user to join. Cayova dispenses a browser plug-in that allows users see what companies are tracking them, through cookies and other technology, as they browse the web. When logged into their system through the plug-in it will block third party cookies from tracking users. Lastly the Cayova box gathers information about users as they browse. Users can then opt-in to sharing this with third parties. A native iOS app is provided allowing users to interact with the system in the same manner as they would the web interface. Users can opt out of any of the above services at any point. Cayova commits to permanently removing deleted accounts from their system.
3.1.2 FreedomBox
FreedomBox [3] is a fully distributed software suite for privacy and control in the home which enables free communication among its users. The solution involves a peer-to-peer mesh networking of commodity boxes. By exploiting a distributed model over a centralised approach, users are given greater control and freedom when using the Internet.
FreedomBox is a Debian platform that is completely open source and free to use, modify, and redistribute. FreedomBox promises:
Email and telecommunications that protects privacy and resists eavesdropping.
A publishing platform that resists oppression and censorship.
An organizing tool for democratic activists in hostile regimes.
An emergency communication network in times of crisis.
That anyone regardless of technical skill can use this solution.
The creators of FreedomBox recommend loading the platform onto a low power plug based computer. The software has been made available for Raspbian, the optimised Raspberry Pi operating system. FreedomBox attempts to achieve its goal of private secure communications through the FreedomBuddy software. FreedomBuddy works by forwarding communications over an anonymising worldwide network, with direct secure connections set up for transmission of large files/data. Also included is a custom version of the Privoxy software. This is a web proxy that strips web pages of ads and ensures secure connections. Its main components are AdBlock, EasyPrivacy and the HTTPS Everywhere plug-in. Finally the other software packages are focused on making FreedomBox easy to use with Plinth (a web interface), Freedom Maker (the installation helper), ExMachina (configuration tool) and Project Publish (publishing tool).
FreedomBox is a very privacy conscious and user-centric system where users own all the data and have complete control over it. It has very limited 3rd party accessibility and has very specific data
domain.
3.1.3 Gigya
Gigya [4] is a commercial entity based in the USA which provides business solutions for connected consumer management. They claim to facilitate businesses in engaging with their consumers with more targeted services.
client's service platform. Companies can then use this data to personalise and drive their products and advertising.
Gigya provides client side and server side developer APIs for utilising their platform. The client side APIs are exposed through a JavaScript library. The server side APIs are REST with JSON payloads. These REST APIs can be integrated into mobile and server applications through a number of SDKs provided.
Gigya is an enterprise-centric data storage solution in which users data is owned by Gigya, accessible by Gigya and stored in encrypted form by Gigya. Users can share their data with select 3rd parties but
do not have complete control over it as they do not own the data.
3.1.4 Personal
Personal Inc. [5] is a commercial entity, launched in November 2011, which provides a suite of proprietary tools for securely storing and sharing personal information. They offer users absolute control over their identity and over access to their data. Personal's product focuses on allowing users to aggregate and manage their personal information in an online vault (50MB of storage per vault). The information stored in these vaults can vary hugely from financials to pet information and covers almost all aspects of life.
The product offered by Personal is a centralised solution i.e. all data is stored on their Hadoop infrastructure. Their infrastructure is hosted by Rackspace in the United States. Data stored includes gems (nuggets of personal information), activity streams (logs) and contacts. The company makes many promises with regards to privacy and data ownership. Personal Inc. commits to not monetising your data, not giving access to third parties without explicit permission and to not push targeted marketing at users without consent. They also commit to non-intrusive logging.
Personal encrypts and stored user data and allows users to have complete control over their data. Users and 3rd party applications can only access data they own or that has been shared
with them. 3.1.5 Mydex
Mydex [6] has an almost identical business model to Personal Inc. however it does offer partnerships with other organisations. Another key differentiator is their hybrid storage model versus Personal's centralised model. In the future users will be given the choice of controlling where their personal data actually exist (currently only cloud storage supported). Mydex states that all technologies they use are open source; however they do not make the software running on their cloud platform available publicly.
Mydex encrypts any user data that is on their system and only the user can access it. The users completely own their data stored by mydex and can selectively share this data with multiple third parties.
3.1.6 OwnCloud
OwnCloud is a cloud storage platform for business enterprise. It offers businesses the opportunity to provide their own cloud storage service to employees with a larger degree of control than existing public cloud service providers. OwnCloud cites the legal difficulties enterprises have using Dropbox as the niche for the product. OwnCloud is a completely open source solution and as such is transparent and extensible.
OwnCloud provides services similar to Dropbox, except that it affords greater control for organisations concerned with the confidentiality of their information. Due to the open source nature of the project organisations can add, remove, and modify any features they want. The organisations are responsible for setting their own security and privacy policies. Each business is also responsible for the how the data is managed. The businesses are the owners of the data. The only stipulation of using OwnCloud is to limit testing for vulnerabilities to your own installation and reporting them to the community. OwnCloud has linked up with hosting providers who offer the ability to rent their cloud solution, allowing organisations without data centres or technical staff to use the OwnCloud platform for their business. The partners that offer this are Net.de, vBoxx, A2 Hosting, Standing Cloud and Saxons IT solutions.
The expertise required to set up OwnCloud makes it infeasible for typical users. However there is nothing to stop an organisation from allowing public access to their OwnCloud.
OwnCloud provides a huge variety of functions to businesses that simply aren't on offer from some of the large cloud storage SPs such as Dropbox, Google Drive etc. It is a powerful piece of software with a beautiful interface to exploit it to the maximum. Most importantly it gives enterprise the ability to control and tailor their cloud storage. Privacy for individual employee is low as their data is stored unencrypted, thus it is accessible by system administrators.
Owncloud owns any data that the users stores on their system and as such has full access to it. The data itself is not encrypted when stored and the user can install plugins which has access to the data. 3.1.7 Pidder
Pidder is a charity organisation with a pay what you want model which facilitates the creation of private social networks among its users. Their platform is centralised and all data is stored on relational databases.
Pidder promises users privacy and anonymity when using the service, they claim no interest or use in sharing your data with thirds parties. Their claims are backed up by hard solutions. Pidder locks themselves out of the data by encrypting it on the client side. For additional privacy they do not log IP addresses of those accessing the service.
3.1.8 Privowny
Privowny is a commercial digital privacy company based in the US whose goal is to empower users by providing a digital memory of all information gathered about them. The system creates a record of all data given; knowingly or not; to third parties while browsing. Users can discover companies that have shared their data through a Privowny account. Privowny is a deployed on centralised platform and Amazon's Web Services is used to store the digital footprints.
Privowny users own all the data stored upon the system which is encrypted on rest. Privowny allows users to selectively share their data with select third parties.
3.1.9 Qiy
QIY is a non-profit organisation whose stated goal is to redistributing the balance of power with regards to personal data in favour of individuals. The central purpose of QIY is to aggregate a user's personal data and allow them greater control over who has access to it.
The site is presently in beta and no public APIs are available. Currently only one Qiy app; called Doors; is live. Doors facilitates the easy and secure login to other services. The browser plug-in gathers login information and presents it to the user.
Qiy is in its infancy and as such a security comparison and analysis cannot be completed.
3.2 OPENi’s Position
As a research project OPENi’s primary objective is to produce an innovative solution that integrates personal data storage and cloud-based services. Similar to FredomBox and OwnCloud OPENi’s output will be released as open-source, however as outlined in the DOW, commercial adoption of the project is also important. Consequently a commercialisation friendly licence will be used for OPENi itself and only 3rd party open-source tools and technologies with commercialisation friendly licences will be
Figure 6:This diagram compares personal data storage services similar to OPENi’s under a number of categories. Based on our perception, each company is placed along a scale from least to most in each category. The diagram shows that OPENi is grouped with the companies that allow their users the most control, it is the most interoperable, and it has the most support for dynamic data. However to lead in these areas some privacy features are sacrificed; consequently other services overtake OPENi in this regards.
The services that we analysed took a varied approach to the type of data that they allow users store on their system. Some are restrictive and only store data from a single domain or data in predefined schemas/structures. Examples are: FreedomBox and Pidder primarily concerned with communications and social networking data, CAYOVA and Privowny concentrating on web browsing data, OwnCloud
on enterprise data like contacts, calendar and documents. Other services give their users more control over the type and structure of data that is stored. Included in this group are Mydex and
Personal which allow their users define custom data structures, and Gigya which integrates with many
3rd party services.
In OPENi we allow users store any type of data in any schema (or object type). This dynamic data
approach makes the Platform more appealing to 3rd party developers; however it complicates matters
with regard to the key OPENi goal of seamless interoperability between applications. To address this complication the OPENi Cloudlet Platform will apply a schema to the data retrospectively through the use of folksonomies with usage metrics dictating the global schemata (See section 6).
Of the competitors FreedomBox, Pidder, and Privowny are quite insular; they operate in isolation and do not integrate with 3rd parties’ applications or services. Others do integrate with 3rd parties to
directly integrating with mobile applications. However OPENi is the most accessible to 3rd parties as it
allows users share their data across applications and cloud-based services. This presents a wealth of data that application developers can tap into and enhance their service with. In addition OPENi also boasts an aggregation feature (that allows users monetise their data in a privacy preserving way (see sub-section 5.3.2)) which gives 3rd parties access to information composed of data from many
cloudlets.
The primary goal of OPENi is to give the user maximum control of their data. We address this through a number of technical solutions and privacy policies. Similar to Personal and Pidder OPENi will implement non-intrusive logging. It will allow a user purge their data from the system as do CAYOVA,
Personal, Pidder and FreedomBox. Similar to CAYOVA we will allow a user to realise the monetary
value of their data by rewarding them for sharing it with 3rd parties. Uniquely it will allow users port
their data to other platforms, and give them control over 3rd party access to their data through the
use of intuitive GUIs.
All the services that we analysed heavily emphasised their security and privacy features.
FreedomBox’s view is that centralised systems are a privacy concern as the platform owners can
access all user data. To counter this perceived risk they implemented a distributed system where each user installs their software on a personal server in their home. FreedomBox was unique in this view, the rest opting for a traditional centralised platform. However their attitude to data protection and privacy differed. Privowny, Pidder, Personal, and Mydex utilise client side encryption to encrypt data before it is sent to their platform; consequently only the user can decrypt their data. In OPENi
4 OPENi’s Personal Data Storage Research
In this section we aim to give insight into OPENi’s research agenda by formulating a number of research questions which we will answer over the lifetime of the project. The questions cover a number of thematic areas such as: mobile application interoperability, meta-processing and data discovery, data monetisation, personal identity, and minimal exposure; the questions are closely aligned with the research agendas outlined in D3.1 and D3.3. Later in this section we identify the requirements and use cases that will help answer these research questions.
4.1 Research Questions
The key overall research question for the OPENi Cloudlet Platform is as follows:
How should a scalable, extensible, secure Cloudlet Platform be developed in order to provide the ability to store users’ data for mobile Apps, social media add-ons, and enterprise level applications?
In order to address the overall research question (RQ) we need to carefully investigate various aspects of storing users’ data: user data unification and monetization, personal user space instantiation on the cloud, digital user-identity formation. The specific research questions that address these issues are as follows:
1. How should an open source Cloudlet Platform enable the instantiation of user spaces in the
cloud, with capabilities such as storage, discoverability, addressability, access, and security of users’ data across applications and devices?
2. How should potential differences in data representation by the 3rd party applications be
negotiated in order to facilitate data re-use and interoperability?
3. How should the Cloudlet Platform present data to enable convenient meta-processing; both
indexing and searching; to facilitate the user in monetising their data in a privacy preserving way?
4. How should the Cloudlet Platform for each individual user encompass and manage their data
(e.g. health, finance, legal data) in order to build their personal identity?
5. How should the Cloudlets as a user centric data store further the currently observed state of
the art HTTP based data access to promote privacy and enable a minimal exposure concept?
4.2 Relevant Requirements and Use Cases
Each of the research questions can be linked with the use cases of the OPENi project in a manner that reinforces the concepts outline in both the use cases and the research questions.
Research question one has distinct links with the scenarios of the MyLife and Personalised in-store shopping use cases. These use cases require a system that enables users to sign up to the service in an easy manner and for the system to create these accounts with all the accompanying configurations and features (storage, security, ect.).
system. The MyHealth scenario from MyLife has both users and medical specialists accessing and editing the same data. By utilising personalised advertising 3rd parties will use the OPENi platform to supply users with targeted ads through analysis of their accessible data. The personalised in-store shopping use case will see retailers supply OPENi with details about their products, stock and offers; it will also provide recommendations on products to users. As the research question states, all the data from these different sources need to be represented in such a way that re-use and interoperability are supported within the OPENi system.
The third research question focuses solely on the Personalised advertising use case of OPENi. The personalised advertising use case will allow 3rd parties utilise user data to create targeted ad campaigns. In keeping with the data protection and privacy ethos of OPENi the shared data will be anonymised. Users must opt in to the advertising programs to allow 3rd parties access to their data. The MyLife use case helps answer the fourth research question. The MyLife use case shows scenarios where users keep details about their health, transaction, stocks and more on the OPENi platform. This information allows users to build and expand their personal identity with the OPENi platform.
Similar to the second research question the fifth question is addressed by all 3 use cases. The OPENi platform will reduce the unwanted exposure of user data to all three services.
Research Question
Relation to OPENi Use Cases MyLife Use Case Personalised Advertising
Use Case Personalised In-store Shopping Use Case
Q1 High Low High
Q2 High High High
Q3 Low High Low
Q4 High Low Low
5 Cloudlet Platform Components
This section will describe the components required to create an OPENi compliant cloudlet platform. It is broken into two sections, one to deal with the management of the overall platform and the other deals with the individual cloudlets. For each component we define what it does and what other components it interacts with.
Figure 7 The Cloudlet Platform components and external entities
5.1 APIs
The APIs will provide the medium for inter-component communication in the Cloudlet and also for external communication with the API Platform and with Apps. More details of the Cloudlet API can be found in section 8.
5.2 Data Storage
An OPENi cloudlet platform requires a data storage component capable of storing three categories of data, 1) user-supplied, 2) app-specific and 3) internal cloudlet data. User-supplied data is created, modified and/or deleted primarily through OPENi Cloudlet API. This data may be in various forms such as text, graphical, audio etc. This differs from app-specific data, which is data that an app may require to function correctly e.g. access tokens, cookies etc. Additionally the internal components of the cloudlet may also require storage of data such as logs, history, credentials, and tokens.
5.3 Platform Management
The platform providers will be responsible for managing the underlying resources, which serve the cloudlets. To enable the management of these resources the following components are crucial to the platform.
5.3.1 Monitoring
Automated monitoring of the cloudlet platform will offer providers the ability to pre-empt certain potential problems and efficiently react to many issues within the platform.
In conjunction with standard infrastructure metrics, logs of platform application actions such as creating cloudlets, inserting data and querying cloudlet data stores will be aggregated and analysed by the monitoring component to provide the platform provider with comprehensive information of the platform as a whole.
Alerts can be configured to notify the platform provider upon the occurrence of certain criteria e.g. available disk space less than 87%, CPU utilization greater than 98% etc.
5.3.2 Data Aggregation
The data aggregation (DA) component will offer 3rd parties the ability to view aggregated user data
from multiple cloudlets while concealing the individual cloudlet owner’s identity. A 3rd party will send a
request to the Cloudlet Platform for aggregated data. The DA will negotiate with the authorisation component to identify cloudlets that wish to share data with the 3rd party in a privacy preserving way.
It then requests the data from each cloudlet, aggregates the data, and sends the results to the 3rd
party. The security access levels required to access user’s cloudlets is outlined in Deliverable 3.3. The DA is an important feature for a number of Service Enablers (SE) which need combined data from a set of cloudlets. We considered a number of alternatives to the DA, one of which involved each SE to negotiate with their users’ cloudlets and aggregate the data themselves; however this approach introduces privacy concerns as the SE could build a profile of their users by replicating their cloudlet data off-platform.
5.3.3 Platform Administration
Platform providers require the ability to initially set, and later adjust, the resources, control and communication settings of the platform in order to maintain a high quality and efficient platform for cloudlets. The administrative tasks include:
Create various types of nodes such as database master node, database slave node, application node, component node etc.
Add/Remove nodes on the platform
Connect to a specific node in order to troubleshoot issue(s) reported by a cloudlet owner
Global platform access control. Revoke the access tokens of a cloudlet owner in the event of an account being compromised.
5.3.4 Provider GUI
The provider GUI will serve as an interface for platform providers to carry out administrative tasks on the platform and view data from the monitoring component such as:
Manage the platforms data e.g. log entries, load balancer metrics and users
Change notification settings from the monitoring component
Carry out administration tasks defined in subsection 5.3.3
5.3.5 Communications
This component is responsible for communicating with the platforms users. It will incorporate an email and SMS service. Email communication is required to notify users of: registration progress, platform updates. Two way SMS communication is utilised to verify that registering users aren’t automated machines.
Users can also combine the communications and notification component to create alerts for cloudlet data mutations e.g. they can get an alert each time their weight is changed by an application.
5.4 Cloudlet Management
The components outlined in this section will facilitate the management of the individual cloudlets on an OPENi platform.
5.4.1 Data access
5.4.2 Management
In an OPENi platform, cloudlet owners are promised full control of their cloudlets. Together with the cloudlet GUI component, the management component provides the individual cloudlet owner with high-level control of their cloudlets. Some common management operations a cloudlet owner can perform are:
Creating and deleting their cloudlet
Porting their data to a cloudlet on another platform
Suspend 3rd parties’ access to their cloudlet data
5.4.3 Authentication, Authorisation, and Accounting
Access to the cloudlet will be restricted by a combination of the authentication and authorisation components. The authentication component will verify the credentials of the incoming request, e.g. username and access token, to determine if the request issuer is trusted. The authorisation component will evaluate if the trusted request issuer has sufficient access to carry out the requested task on the requested resource e.g. does App A have access to read the date of birth, body weight and the exercise reports from the last 6 months from the cloudlet data store.
The details of all access requests, subsequent actions and cloudlet responses will be monitored and logged by the accounting component. These logs will be available in the cloudlet GUI for the cloudlet owner to inspect.
5.4.4 Notification
Various components and external services can sign up for notifications of events on a user’s cloudlet.
5.4.5 Cloudlet GUIs
To empower Cloudlet owners in the management of their cloudlets they will be provided with GUIs. Some of the functions that will be available in this component include:
Viewing access logs
Edit preferences
5.5 Component Interaction
Figure 8 A visualization of the OPENi’s components interconnection: the green components are GUIs, the red are external concerns, and the components with grey borders do not expose an external API. Storage is the central component. It is not exposed through an external API but rather through the authorization and authentication APIs. Most components alter different parts of the storage to some degree. The webserver is needed to serve the GUIs and permission dialogs.
5.6 Research to Component Mapping
The first research question focuses on user spaces within the cloudlet. It outlines important concerns such as instantiation, storage, access, and data security. The instantiation and storage will require the use of the user management, storage, notification, and data components. The data monitoring component will ensure the smooth running of the system from both a security and a data integrity point of view. The authentication and authorisation components will be utilised for ensuring that all access to a user’s data adheres to their data access rules. The users themselves will access the system using the user GUI.
how foreseeable data should be formatted then both the reuse and interoperability concerns can be limited.
The third of the research questions involves processing formatted data to facilitate monetizing in a secure manner. This will require the use of the authentication, storage, notification, and data components to allow for access in order to process the data. The users will be required to use the permissions dialog component to allow for the processing and monetizing of their data. The processing of the data will be accomplished using the data aggregator component.
The fourth research question focuses on allowing the user to manage their data on the cloudlet and facilitating the creation of their personal identity. To manage their data the users will needs access to it, requiring the authentication, storage, notification, and data components. The users will manage their data using the user management, user GUI, and permissions dialog components. The permissions dialog component allows the user to be selective about what elements of their personal identity that can be seen by others while the user management and GUI components enable the user to access their data and personal Identity.
The final research question focuses on the security and privacy of the cloudlet and how it is accessed. The cloudlets can be secured by the authentication, authorisation and blacklist components so that only resources accessible by users will be theirs.
5.7 Use Case to Component Mapping
Several of the components are integral to all the OPENi use cases. Each of the use cases requires some form of access to the data storage and notification components. Many of the key principals around OPENi focus on security and user privacy; therefore the authentication component is used for all use cases that require access to both user and system data.
MyLife - The MyLife use case is a broad use case which entails the storage and management of data from the users’ everyday life including photo, health, financial and messaging data. As previously stated this use case requires the use of systems data storage and each user will be required to authenticate with the system in order to gain access to it. As this use case requires users to sign up, add, and edit their user details the user management and user GUI components will be utilised. As this use case focuses on bringing many different aspects of everyday life together, with each potentially having their own data format it is important for mobile application interoperability that the registry identifies schemas in the data. Users will be required to set permissions on their MyLife resources to allow others to view or modify them using the permissions dialog component.
6 Data model
In OPENi we allow users store any type of data in their Cloudlet. This dynamic data approach makes Cloudlets more appealing to 3rd party developers; however it makes it difficult to achieve seamless
interoperability between applications which is one of OPENi’s key goals. To address this interoperability difficulty the OPENi Registry will apply a schema to the data retrospectively through the use of folksonomies.
The data model defines the systems capabilities to interact with and manipulate the objects and schemata. The Data API defines the manner in which the user can interact with the objects while the Type API defines the interaction with the schemata (or object types).
As the cloudlet is a user centric data storage concept, developers are able to use it to store data within the user’s domain of influence. In order to support all possible use cases a developer is able to imagine, the cloudlet must be able to store all possible objects a developer can define. Any object the developer would not be able to store as part of the cloudlet, would have to be stored externally and therefore outside the user’s domain of influence.
In OPENi, data is created by developers at will and at any time. This means developers are able to create data with the object type of their choosing. A key research goal of OPENi is the interoperability between applications and the ability to discover types and data of other applications. We will offer a type model under which developers may define their own types and discover those of others.
A common approach to achieve interoperability is standardization. A standard is created by parties which share a common field of interest and goals, but may differ in their approach to achieve them. The development of standards may take a long time and in the end may be too narrow [11] or not specific enough to provide a useful interoperability [12]. For these reasons, standardization is not a feasible concept for the OPENi type model. OPENi must be able to support interoperability with a more dynamic approach such as folksonomies.
Both dynamic data and interoperability are crucial to OPENi. Both have to be supported to enable the implementation of any developer use case while supporting seamless interoperability between applications. While researching class based type models we came to the conclusion that they may not be able to allow for a type ecosystem to grow dynamically. Following we will discuss the approaches and their shortcomings.
6.1 Inheritance
Figure 9 A single inheritance model with the ability to extend types. The extensions of types may add new properties to the base type. The corresponding objects can be also be casted and with smaller types. This is achieved by walking the inheritance chain (e.g. objectT+1 -> Type+1 -> Type0, therefore the object can be casted to T0). This concept is called subtyping and it enables OPENi to identify all objects which can be returned. A query for T0 can return object0, 1 and 2 as they all share the properties defined by T0.
The main motivation behind an inheritance model is twofold. It creates a way to relate types semantically to each other. Secondly, it provides a syntactic contract. Any object must provide the properties which are specified in the type. Likewise the inheritance from a parent to its child type guaranties that the properties of the parent are also preset in any object of the child type. This allows code to be written to these contractual expectations. The validity of the object to its type guarantees a certain amount of interoperability, by providing knowledge about the underlying data to the developer. It functions like a self-defined standard and shares some of the pitfalls. First, it only allows a static inheritance chain. This means a type does not change its ancestry during its lifetime. The parent is a fixed reference in the child class and likewise in the object. Secondly, once a property is defined, it cannot be undefined in a sub type. In order to get rid of the property, a type will need to fork the inheritance chain before the type was introduced. Thirdly, it only allows for chains of inheritance. Therefore, single inheritance is unable to express the duality of an amphibious vehicle by deriving it from the types boat and car. Multiple-inheritance allows a class (or object) to inherit from multiple parents (see Figure 10). However, multiple-inheritance creates a more complex ancestry graph, naming conflicts and violates the Liskov substitution model. Most languages today therefore avoid it.
Figure 10 A single- and multi-inheritance model. Boat1 is a Boat, it also it a vehicle, but its unable to be a car, as a car does not share semantic (other than being a vehicle) with a boat. Boat2 is both by having a type (amphibian) which inherits both classes. This is not possible in most programming languages due to the possible name clashes of properties (and the so called diamond problem).
6.2 Interfaces
Figure 11 The graphic visualizes the structural relations types can have to each other. A type can overlap with another type. These two types share common property names and may share a common property type. A type can be contained within another one. This means all of the properties of one type can be found in the other. They can also be equal, meaning they share all properties of each other. Lastly they can be distinct from each other, meaning they do not share properties with each other.
6.3 Multiple types
Both interfaces and classes provide a contractual description for objects. OPENis object types are closely related to interfaces as they do not carry implementations (like classes). When combining multiple interfaces (or types), the potential for naming conflicts exists. Figure 11 visualizes the different constellations types may have to each other when being combined. With the exception of the distinct case, all combinations have overlapping properties. These properties, if they share a common type are not problematic. However, if their types differ, the question which property should be used arises. An example related to Figure 10: Boat as well as Car may have a color property. If, the types of Boat.color and Car.color have a different type, which color declaration is to be used in
Amphibious? This is outlined in Example 2. A common solution to this problem is the ability to select
or rename attributes explicitly or to accept a declaration by convention (e.g. the right most type declaration is to be used). It is important to notice that multiple types do not necessarily imply multiple-inheritance. If a type inherits multiple types, this type can again be a parent to another type. This can lead to complex inheritance graphs. On the other hand objects with multiple may not suffer from complex inheritance graphs, as the inheritance model of these types itself may still be singular.
6.4 Duck typing
duck typing is a feature of dynamic languages, it does not suffer from naming conflicts. If a property is re-defined, it simply carries a different type from this point forward. This follows an analogous ideology to convention over configuration. Code may be receiving “faulty” objects at any time and the system will not assure how an object looks. This is a very dynamic model that would fit the goal of a dynamic type system for the OPENi cloudlet. However, it does not provide any facility for interoperability and is therefore unsuitable for an open type system. Developers could constantly be in conflict as to how an object should look. Figure 12 visualizes how duck typed objects can be perceived in a typed environment.
Figure 12 On the left a multiple type model. On the right a link data model like JSON-LD which can be used for duck typing. The right side types of attributes are declared in the object itself. The model does not support a class inheritance model, but requires type knowledge to be defined in the object. Objects can be very expressive in the right model; unfortunately they also convey a lot of duplicate information and no clear structure. JSON-LD does allow for the “liking” of other types as part of a class like structure, but does not define any enforcement or interoperability of these types (seen on the right most side). A typical single inheritance model is omitted but can be deduced from the left side.
6.5 Shadowing
derivative (child) type which would break the substitution model. Likewise shadowing can also apply to an object. Shadowing is depicted in Figure 13.
Figure 13 A depiction of scopes. A scope may have a property name and gender which may be redefined “shadowed” in its child scopes. The code sees the variables of the current scope and those of the parent scope, provided they have not been shadowed. This can be used in a type and object model as well.
6.6 OPENi
6.6.1 Types
Singular inheritance is a model which has proven suitable to programming. In programming languages, inheritance serves as a contractual assurance that enables subtyping and casting. It enables the system to return objects of a larger type even when a smaller type is requested as seen in Figure 9. However, a static inheritance model does not allow the developer to reduce an existing type freely and to get rid of unwanted properties. In order to find all compatible objects the subtype must exist in the inheritance chain. We will investigate whether explicit inheritance can be useful to the system. A typical inheritance model, demands that the developer knows the type hierarchy a-priory or refactors it later. Both seem unlike for OPENi, as multiple developers will use a type and will likely disagree on later changes or a-priory structures. Nobody, not even the initial developer must be able to alter a provided schema as long as other developers have applications based on objects of this type. Otherwise other developers would be unable to follow the changes and their applications could break. On the other hand, the introduction of compatible subtypes into an inheritance chain is possible. It would require the system to rewire the subtype’s parent relation and would create a new subtype.
automatically liked together by the system. After types are linked on a semantic level, the syntax the developer has provided can be used to build an implicit and changing inheritance model. The dynamic approach allows OPENi to continuously accept new types of any form and weave them into each other, semantically and syntactically, without the developers expressed intents. This allows the system to rewrite its inheritance model and to perform housekeeping on the type system.
An interesting challenge will occur as different developers will add a type with the same intention and therefore name, but with a different structure or attributes in mind. A type typically consists of human readable id and address to reference it. For an open type system it is not feasible to let developers name the schemata they provide. The names of schemata could only be used once and it would be unclear if the community agrees to the naming. The developer instead suggests a name, description and tags which are used as meta-data to guide the automated system. Therefore, the type contains semantic links and a syntactic structure. Additionally the developer is able to provide other hints such as tags, and type names as hints to the system. This provides a challenge as developers have to find, identify and use types defined by others. Even when developers agree on the syntactic structure of a type, they can provide additional semantic hints to the system.
Following is an example schema. The corresponding object is shown in 6.2. The OPENi type system allows the use of multiple types which are referenced by the object. As such, the object supports type composition without multiple-inheritance and can be composed of different so called traits. In this example, a person consists of personal information like the name but is enriched by address and birth information. These three schemata can also be combined into a single one, if the developer feels this is a common approach. As such, the type system prefers a composition over inheritance approach. This is but one approach, and we will further investigate other type and schema approaches during the development. Appendix I shows another.
A type is expressed via a URI (or IRI) and therefore uniquely identified. The objects and schemata are stored and indexed. An index over the types and identifiers of the objects and the schemata is necessary to provide adequate lookup speeds for the most common use cases.
type/afb5e73f7079d9ce805381a380bbf7e5” {
“@context”:{
“openi”: “http://openi.example.org/0.1/” // namespace “givenName”: “openi:type/string” // attribute: type pairs “familyName”: “openi:type/string”
},
“@type”: [“openi:type”, “http://dbpedia.org/page/Person”] // static ”type” declaration + link “@id”: “openi:type/afb5e73f7079d9ce805381a380bbf7e5”, // “Person“, type id
“$name”: “Person”, //human readable name “$description”: “A human being.”, // description “$tags”: [“person”, “human”], //tags
type/acbd…a4d8 {
“@context”:{
“openi”: “http://openi.example.org/0.1/” “address”: {
“@id”: “openi:type/acbd…a4d8/address” // nested
“street”: “openi:type/1ffd…2f11”, // Include Street type named “zip”: “openi:int”
} }
“@id”: “openi:type/acbd…a4d8”, // “Address”, type id } type/1b34e73f7079d9ce805381a380bb7a68 { “@context”:{ “openi”: “http://openi.example.org/0.1/” “birthday”: {
“@id”: “openi: type/1b34e73f7079d9ce805381a380bb7a68/birthday” // nested
“@type”: ”openi:type/1ffd…2f11” // Include a Date type (year, month, day) directly “time”: “openi:type/string” // add time
} }
“@id”: “openi:type/37b5…51f2”, // “Birthday”, type id }
Example 1 The type approached outlined here is based on LD. The schemata itself are JSON-LD objects which provide a context for the objects. The attributes are declared in the context with a possibility to reference external schemata to compose a type through other types. It is not yet decided how OPENi will present types (schemata).
6.6.2 Objects
Since multiple types can be used, name conflicts as outlined before are possible. If types have overlapping properties, their types may not match. We will investigate the feasibility of choosing one type for a property or storing multiple values; one for each type of the property. While multiple values for a property may seem odd, it may be necessary. If an object is found and accessed through one but not all of its types, it should be expected to return the appropriate properties (similar to subtyping). When we allow a type-property combination shadow another, these properties will contain no value when accessed through the subtype and will not be accessible. Such a dual property approach can be found in C# concerning interfaces. Another approach could be to disallow any name conflicts in type compositions, comparable to JAVA.
Likewise, an important concern of ours is the development of an object model which allows the sharing of properties between objects. This will result in a highly relational model which is likely to negatively impact the systems query performance. An important part of our work will be to identify a suitable way to increase the performance of this model or to support it with a technical and fast solution. Technics like caching will likely reduce the impact of the abstraction. A duck typing approach will allow us to dynamically alter and bind object properties at any point. Without the late-binding at a property level (outlined in duck typing) it would be impossible to recombine objects dynamically and even morph them to a different form. While the type system represents a static and standardized object view to the outside, the underlying objects will be highly dynamic and system managed. The “view” or representation of an object will be type bound and therefore static again – to any viewer. The technological implementation of the outlined model will be an interesting research challenge which will be studied further in WP4.
Lastly, objects must be able to migrate from one compatible type to the next. This is a complex challenge in OPENi as developers share objects and types with each other. However it is very likely that developers want to extent and alter current types and therefore objects at some point and develop a new model without losing the old data. While the addition of new types into an object is possible, the reduction of old types is problematic. A developer may use the object under the old type. If the type was removed, the developer would no longer see the object. Shadowing provides the possibility to do such a dynamic migration but as discussed prior, it needs to be carefully designed to avoid the pitfall of over-relating objects and therefore slowing down queries.
Enclosed you can find a simple object example which facilitates multiple types and provides a semantic hint that helps to identify the object.
/object/0570e73f7079d9ce805381a380b1345 {
“@context”: {“@vocab”: “https://reg.example.com/type”}, // where to find classes “@id”: “object/0570e73f7079d9ce805381a380b1345”, // object id
“@type”: [“object”, “afb5e73f7079d9ce805381a380bbf7e5”, “acbd…a4d8”, “37b5…51f2”, “http://dbpedia.org/page/John_Doe”] // type composition + ext. link
“givenName”: “John”, “familyName”: “Doe”, “address”: {
“name”: “2st Street”, “number”: “42” } “zip”: “133700” }, “birthday” : { “year”: “1970”, “month”: “6”, “day”: “31” “time”: “11:11” } }
Example 2 This is an example of a person object. It contains multiple attributes and nested structures. The @type is a JSON-LD compatible keyword which is used to express the “classes” this object is based on. The @id is also JSON-LD compatible and provides a unique id for the object (which is also the relative IRI the object can be found under). The context identifies the base for the @type identifiers.
6.7 Registry
The types are introduced to the cloudlet via the application. Developer outfit their applications with the appropriate types by compiling the schema into the application. The users are prompted by the application for their cloudlets addresses. Once they enter the address, the application can connect to the cloudlet server. The application registers the schemata it requires with the cloudlet platform. The platform will store the schemata. The application will afterwards request access to the schemata and the cloudlet server will ask the user if they agree to these access rights. If the user agrees, the cloudlet will provide an access token to the application, which enables it to access the corresponding data.
