Semantic Web and REST
Upcoming SlideShare
Loading in...5
×
 

Semantic Web and REST

on

  • 4,088 views

Understanding the underlying concepts and principles behind the web is essential to current and future implementation initiatives. For this reason, it is the objective of this paper to uncover the ...

Understanding the underlying concepts and principles behind the web is essential to current and future implementation initiatives. For this reason, it is the objective of this paper to uncover the root of its existence, and to examine the fundamental design notion of the following design principles: Independent specification design, Hypertext Transfer Protocol (HTTP), Uniform Resource Identifier (URI) and Hypertext Markup Language (HTML). This study also aims to develop a better understanding of the emerging web standards, such as REST, SOA, and Semantic Web. The paper discusses some of the misconceptions about URI, HTTP and XML and the following issues: a) In REST and Semantic point of view, there is no difference between slash based and parameter based URI reference; b) HTTP is not a data transfer protocol; it is an application protocol (or a coordination language, if you swing that way). REST does not "run on top of HTTP" but rather HTTP is a protocol that displays many of the traits of the REST architectural style; c) What is Extensible Markup Language (XML) function in Representational state transfer (REST) and Semantic Web? Is it true that most REST services in deployment do not return XML but rather HTML? Is it true that REST has no preference for XML?

Statistics

Views

Total Views
4,088
Views on SlideShare
4,086
Embed Views
2

Actions

Likes
0
Downloads
39
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Semantic Web and REST Semantic Web and REST Document Transcript

  • STRAYER UNIVERSTY NETWORK ARCHITECTURE AND ANALYSIS SUBMITTED TO DR. BRYANT PAYDEN BY ADELMAR ESPLANA GRADUATE STUDENT IN MASTER OF SCIENCE IN INFORMATION SYSTEMS MARCH 2009
  • 2 I. Overview “Knowledge is power (But only if you know how to acquire it)." (The Economist, 2003) Knowledge is awareness and understanding of facts, truth or information in the form of experiences and learning. Today, one of the quickest ways to acquire knowledge is through the Web or WWW (World Wide Web). Using search engine facilities, we can search almost any kind of information. The internet has become a world- wide network of information resource and a powerful communication tool. And the more specific word you type in, in the search engine, the more accurate results you would get. The internet is a powerful tool which may be used in a number of ways such as having online classes, bills payment, booking vacation, scheduling medical appointments, finding the latest news and even taking a virtual tour on vacation destinations. In spite of all these tremendous capabilities that the Web offers, to date, the principle that is being used by search engines in the analysis of material is based on textual indexing. Although search engines have proven remarkably useful in finding information rapidly, they have also been proven remarkably useless in providing quality information. “The biggest problem facing users of web search engines today is the quality of the results they get back.”(Brin S. & Page L.) Currently, search engines can only account for the vocabulary of the documents and has a little concept of document quality thereby producing a lot of junk. Since its inception in 1989, the internet has grown initially as a medium for the broadcast of read- only material, from heavily loaded corporate servers, to the mass of internet-connected consumers. Recently, the rise of digital video, blogging, podcasting, and social media has revolutionized the way people socially interact through the web. Other promising developments include the increasing interactive nature of the interface to the user, and the increasing use of machine-readable information with defined semantics allowing more advanced machine processing of global information, including machine-readable signed assertions. (Berners T., 1996a) A lot of the data that we use everyday are not part of the web. These data which are in various silos, reside in different software applications and different places that cannot be connected easily like bank statements, photographs and calendar appointments. In order for us to see bank statements, we have to use online banking; to manage our calendar appointments and organize our photo collection, we have to use
  • 3 social-oriented websites such as MySpace and Facebook. It is interesting to see on the web photos displayed on a calendar, showing exactly what we were doing when we took them; and bank statement, showing the list of transactions that we incurred. Due to the silo of information where both personal and business information are managed by different software, we are forced to learn how to use different programs all the time. In addition, since data are controlled by applications, each application must keep the data to itself. According to W3C Group, what we need is a “web of data” (Herman I., 2009). Supported by Fielding’s dissertation, he mentioned that what we need is a way to store and structure our own information, whether permanent or temporal in nature, both for our own necessity and for others, be able to reference and structure the information stored by others so that it would not be necessary for everyone to keep and maintain local copies. (Fielding R., 2000) II. Purpose of the Paper Understanding the underlying concepts and principles behind the web is essential to current and future implementation initiatives. For this reason, it is the objective of this paper to uncover the root of its existence, and to examine the fundamental design notion of the following design principles: Independent specification design, Hypertext Transfer Protocol (HTTP), Uniform Resource Identifier (URI) and Hypertext Markup Language (HTML). This study also aims to develop a better understanding of the emerging web standards, such as REST, SOA, and Semantic Web. The paper discusses some of the misconceptions about URI, HTTP and XML and the following issues: a) In REST and Semantic point of view, there is no difference between slash based and parameter based URI reference; b) HTTP is not a data transfer protocol; it is an application protocol (or a coordination language, if you swing that way). REST does not "run on top of HTTP" but rather HTTP is a protocol that displays many of the traits of the REST architectural style; c) What is Extensible Markup Language (XML) function in Representational state transfer (REST) and Semantic Web? Is it true that most REST services in deployment do not return XML but rather HTML? Is it true that REST has no preference for XML?
  • 4 III. Foundation of the World Wide Web According to Tim Berners, “The goal of the Web was to be a shared information space through which people (and machines) could communicate.” (Berners T., 1996a) It was also the original intent that this so called “space” ought to span all sorts of information, from different sources to a wide array of formats, and from highly valued designed material to a spontaneous idea. In the original design of the web, he stated the following fundamental design criteria: (Berners T., 1996a) a) An information system must be able to record random associations between any arbitrary objects, unlike most database systems The concept of database systems has been purposely utilized to facilitate storage, retrieval and information generation of structured data. Unlike, the web concept of “one universal space of information” which is based on the principle that almost anything on the web could be possibly linked to any arbitrary objects. The power of the Web is that linkage can be established to any document (or, more generally, resource) of any kind in the universe of information, whereas in the database systems, one has to understand the data structure to establish the relationship. b) If two sets of users started to use the system independently, to make a link from one system to another should be an incremental effort, not requiring unscalable operations such as the merging of link databases In the business environment, to integrate two different types of systems, it is necessary to perform some degrees of integration efforts such as merging, importing or linking of databases. On the contrary, the idea of web was to be able integrate systems easily. Most of the systems done in the past involve a great deal of integration effort due to the information silo. For this reason, the idea where machine can talk to each other set forth the promise of seamless integration. c) Any attempt to constrain users as a whole to the use of particular languages or operating systems was always doomed to fail. Information must be available on all platforms, including future ones. Platform and language interoperability support the principles of universality of access
  • 5 irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment. d) Any attempt to constrain the mental model users of data into a given pattern was always doomed to fail. If information within an organization is to be accurately represented in the system, entering or correcting it must be trivial for the person directly knowledgeable If the interaction between person and hypertext could be so intuitive that the machine- readable information space gave an accurate representation of the state of people's thoughts, interactions, and work patterns, then machine analysis could become a very powerful management tool, seeing patterns in our work and facilitating our working together through the typical problems which beset the management of large organizations. Independent specification design The basic principles of the Web proposed in 1989 to meet the design criteria were adopted based on the well-known software design principles called “independent specification design”. This design was based on the principle of modularity. Meaning when it is modular in nature, the interfaces between the modules hinge on simplicity and abstraction. This allows seamless compatibility of the existing content, to work with the new implementation. As technology evolves and disappears, specifications for the Web’s languages and protocols should be able to adapt to the new hardware and software changes. Along with this basic principle are the three main components such as URI, HTTP and HTML. URI or Universal Resource Identifier URI is a compact string of characters for identifying abstract or physical resource. It is a simple and extensible means of identifying a resource. A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identifies resources via a representation of their primary access mechanism, rather than identifying the resource by name or by some other attribute(s) of that resource (Berners T., Fielding R. & L. Masinter, 2005). URNs (Uniform Resource Names) are used for identification; URCs (Uniform Resource Characteristics), for including meta- information; and URLs, for locating or finding resources.
  • 6 REST defines URI as a resource based on a simple premise that identifiers should change as infrequently as possible (Fielding R., 2000). While Semantic Web identifies URI’s not just Web documents, but rather real-world objects like people, cars, and abstract ideas. They call all these as real-world objects or things (W3C, 2008b). Deriving URI definitions from the meaning of each letters U -Uniform, R-Resource and I-Identifier as listed below: Uniform allows consistency of its usage, even when the internal mechanism of accessing the resources has changed. It allows common semantic interpretation of syntactic conventions, across different type of resources to work with the existing identifiers. Resources are, in general, any real world “thing” such as electronic documents, images and services, recognized by URI to represent something, for example, electronic document, an image, or a source of information with consistent purpose. Other resources that are not accessible via internet are representation of the abstract concepts, mathematical equations, correlation (e.g., “parent” or “employee”) and values (e.g., zero, one, and infinity). Identifier pertains to information required to distinguish what is being identified from all other things within its scope of identification. The terms “identify” and “identifying” means distinguishing one resource from the other regardless how that purpose is accomplished. One of the capabilities web popularized is the ability of documents to link to any kind, in the universe of information. With this in mind, the concept of “identity” is concerned with the conceptual scheme of identifying objects generically. For example, one URI can represent a book which is available in several languages and several data format. HTTP and URIs are the basis of the World Wide Web, yet they are often misunderstood, and their implementations and uses are sometimes incomplete or incorrect (W3C, 2003). a) A common mistake, responsible for many implementation problems, is to think that a URI is equivalent to a filename within a computer system. This is wrong as URIs have, conceptually, nothing to do with a file system.
  • 7 b) A URI should not show the underlying technology (server-side content generation engine, script written in such or such language) used to serve the resource. Using URIs to show the specific underlying technology means one is dependent on the technology used, which, in turn, means that the technology cannot be changed without either breaking URIs or going through the hassle of "fixing" them. HTTP According to the HTTP 1.0 specification, The Hypertext Transfer Protocol (HTTP) is an application- level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (Berners T., Fielding R. & Frystyk H., 1996b). HTTP messages are generic and communication takes place operationally based on the client/server paradigm of request/response. Messages are all created to comply with the generic message format. Clients usually send requests and receive responses, while servers receive requests and send responses. It is stateless and connectionless in nature because after the server has responded to the client's request, the connection between client and server is dropped and forgotten. There is no "memory" between client connections. Basically, when you type in the URL in the browser, the client and server Connection takes place over TCP/IP. This URL internally gets converted into a Request for server to process, after the server finished processing, and then the server sends the message Response back to the client and Closes the connection of both parties. The downside of it is that, it may decrease the network-performance due to the increasing amount of overhead data per request, the fact that the state of request is not stored in a shared context. The design is patterned and implemented with the idea of object-orientation. In general, objects used internally for each request are as follows: HTTP messages, Request/Response, Entity, Method Definitions, Status Code Definitions, Status Code Definitions, and Header Field Definitions (based HTTP 1.0 specification).
  • 8 The Method field indicates the method to be performed on the object identified by the URL. Methods supported by HTTP 1.1 specification are OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT (Fielding R., 1999). The GET method means to retrieve whatever is identified by the URI. The HEAD is the same as GET but it returns only HTTP headers and no document body. The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: 1) annotation of existing resources; 2) posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; 3) providing a block of data, such as the result of submitting a form, to a data-handling process; and 4) extending a database through an append operation. (Berners T., Fielding R & H. Frystyk, 1996b). HTML The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. (Yergeau F. et.al, 1997) The difference between XML and HTML is that, HTML is defined by W3C that must be followed by every possible browser. XML is an extension, its markup is customizable. It is typically used as storage to hold and describe data. IV. Future of the World Wide Web Say you had some lingering back pain: a program might determine a specialist's availability, check an insurance site's database for in-plan status, consult your calendar, and schedule an appointment. Another program might look up restaurant reviews, check a map database, cross-reference open table times with your calendar, and make a dinner reservation. Tim Berners and others describe this as “web of data”. This will be the new Web capable of supporting software agents that are able not only to locate data, but also to “understand” in ways that will allow computers to perform meaningful tasks with data automatically on the fly (Updegrove, 2001). The Semantic Web is a web of data. It is about common formats for integration and combination of data drawn from diverse sources, where on the original Web mainly concentrated on the interchange of
  • 9 documents. It is also about language for recording how the data relates to real world objects that allows a person, or a machine, to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing (Herman I., 2009). Representational State Transfer (REST) is an architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, while contrasting them to the constraints of other architectural styles (Fielding R., 2000). The fundamental differences between the two are: Semantic Web is an integration solution (a solution to information silo), while REST is a set of state transfer operations universal to any data storage and retrieval system (Battle R. & Benson E., 2007). Semantic Web provides ways to semantically describe and align data from desperate sources while REST offers resource data access operations commonly known as CRUD (Create, Read, Update and Delete). From the traditional “web of pages” to a “web of data”, the Semantic Web goal is to provide a cost- efficient way of sharing machine-readable data. The business of sharing machine-readable data in general has been around for quite some time. Information silo has always been a challenge that researchers and IT practitioners are keen about. Service-oriented architecture (SOA) solutions have been created to satisfy business goals that include easy and flexible integration with legacy systems, streamlined business processes, reduced costs, innovative service to customers, and agile adaptation and reaction to opportunities and competitive threats. SOA is a popular architecture paradigm for designing and developing distributed systems (Bianco P. et al., 2007). In spite of the popularity of SOA and Web Services, confusion among software developers is prevalent. To shed a light, SOA is an architectural style, whereas Web Services is a technology used to implement SOA’s. Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks (W3C, 2004). The Web services technology consists of several published standards, the most important ones being SOAP, XML (Extensible Markup Language) and WSDL (Web Services Description Language). Although there are some other technologies like CORBA and
  • 10 Jini but to limit our discussion, we are only concerned with the Web Services as other do not apply to Web domain. At the heart of the Service Oriented Architecture is the service contract. It answers the question, "what service is delivered to the customer?" In the current web-services stack, WSDL is used to define this contract. However, WSDL defines only the operational signature of the service interface and is too brittle to support discovery in a scalable way. "SOAP” is no longer an acronym, A SOAP message represents the information needed to invoke a service or reflect the results of a service invocation, and contains the information specified in the service interface definition (W3C, 2004). Extensible Markup Language (XML) documents are made up of storage units called entities, which contain either parsed or unparsed data. (Cowan J., 2008). SOAP and WSDL are good examples of XML documents. As mentioned earlier, Web services way is just another roadmap of Service Oriented Architecture. The concept of “web of data” was also introduced as a solution for information silo and, was able to establish the rationale for Web-accessible API (Application Programming Interface). Technically speaking, a Web service is a Web-accessible API. So, why is there a need for REST and Web Semantics? There is a great amount of data available through REST and SOAP Web Services, published by private and public sectors however these data carry no markup that conforms to semantic standards. It is important to provide markup in a manner where Semantic Web application suite understands to make the services compatible and to allow semantic query operations feasible (Battle R. & Benson E, 2007). In the traditional Database Systems, we have SQL (Structured Query Language). It is the language used to interact with the database. In the Semantic world, there is this technology called SPARQL (SPARQL Protocol and RDF Query Language). SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph. The results of SPARQL queries can be results sets or RDF graphs (W3C, 2008a).
  • 11 It is now getting more interesting, that developers have to learn not only SQL but also SPARQL. Thanks to Edgar Frank Codd, the inventor of Relational Database; without his invention we are still using the filing cabinet and physically sorting out and searching records manually. It is important to provide markup in a manner where Semantic Web could understand to make the services compatible and to allow semantic query operations feasible. With the existing SOAP Web services, what needed to be done is to add semantic information to web services, such as OWL-S and SAWDL. They provide details for each Web service parameter that describes how the value is derived from ontology (Battle R. Benson E, 2007). The OWL-S document maps each operation and message defined in the WSDL definition ontology. But the problem with SPARQL is that, it is an RDF Query Language designed for RDF. Since most Web services return plain old XML, a conversion process from XML data to RDF is needed. So where does REST come into play? REST is another roadmap of SOA and a principle that is being applied to a quite few of Web services implementation. While SOAP based services have a WSDL document that defines their operation, there is no standard equivalent for REST services. This is the area where companies who adopted REST earlier must be aware of. Who knows, if companies are really convinced that this is the right way of doing Web services, then maybe in the future there will be a standard way of implementation. V. Discussion a. In REST and Semantic point of view, there is no difference between slash based and parameter based URI reference. There are two major requirements on the Semantic Web where naming of Resource must be followed. First, a description of the identified resource should be retrievable with standard Web technologies. Second, a naming scheme should not confuse things and the documents representing them (Battle R. Benson E., 2007). Both REST and Semantic Web support the idea that “Cool URIs don't change”. Tim Berner explained that the best resource identifiers don't just provide descriptions for people and machines, but are designed with simplicity, stability and manageability in mind. Based on
  • 12 W3C standard, a generic URI syntax consists of hierarchical sequence of components such as scheme, authority, path, query, and fragment. URI = scheme ":" hier-part [“?" query] [“#" fragment] The following are two examples URIs and their component parts: foo://example.com:8042/over/there?name=ferret#nose _/ ______________/_________/ _________/ __/ | | | | | scheme authority path query fragment | _____________________|__ // urn: example: animal: ferret: nose WC3 recommends the use of standard session mechanisms instead of session-based URIs (W3C, 2003). What does it mean? HTTP/1.1 provides a number of mechanisms for identification, authentication and session management. Using these mechanisms instead of user- based or session-based URIs guarantees than the URIs used to serve resources is truly universal (allowing, for example, people to share, send, or copy them). For example: Bob tries to visit http://www.example.com/resource, but since it's a rainy Monday morning, he gets redirected to http://www.example.com/rainymondaymorning/resource. The day after, when Bob tries to access the resource, he had bookmarked earlier, the server answers that Bob has made a bad request and serves http://www.example.com/error/thisisnotmondayanymore. Had the server served back http://www.example.com/resource because the Monday session had expired, it would have been, if not acceptable, at least harmless. The problem with this is that, it does not really guarantee that URI’s used are truly universal. The acceptable practice in this situation is to use some modifiers, like "?" used to pass arguments for cgi, or ";" and to pass other kind of arguments or context information.
  • 13 Roy Fielding did not mention in his dissertation that URI do not allow parameterized reference. Similarly, Semantic Web requirements mentioned that as long as the identifier conforms to the two major requirements above and W3C standard specifications then the use of it is acceptable. Both REST and Semantic Web consistently raised the implementation need of having abstraction to URI. The key abstraction of information in REST is a resource. Any information that can be named can be a resource, a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on (Fielding R. 2000). It was mentioned previously that the biggest challenge of the search engines today is the quality of results. Search engine spiders do not presently crawl many types of “dynamic” web pages. Typical examples of dynamic pages are those internal and external web applications that companies are using to do their business as well as those Web 2.0 emerging sites. In accordance to this, it is important that we identify the types of resource and mapped the underlying entity. Conceptual representation means, resource is an abstraction of some type of arbitrary concept. Once mapping of the concept “resource” to a physical resource is done, it should remain this way as long as possible. Think about pages that have .asp extension. Companies who are still linking to those pages are possibly not working anymore since a lot of companies are now moving to .aspx. b) HTTP is not a data transfer protocol; it is an application protocol (or a coordination language, if you swing that way). REST does not "run on top of HTTP" but rather HTTP is a protocol that displays many of the traits of the REST architectural style. HTTP is not designed to be a transport protocol. It is a transfer protocol in which the messages reflect the semantics of the Web architecture by performing actions on resources through the transfer and manipulation of representations of those resources. It is possible to achieve a wide range of functionality using this very simple interface, but following the interface is required in order for HTTP semantics to remain visible to intermediaries (Fielding R., 2000).
  • 14 Conceivably, it is easy to get the wrong idea that REST sits in between Application Protocol and Transport Protocol when it was cited that REST is a “transfer protocol”. Leveraging the HTTP Headers to provide request context around CRUD operations (Create for POST, Read for GET, Update for PUT and Delete for DELETE) will allow developers to overlay the programmatic API for a website directly on top of the site exposed to web user and reduce the cost and complexity of providing multi- format access to a site’s underlying data. c) What is Extensible Markup Language (XML) function in REST and Semantic Web? Is it true that most REST services in deployment do not return XML but rather HTML? Is it true that REST has no preference for XML? RESTS’s data elements are summarized in Table 1 Table 1 REST Data Elements Data Element Modern Web Examples resource the intended conceptual target of a hypertext reference resource identifier URL, URN representation HTML, document, JPEG image representation metadata media type, last-modified time resource metadata source link, alternates, vary control data if-modified-since, cache-control It is true that Roy did not specify XML as an example of resource and resource metadata; on the other hand, he did mention the representation media type which is the data format of the representation. He described that representation consists of data, meta data describing the data, and, on occasion metadata to describe metadata. As mentioned previously XML is an open standard for describing data. Therefore, the question about “REST has no preference for XML”. It is not true if you are doing Web services but false if you are just creating pages that are not designed for machine
  • 15 interpretation, why do you have to care about returning XML if you don’t need it in the first place? Likewise if you want to share your data, how do you want your data represented? Using file delimited text? The idea of REST and Semantic Web is to coexist with the existing web standards and not to disqualify any of them; in fact it is the idea of Platform and language interoperability. V. CONCLUSION Acquiring data has becoming easier and easier than ever before and with latest technology breakthroughs, there is no doubt that in time the internet will be “all in one”. Along the way, there will be some adjustments and corrections to be done and misconceptions to be addressed (intentional or not - whatever) to reach this so called “web of data”. Support from the industry players is crucial. Data security issues have always been our primary concerned. There are a plethora of questions that must be addressed, such as the following; a) who will annotate the data? b) What is the advantage of giving the data, as we all know that data is a valuable commodity? c) Without any centralized control, how will all this data be connected to one another? d) Will the existing AI techniques be sufficient to process this huge amount of data? In addition, is it even practical to pursue this route? On the other side, web has exploded so rapidly that in the beginning, what we are only concerned about is the sharing of documents. Giving credit to the early contributors who brought us this far, I firmly believe that the simple approach of the existing implementation of web particularly URL (which was originally designed as URI) opened up the door to everybody (computer savvy and none). Explaining URI alone to common people and doing it right the first time is not simple. Philosophically speaking, isn’t it also what the concept of “universality of access” is? In the same way, when you write software, it is not always right the first time. Writing software is an evolving process. Meeting the line of both ends, I believe that there is not much we can do concerning why things are done the URL way, but I do recognize that there is always room for improvement. With a better understanding of what went before and what it is about to come, moving towards the future of Semantic Web is up for us to consider.
  • 16 VI. REFERENCES Berners T., Fielding R. & Masinter L. (2005) Uniform Resource Identifier (URI): Generic Syntax. Retrieved Feb 13, 2009 from http://labs.apache.org/webarch/uri/rfc/rfc3986.html#URLvsURN Berners T. (2002). What do HTTP URIs Identify? Retrieved Feb 20, 2009 from http://www.w3.org/DesignIssues/Overview.html Berners T. (1996a). The World Wide Web: Past, Present and Future. Retrieved on Feb 20, 2009 from http://www.w3.org/People/Berners-Lee/1996/ppf.html Berners T., Fielding R & H. Frystyk (1996b) Hypertext Transfer Protocol -- HTTP/1.0. Retrieved Feb 13, 2009 from http://www.ietf.org/rfc/rfc1945.txt Battle R. Benson E, (2007). Bridging the semantic Web and Web 2.0 with Representational. State Transfer (REST). Retrieved Feb 13,2009 from http://omescigil.etu.edu.tr/semanticweb/papers/sw_4.pdf Bianco P., Kotermanski R. Merson P. (2007 ) Evaluating a Service-Oriented Architecture. Retrieved Feb 13,2009 from http://www.sei.cmu.edu/pub/documents/07.reports/07tr015.pdf Brin S. & Page L. The Anatomy of a Large-Scale Hypertextual Web Search Engine. Retrieved Feb 20, 2009 from http://infolab.stanford.edu/~backrub/google.html Cowan J., Fang A., Grosso P., Lanz K., Marcy G., Thompson H., Tobin R., Veillard D., Walsh N., Yergeau F. (2008) Extensible Markup Language (XML) 1.0 (Fifth Edition) Retrieved Feb 13,2009 from http://www.w3.org/TR/REC-xml/#sec-intro Fielding R. (2000). Architectural Styles and the Design of Network-based Software Architectures. Retrieved Feb 20, 2009 from http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Fielding R., Mogul J., Gettys J., Frystyk H., Masinter L., Leach P. & Berners T. (1999) Hypertext Transfer Protocol HTTP/1.1. Retrieved Feb 13,2009 from http://www.ietf.org/rfc/rfc2616.txt Herman I. (2009). W3C Semantic Web Activity. Retrieved Feb 20, 2009 from http://www.w3.org/2001/sw/
  • 17 The Economist (2003). Knowledge is power. Retrieved on Feb 20, 2009 from http://www.economist.com/business/globalexecutive/education/displayStory.cfm?story_id=17626 Updegrove A. (2001) THE SEMANTIC WEB: AN INTERVIEW WITH TIM BERNERS-LEE. Retrieved Feb 13,2009 from http://www.consortiuminfo.org/bulletins/semanticweb.php W3C (2008a) SPARQL Query Language for RDF Retrieved Feb 13, 2009 from http://www.w3.org/TR/rdf-sparql-query/ W3C (2008b) Cool URIs for the Semantic Web. Retrieved Feb 13, 2009 from http://www.w3.org/TR/2008/WD-cooluris-20080321/ W3C (2004) Web Services Architecture Retrieved Feb 13, 2009 from http://www.w3.org/TR/ws-arch/#id2260892 W3C (2003) Common HTTP Implementation Problems. http://www.w3.org/TR/2003/NOTE-chips-20030128/ Yergeau Y., Nicol G. Adams G. & Duerst M .(1997) Internationalization of the Hypertext Markup Language http://www.rfc-editor.org/rfc/rfc2070.txt