In this paper we argue that the space of personal data is a dataspace as de ned by Franklin et al. We de ne a personal dataspace, as the space of all personal data belonging to a user, and we describe the logical components of the dataspace. We describe a Personal Dataspace Support Platform (PDSP) as a set of services to provide a uni ed view over the user's data, and to enable new and more complex work ows over it. We show the di erences from a DSSP to a PDSP, and how the latter can be realized using Web protocols and Linked APIs.
In their 2005 paper [
Not being in full control of its data is one of the key distinguishing characteristics of a DSSP. In this paper we argue that the space of personal data is a dataspace as de ned by Franklin et al., and we describe the characteristics of a Personal Dataspace Support Platform (PDSP). We show the di erences from a DSSP to a PDSP, and how the latter can be realized using Web protocols and Linked APIs.
In this section we start by detailing the characteristics of dataspaces as originally de ned. Then, we present existing related work which describes the Web of Data as a dataspace, followed by related work in the eld of Personal Information Management. 2.1
Franklin et al. describe dataspaces as having the following distinguishing
characteristics [
Dataspaces are modeled [
Franklin et al. propose a suite of key services, under the name of DataSpace
Support Platform (DSSP) from which we highlight the following: (a) access to
data, (b) cataloging, (c) browsing, (d) search and querying, (e) monitoring and
event detection. The goal of a DSSP is to provide a set of basic functions over the
heterogeneous data in a dataspace, to support the incremental building of more
complex and specialized services. While dataspaces are \not a data integration
approach, they are more of a data co-existence approach", information can be
integrated in a \pay-as-you-go" fashion, as described by Madhavan et al.[
What has started as a Web of Documents, has evolved into a Web of Data. The
Web architecture is well suited to solve data integration problems at very large
scale in an evolutionary fashion. By means of the Resource Description
Framework (RDF) a graph-based data representation is provided, which, in
combination with the use of stable HTTP URIs, allows for integrating data without the
need for fully- edged a priori schema alignment. The support for such exible,
pay-as-you-go type of data integration [
Personal Information Management stemmed as a eld of study in response to the problem of information overload. Many methods and tools have been developed to enable us to organize information better, so that we can easily nd it and re- nd it when needed. However, the growing number of applications designed to aid the management of the information had the side e ect of the information being trapped in unconnected repositories, and incompatible (proprietary) data formats, which in turn led to duplication of data and increased e ort required for organizing.
The Semantic Desktop [
With the shift to the Web, much of the personal information residing online consists of the usual PIM elements: documents, email, and calendar, but is ampli ed by social networks, multimedia, personal annotations, browsing history, activity feeds, location feeds, and much more, all out of the control of the user.
Personal Data Stores are a solution to give users back some control over their personal information. Some come in the form of cloud services which collect and integrate data from numerous other services on behalf of the users, and some are systems that can be installed locally or on servers under the administration of the users themselves. Many Personal Data Store solutions rely on the principles and standards of the Web architecture, as they provide a exible platform to realise highly interoperable network-based systems. 3
Personal Information Management is cited as the rst of two scenarios to
illustrate dataspaces by Franklin et al. [
Based on these characteristics we argue that the space of personal data, as it is now, matches the de nition of a dataspace, by ful lling the characteristics described above. The personal dataspace contains heterogeneous data, is distributed, controlled by many di erent service providers, unlimited in relation to the number and types of information that it can contain, and most importantly, is centered around the user whose data it contains. This last characteristic is what di erentiates a personal dataspace from a generic dataspace.
In the next sections we describe in more detail the components of a personal dataspace, and the services that a Personal Dataspace Support Platform (PDSP) could provide. 3.1
In our application to personal data, all the data sources that collect, store and manage personal information are participants in the dataspace. In the past, the desktop contained most of the personal data, so the participants in the personal dataspace would have been the individual applications { le system and manager, email clients, calendar, task manager, etc. Semantic Desktops uni ed most of the desktop information under a single uniform data representation and storage, regardless of the application it comes from. Thus, such a Semantic Desktop would be seen as a single participant in the personal dataspace. However, desktop applications whose data was not included in the Semantic Desktop can be separate participants, even if they reside on the same desktop. Another set of participants to the dataspace consists of the online applications that collect and store information about the user. This set can include shopping history and wish lists, activity and food tracking, trip planning, emails and calendaring, blogging and micro-blogging, social networks, etc. Mobile applications which track the user movements and activities are also participants in the dataspace.
One of the key characteristics of a dataspace is that it contains all the data in the space. Applied to personal data, this means that the personal dataspace must contain all the data about the person at the centre of the space. However, despite the ever growing number of applications and devices which collect and deal with personal data, only those systems which handle data about the central user, are participants in the personal dataspace of that user. Let's assume we have two people, Alice and Bob, each using tness tracking applications: Alice uses Runkeeper and Fitbit, and Bob uses Fitbit and Endomondo. The Fitbit application will be a participant in the personal dataspaces of both Alice and Bob, while Runkeeper will be a participant only in Alice's personal dataspace. Going further with the example, while Fitbit is a participant in both users' personal dataspaces, it participates in Alice's dataspace only with Alice's collected data, and respectively in Bob's dataspace with Bob's collected data. So, while under the control of the same organization (in this example Fitbit), the participants are in fact distinct for the two di erent users. We can make the distinction better by specifying that in the case of a Web application where the user has an account, the participant to that user's dataspace provides in fact only the view that the user's account in that application has over the data. Some service providers might collect more information on the users than they make available back to the users { for example the browsing history in online shops, and unpublished posts in social networks. Such information, while it is \personal data" is not available in the personal dataspace.
Another consequence of the personal dataspaces revolving around a single person's data is that the personal dataspace of a user can act as a participant in another user's personal dataspace, by means of sharing information between the two. This possibility requires access control management in the PDSP, a service described in the following section.
The relationships between the participants can be explicit and formally expressed { like for example when the user manually connects two applications and allows them to share data completely or partially. For example, our user Alice can explicitly allow access to her Fitbit data from her Runkeeper account, for better monitoring of her daily activity. Relationships can be also implicit, when two participants manage the same type of data, like for instance social connections or tness tracking, but without actually sharing any of the data itself. For example if Bob would also buy and use a Nike+ Fuelband, both his Fitbit and the Fuelband would record activity and movement information, like number of steps, distance, and calories, but independently of each other and without exchanging any data. Such relations can be made explicit by providing a mapping between the schemas, and thus enabling better data integration outside of the systems holding the data. The mappings can be created in the pay-as-you-go fashion, as needed and as available. The PDSP must support the creation of such mappings and the import of existing mappings from third parties. 3.2
Like a DSSP, a Personal Dataspace Support Platform (PDSP) should provide a set of services to access the data contained in the dataspace, and allow basic handling of this data, to support the development of more specialized services on top of the platform.
We list below the services a PDSP should provide, although di erent PDSPs
can choose to implement just a subset, or add more services. Some of the services
here were identi ed in [
Data access The data available from the participants is heterogeneous and dynamic. Accessing it requires support for multiple Web APIs, formats, and protocols, as well as high tolerance to errors and unknowns. This service must have available all the information required to be able to access the data in all the participating data sources, thus relying on the identity management and cataloging services.
Cataloging Depending on the kinds of APIs o ered by the participants, the catalog can contain alternative access points for di erent formats { for example HTML or JSON, or capabilities provided by the participant { for example SPARQL or REST. The catalog should also contain a schema for the data it contains. The VOID1 vocabulary is one possible way of describing the participants exposing RDF data. The catalog does not have the function of storage or archive, but rather of a meta-data store containing information about the data available.
Indexing Search is one of the essential services of a PDSP, and it requires
a reliable indexing service. Some of the participants might already contain an
index over their data, and allow direct access to it, or mediated by a search
and query function, but the PDSP should provide a uniform API over all the
participants. Specialized indexes are recommended for special types of data like
time and location. In the context of personal information the time dimension is
important for reminding [
Mapping The PDSP should provide a way for incremental accumulation of schema mappings between its participants as to enable the pay-as-you-go data integration. The mappings can be manually created by the user, automatically generated, or imported. They can be partial, when not all the possible types of data from a participant are mapped. The mappings are data themselves, and as such they can be shared with other users' PDSPs.
Integration Pay-as-you-go data integration is one of the key functions of a dataspace. In the PDSP it is provided by the mapping service, which allows the incremental creation of a directory of mappings between the data structures provided by various participants. Deeper integration can be done by allowing the creation of relations between resources from di erent participants.
Monitoring The PDSP must be aware of the changes in the data and in the state of the participants, and update its catalog and indexes accordingly. The monitoring service can use event detection mechanisms, subscriber APIs, or any other feature provided by the data sources.
Browsing, search, and query Browsing, search, and query services should allow the users to explore their dataspace, through keyword search as well as 1 http://www.w3.org/TR/void/ structured query, by iteratively re ning and restricting a domain. These services should work uniformly across the dataspace, regardless of the structure and mode of access of the particular participants, as this allows the user to have a uni ed and uniform view into the data, independently of where the data shown comes from. The user should be able to use these services on data as well as on metadata. As with the indexing service, some participants may already provide a search interface.
Identity management As described in the previous section, some of the participants which provide Web APIs to access the users' personal information require that the users are authenticated, or that the application used to access the data on their behalf is authorised. The method for authentication and authorisation could vary, and it is recommended that the PDSP supports all or most of the existing methods. The account information and access tokens must be securely stored.
Access control In combination with the data access and the identity management service, the PDSP becomes a gateway to the user's entire personal information, thus it needs to ensure that the privacy and security of the data is maintained. Additionally, in the case of one user's PDSP becoming a participant in another user's dataspace, access must be controlled so that only the authorised part of the personal data is disclosed.
Annotation Annotation refers to the creation of metadata, and in PIM it is an important feature. The PDSP should support annotation of any type of resources, data, metadata, or participants. Annotations can include data from multiple participants. Provenance is a special type of annotation, and all annotations are data, which can be shared, annotated, queried, etc.
Update Some participants may support updating data through Web APIs, although not all, and not all types of data. In cases when the update cannot be propagated to the source, the service could support saving local versions of the updated data. This can however lead to con icting versions of the same data, which is why provenance information and change logs are important. There are cases when updating data cannot be done at all, for example when it comes from sensors whose readings cannot be changed. In these cases annotations can replace the update.
The architecture of the PDSP that we envision does not provide any applications, although it does not prohibit them either. We see applications as an extra layer on top of the PDSP, and not at the core of the architecture as part of the foundational layers. We propose that the applications, as well as higher level services, are built on top of the PDSP, using the APIs provided by its services.
We consider storage as a higher level service, thus not part of the core suite of services provided by the PDSP. We do not require that the PDSP fetches and keeps duplicates for the personal data already stored by the participating data sources. The way the storage of data is handled is one of the main di erences between a PDSP and Personal Data Stores. A personal dataspace is the space of a user's entire personal data, regardless of where it is located, on the desktop or on the Web; integrated in a Semantic Desktop, or fragmented across many Web platforms. Following the original definition of dataspaces by Franklin et al., we de ne the logical components of a personal dataspace, and we describe a Personal Dataspace Support Platform as a set of services to provide a uni ed view over the user's data.
This work was supported by the EPSRC Theory and Practice of Social Machines Programme Grant, EP/J017728/1.