Based on the success of the Web 2.0, today's IT systems are continuously moving from a solely information-centric data perspective to a more person-centric model and are thereby becoming more social. In this paper we discuss the challenges within the redesign of established data models resulting from that shift. Our aim is to derive requirements for a flexible social (person-centric) data integration layer which enables us to aggregate data from several distributed services while retaining the assignment to the individual (personal) identities. In addition to these theoretical considerations we describe how a “CommunityMashup” could be developed, easily maintained and adapted to frequently changing APIs with a service-oriented approach.
A study of different commercial and open-source Enterprise 2.0 tools in 2009 showed
that only two out of the seven systems supported tracking of user activities. But all of
them enabled their users to trace content changes [
Beside increased significance of personal data today’s IT services have become
more modular and more open (in terms of accessibility to data) during the last decade.
Hence we are facing a variety of different data sources and at the same time the wish
to access (identical) data in different ways as for example with desktop applications,
websites or mobile devices. Already in 2005 Beale showed different systems
supporting social interaction with smartphones and mobile consumption of content
[
Although there are other approaches dealing with data models for Social Software,
e.g. the Semantically Interlinked Online Communities [
As activities of other people / groups are becoming more important and the corresponding data will need to be consumable in various contexts with different devices we are using three representative application scenarios where the integration of person-centric data plays an important role. Adapted from these scenarios we will derive specific challenges and requirements for a data model and a technical solution.
For enabling elderly people to access awareness information from Social Networks without being a direct member of every online service, we currently construct a mobile application showing aggregated awareness information. The displayed information consists of data provided by several people of interest in different social services. In this application scenario information has to be delivered from several people through different services and networks to one single person adapted to his or her individual needs.
CommunityMirrors are large screens presenting information that is otherwise hidden
in IT systems in (semi-) public places, like coffee corners, lobbies or beside the
elevator as described e.g. in [
As third application scenario we use the decentral federated research database
(DFRD) presented in [
When two or more people are using different online services the heterogeneity of data formats and interfaces makes the data delivery from one person to another very difficult. Main challenges are the handling of differing data models, the availability of various formats and the use of frequently changing interfaces. In addition to that several authentication and authorization methods as well as questions concerning licenses and laws about how data may be reused or stored have to be considered.
As ubiquitous devices in all thinkable shapes and colors have become more and more important during the last decade we are facing heterogeneity on the client side, too. Derived from the application scenarios (see Table 1) we distinguish between three different client classes that can consume the aggregated data. The main differences between these classes are the availability of computing power, memory and network connections.
1. Web applications are the most commonly discussed class in the context of mashup development. They are typically executed on a web server and can be accessed with web browsers. 2. Rich client applications execute most of the required calculations on the client device and therefore require a high amount of computing power and memory. 3. Applications for mobile devices have to deal with much less computing power and memory. Most of the available network connections have unreliable bandwidth.
While mobile and web applications need permanent network connections for data access there are certain settings for rich client applications without the availability of a continuous network connection. But there’s still the need of permanent and fast access to required data. The data aggregation itself is independent of the application class. But the different classes require special interfaces to access the data.
In the Web 2.0 era every user provides a huge amount of personal data. Thus, there is a demand for preventing third persons from seeing private information. For that reason most Social Networking Services offer the possibility to grant access only to specified persons or explicitly to external services. These mechanisms must not be bypassed by mashup solutions. So we are facing the requirement to integrate authentication and authorization mechanisms on the mashup side.
Another challenge is the combination of data coming from different sources. With the person-centric approach this mainly requires the decision if two profiles belong to the same human being. Social Software in general relies on users being able to manage their personal data by themselves, for example by providing links to their various profiles. This process can be supported but must not be restricted by any technological automatism, since it might not be sufficiently transparent for the user. 3
To meet the challenges described above the most important requirement besides a person-centric approach is a highly configurable mashup system built with flexible service components reusing existing frameworks. Model driven development for components affected by data model changes is a major claim.
We propose an object-oriented solution to enable direct high-level access to and modification of aggregated data. The introduced application scenarios and the existence of flexible tool chains for application development are the main reasons for this approach. In addition to that generated application frameworks allowing easy development of similar community applications in future versions.
Figure 1 shows the core elements of the current version of the CommunityMashup
data model. The main objects person, content and organization are derived from
data model. The main objects person, content and organization are derived from
existing models like SIOC2 [
Content
+parent
Organisation 0..1
InformationObject + id +author 0..1 +contributors
Person 0..*
+ name +extendedBy 0..*
Extension +leader +members 0..* +extendedBy 0..* In contrast to other models, one important design principle is to include less meta data
In contrast to other models, one important design principle is to include less meta but instead allow tagging and categorization of information. By this approach a lot of data but allow tagging and categorization of information. By this approach a lot of the meta dmaetata cdoamta icnogmfinrogmfrodmifdfeifrfeenretndtadtaatassoouurrcceess iisstrtaransnfsofromremdetdo ctoatecgaotreigesoraineds taagnsd. tags. Only iOdnelnytiitdyenptirteyseprrevsienrgvincghacrhaacratectreirsitsitcicss lliikkee ee..gg.. ththeenanmameoef oafpaerspoenrsaoren maroedemledodeled
ExtenEsixotnenssfioonrsefaosrieearscieormcobminbaintaiotinon automatically.
A person is represented by one single object independently of how often it appears A person is represented by one single object independently of how often he or she within the different sources. This means that persons as well as organizations only appears within the different sources. This means that persons as well as organizations have one consolidated version. With every new data source the aggregated only hinafvoermoantieoncwonillsojulisdt abteedexitdenednetdit.yA.nWexitthenseivoneroybjnecetwfodrathtae isnofourrmceatitohnecoamg ginrgegated informfarotimonanwaidldlitjiuosntalbseouerxcetewndileldb.e Acrneateexdteanndsiorenferoebnjceecdt infotrhethdeatainsefto.rTmhaistiaolnlowcsoming from akneeapdindgititroancakl osfotuhreceorwigiinll abned crreeinatteegdra,ttioanggoefdchaanndgersefbearcekncinetdo itnhethsoeudrcaet.asFeotr. This allowsexkaemeppliengestpraeccikalloyf ttahgegeodrigexintenasnidonreoibnjteecgtsractianngecahsialyngheasndblaeckcoimnptolextherelsaotiuorncse. For between persons. example specially tagged extension objects can easily handle complex relations betweeMnopdeerlsdornivse.n development enables data model evolution Modelfudturrieveneneddse.vTehleorpefmoreenwteenneaebdlaewsadyattoammakoedtehleeavdoalputitoino nto model changes as easy
There is no way to determine all facets of a data model in advance so that it fits all There aiss pnoosswibaley wtoithdoeutterthmeinneeeadlloffamceatnsuaolfcahadnagteas mtootdheel aipnplaicdavtiaonncsebsaosedthoant itthefits all future mneodeedls. .UTshinegreafocorentwinueonuesetdooal cwhaayintooffmeraskteracthkeingadoafpdtaiotanmtoodmelocdhealncghesanangdesthaes easy as posrseigbelnee,reatsipoencoiaflalyppwliciathtioonutcothdee naseewdelolfasmmaniguraatliocnhaonfgeexsisttiongthdeataaptopltihceatnioewnserbased version. As we are using a central data model and transformation rules for data from on the model. Using a continuous tool chain offers tracking of data model changes external services, these model transformations can be adapted (semi-) automatically. and the regeneration of application code as well as migration of existing data to the newer version. As we are using a central data model and transformation rules for data 2 SIOC: Semantically Interlinked Online Community from 3eFxOtAerFn: aFlriensderovfiacFersie,ndthese model transformations can be adapted (semi-)
The CommunityMashup consists of smaller independent modules. Each of these modules acts as a service component and can be combined with others to a complex mashup system. This allows flexible integration of existing services and the distribution over different physical machines. 2 SIOC: Semantically Interlinked Online Community 3 FOAF: Friend of a Friend modules acts as a service component and can be combined with others to a complex distribution over different physical machines.
The meta model shown in Figure 2 describes the possible system compositions.
Basically a mashup system is composed of several sources. The The meta model shown in Figure 2 describes the possible system compositions.
characterizes how the source data is assigned to the target data of the model. Every Basically a mashup system is composed of several sources. The mapping source has a configuration containing meta data, e. g. authentication parameters. characterizes how the source data is assigned to the target data of the model. Every mapping
Additionally there can be an explicit adapter used to transform the data from the source has a configuration containing meta data, e. g. authentication parameters.
external service to a representation according to the internal data mode. The data Additionally there can be an explicit adapter used to transform the data from the provided by a source is optionally filtered by a chain of filters, e. g. for privacy external service to a representation according to the internal data mode. The data reasons. Furthermore every mashup can by itself act as a source and thereby be reused provided by a source is optionally filtered by a chain of filters, e. g. for privacy in more complex compositions. In addition to that the mashup offers the possibility to reasons. Furthermore every mashup itself can act as a source and thereby be reused in persist the data from every source as well as the internally “mashed-up” data in either more complex compositions. In addition to that the mashup offers the possibility to a file or a database. Besides caching which is necessary in offline scenarios this can persist data from every source as well as the internally “mashed-up” data in either a be used to satisfy performance or availability requirements. file or a database. Besides caching which is necessary in offline scenarios this can be
Finally every source and every mashup will be an independent service component used to satisfy performance or availability requirements.
that can be deployed, enabled and disabled separately. This aspect is important in Finally every source and every mashup will be an independent service component order to be able to create distributed mashup configurations. Also a direct execution that can be deployed, enabled and disabled separately. This aspect is important in of mashup components on the client device is possible. For example there could be a order to be able to create distributed mashup configurations. Also a direct execution mashup component running along with its persistency component as a local cache. of mashup components on the client device is possible. For example there could be a
With this approach local components can be directly integrated in rich client mashup component running along with its persistency component as a local cache.
applications. This enables high level access to data objects without the need to deal With this approach local components can be directly integrated in rich client with data exchange. Together with a local persistency this allows seamless switching applications. This enables high level access to data objects without the need to deal between offline and online data usage. with data exchange. Together with a local persistency this allows seamless switching between offline and online data usage.
class MetaModel
Configuration
Persistency File
Database
Filter
+nextFilter +fliterchain 0..1 Source Mashup
Mapping 0..1
Adapter components.
and all dependent components.
A graphical editor for the creation and change of mashup configurations based on the
A graphical editor based on the meta model which allows the creation and change meta model is planned. Most parts of this editor can be generated with existing tools.
of mashup configurations is planned. Big parts of this editor can be generated with Future versions of the editor should be able to interpret these configurations for an existing tools. Future versions of this editor should be able to interpret these automatic deployment and execution of the individual mashup and all dependent configurations for an automatic deployment and execution of the individual mashup
For the creation of the data model and the meta model we used the Eclipse Modeling
Framework (EMF) [
In the previous chapter we introduced the technical solution of the CommunityMashup. We are continuing with a brief overview of the possibilities of concrete applications based on this technical base.
One of the most important aspects is the discovery of communities that were formerly hidden and distributed over several networks. By combining data from the different networks connections of people will be visible, e. g. knowing the same person or liking the same content. Furthermore the CommunityMashup enables access to an aggregated profile of a person that contains all distributed information. The data model allows keeping track of the data origin, so that changes in the profile can be passed to the original source or delivered to all other profiles.
Many of the content-centric services, e. g. wikis, don’t support person-centric awareness streams. With the integration of these services into the CommunityMashup there will be the possibility to automatically create activity streams or similar awareness information. This information can be used in applications based on the CommunityMashup and can be delivered to other source services integrated in the same mashup system. For example a new Wikipedia article can be automatically published as a status update in the Facebook activity stream of the author.
From a more technical point of view, the proposed CommunityMashup solution facilitates the development of applications based on this technical base. The implementation of the three introduced application scenarios (Chapter 1) can be managed without dealing with data integration questions by using a high level API and the integration of CommunityMashup components. 5
Based on the motivation for a person-centric data model for Social Software we outlined challenges within the design and development of a flexible mashup solution and presented a person-centric data model. The use of model driven development can help to facilitate model changes. Application source code can be adapted without manual interaction. Furthermore existing data can be migrated without data loss. The CommunityMashup meta model shows the different components of the mashup solution and denotes the possible configuration options. Concerning the architecture of the CommunityMashup we gave a short overview and introduced the technologies that could be used for its implementation.
As stated in Chapter 2 we consider three target application classes: web applications, rich client applications and applications for mobile devices. Currently we are working on the three usage scenarios of the CommunityMashup described in the motivation: 1. A solution for “best agers” (elderly people) to access awareness information from Social Networking Services with mobile devices. 2. Large semi-public wall-sized screens, our so-called “CommunityMirrors” as a rich client application. 3. A decentral federated research database as a web application with the possibility to present aggregated and filtered data on different web sites. In all of these scenarios we try to enhance the presented data model and the mashup architecture itself in an iterative incremental way in order to be able to make empirical statements about e.g. the usefulness and efficiency in future examinations.