This paper formalizes several independent approaches on how to develop Semantic Web applications using object-oriented programming languages and Object-Triple Mapping. Using such mapping, Semantic Web applications have been developed up to three times faster compared to traditional Semantic Web software engineering. Results show that at the same time, developer satisfaction has been signi cantly higher if they used object triple mapping. We present a formal notation of object triple mapping and results of an experimental evaluation clearly showing the bene ts of such mapping. The work presented here may one day help to make Semantic Web technologies part of the majority of future applications.
Using and handling RDF data in software is not trivial to implement, especially
with regards to the large number of best practices to consider. Before even that,
developers need to learn about RDF concepts and how to deal with them using
RDF programming libraries [
In general, two issues with current Semantic Web programming libraries can be identi ed: First, their complete potential is always visible to developers, instead of by default only revealing those parts that would be su cient for a majority of implementation problems. Second, lots of RDF- and Linked Data-related implementation tasks, such as discovery, retrieval, and publishing of datasets need to be implemented by hand, resulting in huge implementation e orts even for relatively small implementation problem (cf. Section 4).
A promising approach for simplifying Semantic Web software development
is Object Triple Mapping (OTM) [
In Section 3, wie formalize OTM and extend it by a small pseudo-code vocabulary describing linked data functionality. This formalization is a starting point for further research in this important area. We used the formalization for an experimental evaluation of the bene ts of OTM. The results of this evaluation are presented in Section 4. Section 5 concludes the paper. 2
Linked Data has become one of the most popular topics among the emerging
Semantic Web [
The need of simplifying Semantic Web software engineering in a similar way
to ORM has been identi ed in [
All these solutions and the research done around them focus on speci c parts
of the approach chosen, such as feasibility and expressivity of such mapping, but
do not yet aim at supporting the whole process of discovering, retrieving,
processing, and re-publishing linked data, which will involve further steps such as,
e.g., policy or data license checking [10]. To overcome this situation we have
identi ed the principles common to these solutions and formulated design patterns
for OTM, closely resembling ORM design patterns [
It is good practice to encapsulate business or domain logic in classes and methods of object-oriented (OO) programming languages [6]. E.g., if a software product deals with people and relations between them, the software's object model likely contains a Person class and friends eld for this class. To use RDF data in most OO programming languages, the mapping from RDF properties to the domain classes' elds has to be implemented by hand. Our hypothesis is that large parts of this OO handling of RDF concepts, including discovery and retrieval on the WWW, should be hidden from software engineers, making the development of Semantic Web software much easier, and hence encouraging software developers to actually start creating such software. In the following sections, we introduce a formal notation of the knowledge representation in OO programming, a mapping between RDF and OO concepts, and a simple pseudo-code vocabulary relevant for building applications using such mapping. 3.1
The RDF data model has an established formal notation building upon the
following concepts [
in nite set of blank nodes, and L the set of literals.
{ V := U [ B [ L is the set of RDF nodes, { R := (U [ B) U V is the set of all triples or statements, that is, arcs connecting two nodes being labelled with a URI, { any G R is an RDF graph.
How RDF graphs are actually constructed, handled, and transferred is subject
to standards, conventions, and technical constraints. Linked data principles [
For OO programming, there is no single established formal notation focusing on the information representation part. Hence, we just use some basic formal concepts to capture OO environments form the information representation perspective.
of eld names.
{ S := P(O)F is the set of eld assignments s : F ! P(O), { Q := SO the set of system states q : O ! S.
A system state q 2 Q maps each object o 2 O onto a eld assignment s := q(o) 2 S, which in turn maps each eld name f 2 F onto the object's values s(f ) O for this eld. Note that in our notation, a eld assignment returns sets of objects as eld values. This allows to represent programming concepts such as array or collection objects. Ordered lists and formal cardinality and type restrictions (i.e., scalar-value elds or statically typed object de nitions) on OO data models are outside the scope of this paper but can easily represented on top of our formalism if needed.
Example 1 (comparison of RDF and OO data model) Let p1; p2; p3 2 U be URI denoting three people, n 2 U be the URI foaf:name and k 2 U be the URI foaf:knows. An RDF graph describing p1 and p2 might look the following.
G := nhp1; n; \John Doe"i; hp1; k; p2i; hp1; k; p3i; hp2; n; \Jane Doe"io Let us now have a look at this example from the OO perspective. Let o1; o2; o3 2 O be object identi ers denoting three people, name; friends 2 F be eld names, q 2 Q a system state, and s1 := q(o1); s2 := q(o2). The OO representation of G will look the following.
s1(name) = f\John Doe"g s2(name) = f\Jane Doe"g s1(friends) = fo2; o3g 3.2
In this sections we continue to use the set de nitions from the previous section. De nition 3 (Object triple mapping, OTM) An object triple mapping for an RDF Graph R, elds F and objects O is some (G; mt; ma; q) such that { G R is an RDF graph { mt : F 0 ! U for mapped elds F 0 F (the vocabulary map), { ma : O0 ! U for mapped objects O0 O (the instance map) { q 2 Q a system state such that for all u 2 U , o 2 O0, f 2 F 0 and s := q(o) jma 1(u) \ s(f )j 1 jma 1(u) \ s(f )j = 1 , hma(o); mt(f ); ui 2 R Note that this de nition does not require the instance map ma to be injective, which would be desirable in many cases, at least from a software engineer's point of view. However, there might be di erent simultaneous OO representations oi of a single RDF resource u resulting from, e.g., di erent data licenses, trust policies, or access control decisions. Hence, the injectivity of the actual instance map presented to the developer should rather be ensured using additional formal representations of policies, contexts and the like, instead of being a general requirement to the instance map. Also, our notion of OTM does not necessarily require a class map for RDF and OO, since many dynamically-typed object-oriented programming languages do not have the notion of classes. For statically-typed programming languages, an implementation of such class map will however be required. Treating other RDF concepts such as lists or rei cation, and also the semantics of RDFS and OWL are not part of this mapping, but subject to OTM implementations.
Example 2 (OTM) To map RDF representations of people to the
corresponding OO representation (cf. example 1), we need
{ a vocabulary map mt : name 7! n, friends 7! k;
{ mapped objects o01; o02; o03 2 O0 such that ma : o01 7! p1, o02 7! p2, o03 7! p3;
{ a system state q 2 Q and eld assignments s01 := q(o01) and s02 := q(o02).
The mapped objects o01; o02 will exactly look like o1; o2 from example 1:
Although several implementations of such mapping exist (cf. Section 2), for our
research we use our own OTM implementation, which is available licensed under
the GPL3. This implementation strictly follows the OTM design patterns derived
from object-relational patterns [
{ use(u) for u 2 U : Set up the OTM implementation to use the dataset u, i. e. evaluate the data license, and set up the SPARQL endpoint to be used. Even further decisions can be made, such as deciding upon some statistics whether to dereference single URIs for this dataset or rather to download a data dump. { publish(O00) for O00 O: Publish objects as linked data, either by producing serialized RDF les, or by hooking into some Web programming framework. By con guring meta-data for publication such as licenses, several checks, e. g. on license compatiblity, can be performed. 4
Our primary motivation for investigating OTM is to understand why Semantic Web technologies have been picked up so hesistatingly by software developers, and to show software developers how they can simply use and bene t from these technologies. We asked software engineers with little or no experience in Semantic Web software engineering (but yet su cient programming skills) to solve a problem using RDF data sources and programming libraries. 4.1
Each participant was assigned two tasks, one of which was to be solved without OTM, and the other one using OTM. The order of the two tasks and the order of using/not using OTM was randomized to ensure the results will not be distorted by learning e ects. Participants used the Eclipse programming environment and the jUnit framework to test their results4. To simulate the usual work- ow of Web programmers, we provided the participants with example source code of similar solutions [12].
Tasks. The experiment dataset consisted of 12,726 ctious foaf:Person resources, 100 foaf:Document resources, 15 foaf:Group resources, and 169 bldg:Room resources5. Each document had between 2 and 4 authors, each group between 8 and 15 members, and each person knew a number of other people. All resources could be dereferenced by their URI. The following tasks needed to be solved. Task 1. Given a set of URI identifying documents, construct the set of all the documents' authors' names.
Task 2. Given a URI identifying a person, construct the set of all person's friends' friends' names.
The participants were expected to nd a solution close to the following pseudocode (using the vocabulary from Section 3.3), which was however not presented to the participants.
Solution 1. GET_AUTHOR_NAMES(publication_uris): load(dataset_uri) for each uri in publication_uris publication = get(uri) for each person in publication.authors
return person.name Solution 2. GET_SECOND_ORDER_FRIENDS(person_uri): load(person_uri) person = get(person_uri) for each friend in person.friends load(friend.uri) for each friend2 in friend.friends load(friend2.uri) return friend2.name 4.2
Di culty. After each of the two assignments, participants were asked to estimate the di culty of the assigment, the maintainability of the resulting source code, and how di cult a solution would have been using XML stores or RDBMS instead of RDF, on a scale from 0 (trivial) to 10 (too hard). After the rst assignment only (which randomly had to be solved either using OTM or without OTM), participants were asked whether they see potential use of RDF in their near-future projects. Along with these subjective measures, we tracked the time required to nd a working solution, and the number of edit-debug cycles. Source code. Since OTM encapsulates large parts of RDF data handling it is expected that solutions building on OTM will have less lines of code than solutions than non-OTM solutions. To get a deeper understanding of how lines of code will be reduced, we separately counted lines of code carrying { language constructs such as loops, variable declarations etc.; { RDF library initialization code, i. e. creation of or connection to data stores; { data access code, i. e. imperative statements for URI handling such as get, load, use, or query operations, (cf. Section 3.3), and RDF concept manipulation using RDF libraries; and { business or domain logic, i. e. lines of code manipulating domain objects such as people, publications or names, e. g., by handling or accessing elds of domain objects.
Feedback. Besides these rather quantitative metrics, we gathered feedback during and after the experiment. In a questionnaire, we asked the participants to identify the biggest problems during nding the solutions, and to name other types of support they wished they had. 4.3
Undergraduate computer science students at Hasso Plattner Institute, University of Potsdam were invited to to participate in the experiment. Ten participants aged 19 to 27 (mean 22.6) actually took part in the experiment. All participants had between 4 and 9 years of programming experience (mean 6.6). According to their estimation on a scale from 0 (none) to 10 (expert) prior to solving the assignments, only three of them said having some basic knowledge about RDF, the others none (mean 0.9). All participants were experienced with the Java programming language (mean 5.4). Also, most participants had some experience using traditional information stores such as XML documents (mean 3.4) and RDBMS (mean 3.9). 4.4
Di culty. The results for developer satisfaction were surprisingly clear (Fig. 1). Implementing the assignments was found to be signi cantly easier using OTM (mean 2.4, = 1:8) than using the Jena RDF library only (mean 6.4, = 2:1). Also, the participants judged their solution signi cantly easier to maintain (both for themselves: 1.13, = 1:6, and if they let somebody else do it: 2.13, = 1:5), if OTM had been used compared to non-OTM (means 4.3, = 1:8 and 5.9, = 1:1). However, whether the rst assignment was to be solved using OTM or without OTM had no in uence on the participants' estimation of the di culty of integrating Semantic Web technologies in their own future projects (means 4 and 5). Regarding the estimated di culties, we can eliminate variance by comparing the di erences of the di culty of the implementation and the estimated di culties of alternative approaches using XML or RDBMS (Fig. 2). By means, the non-OTM solution has been rated more di cult compared to traditional data formats, whereas the OTM solution has been rated easier to implement than traditional data formats. However, the di erences for these relative di culties are not signi cant. For Task 1 ( nding the names of publication authors), both the number of edit cycles (non-OTM mean 29, = 6:6) and the time needed to nd the solution (mean 1.2 hours, = 0:5) was signi cantly lower using OTM (8.8 edit-debug cycles, = 6:2 and 0.4 hours, = 0:2, Fig. 3). For Task 2 ( nding the names of friends' friends), the mean number of edit-debug cycles was increased from 8 to 19, while the mean time needed to nd the solution was decreased from 0.6 hours ( = 0:3) to 0.4 hours ( = 0:4) using OTM. However, the di erences for Task 2 are not signi cant. The combined gures for Task 1 and Task 2 show that the number of edit-debug cycles remains stable, but the development time has been decreased signi cantly using OTM. It is unclear why the number of edit-debug cycles is larger for Task 2 using OTM. But since the development time was not increased, we do not consider this a general weakness of OTM. It will however be interesting to direct further research in this direction. Source code. The gures for the source code metrics are clear again (Fig. 4). The overall lines of code are reduced from 20.9 ( = 5:4) not using OTM to 11.3 ( = 7:7) using OTM. The number of lines of code carrying language constructs (mean 5.1 for non-OTM and 4.4 for OTM) and lines carrying business and domain logic (means 5.1 and 3.5) remain about the same, no matter if OTM is used or not. But lines of code for library initialization (non-OTM mean 4.8, = 1:8) and data access (12, = 5:4) are reduced signi cantly to 1.5 ( = 1:4) and 2.8 ( = 3:9) if OTM is used. This is plausible as using OTM no objects simply representing vocabulary (such as Jena's Property) or data access interfaces (such as Jena's StmtIterator) need to be instantiated. Additionally, using our OTM implementation the load operation can be omitted, as on calls to get and on eld access load is called automatically. However, the main bene t of these implicit calls is not reduced lines of code, but improved separation of concerns, i. e. data access is separated from domain logic.
(a) number of edit-debug cycles (b) time in hours needed to nd solution
Qualitative Feedback. Asked for the biggest problems they faced solving the non-OTM tasks, participants found it generally hard to understand the Jena API. Participants found it di cult to understand the central Jena classes Model, Resource, and Property, which is due to their lacking knowledge of RDF concepts. Also, participants had problems understanding Model.read, which loads RDF data from the URI speci ed, and Model.getResource, which only creates a Resource object to be further processed in Java. Some were unsure when a String in Jena was a literal value, and when it represented a URI. One participant commented \The source code contains weird objects, which do not have to do anything with the problem domain. This causes programming mistakes, because these objects are untyped." He mentioned the example of deciding whether RDFNode is a Literal or a Resource. Also, Jena's StmtIterator, which needs to be used in order to read triple information, was criticized for being confusing to use. All in all, participants highly valued the source code examples we provided, and said nding a solution would have taken much longer without the example. However, some would have preferred more comprehensive examples, featuring nested loops, or complete howto documents.
OTM received less comments, which is probably due to the fact that each participant was to solve two assignments{one using OTM, one without{and the OTM task was easier to solve than the non-OTM task. Still, we received valuable feedback. Participants found it hard to nd the mapped Java class representing resources of a speci c RDF type. Some participants have been observed analyzing all mapped Java classes available, others just read the example source code provided and concluded the right classes to use. However, one participant just guessed arbitrary (wrong) classes to be used in his source code and got stuck for a while. Although our OTM implementation simpli es URI dereferencing by implicitly loading RDF graphs when instantiating mapped objects, it took one participant a while to nd out how to explicitly load a whole dataset as needed for Task 1. Some participants had trouble in dealing with generic Java types used for collections of objects, and hence could not fully bene t from our OTM framework.
Both the OTM and non-OTM solutions shared some comments. Participants said a graphical representation of the RDF schema, or the mapped class model, and a graphical browser for the dataset would have helped them to understand the data structures and would have improved their implementation performance. Also, participants complained about not having understood how or where the data had actually been stored. Only very few participants had the idea of viewing the URI provided by the test framework in a Web browser window. 5
In this paper, we presented a formalism for Object Triple Mapping (OTM), a promising approach to structuring the development of Semantic Web software. Our OTM formalism harmonizes several implementions seeking to simplify Semantic Web application development and adds process elements to describe complete programs operating on linked data. Our second contribution is an experimental evaluation of OTM. We presented the results of this experiment, clearly showing that { OTM speeds up the development of Semantic Web software. { Lines of code needed to solve several tasks are reduced by half using OTM, and the share of \purely technical" lines of code is diminished so that using OTM, business logic and program structure stands out in the code. { Improved programming experience can be measured, as developers without Semantic Web programming experience nd it simpler to develop software using OTM, and are more satis ed with the quality of their results.
The experiment material, assignments, datasets etc. can be downloaded from the experiment web site6. We encourage readers to join the evaluation, and share their results with us. To obtain a broader view on what are the Semantic Web software engineers' pains, how we can help them, and which technology they actually prefer, we will extend our evaluation to more programming languages and RDF programming libraries. Besides this planned continuous evaluation, we will publish the direct and indirect feedback we receive from participants, and will incorporate that feedback into our own OTM implementation for further evaluation, and are willing to contribute to other existing OTM implementations.
As the results of our experiment are very promising, we are con dent to contribute in further spreading the word about positive experience using Semantic Web standards and technologies. Once software engineers and managers are convinced that Semantic Web technologies can be introduced in software projects without adding costs, or even reducing costs, software will start to contain more and more Semantic Web technologies, fostering interoperability and data mash-ups. By then, software engineers will be willing to learn more about these technologies and more complex software projects going beyond the features of o -the-shelf OTM implementations can nally be done.7
http://hpi-web.de/meinel/quastho . 6. Fowler, M., Rice, D.: Patterns of Enterprise Application Architecture. Addison
Wesley (2003) 7. Bizer, C., Seaborne, A.: D2rq { treating non-rdf databases as virtual rdf graphs.
In: Proc. of the 3rd International Semantic Web Conference, Springer (2004) 8. Eberhart, A.: Automatic generation of java/sql based inference engines from rdf schema and ruleml. In: Proc. of the 2nd International Semantic Web Conference, Springer (2002) 9. Saatho , C., Scheglmann, S., Schenk, S.: Winter: Mapping rdf to pojos revisited.
In: Proccedings of the ESWC 2009 Demo and Poster Session. (2009) 10. Miller, P., Styles, R., Heath, T.: Open data commons, a licence for open data. In: Proceedings of the WWW2008 Workshop on Linked Data on the Web, Springer (2008) 11. Hartig, O., Bizer, C., Freytag, J.C.: Executing sparql queries over the web of linked data. In: Proc. of the 8th International Semantic Web Conference, Springer (2009) 12. Brandt, J., Guo, P.J., Lewenstein, J., Klemmer, S.R.: Opportunistic programming: How rapid ideation and prototyping occur in practice. In: Proc. of the Fourth Workshop on End-User Software Engineering, ACM (2008) 13. Quastho , M., Sack, H., Meinel, C.: Can software developers use linked data vocabulary? In: Proc. of I-Semantics '09. (2009)