Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Semantic Web Servers


Published on

  • Be the first to comment

Semantic Web Servers

  1. 1. Semantic Web Servers Engineering the Semantic Web Graham Moore Ontopia [email_address]
  2. 2. Overview <ul><li>A vision of the Semantic Web </li></ul><ul><li>The State We’re In </li></ul><ul><li>The Generic Missing Piece – Semantic Web Protocol </li></ul><ul><li>Use cases for distributed processing </li></ul><ul><li>Aspects of semantic web servers </li></ul><ul><li>An evaluation of existing/proposed protocols </li></ul><ul><li>Semantic web protocols: </li></ul><ul><ul><li>RDF Net API </li></ul></ul><ul><ul><li>Topic Maps and Fragment Processing </li></ul></ul><ul><li>Conclusions, Issues and Further work </li></ul>
  3. 3. A Vision of the Semantic Web <ul><li>The web as is ”is a place where machines serve up information for consumption by humans” </li></ul><ul><ul><li>Web servers, serving Web pages using HTTP </li></ul></ul><ul><li>The web as it could be ”where information, knowledge and data served by machines is processable and ’understandable’ by machines” </li></ul><ul><ul><li>Agents booking my dentist appointment based on my diary </li></ul></ul><ul><li>The web as it could be ”the ability to use simple metadata and complex classification data to organise and locate web resources” </li></ul><ul><ul><li>Agents querying about required information and following knowledge trails to track down information that I want. </li></ul></ul>
  4. 4. A Vision of the Semantic Web <ul><li>SW Data </li></ul><ul><li>SW Data </li></ul><ul><li>Agents </li></ul><ul><li>Semantic Web </li></ul><ul><li>My Agents </li></ul><ul><li>My Published Diary </li></ul><ul><li>My Dentist’s Schedule </li></ul>
  5. 5. The Reality of the Semantic Web <ul><li>SW Data </li></ul><ul><li>SW Data </li></ul><ul><li>Agents </li></ul><ul><li>Semantic Web Unplugged </li></ul><ul><li>My Agents </li></ul><ul><li>My Published Diary </li></ul><ul><li>My Dentist’s Schedule </li></ul>
  6. 6. The State We’re In <ul><li>We currently have </li></ul><ul><ul><li>Standards that can support SW activities </li></ul></ul><ul><ul><ul><li>Representation </li></ul></ul></ul><ul><ul><ul><ul><li>RDF, Topic Maps </li></ul></ul></ul></ul><ul><ul><ul><li>Constraints </li></ul></ul></ul><ul><ul><ul><ul><li>RDF Schema, OWL </li></ul></ul></ul></ul><ul><ul><ul><ul><li>And coming soon… TMCL, </li></ul></ul></ul></ul><ul><ul><ul><li>Query Languages </li></ul></ul></ul><ul><ul><ul><ul><li>Again any moment now… TMQL, RDF QL </li></ul></ul></ul></ul><ul><ul><li>Tools to make it happen </li></ul></ul><ul><ul><ul><li>There are now a number of RDF and Topic Map tools that can be used for the management and deployment of topic maps solutions. </li></ul></ul></ul><ul><li>Sounds Great! – So what is the problem… </li></ul>
  7. 7. The State We’re In <ul><li>The tools and standards we have right now are great for stand alone single server knowledge push solutions. </li></ul><ul><ul><li>e.g. Ontopia is developing an educational tool that allows teachers and students to collaboratively develop topic maps that describe a subject area. </li></ul></ul><ul><ul><li>The architecture is an OKS server accessed by users via a web application </li></ul></ul><ul><ul><li>the wire: only HTTP and HTML, despite SW tech on server </li></ul></ul><ul><li>This is a very common architecture for projects using the Topic Map or RDF paradigm. </li></ul><ul><li>This is just one architecture that is required in order to fulfil the vision of the semantic web. </li></ul><ul><li>What we are missing is the </li></ul><ul><ul><li>‘ Standardisation of operations that can be invoked in a distributed environment’ </li></ul></ul>
  8. 8. Semantic Web Layer Cake Where is the Protocol?
  9. 9. Semantic Web Protocol <ul><li>Communication protocols for the semantic web have been ignored. For the Semantic Web to really work, to gain adoption this needs to be rectified. </li></ul>
  10. 10. Semantic Web Protocol <ul><li>For semantic web clients to be able to talk with servers of RDF and Topic Maps, or for semantic web peers to communicate we need standardized protocols. </li></ul><ul><li>Currently the only mechanisms we have for semantic web communication is either: </li></ul><ul><ul><li>Using existing HTTP protocols to access and put RDF and Topic Map XML documents onto web servers </li></ul></ul><ul><ul><li>Proprietary protocols </li></ul></ul><ul><li>HTTP protocols are not SW aware and thus the power of the data (rdf / topic maps) cannot be exposed or exploited! </li></ul><ul><li>Proprietary protocols – well, this is not really the way we want the web to develop </li></ul>
  11. 11. Semantic Web Protocol Use Cases <ul><li>Why do we need a SW Protocol? </li></ul><ul><ul><li>Web Clients that wish to pose a SW query about a resource they are displaying to the user. </li></ul></ul><ul><ul><ul><li>Internet explorer has a SW window that shows SW data about a resource </li></ul></ul></ul><ul><ul><li>Client applications that are creating SW data that they want to aggregate on a server to share it with other client applications. </li></ul></ul><ul><ul><ul><li>My calendar client application creates SW data and wishes to publish it from a single central server </li></ul></ul></ul><ul><ul><li>Business applications that are producing SW data based on SW data exposed by other business applications </li></ul></ul><ul><ul><ul><li>A stock control system queries a transaction processing system and then publishes sw data for review by the store manager </li></ul></ul></ul><ul><ul><li>Data integration from multiple distributed data applications </li></ul></ul><ul><ul><ul><li>A web application wishes to expose data from a number of sources. It needs to query several SW applications and then expose this aggregated data as dynamic web pages </li></ul></ul></ul>
  12. 12. Aspects of a SW Server <ul><li>Defn: Semantic Web Server </li></ul><ul><ul><li>‘ A piece of software that implements semantic web protocols in order to service clients that may want to query and update semantic web data’ </li></ul></ul><ul><li>Criteria: </li></ul><ul><ul><li>Update capability </li></ul></ul><ul><ul><li>Query capability </li></ul></ul><ul><ul><li>Ease of deployment </li></ul></ul><ul><ul><li>Transaction Support </li></ul></ul><ul><ul><li>Ease of implementation </li></ul></ul><ul><ul><li>Server Introspection </li></ul></ul><ul><ul><li>Identity resolution </li></ul></ul><ul><ul><li>Security and Auditing </li></ul></ul><ul><ul><li>Implementation footprint </li></ul></ul>
  13. 13. An evaluation of existing/proposed protocols <ul><li>HTTP </li></ul><ul><li>URIQA </li></ul>
  14. 14. HTTP <ul><li>We don’t want RDF exposed as RDF XML files </li></ul><ul><li>We don’t want Topic Maps exposed as XTM files </li></ul><ul><li>Note: this doesn’t mean in either case that we don’t want to receive some data in these formats we just don’t want to operate in terms of these formats. </li></ul><ul><li>No way to query, </li></ul><ul><li>No way to perform updates unless working at the file level </li></ul><ul><li>No introspection (as to the semantic behaviours) </li></ul><ul><li>No TXN Support, Identity Resolution </li></ul><ul><li>Don’t want to mandate a single implementation strategy. </li></ul>
  15. 15. HTTP (2) <ul><li>This is part of the reason why the semantic web has yet to gain traction! </li></ul><ul><li>Clients don’t know how to access semantic web data in a standard way </li></ul>
  16. 16. URIQA <ul><li>URI Query Agent, Patrick Stickler (Nokia) </li></ul><ul><li>HTTP extension that given a URI it will return a concise bounded description. </li></ul><ul><ul><li>All statements where the subject of the statement is the URI in question. </li></ul></ul><ul><ul><li>Iteratively, for all statements included in description thus far, for all anonymous node objects, all statements where the subject of the statement is that anonymous node. </li></ul></ul><ul><ul><li>Iteratively, for all statements included in description thus far, all statements relating to their reification. </li></ul></ul><ul><li>Easy to deploy, implement </li></ul><ul><li>Basic query support, </li></ul><ul><ul><li>Not very expressive. </li></ul></ul><ul><ul><li>Good enough to do something very useful </li></ul></ul><ul><li>No update support </li></ul><ul><li>Small footprint </li></ul><ul><li>No introspection </li></ul><ul><li>Not a general mechanism for interacting with RDF Models. </li></ul>
  17. 17. Next generation SWS protocols <ul><li>While the above protocols provide some of the features that are desirable in a SWS protocol they are far from adequate to truly enable the semantic web. </li></ul><ul><li>Next we present two related protocols that attempt to fulfil the key SWS requirements. </li></ul><ul><ul><li>RDF Net API </li></ul></ul><ul><ul><li>Topic Map Fragment Processing </li></ul></ul>
  18. 18. RDF Net API <ul><li>Background: </li></ul><ul><ul><li>Developed by Andy Seaborne (HP) and Graham Moore after separate but related works </li></ul></ul><ul><ul><ul><li>Joseki </li></ul></ul></ul><ul><ul><ul><li>Empolis k42 Semantic Web Server </li></ul></ul></ul><ul><ul><li>First drafted at the 1 st Semantic Web Conference in Sardinia </li></ul></ul><ul><ul><li>Since revised and recently submitted to W3C. </li></ul></ul><ul><li>Goal: To define a protocol that would enable the semantic web by providing a remote protocol for querying and updating RDF Models. </li></ul>
  19. 19. SWS Architecture Overview RDF Model Impl (Jena) Client Application RDF Net API Processing Layer Client Application <ul><li>Messages (up) , SW Data (down) </li></ul>
  20. 20. SWS Architecture Overview (2) Business Application RDF Layer Client Application RDF Net API Processing Layer Client Application <ul><li>Messages (up) , SW Data (down) </li></ul>Business Application
  21. 21. Definition of an abstract protocol <ul><li>We did not want an XML based language </li></ul><ul><li>We did not want to do the syntax first </li></ul><ul><li>We defined an abstract protocol </li></ul><ul><ul><li>This allows many different implementations to be written </li></ul></ul><ul><ul><li>This allows different transport/message protocols to be used </li></ul></ul><ul><ul><li>This should allow us to define the semantics of the operations in a robust fashion </li></ul></ul><ul><ul><li>It seemed like the sensible thing to do. </li></ul></ul>
  22. 22. RDF Net API - Overview <ul><li>Query </li></ul><ul><li>GetStatements </li></ul><ul><li>InsertStatements </li></ul><ul><li>RemoveStatements </li></ul><ul><li>Put Statements </li></ul><ul><li>Update Statements </li></ul><ul><li>Options </li></ul>
  23. 23. RDF Net API – Query RDF Net API Processing Layer Client Op-Prototype: query(ModelReference, Query, QueryLang, ResultsFormat) => StatementSet ModelReference: Reference to the target model for this operation Query: The query to be executed QueryLanguage: Indication of the query language ResultsFormat: Indication of the format of the results to be returned as a set of statements StatementSet: Set of statements returned
  24. 24. RDF Net API – GetStatements RDF Net API Processing Layer Client Op-Prototype: getStatements(ModelReference, Subject, Predicate, Object) => StatementSet ModelReference: Reference to the target model for this operation Subject: URI or * (wildcard) Predicate: URI or * Object: URI,literal or * StatementSet: Set of statements returned
  25. 25. RDF Net API – InsertStatements RDF Net API Processing Layer Client Op-Prototype: insertStatements(ModelReference, StatementSet) ModelReference: Reference to the target model for this operation StatementSet: Set of RDF statements for the operation
  26. 26. RDF Net API – RemoveStatements RDF Net API Processing Layer Client Op-Prototype: removeStatements(ModelReference, StatementSet) ModelReference: Reference to the target model for this operation StatementSet: Set of RDF statements for the operation
  27. 27. RDF Net API – PutStatements RDF Net API Processing Layer Client Op-prototype: putStatements(ModelReference, StatementSet) ModelReference: Reference to the target model for this operation StatementSet: Set of RDF statements for the operation
  28. 28. RDF Net API - UpdateStatements RDF Net API Processing Layer Client Op-prototype: updateStatements(ModelReference, RemoveSet , InsertSet) ModelReference: Reference to the target model for this operation RemoveSet: Set of RDF statements to be removed InsertSet: Set of RDF statements to be inserted
  29. 29. RDF Net API - Options RDF Net API Processing Layer Client Op-prototype: options(ModelReference) => StatementSet ModelReference: Reference to the target model for this operation StatementSet: Results of the operation
  30. 30. RDF Net API - Bindings <ul><li>Although we have an abstract protocol we wanted the document to have some concrete implementation bindings. </li></ul><ul><li>We chose to define an HTTP and SOAP binding for the protocol </li></ul>
  31. 31. RDF Net API – HTTP Binding <ul><li>Uses GET with parameters for Query and GetStatements e.g. </li></ul><ul><ul><li>GET HTTP/1.1 </li></ul></ul><ul><li>POST is used for Update, Insert and Remove </li></ul><ul><li>PutStatements uses HTTP PUT </li></ul><ul><li>Options are retrieved by using HTTP OPTIONS </li></ul><ul><li>All data is received and sent as RDF XML, although could support N3 etc </li></ul>
  32. 32. RDF Net API – SOAP Binding <ul><li>To enable Semantic Web Servers to be generic Semantic Web Services we decided to define a SOAP binding for the API. </li></ul><ul><li>But before we could start mapping the operations we needed to define an RDF Data Model representation in XML Schema. </li></ul>
  33. 33. RDF Data Model in XML Schema <types> <schema targetNamespace='' … > <complexType name=&quot;rdfstatement“ <sequence> <element name=&quot;subject&quot; xsd:type=&quot;xsd:string&quot; /> <element name=&quot;predicate&quot; xsd:type=&quot;xsd:string&quot; /> <element name=&quot;object&quot; xsd:type=&quot;xsd:string&quot; /> <element name=&quot;isObjectLiteral&quot; xsd:type=&quot;xsd:boolean&quot;/> </sequence> </complexType> <complexType name=&quot;rdfstatementvector&quot;> <all> <element name=&quot;item&quot; type=&quot;tns:rdfstatement&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/> </all> </complexType> </schema> </types>
  34. 34. Example SOAP Binding – Update Statements <message name=&quot;updateStatementsRequest&quot;> <part name=&quot;modelid&quot; type=&quot;xsd:string&quot; /> <part name=&quot;statementToRemove&quot; type=&quot;tns:rdfstatementvector&quot;/> <part name=&quot;statementToAdd&quot; type=&quot;tns:rdfstatementvector&quot;/> </message> <operation name=&quot;updateStatements&quot;> <input message=&quot;updateStatementsRequest&quot; /> </operation>
  35. 35. RDF Net API - Evaluation <ul><li>Simple yet powerful set of operations </li></ul><ul><li>Easy to implement and deploy </li></ul><ul><li>Some transaction support (enabled by the no edit policy) </li></ul><ul><li>Small footprint </li></ul><ul><li>Open query capability (this is the best we can do until something is standardized!) </li></ul><ul><li>Update operations provided </li></ul><ul><li>Introspection support in an extensible fashion </li></ul>
  36. 36. Issues & Questions <ul><li>No security or auditing </li></ul><ul><ul><li>Although could argue that HTTPS and digital signatures could be used to achieve this to some degree </li></ul></ul><ul><li>Why cant the query language do it all? </li></ul><ul><ul><li>If we have update in RDFQL why do we need these operations? </li></ul></ul><ul><li>Where is the formal definition of the operation semantics? </li></ul><ul><li>Why is it so simple? </li></ul>
  37. 37. RDF Net API - Summary <ul><li>RDF Net API is intended to be a SW enabler. We see it as being the SAX of the Semantic Web. </li></ul><ul><li>This protocol provides a starting point to get the semantic web talking – this is an issue that has been ignored for too long! </li></ul>
  38. 38. Now hang on just one minute!! <ul><li>Where is the Topic Map protocol? </li></ul>
  39. 39. Topic Map Servers – SWS in disguise <ul><li>Topic Map Server </li></ul><ul><ul><li>Topic Map Fragments </li></ul></ul><ul><ul><li>Fragment processing protocol </li></ul></ul><ul><li>Some aspects of the approach taken with the RDF Net API can be borrowed in defining a Topic Map Server. </li></ul><ul><ul><li>HTTP, SOAP bindings tactic </li></ul></ul><ul><ul><li>The no update policy </li></ul></ul><ul><ul><li>Effectively we will re-use the infrastructure and the general shape of the protocol but replace RDF with Topic Maps. </li></ul></ul>
  40. 40. Basic Building Block – Topic Map Fragments <ul><li>Issue: A topic map is a graph of interconnected nodes. In a distributed application it is undesirable to transport all of these nodes from one application to another. What is required is the ability to send a small part of the graph, a topic map fragment, to another application. </li></ul><ul><li>The core issue is how to deal with /resolve </li></ul><ul><ul><li>Dangling pointers </li></ul></ul><ul><ul><li>How much graph to grab </li></ul></ul><ul><li>There have been a number of proposals floated for how this should actually work. </li></ul>
  41. 41. Topic Map Fragment Algorithm <ul><li>When creating a fragment there are three variables that define which part, and how much of the topic map graph to return </li></ul><ul><li>The first piece of information that we need is where to start from: </li></ul><ul><ul><li>So we need some Topic or Association identifier (this could also be a TMQL query) </li></ul></ul><ul><li>Given that a topic map can be seen as a graph we need a ‘depth’ property to indicate how many ‘hops’ in the graph we should make. </li></ul><ul><li>Finally, Topics themselves are complex structures consisting of names, occurrences, identities etc, so we want a ‘detail’ property. This is some indicator about which topic details should be returned as part of the Topic. This could also be a localised TMQL expression. </li></ul>
  42. 42. Example <ul><li>Fragment request : </li></ul><ul><ul><li>Topic Subject Address : </li></ul></ul><ul><ul><li>Depth : 3 </li></ul></ul><ul><ul><li>Detail : ./names[1] </li></ul></ul><ul><li>Would return the topic indicated plus topics to within a depth of 3 (there are several alternative interpretations of depth) and any topics returned will only contain one name (if it exists). </li></ul><ul><li>A refinement on this could be to map detail expressions to depth i.e. </li></ul><ul><ul><li>dd(1, ./names[1] ; ./occurs[2]), … dd(4 , ./names[1]) </li></ul></ul>
  43. 43. A More generalised approach <ul><li>Replace selection of fragment constituents to be a single TMQL query. </li></ul>
  44. 44. Dangling Topics <ul><li>When the fragment is generated special system specific ids are used. </li></ul><ul><li>These are recognised by the client application and can be used in subsequent requests to retrieve further fragments. </li></ul>
  45. 45. Topic Map Fragment as an enabler <ul><li>Whatever the actual algorithm adopted we can make use of Topic Map fragments in conjunction with a control protocol to implement a Topic Map Server. </li></ul>
  46. 46. A Protocol for Topic Map Server <ul><li>Issues that don’t exist with RDF: </li></ul><ul><ul><li>No complex structures </li></ul></ul><ul><ul><ul><li>i.e. only triples </li></ul></ul></ul><ul><ul><ul><li>Makes the no update policy easier to support </li></ul></ul></ul><ul><li>Query </li></ul><ul><li>Add </li></ul><ul><li>Remove </li></ul><ul><li>Update </li></ul><ul><li>options </li></ul>
  47. 47. Topic Map Server - Query <ul><li>Essentially the same as the RDF Net API except in the nature of the query (TMQL) and the nature of the result (A Topic Map fragment) </li></ul>
  48. 48. Topic Map Server – Add / Remove Issues <ul><li>Both add and remove send a topic map fragment to the server and expect the information contained within the fragment to be added/ or removed from the topic map. </li></ul><ul><li>While this is fine for adding or removing complete topics and associations it is not adequate for the addition of names, occurrences and identities to topics nor for their removal. </li></ul>
  49. 49. Topic Map Server – Fragment Contexts <topic id=“t-1”> <baseName> <baseNameString>Semantic Web Server</baseNameString> </baseName> </topic> If we are adding this, do we want to add a new topic with a new name, or add a name to an existing Topic?
  50. 50. Topic Map Server – Fragment Contexts <ul><li>Goal : to indicate if the topic should be added to or added </li></ul><ul><li>Several options, </li></ul><ul><ul><li>The ‘id’ property should contain a ‘internal system identity’ </li></ul></ul><ul><ul><li>A new property is defined on topic - isContextTopic </li></ul></ul><ul><ul><li>A special type is used within the topic </li></ul></ul><ul><ul><li>The system id exists as a subject address for this topic </li></ul></ul><ul><li>All act to inform the processing tm server about what kind of add or remove to perform. </li></ul>
  51. 51. Example Add <ul><li>Add : </li></ul><topic id=“t1”> <subjectIndentity>ontopia:system:topic:23</subjectIdentity> <baseName>Graham Moore</baseName> <baseName>gdm</baseName> </topic> <topic id=“t2”> <baseName>Lars Marius Garshol</baseName> </topic>
  52. 52. Topic Map Server - Update <ul><li>As with RDF Net API update is a single transaction that performs a remove then an add. </li></ul>
  53. 53. Topic Map Server - Summary <ul><li>Possess the same qualities as the RDF Server </li></ul><ul><li>Slightly more complex with the need for context topics within the topic map fragment </li></ul>
  54. 54. Future Work <ul><li>Evolution of RDF Net API and Topic Map Server </li></ul><ul><li>Possible work items, OWL , TMCL layers introduced into the protocol </li></ul><ul><li>Would be nice to see a standardisation of query languages </li></ul>
  55. 55. Resources <ul><li>SNAPI (Semantic Network API) Source forge project </li></ul><ul><li>RDF Net API – W3C submission </li></ul><ul><li>Joseki </li></ul><ul><li>New W3C Activity – Data Access? </li></ul>
  56. 56. SWS protocol give the Semantic Web a chance to be a WINNER! <ul><li>Just Like Johnny! </li></ul>
  57. 57. Conclusions <ul><li>There already exists some basic protocols that are showing how the semantic web can develop </li></ul><ul><li>With the RDF Net API and the Topic Map Server protocols we have defined simple yet powerful mechanisms that can enable the web to become semantic web </li></ul><ul><li>We need adoption, implementation and deployment and we think it will come </li></ul>
  58. 58. One last thought… <ul><li>‘ So is building the Semantic Web really a futuristic research vision for a bunch of rocket scientists? As you see, the answer is no. The Semantic Web, like the World Wide Web, can grow from taking well established ideas, and making them work interoperability over the Internet. This is done with standards, which is what the World Wide Web Consortium is all about.’ </li></ul><ul><li>Integrating Applications on the Semantic Web (Oct 2002) </li></ul><ul><ul><li>James Hendler </li></ul></ul><ul><ul><li>Tim Berners-Lee </li></ul></ul><ul><ul><li>Eric Miller </li></ul></ul><ul><li>Well, gentlemen, as far as I can see the W3C is missing one very large piece! </li></ul>