Triple Fetching

The basic editing functions described earlier only utilized JavaScript code, i.e. only processed data on the users’ computers. Features connected to Sindice also use server-side computing via Django. This procedure includes two major steps: a) Getting URIs of RDF graphs that matchrdfedit’s users needs, discussed in this section, and b) extracting and mapping triples from those graphs into the one the users work on inside theirrdfedit browser interface, described in the next section (4.3.13).

Making use of Sindice’s search engine capabilities, rdfedit should execute semi-preconfigured queries to obtain graphs containing relevant data for the user. Admin-istrators of rdfeditcan create query-presets on certain types of data that should be

re-4.3 rdfedit Editing Interface

{

" P e r s o n " : {

" fq = d o m a i n " : " d b p e d i a " ,

" fq = c l a s s " : " foaf : p e r s o n "} ,

" L o c a t i o n " : {

" fq = d o m a i n " : " g e o n a m e s " ,

" fq = f o r m a t " : " RDF "}

}

Listing 4.6: Triple Fetching configuration for thePersonandLocationpreset

trieved. These query-presets include parameters offered by Sindice’s API. All the user has to do is to choose among the existing presets (e.g. Person, Location, Piece of Art) and enter query keywords that describe their needs.

Listing 4.6 shows query-presets for the type Personand Location. The first configura-tion, labelled Person, tellsrdfeditto construct a query-URL, so that Sindice should only look up RDF graphs originating from the DBpedia that contain the class foaf:person.

When looking up aLocation, data from geonames.org should be retrieved. Since geon-ames is likely to return tabular HTML data, the configuration specifies to obtain RDF data, so triples can be extracted directly from the graphs.

The process of fetching triples via Sindice requires the interplay of Django and JavaScript at multiple instances and can be roughly summarized as followed (also cf.

Figure A.10, p. 99):

Django. When generating the HTML page, the triple fetcher configuration file is being accessed to read the labels of the presets (here: Personand Location) and insert those strings in the dropdown-list-button where users can choose a query-preset (see Figure A.11, p. 100, marked blue).

JS/DataTables. The last row on the rdfedit user interface (cf. Figure A.3, p. 96, marked green) is used to invoke the triple fetching mechanism (cf. Figure A.11, p. 100, marked red). On the left side, users can enter query keywords, in the middle they can choose among given presets and the buttons on the right side are there to execute the query mechanism and to choose among the list of result URIs.

4.3 rdfedit Editing Interface

Pressing theFetch Graphs-button invokes the browser to submit the entered query keywords and chosen query preset to Django using an AJAX callback function. Asyn-chronous JavaScript and XML (AJAX) is designed to allow the dynamic and asyn-chronous exchange of small chunks of data between clients, e.g. a web browser on a personal computer and web applications, i.e. servers, and add content dynamically to a web page without having to reload that website. The data sent to the server is processed in some way and induces the server to sent some kind of result data to the client.

For example, users click on a thumbnail image of a product in an online-shop. By doing so, the browser-client requests more information about that product (e.g. man-ufacturer, available colors and size dimensions) from the server, which looks up that information in an internal database and returns that data in a form, the client can work with. The browser receives that data and injects it into the web page, in order to be viewed by the user.

Django. Django receives those parameters (keywords and preset) and constructs a query URL implementing the following procedure⁵⁶:

(a) Take the base URL of the Sindice API⁵⁷. (b) Appendq=<keywords>&to the API-URL.

(c) Look up the configuration for the chosen preset.

(d) For each key (parameter) in that preset, append<parameter>=

valueOf(<parameter>)&to the API-URL.

(e) Appendformat=JSON to the API-URL to ensure the return data from Sindice is a JSON document.

(f) The following query example is an URL to request relevant RDF graphs about Herman Melville coming from the DBpedia having the class foaf:person. The data should be returned as JSON:

http://api.sindice.com/v3/search?q=Herman+Melville&fq=domain:dbpedia&

fq=class:foaf:person&format=json

56The full source code of that procedure can be found in Listing B.10 (p. 112)

57http://api.sindice.com/v3/search?

4.3 rdfedit Editing Interface

When the query construction is done, a query to Sindice is sent by Django. Sindice returns a JSON document containing metadata about graphs that match the query (cf.

Listing B.11, p. 113 for an example), including the URIs to access those RDF graphs.

The matches listed in the result document are sorted by their respective ranks assigned by Sindice.

Note that Sindice does not return the RDF graphs themselves, for their state in Sindice’s index might not always be congruent to their actual representation in their respective original data bases.

Django extracts the URIs of the matching graphs and transfers them to the user using AJAX again.

JS/DataTables. The result URIs are injected into theChoose Graphbutton as a drop-down list. When users click on that button after they have invoked a query, they can choose an URI among the results by clicking on that button (cf. Figure A.12, p. 100). If they have made their choice and clicked on the URI that seems to fit their needs best, rdfedit starts to extract triples from the graph behind that URI and map them into the local graph appropriately.