RDF Objects 1. Alex Barnell Information Infrastructure Laboratory HP Laboratories Bristol HPL November 27 th, 2002*

Transcription

1 RDF Objects 1 Aex Barne Information Infrastructure Laboratory HP Laboratories Bristo HPL November 27 th, 2002* E-mai: Andy_Seaborne@hp.hp.com RDF, semantic web, ontoogy, object-oriented datastructures The Semantic Web is growing in both size and compexity, with the number of data sources and vocabuaries both increasing. This report shows how arge RDF databases can be accessed in smaer, more manageabe chunks, known as RDF Objects. RDF Objects encapsuate compound data structures, giving appications a more granuar view of a database. Appications can contro the size and structure of RDF Objects by atering the data extraction rue and by fitering the returned data by vocabuary. Links between RDF Objects, anaogous to hypertext inks, enabe appications to connect and navigate data across different databases. OWL and DAML ontoogies are used to discover the identifying properties of resources, aowing information to be aggregated from mutipe databases without the need for constant identifiers. An HTTP impementation of an RDF Object Server has been deveoped and used to deveop toos for W3C Working Groups. * Interna Accession Date Ony Approved for Externa Pubication 1 Enquiries concerning this report shoud be directed to Andy Seaborne emai: Andy_Seaborne@hp.hp.com Copyright Hewett-Packard Company 2002

2 RDF Objects Aex Barne Semantic Web Appications Group, Hewett Packard Laboratories Bristo, Avon, Engand Abstract The Semantic Web is growing in both size and compexity, with the number of data sources and vocabuaries both increasing. This report shows how arge RDF databases can be accessed in smaer, more manageabe chunks, known as RDF Objects. RDF Objects encapsuate compound data structures, giving appications a more granuar view of a database. Appications can contro the size and structure of RDF Objects by atering the data extraction rue and by fitering the returned data by vocabuary. Links between RDF Objects, anaogous to hypertext inks, enabe appications to connect and navigate data across different databases. OWL and DAML ontoogies are used to discover the identifying properties of resources, aowing information to be aggregated from mutipe databases without the need for constant identifiers. An HTTP impementation of an RDF Object Server has been deveoped and used to deveop toos for W3C Working Groups. 1. Context and Background 1.1 RDF and the Semantic Web The Semantic Web is the part of the Internet that machines can understand. It consists of data written in machine-readabe anguages, such as RDF [1], the Resource Description Framework. To be "machine-readabe" means much more than just to be in eectronic form. To be machinereadabe, the machine must be abe to understand the document without ambiguity. This is in contrast to the Word Wide Web whose documents are written using anguages that machines do not understand, such as Engish. RDF is the main anguage of the Semantic Web, a simpe anguage that uses graphs to represent coections of statements. Nodes in the graph represent things, and arrows represent reationships between the things they connect. RDF's origina purpose was to aow metadata to be attached to web pages, but it is powerfu enough to describe more compex entities ike peope and organisations. RDF is even fexibe enough to be used as the foundation for a number of more powerfu anguages such as DAML+OIL [2] and its successor-to-be, OWL [3], the Web Ontoogy Language. 1.2 The Word Wide Web Consortium The W3C [4] is a forum for the deveopment of Internet technoogies. Initiay created to promote compatibiity amongst Web browsers, the Consortium now concentrates on more advanced technoogies such as the Semantic Web and Web Services. The Consortium is made up of a number of Working Groups, each tacking the issues invoved with a particuar technoogy. A Working Group's goa is to produce specifications that aow independent deveopers to create impementations of a technoogy that are compatibe with each other. For exampe, the RDFCore Working Group [5] works to deveop specifications for the RDF anguage. Working Groups use Internet maiing ists as their main method of communication. The ists are used for genera discussion and to report new deveopments. For exampe, RDFCore members use the RDFCore Maiing List [6] to inform the group of competed actions. Groups hod reguar teeconferences in which forma decisions are made. Actions are assigned to each member of the group in order to create progress. A Group produces specifications and other documents group its course, and once a of the outstanding issues have been resoved, those specifications can become recommendations. The W3C process is formay described in the W3C Process Document [7]. 1.3 Semantic Web Appications at Hewett Packard The Semantic Web research team [8] at HP Labs, Bristo, is activey deveoping Jena [9], a Java API for manipuating RDF. Jena provides a rich Mode interface giving a resource-centric set of operations on RDF data. Some Members of the Jena team are aso members of RDFCore, the W3C Working Group for RDF. The Sweb-Apps team at Hewett Packard was formed in Apri 2002 and has been investigating the issues invoved in deveoping a Semantic Web Appication using the Jena tookit. Specificay, they have been tasked with creating a suite of Semantic Web toos to be used by

3 W3C Working Groups to automate and assist the Working Group process. The fied of Semantic Web appication deveopment is sti in its infancy, and many questions are sti to be answered: What does it mean to be a Semantic Web Appication? What toos do deveopers need to create Semantic Web Appications? Are there any recurring patterns invoved in designing Semantic Web Appications? To what extent does Jena meet the needs of the Semantic Web appication deveoper? 1.4 Toos for Working Groups Discussion with members of the RDFCore and WebOnt Working Groups aowed the sweb-apps team to identify three areas in which Semantic Toos woud be usefu for Working Groups. Action and Issue Manager - Actions are tasks to be competed, and go through a number of phases that form the action's ifecyce. Actions are created during Working Group meetings, where they are given a description, for exampe to review a certain document, and are assigned to one or more members of the group. Actions are then active unti they are either competed or discontinued. Issues aso have a ifecyce, being created then active ti either resoved or abandoned. Issues are different to actions in that it is the responsibiity of the entire group to resove an issue, not just a particuar individua. Actions and Issues can be modeed as finite state machines, having states corresponding to their phases. Teeconference Meeting Assistant - Many Working Groups use IRC (Internet Reay Chat) in conjunction with teephone conferences to og the decisions made in the meeting. An IRC robot coud assist with this process by automaticay waking the group through the agenda items, recording the decisions made, and by automaticay producing the minutes for the meeting based on the decisions made. The agenda for the next meeting coud aso be partiay automated by incuding the recenty competed actions as agenda items. Maiing List Assistant - Working Group members use maiing ists to circuate news and views to the rest of the group. For exampe, members can send their regrets that they cannot attend the next meeting, or can inform the group that they have competed one of their actions. A maiing ist assistant coud automaticay detect these messages and take the appropriate action. FIGURE 1: An Action represented using RDF Working Groups, Peope and Actions can a be described using compound data structures in RDF. Figure 1 shows an action described using RDF. The action is represented by the highighted resource, and the rest of the graph structure gives the detais of the action: whom it is assigned to, that person's emai address, the ID of the action, and so on. It is the entire coection of statements in the graph that describe the action, not just the action resource's immediate properties. Many other entities are aso described using compound RDF data structures, for exampe VCards [10], RSS News Feeds [11], and vca Caendar information [12]. RDF Objects have been designed to encapsuate the concept of compound data structures, enabing them to be extracted from databases and treated as atomic entities. The RDF Object API provides higher-eve access to RDF than the Jena API; RDF Objects have a arger granuarity than individua statements, which simpifies the deveopment of appications that dea with compex RDF data structures.

4 2. RDF Databases Athough there is a singe specification for the RDF anguage [13], there is currenty no such standardisation for methods of accessing remote RDF databases. A number of proposas have been made by deveopers, each with different cient-server protocos and different cient APIs. Joseki [14] and Jena SQL Modes [15] are two of the proposas, both with usabe impementations. This section describes the two systems and investigates the issues invoved in database access from the point of view of the appication. 2.1 Use Cases A Semantic Web Appications can be spit into two categories: 1. Appications that access RDF from a singe database 2. Appications that access RDF from mutipe databases In the first case, a the RDF that the appication uses is from a singe graph. An exampe woud be a Persona Information Manager that uses RDF to store user bookmarks in a singe database. In the second case, appications wi often need to merge data from different databases. For exampe, an Enterprise appication might want to find the contact detais (phone, emai etc) of a Project Manager. It coud achieve this by combining information about the project from the project database with information about the manager from the empoyee database. Without the abiity to combine information from different sources, the Semantic Web is no onger a Web, but a coection of discrete data sources. It is therefore important to make using mutipe databases a simpe task for the appication, whist sti giving the appication contro over how the data is combined. 2.2 Existing RDF Database Systems Joseki Joseki [14] is an RDF database server that aows databases to be queried using the RDQL query anguage. The Joseki server is written in java using Jena, and aows the databases to be stored in SQL servers. There is a java cient API, which aso works with Jena. Cients send requests to the Joseki server using HTTP GET. RDQL queries are graph patterns with any number of variabes. The query beow finds a the actions in a database, the peope assigned to those actions, and the emai addresses of those peope. A question mark in the query indicates that the term is a variabe. SELECT?actionID,?person,?emai WHERE (?action, <rdf:type>, <action:action>), (?action, <action:id>,?actionid), (?action, <action:assignedto>?person), (?person, <rdf:type>, <person:person>), (?person, <person:emai>,?emai) The resut is a tabe of variabe bindings, with the coumns being the variabes and the rows being the resuts. For exampe, the resuts might be:?actionid?person?emai "REVIEW-DATATYPES-DOCUMENT" (bank) <maito:brian@w3.org> "ATTEND-MEETING" (bank) <maito:jeremy@w3.org> "ATTEND-MEETING" (bank) <maito:patrick@w3.org> In this particuar resut set, a the bindings of?actionid are iteras, a the bindings of?person are bank nodes, and a the bindings of?emai are named resources (URIs). Cients can make changes to the database by adding and removing sets of statements. The Joseki cient-server protoco creates bank node identifiers so that a cient can refer to an existing bank node when adding or removing a statement Jena SQL Modes The Jena tookit comes with a reationa database casses [15] that aows RDF to be stored in SQL databases and accessed through the Mode interface. This aows remote RDF to be accessed with the same API as oca RDF data, as ong as remote JDBC connections can be made. Using remote

5 SQL modes invoved three types of overhead: Initia SQL connection overhead At east one remote JDBC ca is needed for every Jena function ca On the SQL server, the database needs to be accessed for every tripe operation Other RDF Databases incude Sesame [16] and rdftp [17]. Sesame aows databases to be queried using the RQL query anguage, which has expicit support for RDFS schemas, but not DAML or OWL ontoogies. rdftp uses a reationa database to stored RDF, and aows databases to be queried using property-vaue pairs. 2.3 Issues in RDF Database Design Many rea-word entities ike Peope and Working Groups do not have URIs, and are modeed in RDF using bank nodes. Instead of being identified by a URI, they can be identified by their unambiguous properties. These properties can be determined from OWL and DAML ontoogies. An appication wanting to query a database for information about a person wi need to identify that person by their unambiguous properties, for exampe their emai address or socia security number. This is a probem in RDQL, because there might be many properties that coud be used, but if even one fais then the entire query wi fai, because RDQL does not aow partia matches. RDF Objects have been designed to aow cients to query databases without knowing exacty how resources are identified in the database. This is achieved by both the cient and server making use of DAML and OWL ontoogies behind the scenes, so whereas with Joseki and SQL Modes it was the responsibiity of the appication to identify resources, with RDF Objects, the cient ibrary and server do the identification automaticay, aowing appications to treat bank nodes ike any other resource, simpifying the deveopment process. 3. Requirements for RDF Objects 3.1 RDF Objects An RDF Object is a piece of information from a database. Different types of information from a database can be retrieved as an RDF Object. In particuar, it shoud be possibe to retrieve information about a particuar resource in the database, forming a compound data structure. This shoud be suitabe for retrieving actions, peope and working groups stored in RDF. It shoud aso be possibe to search a database and retrieve the resuts as an RDF Object. It shoud be possibe to find more information about a resource in an RDF Object, either in the same database or a different one. In the remainder of this report, the terms "RDF Object" and "Object" are used interchangeaby. 3.2 Defining and Describing RDF Objects RDF Objects shoud be defined and described using RDF. Object Definitions shoud provide enough information for an agent to retrieve the correct Object from the correct Object Server. This wi aow Object Descriptions to be embedded in Object data, aowing inks between Objects (see beow). 3.3 RDF Object Server An RDF Object Server shoud be abe to accept an RDF Object definition from a cient and return the generated RDF Object to the cient. An RDF Object Server shoud be abe to store data in SQL databases and on the oca fie system. The server shoud have a moduar design aowing additiona storage modues and extraction agorithms to be added. 3.4 Editing and Updating RDF Objects Cient Appications shoud use the Jena Mode API to manipuate data from a returned RDF Object. Cients shoud be abe to make permanent changes to an RDF Object by sending the changes it has made to the Object to the RDF Object Server. This wi aow changes to Action and Working Group Objects to be atomic operations, and eave the database in a consistent state. 3.5 Linking and Aggregating RDF Objects

6 A separate RDF Object cient API shoud provide extra functionaity for creating inks between different objects, which coud possiby be on different servers. The cient API shoud aow inks between Objects to be traversed, even when the Objects are on different servers. It shoud be possibe to aggregate data from different databases by making use of Object inks. This wi aow Working Groups, Peope and Action Objects to be spread over mutipe databases but sti be used together. 4. RDF Objects 4.1 Definition of RDF Objects An RDF Object is a chunk of RDF that is extracted from a database. More technicay, it is a subgraph of the RDF stored in the database. The extraction of the subgraph is performed by a particuar extraction agorithm. Each agorithm can have its own parameters. One parameter is common amongst many agorithms is the "focus resource". This is the resource in the database that acts as the centra point of the extracted subgraph; the agorithm wi start at this resource in the database and recurse through the graph using some path agorithm to extract the RDF Object. 4.2 Object Descriptions An RDF Object can be represented by a resource in an RDF graph. The RDF Object can have properties that describe itsef sufficienty enough for an agent to be abe to retrieve the Object. In particuar, the properties that wi need to be incuded in the description are: The RDF Object Server that provides the RDF Object The source database on that server The extraction agorithm, focus resource, and other parameters An exampe of an RDF Object Description is given in Figure 2. The patterned resource denotes the RDF Object being described. Note that this graph is not the RDF Object itsef, but a description of the Object. The Object is extracted from the urn:w3c:members database, using the BasicCut extraction agorithm, and urn:peope:tom as the focus resource. The resuting Object woud contain the information about Tom in the database. More information about the BasicCut extraction agorithm is given in section Extraction Agorithms FIGURE 2: An RDF Object Description Different RDF Objects can be extracted from a database by using different subgraph extraction

7 agorithms. Extraction agorithms are represented by RDFS casses that are subcasses of ExtractionAgorithm. Instances of these casses represent a particuar extraction, and have associated properties that are used as parameters to the agorithm. The input database and output object are incuded as parameters to a agorithms. Two specific extraction agorithms have been deveoped in order to meet the feature requirements. The first agorithm is the "Basic Cut" agorithm, which aows information about a particuar resource to be retrieved from a database. The depth and breadth of the extracted information can be varied by atering the recursion depth of the agorithm, and by fitering the subgraph by vocabuary. The second agorithm is the "RDQL Search" agorithm, which aows an entire database to be searched using the RDQL query anguage, and the resuts returned as an RDF Object Basic Cut Agorithm The Basic Cut agorithm returns information about a resource, without the cient needing to know what kind of data is stored about that resource in the database. The Basic Cut agorithm takes three arguments: 1. The focus resource 2. The recursion depth 3. A optiona ist of vocabuaries to fiter by (either an incusion or excusion ist) The focus resource can either be a URI, or a bank node with identifying properties. The RDF Object is extracted by first ocating the focus resource in the database, and then by recursing in a directions from this resource through the graph to the specified depth. In traversing arcs between resources, the direction of the arrow is unimportant; they are treated as non-directiona. This is because an arrow that points to a resource is often important information about that resource. For exampe, the statement "Scott isauthorof Waverey" is information about both the person Scott and the nove Waverey, and the statement shoud be part of both the Scott Object and the Waverey Object. If a ist of vocabuaries to incude is specified, an arc wi ony be traversed if it is a property from a vocabuary that is in the incusion ist. If a ist of vocabuaries to excude is specified, an arc wi ony be traversed if it isn't a property from a vocabuary that is in the excusion ist. The agorithm incudes any RDFS type and abe properties of resources even if they woud normay be outside of the recursion depth. This is as a convenience to cient appications, which wi in many cases need this information to make sense of the Object, and saves them from having to make an extra query to the database. The Basic Cut agorithm aso incudes the identifying properties of each bank node (if any). The cient API can make use of this information to ocate the same resource in a different database, by using the identifying properties as a query pattern in the focus resource of the new Object. Figure 3 shows a Working Group Database, and Figure 4 shows an RDF Object extracted from the database, using the Basic Cut agorithm with Tom as the focus (Tom is the patterned resource).

8 FIGURE 3: A Working Group Database RDQL Search Agorithm FIGURE 4: RDF Object focussed on Tom The RDQL Search Agorithm takes an RDQL query string as a singe parameter. The agorithm executes this query over the database, and converts the query resuts tabe into an RDF Object that contains the resut data. The Object graph is the minima compete subgraph for the query, i.e. when it is queried with the query string, the resuts wi be the same as if the query was performed against the database. The RDQL Search agorithm, ike the Basic Cut agorithm, wi incude the identifying properties of each bank node in the resut set, even if those properties where not queried for. This saves the cient from having to manuay modify queries to obtain the identifying properties, which is probematic when the cient knows itte about the structure of the data being queried, since a partia faiure in a query fais the entire query. This is the biggest difference between this impementation of RDQL querying and Joseki. The RDF Object Server uses RDQL to find the resuts, but not as the extraction rue. 4.4 Links between Objects Use Cases There are three possibe ways of inking resources from different Objects, which we ca Simpe, Identity, and Cross-Linking. Linking is the act of creating a property arc between two resources Simpe Linking Simpe Linking is the form of inking aready possibe using Jena's addproperty method of Resources. For exampe, x.addproperty(p, y) creates a ink with property p between resource x and y, where x and y coud be from different Objects. A probem occurs when resource y is a bank node. The identifying properties of y are not copied by Jena into the Object containing resource x, making it impossibe to determine what resource the bank node refers to. This is demonstrated in figure 5. A ink is created between a Working Group in Object A and a person in Object B. The person is identified in Object B using his emai address, but this information is ost in Object A when the ink is made, because Jena does not copy the identifying properties of the bank node.

9 FIGURE 5: Simpe Linking Identity Linking Identity inking is an extension to Jena's addproperty() that does copy the identifying properties of bank nodes into the other Object. An exampe is given in figure 6, using the same scenario as in figure 5 but this time using an identifying ink to copy the identifying properties of the person. Identity inking is performed using the RDFObject cient API: ink(resource x, Property p, Resource y) Cross-Linking FIGURE 6: Identity Linking Cross-Linking is short for Cross-Reference Linking. It extends Identity Linking by adding information about the origin of the inked-to resource to the object of the inked-from resource. This aows an agent who subsequenty accesses Object A to discover information about the inked-to in Object B without previousy knowing about Object B. This ony becomes possibe with Cross-Linking; in Identity Linking the origin of inked-to resource is ost. Figure 7 shows the same scenario again, but using a cross-ink. FIGURE 7: Cross-Linking A Cross-Link is anaogous to an HTML Hyperink. Cross-inks do for Semantic Web agents what hyperinks do for Web users. Because hyperinks are transitive, users can repeatedy foow inks to "surf the web". In the same way, cross-inks are aso transitive, aowing appications and agents to recursivey foow inks to find more information about resources, which can be aggregated into a new Object. Cross-inking is performed using the RDFObject cient API: crosslink(resource x, Property p, Resource y) 5. Resuts and Concusion

10 An RDF Object Server was depoyed in HP Labs, and the RDF Object cient API was used to deveop a Maiing List Assistant. Different Objects were stored in different databases: Peope were stored in a peope database, and severa Working Groups representing the teams in HP Labs were each stored in their own their own database. Cross-inks were used to connect Working Groups to their members. An emai bot was set up to monitor the maiing ists of each group. It was configured using an RDF Object, and used cross-inks to connect the Working Groups it was to monitor to the configuration object. The foowing of these inks aowed the bot to access the correct database of each working group, and to create new action objects in the correct ocation. A GUI for editing and inking RDF Objects was created to aow the bot to be re-configured to assist different Working Groups. RDF Objects aow arge RDF databases to be accessed in smaer, more manageabe chunks. Compound data structures are encapsuated by RDF Objects, giving appications a simper conceptua view of the word than if the individua statement was the atomic unit of information. An ontoogy-aware server and cient ibrary aows data to be modeed using bank nodes rather than URIs, which is more convenient for representing non-web entities ike peope and working groups. Links between Objects aow cients to discover and aggregate data from different sources. The inking API encourages appications to create inks between data sources, and in doing so it provides the gue necessary for the Semantic Web. References [1] Resource Description Framework: [2] DAML+OIL: [3] OWL: [4] W3C: [5] RDFCore Working Group: [6] RDFCore Maiing List [7] W3C Process Document: [8] HP Labs Semantic Web Research: [9] Jena: [10] VCards in RDF: [11] RSS: [12] RDF Caendar Taskforce: [13] RDF Mode and Syntax Specification: [14] Joseki: [15] Jena RDB Support: [16] Sesame: [17] rdftp: Aex Barne is the author of RDF Objects, and can be contacted at aeb99@doc.ic.ac.uk Copyright Hewett-Packard Company, 2002