GDPR's Right to Data Portability requires data to be provided in an interoperable, commonly used, and machine-readable format and facilitates its transfer between controllers. However, a major challenge for such data to be used between di erent services is agreement over common schemas to de ne the semantics of data. We present our vision of a holistic process for organisations to export and import data in an interoperable manner by using ontology matching and mapping techniques to identify a common model towards schema-negotiation. Our approach enables organisations to exchange data using a common base schema, thereby motivating greater innovation in the ecosystem through data reuse. To demonstrate our vision, we present a proof-of-concept application of ingesting data from Facebook into Twitter.
Interoperability of data between services can facilitate innovation, collaboration, and competition to enable a richer ecosystem of services. The Right to Data Portability (RtDP) was designed and implemented with this as the motivation in Article 20 of the European General Data Protection Regulation1 to provide a legal impetus for data to be exported out of silos and shared between services. RtDP requires organisations2 to provide a copy of personal data they have collected from an individual in a structured, commonly used, and machine-readable format. RtDP also permits data to be transmitted directly to another organisation. In principle, this provides individuals as well as organisations the freedom to obtain and reuse existing data from di erent services and encourages greater competition and innovation between services by countering data silos and user monopolies.
As of August 2020, however, RtDP is yet to be e ectively implemented, and
there is a lack of consensus in structure and semantics of data which presents
technical di culties associated with interoperability and data sharing across
services [
In this article, we present an overview of practical problems regarding implementation of data portability which skew the balance of power against new services and SMEs (small and medium sized enterprises). We then present our vision for a solution that aims to solve this problem using the notion of semantic interoperability where `data models' or `schemas' are a) developed within a community, b) embedded or associated with data to convey meaning, and c) aligned with other schemas to enable importing and exporting data between services { thus achieving the intended goals of RtDP.
The novelty of our approach is within the lack of consensus about semantics required between exporting and importing services through a registry of curated schemas that act as a base for interpretation and permit variations in use-cases and applications. To achieve this vision, we propose the use of ontology matching and alignment techniques as the `bridge' for data interoperability between two services. Further, we discuss the application and role of ontology matching to produce mappings for exporting (downlift) and importing (uplift) data directly between services.
The rest of this article is structured as follows: Section 2 presents the legal requirements and existing implementations of RtDP, and discusses practical challenges with a focus on the feasibility of meaningful exchange of data and the role of semantics; Section 3 presents our vision of a solution and its application on a hypothetical scenario involving transfer of data from Facebook to Twitter; Section 4 concludes this article with a discussion on the practical considerations for implementing our solution and its potential for helping SMEs innovate in an existing dominant ecosystem.
2.1
Article 20 and Recital 68 of the GDPR3 stipulate data to be provided under
RtDP to be structured, commonly used, machine-readable, and interoperable
format. further introduces the requirement of interoperability and motivates
creation of interoperable formats that enable data portability. They also provide
for such data to be transferred (directly) from one Data Controller to another.
The guidelines on RtDP provided by Article 29 Working Party (WP29) further
3 This articles focuses only on the data formats and interoperability requirements for
RtDP. Conditions where the right applies, obligations of an organisation, and its
compliance is not relevant to this work.
clarify that the RtDP \does not place obligations on other data controllers to
support these formats" [
Guidelines by WP29 and various Data Protection Authorities on data
formats includes use of XML, JSON, and CSV which are widely adopted and used
for interoperability. WP29 states that such data formats should be accompanied
\with useful metadata at the best possible level of granularity, while
maintaining a high level of abstraction ... in order to accurately describe the meaning
of exchanged information" [
Currently, EU's Next Generation Internet initiative is funding projects through
the Data Portability and Services Incubator (DAPSI6) which lists directions for
possible solutions as common shared formats, vocabularies and ontologies for
domains, and methods for (semi-)automatically converting data including semantic
mapping. The ISO/IEC 19941:20177 standard for cloud interoperability outlines
the requirements for semantic interoperability, and the practical use of semantic
web standards towards shared understanding. An early paper from 2008
presented reuse of semantic web vocabularies for data interoperability within social
networks [
RtDP has been implemented in a wide range of services given its nature as a legal obligation. Several organisations have developed dedicated tools for RtDP such as Google's `Takeout', Facebook's `Download Your Information', and Twitter's `Your Twitter Data'. An example of data portability directly between services is transferring photos from Facebook to Google Photos8. The Data Transfer Project9 (DTP) is a combined initiative consisting of IT behemoths Apple, Facebook, Google, Microsoft, Twitter - to develop an open-source, service-to-service data portability platform. To this end the project is developing10 `Data Models' as a common interoperable schema between services.
While these examples are optimistic, the reality is that RtDP has not seen its
full impact, and has not been su ciently implemented by any service or
organi4 https://ico.org.uk/for-organisations/guide-to-data-protection/
guide-to-the-general-data-protection-regulation-gdpr/
individual-rights/right-to-data-portability/
5 Semantic interoperability was an explicit aim in earlier drafts of WP29 guidelines
but was reduced to just `interoperability' in the nal published version [
Semantic interoperability, in its role as a solution for data portability, depends on the establishment and sharing of schemas along with the data. schema.org11 is a good example of shared and interoperable schema development across services and use-cases based on its continued development and use at web-scale. Another example is Shape Repo12 which reuses existing vocabularies (such as WikiData13) to declare schemas for use in SOLID14 application development. Similar to these, we base our approach on establishment of common schemas for semantic interoperability through community engagement and maintenance. In this section, we discuss some challenges present within the ecosystem which justify our approach of a community-driven common schema.
(1) When exported data contains no schema: Unless there is an explicit legal requirement that mandates the association of schemas in a speci c manner with exported datasets, this situation is likely to continue. So the question arises over who should develop and maintain the schemas? A dominant organisation has interest in maintaining control over its data and reducing its usefulness to other organisations who might be potential competitors. At the same time, these other organisations (and individuals) would be interested in reusing the exported data to enrich or enhance their own features and o erings. Therefore, it is in the natural interest of the community at large to produce schemas to enrich its data-based services to drive innovation and competition. The existing ecosystem based on services o ering APIs presents validation of this argument.
(2) When exported data contains a schema: If a service already provides a schema with its exported dataset, it is easier to utilise this schema rather than develop a new one. However, in the longer run, an independent schema is 11 https://schema.org/ 12 https://shaperepo.com/ 13 https://www.wikidata.org/ 14 https://solidproject.org/ more resilient to control by one provider and can also be managed more e ciently across use-cases. This is evident in the situation where the service changes its schema, thereby requiring every tool and service dependant on its schema to also change their implementations. Therefore, even where a data comes with a schema attached, it is bene cial to develop a common schema and super-impose the data's schema on it.
(3) Stakeholders beyond domains: Thus far, we have only considered situations where services directly compete with each other within the same domain. However, data can also be useful for integration into other services or for added features. An example of this is a service that o ers recording `daily logs' from a user's social media posts regardless of service. In such cases, it may be to the bene t of the service provider to encourage development of features dependant on its data. While the data providing service would want to restrict such services to only work with their data, the service itself would be inclined to support as many services as possible - an avenue for using common schema and tools based on it.
(4) Cost of development and Control: Larger organisations have more resources at their disposal and larger freedom to experiment. Small organisations (SMEs) are often resource-constrained and rely on innovation to compete. Therefore, a common and shared approach for managing intoperable data is of greater bene t to SMEs, which provides an incentive for them to pool their use-cases and resources together to collaborate and share the burden of competition. 3
Our vision for implementing RtDP addresses the challenges discussed in Section 2.3 by proposing use of common schemas for `semantic interoperability' in data exchange between services. This includes an interoperable data portability arrangement that bene ts all stakeholders by permitting data exporters to continue using their own semantics and data importers understanding the embedded semantics in data. The common schema is used to abstract service-speci c design patterns and to serve as a source for common data within a domain. The shared-community aspect of the approach enables sharing of tasks and reducing the e ort required in reuse of data and establishing common schemas.
The role of semantic web in this process concerns acting as an interoperable semantic representation using the RDF, RDFS, and OWL standards. We propose utilising ontology matching and alignment to identify the correct schemas for data exported from service A to be transformed and imported into service B. We also propose utilising ontology matching to permit reuse of data based on common schemas without explicit agreement between an exporter and importer. Similarly, we also propose using uplift/downlift mappings between schemas as a technique to potentially perform this step without requiring transformation of data into RDF.
Ontology matching is \the process of generating an ontology alignment
between a source and a target ontology" [
To explain and discuss the application of semantic web, ontology matching, and mappings in our approach in detail, consider the hypothetical use-case of an individual wishing to obtain posts exported from Facebook and import them to Twitter. This use-case can also be generalised for services both within and outside the social media domain looking to import and reuse some or all of the Facebook data - which furthers the usefulness of our approach. 3.1
Currently, both Facebook and Twitter19 export their data under RtDP as JSON20 | a non-semantic format.
The rst step in ingesting Facebook's JSON data is thus to understand its structure and its schema. Where services undertake this e ort individually, each service has to duplicate the e ort of understanding the structure and keeping its tool updated. By sharing this task, the community can maintain a documentation of the data's schema and structure. If and when Facebook changes the data structure or format, the community can update its documentation without duplication of e ort. While it is Facebook's prerogative to structure its data and change it as it feels t - an argument can be made that frequent and unreasonable changes are detrimental to the spirit of RtDP.
To minimise impact of such changes, a schema corresponding to Facebook's data is created in the common registry, and any tools ingesting Facebook's data utilise the schema instead. Minimal e ort is required to `transform' the data from its underlying structure to one corresponding with the established schema - such as through a python script to convert to CSV or through RDF mapping to convert to JSNO-LD - based on what the desired output format is. 15 The \OM" workshop has been continuously running at ISWC since 2006. 16 OAEI, the Ontology Alignment Evaluation Initiative, has been running yearly since 2004, evaluating the latest ontology matching technologies: http://oaei. ontologymatching.org/ 17 http://alignapi.gforge.inria.fr/ 18 http://neon-toolkit.org/ 19 Information about Twitter's data may be out-of-date as its export tool has been non-operational as of August-15-2020. 20 Facebook exports data as a JSON dump. Twitter exports data as a JavaScript le with JSON objects. Neither supply information about the schema or structure of their data.
The creation of a Facebook schema is based on rst creating a common schema representing `a social media post'. The concepts in the Facebook schema are thus specialised variations of the common schema, representing Facebook as a speci c type of social media. This abstraction permits a data importer to target data speci cally from Facebook (through the Facebook schema) or any social media (through the common social media schema). The abstraction also works to encourage designing common tools to work on the data rather than specialised ones targeting individual services. Figure 1 depicts an example of a common schema targeting social media posts.
The creation of a common schema where none exists is di cult if a community agreement is necessary over its concepts and structure. Therefore, we suggest seeding the rst common schema with concepts from dominant data providers in the domain and normalising it towards other existing providers. In the current use-case, this would mean rst creating a schema from Facebook's data, then creating a common schema based on Facebook's schema, and updating Facebook's schema to use the common one as its base. By this we mean sub-classing concepts in specialised schemas from common ones. Later, when creating Twitter's schema, the existing common schema for social media can be used to guide the schema creation process. 3.3
In the common and Facebook schemas, the generic terms `post', `media', `timestamp' are suitable for use in both since Facebook does not have any specialised variation of these. However, concepts such as `like' or `reaction' may present problems in abstraction and generalisation as they may not be present in other service in the same context. For example, Twitter de nes21 the `ยช' symbol to mean a `like' whereas Facebook de nes22 its `reactions' as an enumeration consisting of `like, love, wow, haha, sorry, angry'. Aligning the two is di cult due to semantic di erences in the two terms. One interpretation is that only a Facebook `love' is equivalent to Twitter `like', whereas another possible interpretation is that any Facebook reaction should be equivalent to Twitter `like'.
We propose the use of ontology matching and alignment techniques to assist in the schema alignment and discovery process as well as to resolve equivalence between concepts. This can be an automated process, but we also emphasise its value in encouraging discussion amongst schema creators and maintainers through a human-in-the-loop process. The role of common schemas in this is to provide a measure of commonality in the identi cation and structuring of source and target schemas, as well as to ease the process of nding related and equivalent data patterns. For example, in the case of a Facebook post and Twitter `tweet', the relationship is easy to establish based on their common super-classes.
Facebook Common Schema Twitter Type of alignment Post Post Tweet Simple Contents Contents Contents Simple Timestamp Timestamp Timestamp Simple User Person Pro le Complex Friend Knows Follows Complex
Attachment Media Media Simple
Ontology alignment techniques may also provide a way to integrate data where no possible contextual similarity is apparent. For example, Facebook's `friend' concept and Twitter's `follows' concept are di erent in their behaviour and discourse - yet they share similarity in their pattern of association with an individual. It is up to the importer then to determine whether they want to support and utilise such alignments or to discard them in favour of more semantically-re ned ones.
Once the matching concepts have been found, the process of transferring data to the target service can take place. An explicit way to do this is to rst transform the source data to RDF using its corresponding schema (in this case the Facebook schema), then creating an alignment table using the ontology matching process, and then to generate the dataset using the target schema (in this 21 https://help.twitter.com/en/glossary 22 https://developers.facebook.com/docs/graph-api/reference/v8.0/object/ reactions case the Twitter schema). To reduce the number of transformations required in this process, mappings can be potentially used to directly enable the importing service to ingest the source data without the intermediary transformations.
Uplift mapping is the process of converting a data into RDF, while downlift is its inverse. Considering that Facebook exports a JSON data dump, and that Twitter similarly will import23 a JSON data dump - the process of transformations will involve: (i) uplift Facebook's JSON data into RDF using Facebook schema; (ii) transform RDF data from source schema into target schema using the ontology mapping process; (iii) downlift data into JSON for Twitter. Since the role of step (ii) is merely to nd an alignment between the schemas of Facebook and Twitter, the actual transformation of data can take place directly from Facebook's JSON to Twitter's JSON format. 3.4
An interesting research question thus arises out of this arrangement - \can we
utilise the schema alignments and the mappings to create a tool that will convert
the source data to target data?". We believe that it is reasonable to hypothesise
that such a tool can indeed be created based on the fact that the structure (i.e.
speci c arrangement of data structures) of source and target data can itself be
considered schemas, and therefore can be utilised to convert one to another.
The question around implementing this is then concerned about the e ciency
rather than su ciency. A related area facing similar research challenges is the
utilisation of GraphQL to retrieve data from a triple-store in the shape requested
by rewriting the query in SPARQL [
The use-case we discussed concerned moving data from one social media service to another (Facebook to Twitter). However, RtDP makes it possible to reuse data across a larger plethora of services across domains. For example, Facebook's data contains information about locations the user has tagged their post with (or checked-in). This information could be relevant in any other service providing features that utilise location data - such as a visualisation service that shows all the locations an user has been to on a map. Such a service may want to broaden its data import feature to encourage users to submit any location data regardless of its source. Potential sources of such data include: explicit location data shared by user, location tagged in photos, location tagged in social media posts, location inferred from place names and descriptions, location associated with review of a restaurant, or location associated with monetary transactions of a card. Instead of developing separate tools for each of these sources, the service can instead target the underlying common location schema and utilise our approach to ingest the data from a variety of source without additional e ort.
In order to identify the potential sources of data, the service can declare the schema for the data it intends to import. For example, this can be a location 23 Twitter does not provide a data import service. So we reasonably assume its import tool will accept the same data format and structure as its export tool concept with a label and co-ordinates. A label-based search for related schemas will only retrieve schemas that contain the concept location or its synonym such as `place'. However, ontology matching techniques can provide richer results by identifying similarly `shaped schemas' that contain labels and co-ordinates. Further ne tuning is possible by focusing on co-ordinates and its variations while excluding labels. This thus provides an opportunity for utilising ontology matching techniques to identify relevant design patterns for schema discovery. 4
In this paper, we proposed an approach leveraging ontology matching and alignment techniques to achieve data interoperability between online services dealing with personal data. Having GDPR's Right to Data Portability (RtDP) in mind, we described a typical use-case where users of a social networking service (e.g. Facebook & Twitter) are willing to | and should be allowed to | export their own personal data in a machine-readable format and reuse it on a di erent service. We described how Semantic Web technologies and ontology matching could assist in the alignment with a common schema that is used as a `bridge' between heterogeneous data schemas. The role of common schemas is to provide a measure of commonality in the structuring of source and target schemas. Finally, we showed how data mappings could be used, and shared via a community-driven repository, to automate the conversion processes. Actually, this last point opens the doors of e cient Data Portability to SMEs which have to allow this feature given the RtDP; in particular, SMEs will be able to minimise the cost of making user data more easily ported to another provider.
We envisage several advantages with the adoption of the proposed approach, both for end-users and companies. First, schemas and mappings are open and maintained by the community, lowering the costs for both parties in managing the data transformations. Second, maintenance costs are lowered and distributed to the community, removing possible bottlenecks or single points of failure, typical of ad-hoc data transformation pipelines. Third, a descriptive and machine-readable schema would not be required from the data exporters anymore, keeping the complexity low at the data sources. Fourth, reliability of data transformations would increase. For instance, when one data source changes, mappings updates are faster to perform compared to changes to many ad-hoc pipelines. Fifth, the automation potential would increase dramatically with improved, more accurate, ontology matching techniques.
As part of our future work, we plan to implement and test our solution in di erent use-cases and with di erent services. This would create a baseline that can be o ered to the community and, ideally, adopted and expanded by the community itself. From a more scienti c perspective, we will investigate the increased automation possibilities o ered by complex ontology matching techniques. Other avenues of potential work include exploration of our approach for interoperability between services and APIs based on semantics, evaluating the e ciency and feasibility at large scales, and discussing the application of our approach within the broader areas of legal compliance and data protection. Acknowledgments: This research was conducted with the nancial support of the European Union's Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie Grant Agreements No. 801522 and No. 713567 at the ADAPT SFI Research Centre at Trinity College Dublin. The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant #13/RC/2106.