dretblog

First International Workshop on RESTful Design (WS-REST 2010): Call for Papers

First International Workshop on RESTful Design (WS-REST 2010)

In conjunction with the Nineteenth International World Wide Web Conference (WWW2010), Raleigh, North Carolina

Web site: http://ws-rest.org/

Paper submission deadline: February 8, 2010, 23.59 Hawaii time
Notification of acceptance: March 1, 2010
Camera-ready papers due: March 14, 2010
Workshop Date: April 26, 2010

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 first edition of WS-REST, co-located with the WWW2010 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. Submit at the WS-REST 2010 EasyChair installation.

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

Program Committee Chairs

• Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
• Erik Wilde, School of Information, UC Berkeley, USA
• Alexandros Marinos, Faculty of Engineering & Physical Sciences, University of Surrey, UK

Program Committee

• Rosa Alarcon, Pontificia Universidad Catolica de Chile
• Subbu Allamaraju, Yahoo Inc., USA
• Tim Bray, Sun Microsystems, USA
• Bill Burke, Red Hat, USA
• Benjamin Carlyle, Australia
• Stuart Charlton, Elastra, USA
• Joe Gregorio, Google, USA
• Michael Hausenblas, DERI, Ireland
• Rohit Khare, 4K Associates, USA
• Frank Leymann, University of Stuttgart, Germany
• Mark Nottingham, Yahoo Inc., Australia
• Aristotle Pagaltzis, Germany
• Ian Robinson, Thoughtworks, USA
• Richard Taylor, UC Irvine, USA
• Stefan Tilkov, innoQ, Germany
• Steve Vinoski, Verivue, USA
• Jim Webber, Thoughtworks, USA
• Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

WS-REST Web site: http://ws-rest.org/
WS-REST Email: chairs@ws-rest.org

Mavic Ksyrium ES Cracked Rim

after a bit more than two years, the rear wheel of my pair of Mavic Ksyrium ES (now sold as Ksyrium SL) wheels has basically completely disintegrated. the back wheel has 10 drive-side spokes, and eight of them looked like the one shown here, with severe cracking in the rim. i am surprised that none of the spokes pulled out, i was probably getting very close to that. i noticed that the back wheel became untrue, and a closer look then revealed that the complete rim was in really bad shape.

the wheel is a bit over two years old and has no more than 5000 miles on it, probably quite a bit less. i am 185lb, and i ride a forgiving carbon frame, and there is no weight limit for these wheels. i specifically bought them because everybody said that for a pair of light-weight wheel, these would be the ones to get in terms of durability. they were $1200 for the wheel-set retail price, which i consider to be expensive enough to also expect good service from a company.

my bike dealer sent the wheel to Mavic and eventually i had a lengthy conversation with the Mavic Man. to me it seemed clear that with the rim cracking almost everywhere, there must be a problem with the aluminum, maybe temperature or material issues during production. however, even though this wheel clearly did not perform as you might expect from a high-end wheel, and was showing clear signs of production problems, the Mavic Man was in no mood to compromise. it was pretty clear that he never even looked at the rim, neither.

so now i am getting a rebuild of the back wheel which replaces everything except the hub, and that costs $350. pretty expensive, but hopefully worth it. it doesn't seem to be the case that many of these wheels are failing the way mine did, so i hope the new one will last longer than the one i had. it's a great wheel to ride as long as it doesn't break. regardless of that, this was the last pair of Mavic wheels i bought (and i have bought a couple of them before, and all of them held up well). if there's enough choice, i try to avoid rewarding bad customer service.

if you also have problems with Mavic rims, please leave a comment, and if you are lucky enough to have Mavic helping you out, please let us know how you did it!

The Linked Data™ Police

this morning i was contacted by the Linked Data™ Police. i found the following email in my inbox, from a pretty well-established researcher at a pretty well-established institution:

I came across this: http://repositories.cdlib.org/ischool/2009-035/

So you consciously redefine term linked data to mean something different. Look, the big point of linked data is that it means you are interoperable with a large number of existing data sources available in the same data model and protocol, like Freebase, DBpedia, Geonames, and so forth. I had to explain to colleagues that no, there is nobody working on providing linked data for recovery.gov, and the guys in Berkeley who claim to be working on it are actually just abusing the term as a buzzword in order to get free attention, but actually have no intention of delivering anything that's interoperable with the linked data standards.

There are perfectly descriptive terms for the technology you are using, REST and ROA.

You do a disservice to yourself. What you do is intellectually dishonest and unnecessarily antagonizes those who have worked hard to establish a set of interoperable practices around RDF on the web.

Please stop this practice.

so instead of just discussing the question of whether Linked Data requires RDF, you now get a cease and desist letter when your work is about publishing data that is linked and you dare to call it Linked Data. i think the letter mostly speaks for itself, but what really scares me is the upside-down attitude expressed by it. instead of looking at the web at something that is good and helpful and should be improved by adding more semantics, and then trying to figure out the most effective way of doing this, given the constraints of the scenario considered, it starts with a set of technologies you have and want to use, and then claim that whatever you want to do, you have to do it using those technologies.

generally, the approach to use generic problem names to refer to specific technologies is something that only helps to confuse a lot of people, and mostly is an attempt to position these technologies in a way which makes competition harder. my favorite examples for bad labels for specific technologies are Linked Data, Semantic Web, Web Services, and XML Schema. if you build technologies, stick to calling them technologies, don't start calling them solutions. a solution is a technology that is applied to a given problem within the limits given by the problem scenario's constraints, and no technology can predict the problem.

oh, and, just for the record: if you look at the approach we're taking beyond just checking of whether we propose to use RDF directly, RDF is just a stylesheet away. publish your data in a RESTful way that's accessible to all feed users and readers out there, and then writing some GRDDL that will fill a triple store becomes trivial. which kind of demonstrates the point that RDF is just an implementation issue, it should not be the litmus test of whether you follow the True Path Of Linked Data. and the report quoted above actually explicitly explains exactly what we do, and how it compares to the narrower definition of Linked Data:

Recently, the idea of openly accessible data has been promoted under the term of linked data, with recent recommendations being centered around a very specific choice of technologies and data models (all centered around Semantic Web approaches focusing on RDF for data representation and centralized data storage). While it is possible to use these approaches for building Web applications, our recommendation is to use better established and more widely supported technologies, thereby lowering the barrier-to-entry and choosing a simpler toolset for achieving the same goals as with the more sophisticated technologies envisioned for the Semantic Web. For the remainder of this report, we use the term linked data as the general concept of publishing interlinked data representations, without referring to the one specific way of implementing it that is often associated with that term as well.

i think this is about as clear as you can get. and i think a pretty large set of substantial  problems have yet to be tackled in the RDF approach to linked data; identity, provenance, dynamic services, granularity, and updates come to mind. so rather than arguing about who is entitled to call linked data Linked Data™, it might be more interesting and enlightening to compare different approaches as solutions for specific problems, and see how well they work.

Information Engineering Elevator Pitch

the more i think about Information Engineering as a potential label for what we are doing at the School of Information, the more i like it. one of the exercises we occasionally engage in is the development of elevator pitches, trying to explain what the heck it is that we do at the School of Information. this problem of defining who we are and what we do is probably one that is shared be a few other young disciplines, but generally not so much by older and established disciplines. branding itself as a School of Information also does not help that much, the name is so vague that it explains little, and excludes few things.

here is my attempt at creating an elevator pitch for our program, based on the assumption that what we do is centered around the two basic foundations of Information of our object of study, and Engineering as the method of how we approach it, using analytic and constructive skills to improve the ways in which information is being understood and used.

Information Engineering is concerned with the study of phenomena, technologies, and tools in information-intensive settings. Looking at information from a variety of perspectives such as society, culture, technology, law and policy, and economics, it enables people to analyze, design and build in these settings, always starting from a thorough understanding of the options and constraints that are created by all of these perspectives. The specific value created by that approach lies in the scope that goes beyond any of the individual perspectives, which allows people to more completely understand the context in which they analyze, design and build.

well, that may be a little more than an elevator pitch, or one for a really long elevator ride. on the other hand, since South Hall happens to have the slowest elevator in the known universe, this might still qualify for an elevator pitch.

Comparing SMS URIs

it was a bit early to declare that the SMS URI scheme was finished. another iteration was required, this time an update to version draft-wilde-sms-uri-20. the main reason was that the draft did not contain any information on how to compare SMS URIs. Section 2.4 now explains how to compare SMS URIs (mostly based on the definition of how to compare to tel: URIs), and (once again...) hopefully that was the last change required before the draft can be published as an RFC.

this is a really long process, but on the other hand it is really good to see that people care enough about this to take a close look and comment on the draft. thanks for all the comments!