Making the Semantic Data Web easily writeable

Making the Semantic Data Web easily writeable with RDFaedit Sebastian Dietzold, Norman Heino, S¨oren Auer, and Philipp Frischmuth Universit¨ at Leipzig, Institut f¨ ur Informatik, Augustusplatz 10-11, D-04109 Leipzig, Germany, {lastname}@informatik.uni-leipzig.de

Abstract. We present RDFaedit a solution for editing distributed and syndicated content in the Word Wide Web with semantic editing widgets. The system is able to extract fine-grained semantic content chunks from RDFa-enhanced websites and generate an edit form for the user, which is sensible to the type and context of the edited data. For that purpose, the underlying Semantic Web infrastructure is used to retrieve more information about the data classes and properties. In particular, we use SPARQL endpoints to gather RDF vocabulary descriptions on the fly from the web and cached schemata for the most frequently used RDF vocabularies to decide about the best-suited edit form for the respective situation.

1

Introduction

The overwhelming success of the World Wide Web was to a large extend based on the ability of ordinary users to easily author content. In order to publish content on the WWW, users had to do little more than to annotate text files with few, easy to learn HTML tags. Unfortunately, on the semantic data web the situation is slightly more complicated. Users not only have to learn a new syntax (such as N3, RDF/XML or RDFa) but have also to get acquainted with the RDF data model, ontology languages (such as RDF-S, OWL) and a growing collection of connected RDF vocabularies for different use cases, like FOAF, SKOS and SIOC. Previously, many approaches were developed to ease the syntax side of semantic authoring [13, 4]. In this paper we present an approach, which also hides the data model from ordinary users and thus allows absolute novices to create semantic representations easily. The RDFaedit approach is based on the idea of making arbitrary XHTML views with integrated RDFa annotations editable. RDFa [2] is the W3C Recommendation, which allows to encode human and machine readable representations within a single HTML document. RDFaedit builds on RDFa by preserving provenance information in RDFa representations following the named-graph paradigm and establishing a mapping from RDFa view representations to authoring widgets. On configurable events (such as the clicking of a button or moving over a certain information fragment with the mouse) the widgets will be enabled and

allow the editing of all RDFa annotated information on the Web page. While editing, the widgets can access background information sources on the Data Web in order to facilitate reuse of identifiers or encourage interlinking of resources. Our resource editing widget, for example, suggests suitable previously defined resources derived via calls to the Sindice semantic web index [?]. Once, editing is finished the changes are propagated to the underlying triple stores by means of the SPARQL/Update language. RDFaedit is not at all limited to editing semantic representations from a single source. An RDFa view made editable with RDFaedit can contain statements from a variety of sources, which can be edited simultaneously and completely transparent to the user. Based on our extended RDFa markup supporting named graphs and SPARQL/Update endpoint information, simultaneous changes of several graphs from different sources will be dispatched to the respective SPARQL/Update endpoints. RDFaedit is implemented in JavaScript so that it works completely on the browser side and can be used together with arbitrary Web application development techniques. In particular with this paper, we make the following contributions:

– We define a light-weight extension of RDFa to accommodate named graphs and an RDF vocabulary to provide metadata on these graphs, like SPARQL/Update endpoint information. – We develop the RDFaedit library, which can be used to make arbitrary RDFa representations editable. – We provide a number of widgets for authoring common data types and define a mechanism for plugging in and automatically configuring additional editing widgets. – We demonstrate the benefits of RDFaedit in two use cases: semantic authoring in OntoWiki and editing of information from multiple sources in the LinkedGeoData browser. As a result, RDFaedit rapidly simplifies the authoring of semantic information. Users can interact with semantic web applications, without having to learn a new syntax or even having to get acquainted with the RDF data model or other knowledge representation formalisms. This adds easy write support to semantic web applications, which can help them to significantly enlarge their user bases and generally to achieve a higher penetration of semantic web technologies. The paper is structured as follows: We describe the requirements which guided the development of RDFaedit in Section 2. We present our RDFa extension for representing named graphs and provenance in Section 3. We describe the architecture and implementation of our approach in Section 4. We evaluate the approach on the basis of our Semantic Wiki OntoWiki as well as the LinkedGeoData browser in Section 5. Finally, we survey some related work in Section 6 and conclude with an outlook on future work in Section 7.

2

Requirements

In this section, we gather and describe the most important requirements, which guided the development of RDFaedit. The rationale behind the development of RDFaedit was to provide a general framework to edit data chunks (triple or multiple triples) in XHTML pages by means of small authoring components called editing widgets (or in this paper just widgets). The framework, which should be usable with arbitrary Web applications, should provide edit functionality on top of RDFa-annotated web pages with only minor modifications to the existing markup, i. e. there should be no need to create special edit views. This will reduce the effort required for the development and maintenance of (Semantic) Web applications significantly. For Web applications which focus on collaboration and interaction, we can assume that probably more than 50 % of the effort regarding the user interface creation is spent on implementing and maintaining edit functionality. To allow mashing-up content from different sources the framework should preserve the provenance of all content chunks, even if combined on a single resulting XHTML page. This allows to hide even more complexity from the user, since he does not have to care where to edit certain information or to switch between different editing views. To achieve this goal we have to provide a vocabulary to connect RDFa fragments with updatable endpoints. RDFaedit should provide functionality to not only edit existing information but also for creating new data. The framework should also allow to distinguish between writeable and non-writeable information sources. This way authentication and access control is easily combinable with RDFaedit, without increasing the complexity of the implementation for Web developers. In order to make the general editing framework as flexible as possible, the goal was to provide a number of authoring widgets for specific content types, such as resource references, dates, locations, images/files etc. The Web developer/designer should not be limited in his possibilities to create Web designs. RDFaedit should be as unobtrusive as possible and provide flexible editing widgets (or allow different configurations e. g. via CSS definitions) for different usecases, such as inline editing, popup/overlay editing etc. RDFaedit should also retrieve background information (such as schema/vocabulary information with domain/range restrictions) required for the selection of appropriate widgets. Further it should facilitate the interlinking of information on the basis of the Linked Data paradigm and incorporate services for establishing links such as Sindice, DBpedia and Geonames.

3

Named Graphs and Provenance in RDFa

RDFa enables the annotation of information encoded in XHTML with RDF. This allows to extract a set of RDF triples from an RDFa annotated XHTML page. RDFaedit makes these triples editable, but in order to persistently store changes RDFaedit needs information about the information source (i. e. SPARQL, SPARQL/Update endpoint) the triples were obtained from and which named RDF

graph the triples belong to. In order to make this information available, we define a slight extension of the RDFa annotations. To represent information about the information source, we follow the named graphs approach [6]. We created a vocabulary1 to represent attributes and relations for the following purposes: – In order to link certain RDFa annotations on the page to the respective querying/update services, namely SPARQL/Update and SPARQL endpoints, we propose the use of the link HTML tag with attributes about to identify the named graph, rel with attribute value update:updateEndpoint and href with the URL of the respective SPARQL/Update endpoint. – For declaring, which statements belong to which named graph we propose the use of the attribute update:from with the named graph as attribute value, to which all nested RDFa annotations should belong to. The update:from attribute and the additional RDFa processing rules are inspired by [9]. The next listing is an example of an RDFa-enhanced XHTML snippet from the LinkedGeoData browser (which we describe as a use case for RDFaedit in more detail in section 5). All RDFa attributes as well as our update vocabulary extensions are highlighted. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

< head > [...] < link about =" http :// trunk . ontowiki . net / myComments /" rel =" update : updateEndpoint " href =" http :// trunk . ontowiki . net / sparul "/ > [...] < div typeof =" lgeo : node " about =" http :// linkedgeodata . org / triplify / node /23905418" update : from =" http :// linkedgeodata . org / data /" >

Public OSM Data

< li > Name : < span property =" lgeo : name " > Hotel Habana Libre [...]
• Lat / Long : < span property =" geo : lat " >23.1398731 / < span property =" geo : long " > -82.3824309

  Private Annotations < ul update : from =" http :// trunk . ontowiki . net / myComments /" >

  Comment : < span property =" rdfs : comment " > awesome !

  Rating : < span property =" my : rating " >9

  Last Visit : < span property =" my : lastVisited " >2009 -07 -10 1
  
  The RDFaedit vocabulary namespace is http://ns.aksw.org/update/ and we use the prefix update for this namespace throughout this paper.
  
  The link element in the head of the HTML page beginning from line 3 relates the named graph http://trunk.ontowiki.net/myComments/ to the SPARQL/Update endpoint http://trunk.ontowiki.net/SPARQL/Update, by using the object property updateEndpoint from the widget vocabulary. The div element in lines 8 to 27 describes one OpenStreetMap node represented as RDFa with vocabulary from the LinkedGeoData project. The representation is split into a public and a private named graph, containing information from different triple stores. The from attributes (in line 10 and 21) from the RDFaedit vocabulary are used to make all extracted statements of the entire underlying DOM branch part of a named graph. The XHTML listing above represents the source code of the example screenshot from the LinkedGeoData editor in Figure 5. The XHTML page is parsed by the RDFaedit RDFa+named-graph parser into the triples (represented in N3 notation) shown in the following listing2 : 1
  
  my : update : updateEndpoint < http :// trunk . ontowiki . net / sparul >.
  
  2 3 4 5 6 7 8
  
  < http :// linkedgeodata . org / data / > = { < http :// linkedgeodata . org / triplify / node /23905418 > a : node ; : name " Hotel Habana Libre "; wgs : lat "23.1398731"; wgs : long " -82.3824309" . }.
  
  9 10 11 12 13 14 15
  
  my : = { < http :// linkedgeodata . org / triplify / node /23905418 > my : lastVisited "2009 -07 -10"; my : rating "9"; rdfs : comment " awesome !". }.
  
  The extracted model consists of two named graphs and an additional statement in the default graph. For one of these named graphs, update information is available. The RDFaedit widget library treats all statements from named graphs without update information as read only statements.
  
  4
  
  System Architecture and Implementation
  
  In this section we describe the implementation of RDFaedit. An architectural overview of the approach is depicted in Figure 1. The components involved are: – An XHTML page annotated with RDFa and a named-graph extension as described in the previous section, – for each named graph that is intended to be writable: a SPARQL/Update endpoint to which updates are sent and an optional SPARQL endpoint to gather additional information (see below), 2
  
  Due to limited space we omit the first lines with prefix definitions for rdfs, wgs, update and my.
  
  – the RDFauthor API with a set of editing components (called widgets) and included libraries. Conventional edit forms are usually processed on the server. Thus, unsuitable decisions (e. g. the wrong input form presented due to an earlier input error) cannot be revised. In our approach, all editing logic resides in the client. This way, inappropriate widget decisions can be revised or completely changed on the user’s request. Since we do not assume a one-by-one relation between widgets and statements, a widget can be responsible for more than one statement3 .
  
  Web Server
  
  SPARQL/Update, (SPARQL) Endpoint
  
  ...
  
  SPARQL/Update, (SPARQL) Endpoint
  
  for each Named Graph Web Server
  
  generates
  
  Web Browser JavaScript API
  
  RDFa-annotated XHTML Page
  
  w1
  
  w2
  
  w3
  
  ...
  
  wn
  
  Widgets
  
  User's View
  
  Fig. 1. RDFedit architecture overview.
  
  In-page triple storage (page graphs) and RDFa parsing are included from external projects. The RDFauthor API thus has three components: – RDFauthor JavaScript objects, – an in-page RDF store based on the rdfQuery jQuery plug-in, developed by Jeni Tennison4 , – an RDFa parser component obtained from the W3C RDFa Javascript implementation page5 (slightly extended to parse named graph attributes as well). 3
  
  4 5
  
  This is important for widgets like a graphical map selector widget, where the user changes both latitude and longitude at once. http://code.google.com/p/rdfquery/ http://www.w3.org/2006/07/SWD/RDFa/impl/js/
  
  Our own contribution to this stack, namely the RDFautor JavaScript objects are a collection of scripts that allow the creation of an edit view and included widgets. It can be either included into the existing page or displayed as an overlay. The overlay approach provides sleek editing capabilities for even the most complex XHTML+RDFa markup while the inline option can be used to seamlessly integrate authoring functionalities into existing pages. 4.1
  
  Page Processing Procedure
  
  Page processing is controlled by the RDFauthor front object which starts the parsing process and adds each triple found to the internal rdfQuery stores. Simultaneously, trigger events can be added to the respective DOM element, allowing for element-based edit triggers. In addition to starting the edit process on a single element, all statements can be edited at once via page-wide triggers.
  
  1.�User�loads�RDFa�page 6.�Propagate�updates to�linked�services
  
  2.�Parse�statements into�graph(s) 5.�Wait�for�user input�and�submission
  
  3.�Select�corresponding widgets�for�triples 4.�Run�widgets�on different�events
  
  ?
  
  Fig. 2. Default page processing
  
  The following list summarizes the supported edit triggers: – Clicking on a stylus button next to an element containing the object of a statement, – moving the pointer and hover over an object element, – a custom application-specified trigger like the edit toolbar in OntoWiki (see Section 5), – a bookmarklet which loads all RDFaedit components and runs all widgets at once, – the universal edit button6 . After the user has triggered one of these events, editing functionality can be added to the page in one of the following ways: – A single-statement overlay, 6
  
  http://universaleditbutton.org
  
  – a single-statement widget injected into the page or – a bulk overlay containing widgets for all editable statements. Figure 2 depicts the default page processing procedure. Initially, the user loads an RDFa-annotated web page into her browser (1). She then triggers the parsing process by one of the possible edit triggers the developer of the page has decided to make available on his page (2). RDFa parsing and widget selection happens lazily on the first of those events. For each statement on the page the corresponding widget is selected by an algorithm described in more detail in Section 4.3 (3). An edit view is presented to the user in one of the ways described above. In which way is controllable by the author of the page (4). The user completes her editing tasks and submits her changes or cancels the whole process (5). In case of submission, the changes are propagated back to the services linked to each graph (6). In Section 4.4 we describe this process in more detail. 4.2
  
  Statement Adding Methods
  
  New content can be added by either using existing content as a template or adding entirely new statements. On the basis of existing content there are three options: – Creating a new statement that shares subject and property with an existing statement. Our approach supports this case via a small button besides each statement. – Creating a new statement that shares the subject with an existing statement. At the end of a subject description a small button is shown that lets the user add a new statement to the subject’s description. – Creating a new resource using an existing resource as a template. Widgets for all properties found on the template resource are available on the new resource. If no template data is available, a suitable widget is selected by the process described in the next Section. 4.3
  
  Widget Selection
  
  Widgets for editing existing statements are selected by incorporating the object’s datatype and the property from the encoded RDFa model. If no datatype is present (plain literal or object property), a deployed selection cache of precalculated decisions is used. For this cache, we analyzed 19 of the most frequently used namespaces listed by the Ping the Semantic Web service7 . Together, these vocabularies describe 124 datatype properties and 176 object properties. For these 300 properties, we populated the widget selection cache with information on type and datatype 7
  
  http://www.pingthesemanticweb.com/
  
  of the properties used. This cache is made available as a JSON file. Most of the datatype properties requested a standard literal widget. Only 17 datatype properties had an integer domain (float 8, date/time 4, boolean 2). If the named, graph from which the statement originates, is linked to a SPARQL endpoint and neither the RDFa model nor our cache can provide useful hints as to which widget to use, RDFaedit tries to retrieve this information from the SPARQL endpoint by querying for rdf:type and rdfs:domain of the property. Once, the widget selection is finished, an editing process can be started. Figure 3 and Figure 4 show different types of widgets, e.g. for literal typed with xsd:date datatype and plain literals with language tags (Figure 3) and for object properties (Figure 4). 4.4
  
  Update Propagation
  
  When the user finishes the editing process, all widgets involved are asked to update the page graph with their changes. The difference between the original and modified page graphs are calculated (i.e. added statements, removed statements), yielding a diff graph. The associated store to each graph is then updated with the respective diff graph by means of SPARQL/Update [11] INSERT DATA and DELETE DATA operations. By explicitly listing all inserted or deleted triples sophisticated SPARQL/Update support is not required. Additionally, RDFaedit can cope with several access control scenarios. RDFaedit evaluates the server response to SPARQL/Update requests and can react to 401/403 HTTP status codes (Unauthorized/Forbidden) by displaying a login form. In a case of a server error (e. g. the triple store do not allow to change specific attributes), RDFaedit processes these status codes (405, 5xx) as well and informs the user.
  
  5
  
  Use Cases and Evaluation
  
  In order to demonstrate the benefits of RDFaedit, we integrated the approach into two semantic web applications. Firstly, RDFaedit became the original semantic authoring component in our Semantic Wiki OntoWiki. Secondly, we integrated RDFaedit as a stand-alone component into the faceted linked geo-data browser and editor, where it allows to edit information from multiple sources. 5.1
  
  OntoWiki
  
  OntoWiki [4]8 is a tool for browsing and collaboratively editing RDF knowledge bases. Different from other Semantic Wikis, OntoWiki uses RDF as its natural data model instead of Wiki texts. Information in OntoWiki is always represented according to the RDF statement paradigm and can be browsed and edited by means of views, which are generated automatically by employing the ontology 8
  
  Online at: http://ontowiki.net
  
  features, such as class hierarchies or domain and range restrictions. OntoWiki adheres to the Wiki principles by striving to make editing of information as simple as possible and maintaining a comprehensive revision history. It was recently extended to incorporate a number of Linked Data features, such as exposing all information stored in OntoWiki as Linked Data as well as retrieving background information from the Linked Data Web. Besides providing a comprehensive user interface, OntoWiki also contains a number of components for the rapid development of Semantic Web applications, such as the RDF API Erfurt, methods for authentication, access control, caching and various visualization components.
  
  Fig. 3. OntoWiki widget overlay for different properties
  
  RDFaedit is used in OntoWiki both in the generic resource property view as well as in extensions which render resources in a domain-specific way (e. g. specific visualisations for SKOS concepts or FOAF persons). To integrate RDFaedit in OntoWiki, we had to extend it in two ways: 1. We extended the default properties view for resources and every other view with RDFa attributes to annotate which data is presented as well as to link the graph to the internal update service. Since OntoWiki is entirely based on an RDF store, this extension was easy to deploy. Also, all extension developers had to extend their views e.g. for SKOS concepts. 2. We included RDFaedit by linking it in the head of every OntoWiki page and adding JavaScript edit buttons on every page where data should be editable.
  
  The integration of RDFaedit into OntoWiki is displayed in Figure 3. For all information displayed at the user interface OntoWiki generates RDFa views, which can be edited using RDFaedit with a simple click on an edit button. In order to reuse previously defined resources as much as possible we included a resource selector, which searches in the background for existing resources matching the search string typed by the user (see Figure 4).
  
  Fig. 4. Create a new statement with an existing object property.
  
  Adding new properties to an existing resource is done in two steps. First, the user chooses a property which he wants to use. He types a name or description fragment into the search input field of the property widget and RDFaedit searches for properties in the referenced SPARQL endpoint of the given named graph. After that, the corresponding widget is selected from the library as described in Section 4.3. As a result of the RDFaedit integration, OntoWiki now is able to handle not only different visualisations for specific content. OntoWiki can use these views as a base for independent editing widgets, thereby achieving a new level of content versatility. 5.2
  
  LinkedGeoData
  
  In order to showcase the simultaneous authoring of information from multiple sources, we integrated RDFaedit into the facet-based browser and editor for the linked geo data (cf. [3, 1])9 . It allows to browse the world by using a slippy map (see Figure 5). Once a region is selected, the browser analyzes the descriptions of nodes and ways derived from the OpenStreetMap data in that region and generates facets for filtering. Once a facet or a specific facet value has been selected, matching elements are displayed as markers on the map and in a list. If the selected region is changed, these are updated accordingly. 9
  
  Available online at: http://linkedgeodata.org/browser.rdfa
  
  If a user logs into the application by using her OSM credentials, the displayed elements can directly be edited in the map view. For this, the browser generates a dynamic RDFa view based on existing properties and employs RDFaedit to make this view editable. The form also allows to add arbitrary additional properties. In oder to encourage reuse of both properties and property values, the editor performs a type-ahead search for existing properties and property values and ranks them according to the usage frequency. When changes are made, these are propagated by RDFaedit to the main OSM database by using a SPARQL/Update wrapper around the OSM API.
  
  Fig. 5. RDFa enhanced OpenStreetMap Browser/Editor with additional personalized annotation section.
  
  In addition to authoring information in OpenStreetMap, the linked geo-data editor allows to annotate arbitrary information with personalised information such as comments and ratings. Since the OpenStreetMap only focuses on factual and mostly non-personalised information, we added a second information store to deal with this kind of artefacts. We employed a distinct OntoWiki instance and created a simple storage schema to accommodate the personalised information. Since OntoWiki is both a SPARQL and a SPARQL/Update endpoint by default, we only had to generate a respective RDFa annotated information section into the geo-data editor which represents the named graph as well as to link this named graph to the OntoWiki update endpoint.
  
  6
  
  Related Work
  
  The problem of making semantic web content easier writable was recognized by a number of authors. Pushback [8], for example, tackles this problem by providing a vocabulary and methodology for bi-directionally mapping Web 2.0
  
  datasources and APIs to RDF. Already earlier we presented in [7] a JavaScript API that allows the independent creation of editing widgets for embedded RDFa. In [12] a document style editing model over RDF data is presented, which as RDFaedit is based on commonly available HTML manipulation tools and rdfQuery, a javascript RDFa library, to maintain an RDF model embedded in the page. Also, Tabulator [5] allows modification and addition of information naturally within the browsing interface, and to relay changes to the server. However, due to Tabulator’s nature of being a generic data browser little effort is done to cater users unfamiliar with the RDF data model. Loomp [10] aims at providing a user interface for both creating textual content as well as annotating this content using semantic representations.
  
  7
  
  Conclusion and Future Work
  
  We presented RDFaedit, a simple and light-weight approach to make arbitrary RDFa views editable. RDFaedit does not only simplify the syntactic editing of semantic representations but it also allows to completely hide the RDF and related Ontology data models from novice users. Thus RDFaedit contributes to enabling more users to successfully use and interact with Semantic Web applications. Since RDFaedit converts an RDFa annotated view directly into an editable form, the costs for the development and maintenance of (Semantic) Web applications can be significantly lowered. Regarding future work we aim at integrating RDFaedit into more (Semantic) Web applications and establishing a repository of forms and widgets for common vocabularies and datatypes. Based on such a comprehensive repository of common vocabulary renderings, RDFaedit could evolve into a participatory semantic mashup technology.
  
  References 1. Ben Adida, Mark Birbeck, Shane McCarron, and Steven Pemberton. RDFa in XHTML: Syntax and Processing. Recommendation, World Wide Web Consortium (W3C), October 2008. http://www.w3.org/TR/rdfa-syntax/. 2. S¨ oren Auer, Sebastian Dietzold, Jens Lehmann, Sebastian Hellmann, and David Aumueller. Triplify Lightweight Linked Data Publication from Relational Databases. In Proceedings of the 17th International Conference on World Wide Web, WWW 2009, Madrid, Spain, April 20-24, 2009, pages 621–630, 2009. 3. S¨ oren Auer, Sebastian Dietzold, and Thomas Riechert. OntoWiki - A Tool for Social, Semantic Collaboration. In Isabel F. Cruz, Stefan Decker, Dean Allemang, Chris Preist, Daniel Schwabe, Peter Mika, Michael Uschold, and Lora Aroyo, editors, The Semantic Web - ISWC 2006, 5th International Semantic Web Conference, ISWC 2006, Athens, GA, USA, November 5-9, 2006, Proceedings, volume 4273 of Lecture Notes in Computer Science, pages 736–749. Springer, 2006. 4. S¨ oren Auer, Jens Lehmann, and Sebastian Hellmann. LinkedGeoData - Adding a Spatial Dimension to the Web of Data. Submitted to International Semantic Web Conference 2009, 06 2009.
  
  5. T Berners-Lee, J. Hollenbach, K. Lu, J. Presbrey, E. Pru d’ommeaux, and m.c. schraefel. Tabulator Redux: Writing Into the Semantic Web. Technical Report ECSIAMeprint14773, Electronics and Computer Science, University of Southampton, 2007. Last Modified: 13 Apr 2008. 6. Jeremy J. Carroll, Christian Bizer, Pat Hayes, and Patrick Stickler. Named graphs, provenance and trust. In WWW ’05: Proceedings of the 14th international conference on World Wide Web, pages 613–622, New York, NY, USA, 2005. ACM. 7. Sebastian Dietzold, Sebastian Hellmann, and Martin Peklo. Using JavaScript RDFa Widgets for Model/View Separation inside Read/Write Websites. In Proceedings of the 4th Workshop on Scripting for the Semantic Web, 2008. 8. Michael Hausenblas et.al. pushback - Write Data Back From RDF to Non-RDF Sources. ESW wiki, 2009. http://esw.w3.org/topic/ PushBackDataToLegacySources. 9. Toby Inkster and Kjetil Kjernsmo. Named Graphs in RDFa (RDFa Quads), January 2009. http://buzzword.org.uk/2009/rdfa4/spec. 10. Markus Luczak-Roesch and Ralf Heese. Linked Data Autoring for non-Experts. In Workshop on Linked Data on the Web, 2009, Madrid, 2009. 11. Andy Seaborne and Geetha Manjunath. SPARQL/Update: A language for updating RDF graphs. Technical Report Version 5 : 2008-04-29, Hewlett-Packard, 2008. http://jena.hpl.hp.com/~afs/SPARQL-Update.html. 12. Rob Styles, Nadeem Shabir, and Jeni Tennison. A Pattern for Domain Specic Editing Interfaces Using Embedded RDFa and HTML Manipulation Tools. In Proceedings of the 5th Workshop on Scripting for the Semantic Web, 2009. 13. Tania Tudorache, Natalya Fridman Noy, Samson Tu, and Mark A. Musen. Supporting Collaborative Ontology Development in Prot´eg´e. In Amit P. Sheth, Steffen Staab, Mike Dean, Massimo Paolucci, Diana Maynard, Timothy W. Finin, and Krishnaprasad Thirunarayan, editors, International Semantic Web Conference, volume 5318 of Lecture Notes in Computer Science, pages 17–32. Springer, 2008. 14. Giovanni Tummarello, Renaud Delbru, and Eyal Oren. Sindice.com: Weaving the Open Linked Data. In Karl Aberer, Key-Sun Choi, Natasha Fridman Noy, Dean Allemang, Kyung-Il Lee, Lyndon J. B. Nixon, Jennifer Golbeck, Peter Mika, Diana Maynard, Riichiro Mizoguchi, Guus Schreiber, and Philippe Cudr´e-Mauroux, editors, The Semantic Web, 6th International Semantic Web Conference, 2nd Asian Semantic Web Conference, ISWC 2007 + ASWC 2007, Busan, Korea, November 11-15, 2007, volume 4825 of Lecture Notes in Computer Science, pages 552–565. Springer, 2007.