dretblog

Linked Data and REST: A Match Made in W3C

the W3C announced yesterday that the Linked Data Platform (LDP) Working Group has been officially launched. in case you're interested, the proposed charter is a great starting point to learn more. i am happy and proud to be listed as a proposed co-chair of the WG (together with IBM's arnaud le hors). i think this activity will be a pivotal point in the development of linked data, and interestingly, the driving force behind the working group has been the fact that linked data is probably considerably more interesting as a BI-like data integration platform than it is as an AI-like ontology/inference technology, and it's great to see that such a pragmatic view now has become the driving factor behind something as substantial as a W3C working group.

personally, what makes me most hopeful for the future of linked data on a much larger scale than so far is the very open attitude towards REST as expressed in the charter. this means that REST with its focus on encapsulating interaction semantics in media types now is readily available as a toolkit on which linked data can build. over are the days where every last bit in a linked data scenario had to be RDF, and if it were not, then things could not be linked data. this open attitude means that linked data now can grow much faster, can be more inclusive in its choice of components, and does not have to reinvent the wheel for every little piece of machinery that has to be put in place. most importantly, real-world developers will be able to ease into linked data comfortably, first finding a feed providing interesting data and useful services around it (updates, notification services, push services, ...), then happily using its entry-level metadata, and once they decide they really have found something of interest and value, they will encounter RDF when they dive into the actual payload.

linked data is a data model, and REST is an interaction model, and as such they are two nicely complementary parts. while it will be important to make sure that the data model itself is maintained at the payload level, many of the issues listed in the charter can be readily addressed by choosing existing and well-established standardized components (3/4/5/9/10/11 likely can be solved by using a combination of RFCs 4287/5005/5023 and some best practices how to use them). however, other issues may go right to the heart of RDF (for example the question of how to handle RDF granularity so that RDF documents become part of RDF's model). whatever exactly we will be able to address and achieve in the group, i am really looking forward to pragmatically combine linked data and REST, and i hope i will be part of an activity that will take linked data from being the 1% of how people handle data integration and big data, to being the 99%.

REST Layers and REST Applications

there has been a rather long history of people trying to describe REST applications, and an equally long history of responses saying that it cannot be done, should not be done, and that REST is allow about following your nose across a web of interlinked resources. many approaches have used some kind of RDF-based model, and have either tried to model/describe an application in terms of SemWeb principles, or in some cases the standards (such as HTTP) themselves. however, so far there seems to be no consensus on whether it could/should be done, and given the fact that we expect RESTful APIs to become more popular, it would be good if the REST community could provide some guidance on how those APIs should be described/documented.

in an attempt to better understand what and why people are trying to accomplish when they try to describe REST, here is a first approach to more cleanly layer the issues, see what's already around, and try to figure out what value could provided by some format/technology for each layer. we are actively working in this area because we simply need something that will allow service providers to describe (and by that we mostly mean document) their services. our platform allow customers to define and expose REST services, and when they do this and want to point, for example, external partners at these services asking them to develop clients, instructing them to tell your external partners to follow their nose just doesn't quite cut it.

in this first attempt at a layering model, there are five layers:

1. architectural style: this is where REST itself is defined, independent of any technology. this is where the architectural principles of the style are defined, and fielding' thesis by definition is the one and only authoritative source in this layer.
2. technology framework: on top of REST's principles, web architecture encompasses a set of enabling mechanisms, most importantly URI for identification, HTTP for interaction, and media types for labeling representations (and it is interesting to notice that the core technologies on this layer are all defined by IETF instead of the W3C). while this layer is essential for the fabric of the web, in itself it does not yet define a working system, because it lacks concrete representations that can be used as transfer formats.
3. core technologies: for the human web, HTML is the most important media type (but without more media types such as images, the web never have succeeded), and for machines XML and RDF have become important enabling technologies. it is important to notice that all of these media type are application-agnostic and not application-specific formats. clients need to support those media types to work properly, but without additional guidance (provided by human operators or additional information), they don't know what they are doing and blindly interact with a set of semantically shallow resources. core technologies allow clients to work in a RESTful way, but they may not allow servers to expose the richness of the services they are providing.
4. added semantics: (almost) all of the web's core technologies have some mechanism to add semantics. sometimes these mechanisms have formalized representations (such as XML's DTDs or XSD), sometimes not (HTML profiles are not described in any standardized way). some added semantics are metamodels (XML schema languages allow authors to define their own schemas), some are fixed models (podcasts define a fixed set of extensions that can be found in feeds). most importantly, the core technologies provide ways how these added semantics can be signaled to clients, for XML through namespaces and/or associated schemas, and for HTML through profile parameters (and the proposed 'profile' link relation type might be able to unify this mechanism across media types). added semantics allow servers and clients to support semantic overlays that allow richer and more semantics-driven forms of interaction.
5. applications: based on core technologies and possibly added semantics, developers build applications, which expose the resources of a given service in some URI space. these applications can use any number of media types and any set of added semantics on top of these, and in some cases developers will define their own media types, whereas in others they will just reuse existing ones. in both cases, the application is seamlessly embedded into the bigger context of the RESTful system, and while that may be not interesting at all for some clients, and might as well be interesting for others. for the HTML web, google's sitemaps format has become an established representation in this area because it allows servers and certain clients (crawlers) to interact in ways that are advantageous for both sides.

based on some of the discussions that happened around describing REST, it seems that at times, there was a mismatch in where in these layers people wanted to be. when it comes to layers 3 and 4, documentation/description should be the media type or semantic extension itself. for these cases, all that a client should need to know is the processing and operational model of the resource, and then it can act. however, when it comes to layer 5, i am a firm believer that there are scenarios where a description format would be very desirable, and the sitemaps format is one (very widely deployed) example.

in our work on the Resource Linking Language (ReLL) we have explored this area and made some design choices that i would now make differently. but generally speaking, giving application providers the possibility to describe the extent of their application and doing that in a way which itself is a self-describing resource seems like a very RESTful approach. if a client is interested in this information, there is a discovery mechanism (for sitemaps a slightly awkward robots.txt-based rule that hardcodes an URI-based approach) and then the client can happily use that information, and could for example inform the user that he is now leaving the application (which may or may not be indicated by a change in the some URI prefix). if clients are not interested in the notion of an application at all (like regular users happily surfing the web without ever experiencing application boundaries), they simply ignore this information.

starting from this idea of REST layers, i'd be curious to get some feedback about the perceived usefulness of a description language that specifically just resides in layer 5. the main goal is to establish a format that could be seen as sitemaps for REST, and definitely should be less chatty than exhaustively listing all URIs. this would allow service providers to describe the universe of resources they are exposing, and would give clients a snapshot view of the current expectations they can have about exposed resources, and the assumptions about where the scope of the applications ends. in a follow-up to this post, i will outline our scenarios, and write more about the things we would like to include and exclude in such a REST Application Description Language.

Action URIs

anybody doing non-trivial things with REST sooner or later runs into interactions beyond the simple CRUD (create/read/update/delete) operations. there often are cases where operations might be tied to a specific resource (or mainly to that resource), and then the question is how model this in a RESTful way. a pattern that is seen frequently is the action URI, which is a URI that specifically represents one action on one resource.

for example, if there is an open order http://example.com/order/42, then the payment action will be represented at the URI http://example.com/order/42/payment. clients will interact with that by using either PUT or POST (PUT seems to be the preferred way) to submit a payment.

this clearly works, as demonstrated by many existing APIs, but is it really the best or only way of doing it? there are some issues with this design:

1. no linking: if this is just a payment service, why not use http://example.com/order/payment instead and have a payment media type that links to the order being paid? that would not only make the payment resource a more reasonable interaction point (it's basically like a cashier accepting many different things to be paid for), it also would allow for richer functionality such as paying for multiple orders (simply link to all the orders you're paying for) or even paying for third-party orders (simply link to these 3rd-party orders).
2. contrived resource model: if the action indeed is bound to a single resource (in contrast to the potentially more general action mentioned in issue 1), then why is it a resource? it seems that the interaction taking place is to submit a state change to the actual resource, and then that resource is changing state (from awaiting payment to paid) as a result of that interaction. what is the reasoning behind turning the payment into an action, and why is it significantly better than the dreaded just embed action=payment in URI query parameters anti-pattern?
3. not media type centric: if payment is done using a payment request, then there has to be a self-describing document conveying the payment data. this could be submitted to a general payment resource (as described in issue 1) or to the resource itself (as described in issue 2), but there really does not seem to be a good reason why it would need to be submitted to a specific URI just minted for that particular operation on that particular resource.

please keep in mind that even if you would use a general-purpose payment URI or POST a payment to the order URI, clients would still only be linked to the payment URI when payment would be a state change permitted by the server. as usual, a rel="payment" link would only be included if paying was an option, and the only difference to the resource-specific action URI approach would be that it would point to either a general-purpose payment URI, or to the URI of the order accepting the payment media type.

after a quick but non-representative look at some books and APIs, it seems to me that the resource-specific action URI is a pretty common pattern, and i would be interested in opinions about the alternatives, and also whether people have looked at all these patterns and have made decisions between them because of constraints that made one pattern a better fit that the other. as usual, there are many ways to solve a given problem, but the resource-specific action URI may be one pattern that could be replaced by others, at least in some scenarios.

From AI to BI

or the alternative title for this could have been The Killer App for Linked Data. more about the killer app in a minute, first about the not-killer-app, the hope that linked data will converge on a small set on vocabularies, and then become interlinked in the elusive Giant Global Graph.

at the Linked Data on the Web (LDOW 2011) workshop at WWW2011 this march, one of the most interesting discussions was about why there was no wider adoption of some core vocabularies. some people said it was just a problem that the right platform for sharing vocabularies had not yet been found.

however, in their excellent SIGMOD Record article From Semantic Integration to Semantics Management: Case Studies and a Way Forward, arnon rosenthal, len seligman and scott renner make the following empirical observation from their experiences in a large and decentralized environment:

Semantic agreement comes at a cost, and that cost is driven both by the number of people who require a shared understanding, and the number of concepts they must all understand. The cost element appears to be the person-concept. We are aware of many examples of small numbers of participants agreeing on large, complex standards (e.g., meteorology) and of larger numbers of participants agreeing on modest standards (e.g., cursor on target), but we have seen few successes where large numbers of autonomous participants agreed to a large, complex standard. (page 47)

this is just empirical, but it's definitely food for thought: how realistic is it to hope that, even given some better platform to encourage the reuse of vocabularies than there currently is, this is going to happen? is the problem a mere get-vocabularies-to-the-people problem, or one of people-usually-do-not-agree-on-vocabularies? case in point (as usual) is HTML, which is crappy as a publishing vocabulary, but was probably successful because it is easy to understand, easy to use, takes a lot of bending without breaking, and delivers excellent value through the network effect.

now back to the title: from AI to BI? in the discussion following the problem of vocabulary adoption and thus data fragmentation, richard cyganiak, a very well-known linked data researcher from DERI, made a remark that surprised and delighted me. he said that the most linked data value usually is derived by dumping all data in a single triple store, and then working on that. this has been practiced for years now, with all the triple boasting of various linked data groups being a very good indicator, but it seemed to me that in most cases this was supposed to be a temporary fix until full distribution, decentralization, and interconnectedness could be achieved. it was great to hear richard saying that centralized data crunching was basically the main activity when it comes to using linked data.

what used to be called data mining now seems to morph into something a bit wider labeled data science; and what used to be data warehousing now is the exact same thing but called business intelligence (BI) (listen to hal varian explaining how essential all of this already is and will increasingly be). what i am suggesting is that BI is the killer application for linked data and RDF. for this to happen, RDF needs to shed all the semantics/reasoning bulk, something that could be done with the ongoing work around a revised RDF, but, as richard remarks, does not seem to happen (yet). this activity may be an important inflection point in RDF's history: become more powerful and sophisticated and even less accessible to the mainstream and the needs of average data management, or radically simplify and become the foundation for something that's accessible and usable for many people and applications.

imagine average BI providers understanding and applying linked data principles: it would work pretty much exactly the same way the popular linked data cloud is being produced: scrape existing sources based on often not-so-pretty back-end processes, sprinkle the individual parts with a bit of provenance info, dump everything in a triple store, and start SPARQLing away. refine that to be real-time and push-enabled all the way through, and you have the holy grail of BI: real-time BI!

the main beauty of this idea is twofold: first, and maybe most importantly, there is a ton of interest and money in BI. that matters a lot. second: since BI is not globally distributed but centralized, there is no need to worry about the vocabulary problem. make sure you know what RDF you generate from your data, maybe use some simple ontologies (or none at all), and then just use SPARQL on the raw RDF data.

i am wondering if and how much SPARQL as the core part in such a model of BI would need to adapt. maybe have simple datatype support in SPARQL and have a simple datatype vocabulary for RDF (such as XSD) so that the storage and queries could be better optimized for typed queries? is there anything else? and how does all of that sound as a killer app? i think this is much more realistic (both in the sense of this actually works and this might actually succeed) than expecting to be able to semantically query the web.

WoT 2011 Deadline Extended

due to popular demand, we have decided to extend the submission deadline for the Second International Workshop on the Web of Things (WoT 2011). The new dates are shown below in the excerpt from the original Call for Papers for WoT 2011 (which has also been updated).

Important Dates

• Submission deadline: February 11, 2011
• Notification of acceptance: March 11, 2011
• Camera-ready versions of accepted papers: March 21, 2011
• WoT 2011 Workshop: June 12, 2011

we are looking forward to your submissions! please refer to the submission instructions for preparing your submission and submit papers at the WoT 2011 EasyChair submission page (thanks again EasyChair for the great free service!).

WS-REST 2011 Deadline Extended

due to popular demand, we have decided to extend the submission deadline for the Second International Workshop on RESTful Design (WS-REST 2011). The changed dates are shown below in the excerpt from the original Call for Papers for WS-REST 2011 (which has also been updated).

Important Dates

• Submission deadline: January 31 February 10, 2011, 23.59 local time San Francisco, CA (PST)
• Notification of acceptance: February 15 25, 2011
• Camera-ready versions of accepted papers: February 28 March 12, 2011
• WS-REST 2011 Workshop: March 28, 2011

we are looking forward to your submissions! please refer to the submission instructions for preparing your submission and submit papers at the WS-REST 2011 EasyChair submission page (thanks again EasyChair for the great free service!).

Workshop on RESTful Design 2011 (WS-REST 2011): Call for Papers

Second International Workshop on RESTful Design (WS-REST 2011)

In conjunction with the Twentieth International World Wide Web Conference (WWW2011), Hyderabad, India

The Second International Workshop on RESTful Design (WS-REST 2011) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.

Background

Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.

This second edition of WS-REST, co-located with the WWW2011 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:

• Applications of the REST architectural style to novel domains
• Design Patterns and Anti-Patterns for RESTful services
• RESTful service composition
• Inverted REST (REST for push events)
• Integration of Pub/Sub with REST
• Performance and QoS Evaluations of RESTful services
• REST compliant transaction models
• Mashups
• Frameworks and toolkits for RESTful service implementations
• Frameworks and toolkits for RESTful service consumption
• Modeling RESTful services
• Resource Design and Granularity
• Evolution of RESTful services
• Versioning and Extension of REST APIs
• HTTP extensions and replacements
• REST compliant protocols beyond HTTP
• Multi-Protocol REST (REST architectures across protocols)

All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on lessons learned rather than describing an implementation.

Papers must be submitted electronically in PDF format.

Easychair submission page: http://www.easychair.org/conferences/?conf=wsrest2011

Important Dates

• Submission deadline: January 31 February 10, 2011, 23.59 local time San Francisco, CA (PST)
• Notification of acceptance: February 15 25, 2011
• Camera-ready versions of accepted papers: February 28 March 12, 2011
• WS-REST 2011 Workshop: March 28, 2011

Organizers

• Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
• Erik Wilde, School of Information, UC Berkeley, USA
• Rosa Alarcon, Computer Science Department, Pontificia Universidad de Chile, Chile

Program Committee

• Jan Algermissen, Nord Software Consulting, Germany
• Subbu Allamaraju, Yahoo Inc., USA
• Mike Amudsen, USA
• Benjamin Carlyle, Australia
• Stuart Charlton, Elastra, USA
• Duncan Cragg, USA
• Joe Gregorio, Google, USA
• Michael Hausenblas, DERI, Ireland
• Ralph Johnson, University of Illinois, USA
• Rohit Khare, 4K Associates, USA
• Yves Lafon, W3C, USA
• Frank Leymann, University of Stuttgart, Germany
• Ian Robinson, Thoughtworks, UK
• Stefan Tilkov, innoQ, Germany
• Steve Vinoski, Verivue, USA
• Jim Webber, NEO4J
• Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

WS-REST 2011 Web site: http://ws-rest.org/2011/
WS-REST 2011 Twitter: http://twitter.com/wsrest2011
WS-REST 2011 Email: chairs@ws-rest.org

Web of Things 2011 (WoT 2011): Call for Papers

Second International Workshop on the Web of Things (WoT 2011)

In conjunction with the Ninth International Conference on Pervasive Computing (Pervasive 2011), San Francisco, California

Web site: http://www.webofthings.com/wot/2011/

Paper submission deadline: February 4, 2011
Notification of acceptance: March 11, 2011
Camera-ready papers due: March 21, 2011
Workshop Date: June 12, 2011

The world of embedded devices has experienced radical changes; real-world objects such as home appliances, industrial machines and wireless sensor and actuator networks embed powerful computers which often can connect to the Internet. Likewise, more and more common objects are being tagged with RFID tags or barcodes. Considering the recent progress in mobile communications (increased bandwidth for cell phone networks, as well as urban wireless broadband networks), Internet access will very likely become a commodity accessible from most real-world devices. This convergence of physical computing devices (wireless sensor networks, mobile phones, embedded computers, etc.) and the Internet provides new design opportunities and challenges, as digital communication networks will increasingly not only serve virtual data (images, text, etc.), but also serve access to real objects. While the Internet of Things has become a well-known brand for a set of research issues in the pervasive and ubiquitous computing communities, the main focus of this research theme has been on establishing connectivity in a variety of challenging and constrained networking environments. Our hypothesis is that the Web of Things is the next logical step in the ongoing evolution, enabling new applications and providing new opportunities. The Web of Things takes the next step from establishing connectivity and thus the ability to communicate with Things, to a vision where Things become seamlessly integrated into the Web, not just through Web-based user interfaces of specific applications, but by simply blending into the information and interaction space created by the Web and its architectural principles. The Web of Things workshop solicits contributions in the areas of architectures for a Web of things, decentralization, real-time interactions with things, services for the physical world, Web-scale applications, as well as questions of user interface and interaction design, where a Web of Things requires application designers to think beyond standard Web browsers and embrace alternative clients such as mobile devices or even more constrained environments.

• Decentralized Web architectures fostering the Web of Things
• Real-time communication with the real-world
• Deployments, and evaluation of Web of things systems
• Human-things interaction models and paradigms
• Web composition of the physical world and physical mashups
• Searching and discovering things and their services on the Web
• Security, access control, sharing of physical things on the Web
• Applications of the Web of Things (smart homes/cities/factories)
• Business opportunities for the Web of Things
• Use and developments of latest Web technologies for the physical world (e.g., 6lowpan, HTML5, microformats, REST, cloud and services, social networks, etc.)

In this second edition of the workshop (WoT 2010 took place at PerCom 2010) will will consolidate the community and focus even more on the Web aspect of networking things. We will provide an interactive forum for WoT researchers to learn and discuss about existing efforts to enable cross-fertilization. In order to ensure a high-quality technical session, submissions must cover one of the topics above and should not exceed six (6) ACM SIG Proceedings Template pages. Research papers must be original prior unpublished work and not under review elsewhere as they will be published to the ACM digital library and listed on DBLP. All submissions will be peer-reviewed and selected based on their originality, merit, and relevance to the workshop. Submission requires at least one author to present the paper on-site.

Organizers:

• Dominique Guinard, ETH Zurich and SAP Research Zurich
• Erik Wilde, School of Information, UC Berkeley
• Vlad Trifa, ETH Zurich and SAP Research Zurich

Program Committee:

• Friedemann Mattern, ETH Zurich, Switzerland
• Albrecht Schmidt, University of Duisburg Essen, Germany
• Cesare Pautasso, Universita della Svizzera Italiana (USI), Switzerland
• Adam Dunkels, SICS, Sweden
• Vlad Stirbu, NOKIA, Finland
• Gary Gale, Nokia, Germany
• David Resseguie, Oak Ridge National Laboratory, USA
• Marc Langheinrich, Universita della Svizzera Italiana (USI), Switzerland
• Rosa Alarcon, Pontificia Universidad Catolica, Chile
• Tim Kindberg, matter 2 media, UK
• Florian Michahelles, ETH Zurich, Switzerland
• Inaki Vazquez, University of Deusto, Spain
• Gerd Kortuem, Lancaster University, UK
• Dave Raggett, W3C, UK
• Olivier Liechti, University of Applied Sciences of Western Switzerland, Switzerland
• Christian Floerkemeier, Auto-ID Labs, MIT, USA
• Artem Katasonov, VTT Labs, Finland
• Liselott Brunnberg, MIT Mobile Experience Lab, USA
• Guido Moritz, University of Rostock, Germany
• Claro Noda, Universidade do Minho, Portugal
• Masayuki Iwai, University of Toyko, Japan
• Jacques Pasquier, University of Fribourg, Switzerland
• Till Riedel, TecO Karlsruhe Institute of Technology, Germany
• Rodger Lea, University of British Columbia, Canada

Adobe Acrobat Accessibility

visiting http://acrobat.com/ with mobile safari is a special experience, one that very few companies provide to potential customers: the site tells you that you are using an unsupported browser, and urges you to upgrade to a supported browser. which is especially funny on the iPhone, because that essentially asks you to upgrade to a supported phone.

clicking the supported browsers link is interesting, too, because it takes you to a page listing the system requirements for acrobat.com. and of course what they need is not actually acrobat (i.e., PDF) support but flash, because adobe pages — big surprise here — tend to be very flash-centric. given that i only wanted to look up information about acrobat products on the iPhone (where PDF is actually supported), i found it particularly strange to be greeted by such an unwelcoming page.

another facet i really liked about the page is how it sports an accessibility link while at the same time being the prime example of how to not be accessible on the web (zero fallback information about the actual site). adding another nice touch, the accessibility link leads to the same unsupported browser page, so unfortunately accessibility information is only accessible to those blessed with a supported browser (it looks like adobe refuses to deliver its actually HTML-based accessibility page to mobile safari). what's most interesting about this is that adobe aficionados always point out that it is possible to create accessible content with flash or PDF, and in theory this indeed is the case. but if adobe itself does not care enough to actually do it, or maybe tried and was unsuccessful, then this tells us a fair bit about the real-world accessibility potential of those technologies.

REST: From Research to Practice

Call for Chapter Proposals

Editors:

• Cesare Pautasso, University of Lugano, Switzerland
• Erik Wilde, UC Berkeley

Publisher:

• Springer

Book Web Site:

• http://www.ws-rest.org/book/

Introduction

REST has gained popularity not only as an alternative approach to building Web Services, but it also has now become a buzzword that is often used to denote a lightweight and loosely coupled approach to design and implement Service-Oriented Architectures. In this book we are focusing on applying REST beyond public Web applications (e.g., in enterprise environments), and on reusing established and well-understood design patterns when doing so. The goal is to establish a good understanding of what REST is about, and the constraints it focuses on as an architectural style. The reader will be able to understand how RESTful systems can be designed and deployed, and what the results are in terms of benefits and challenges encountered in the process.

Since REST is relatively new as an approach for designing Web Services, the more advanced part of the book collects a number of challenges to some of the assumptions and constraints of REST, and looks at current research work on how REST can be extended and applied to scenarios that often are considered not to be a good match for RESTful architectures.

In summary, the goal of the book is to allow readers to come to a deeper understanding of REST on a practical as well as on an advanced level, and to provide an outlook what research on REST is currently working on. The main aim of the book is thus to serve as a starting point for people looking for a deeper principled understanding of REST, its applications, its limitations, and current research work in the area. It is intended for information and service architects and designers who are interested to learn about REST, how it is applied, and how it is being advanced.

Topics of Interest

We are seeking high quality contributions with chapters on, but not limited to, the following topic areas:

• REST Application Case Studies
• REST Design Patterns
• REST Development Frameworks
• REST Extensions
• REST Research

Submission Procedure

Interested researchers and practitioners are encouraged to submit on or before September 15th, 2010 a 1-2 page chapter proposal clearly explaining the content of the proposed chapter through the easychair on: http://www.easychair.org/conferences/?conf=rest2011

The proposal should contain the following information:

• Title of the Chapter
• Name of the Author(s), Affiliation, Email
• Topic Area Covered by the Chapter
• Abstract
• Outline of the Chapter

Authors of accepted proposals will be notified by September 20th, 2010 about the status of their proposal. Full chapters (up to 20 pages in Springer format) will be due by October 15th, 2010. All submitted chapters will be reviewed for technical correctness and clarity by at least 3 reviewers. Selected contributors may also be requested to serve as reviewers for this book project. Once reviewed, the final chapters have to be delivered by November 15th 2010 in order to ensure that the book can be published in the first quarter of 2011.