dretblog

Good Lists are Hard

being a web plumber, one of pages i visit almost daily is the technical reports (TR) page of the W3C at http://www.w3.org/TR/. when this page was updated last week (as part of the launch of the new W3C site), it was amazing to see how many things you can break at the same time, and it also was an interesting lesson in how simple and smart design can be much more usable and useful than just adding functionality.

the old TR was a good web page in a variety of ways. it was lightweight, had a completely noise-free design, had all the recent updates on top as shortcuts to the complete listings further down, and in short was a well-designed and self-contained representation of the TR work done by the W3C. you could go there, quickly see up the latest additions with your browser clearly highlighting the pages you had not yet visited, and do everything else with the browser's find function. it was one of the pages i always showed to people when explaining why simple and smart is often better than just adding fluff without properly considering usability and utility.

the new TR page managed to break almost everything that was useful, and it does so in a variety of ways. it removed the previously smart quick/complete combined view, it added a lot of visual noise, and it breaks the previously correct usage of the W3C's spec URIs. here is where the new design fails:

• quick view plus complete info. one of the useful things of the old page was the fact that it had a short recent specs section at the beginning, and complete listings further done. it was a very elegant way to both have a quick view of what's new, and a complete view of everything, all available via simple browser-based search. now there are more options, but none of those is as useful as the old view, which is not available anymore.
• useless layout noise. the layout of the old page was simple yet effective, putting as much information in one browser window as possible. the new layout contains a lot of useless layout noise such as horizontal lines between each line, plus a lot of spacing surrounding the text and the lines. it probably doubles the space required per item, while also listing less information. using a table costs even more space without adding any value to the presentation.
• proper URI handling. W3C specs have versioned as well as canonical URIs, and the old TR page linked to the versioned URIs, which is the right thing to do, because the TR page contains a date-based of specs, and not a list of canonical URIs of the latest versions of all specs. the new page links to the canonical URIs, essentially linking to something other than the resource it is actually listing on the TR list. this even breaks basic principles of REST, where the pages users are GETting don't properly link to the resources they are referring to; instead they are referring to a canonical URI that does not represent the actual document that has been published. the very real consequence of this particular breakage is that the browser cannot reliably color the links based on whether the URIs of the particular versions are in the history or not.

in summary, it would be interesting to know whether the new TR has undergone any internal usability and utility testing before being released. it is broken in a variety of ways, which is kind of interesting, but from the perspective of a regular user, it really is sad to see that a page as useful and well-designed as the old TR page is being replaced by a much more noisy and much less useful version. i will certainly miss the old TR, and i guess so will others who were closely following the W3C's TR work.

if you think the old TR was better, please leave a brief +1 comment here, and maybe it will at least come back as a classic view for those who like web pages that are simple and effective.

Web Services for Recovery.gov

together with my colleagues eric kansa and raymond yee, we have just published a new paper about Web Services for Recovery.gov as UCB ISchool Report 2009-035. the main goal of this report is to highlight a side of the open and transparent data debate that is often overlooked. some people look a lot at web site design in terms of HTML/CSS design and usability/accessibility, and other people look a lot at how to make data available, focusing on what essentially boils down to building download portals. our main contribution is to highlight the fact that download-oriented data access is not sufficient to provide timely access to evolving data sources, for two main reasons:

• data is never complete. data is always connected to more data, and download formats often disrupt this connection, making the data decontextualized and making it harder to understand how it is embedded into the world. once data is decontextualized, it can be very hard or almost impossible to contextualize it again, re-establishing all the connections to related data that existed where the data originated.
• data is never static (unless it's purely historical data). downloads not only are decontextualized in terms of connectivity with other data, they also are decontextualized with regard to time. any data source that is frequently updated must have simple ways for synchronizing data, so that more efficient ways of data access than periodical downloads can be established.

starting from our earlier report on how ARRA reporting should use lightweight and web-based technologies, we are again focusing on technologies which are powerful enough to implement dynamic and machine-friendly services, but on the other hand also simple enough so that citizen developers can easily understand and use them. refining our earlier report, we are now focusing on widely established and supported technologies such as XML and feeds. we make concrete recommendations how to build web services for recovery.gov that are both more sophisticated than download approaches, while still being easy to implement both on the provider as well as on the consumer side. here's our report's abstract:

One of the main goals of the Recovery.gov Web site is to provide information about how funds for the American Recovery and Reinvestment Act (ARRA) of 2009 are allocated and spent. In this report, we propose a reporting architecture that would focus on the reporting services rather than the Web site and page design, and that uses these Web services to build the user-facing part of ARRA reporting. Our proposed architecture is based on simple and well-established Web technologies, and the main goal of this architecture is to provide citizens and watchdog groups simple and easy access to machine-readable data. Our architecture uses a more sophisticated framework than simple downloads of data files. Our proposed architecture is based on the principles of Representational State Transfer (REST) and uses established and widely supported Web technologies such as feeds and XML. We argue that such an architecture is easy to design and implement, easy to understand for users, and easy to work with for those who want to access ARRA reporting data in a machine-readable way.

you can find the Web Services for Recovery.gov report in the iSchool's eScholarship repository. any feedback about the report is very welcome, and please make sure to also visit our new Architecting Transparency web site, which has been specifically built to highlight and demonstrate some of the issues described in the report.

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

First International Workshop on the Web of Things (WoT 2010)

In conjunction with the 8th IEEE International Conference on Pervasive Computing and Communications (PerCom 2010), Mannheim, Germany

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

Paper submission deadline: October 18, 2009 November 15, 2009 (Extended)
Notification of acceptance: December 21, 2009
Camera-ready papers due: January 29, 2010
Workshop Date: March 29 or April 2, 2010

The world of embedded devices has experienced radical changes over the past few years as real-world objects can now easily connect to the Internet. This convergence of physical computing devices (wireless sensor networks, mobile phones, embedded computers, etc.) and the Internet provides new design opportunities and challenges. The Internet of Things has mainly focused on establishing connectivity in a variety of challenging and constrained networking environments, and the next logical step in the evolution in pervasive computing builds on top of network connectivity by focusing on the application layer: how to develop ubiquitous computing applications on top of heterogeneous devices? The Web of Things is the vision that brings embedded devices into the Web by using Web standards as application protocol to interact with things. This workshop aims at bringing together the pervasive computing and Web communities to explore the possibilities for using the core principles and technologies of modern Web architecture (e.g., HTTP, REST, Atom, JSON) for seamless integration of things into the Web and developing applications on top of web-enabled devices (physical mashups). Research contributions are solicited in the following areas:

• Web-based interaction patters for embedded devices (streaming, eventing, etc.)
  
• Applications, deployments, and evaluation of Web of things systems
  
• Human-things interaction models and paradigms (mobile interfaces, etc.)
  
• User-oriented, context-aware discovery and dynamic search for the real world
  
• Web composition and macro-programming models (e.g. mashups)
  
• Semantic technologies for description of devices and services
  
• Optimization methods for embedded Web servers and applications
  
• Security, access control, and physical sharing of physical things on the Web

Since this workshop is the first in this area, the goal is to develop a community in this area and provide an interactive forum for researchers to learn and discuss about existing efforts to enable cross-fertilization. Hence, we expect all attendees to read all workshop papers in advance and to prepare questions for each. Presentations shall specifically highlight and address similarities and differences with other accepted papers. This will help to provide a forum to foster future collaboration, beyond the mere presentation of research results. In order to ensure a high-quality technical session, submissions must cover one of the topics above and should not exceed six (6) IEEE conference format pages. Research papers must be original prior unpublished work and not under review elsewhere as they will be published on the IEEE Digital Library. 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 fully register for PerCom 2010 and 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:

• Gregor Broll, DOCOMO Communications, Germany
• Adam Dunkels, SICS, Sweden
• Martin Gaedke, University of Chemnitz, Germany
• Stamatis Karnouskos, SAP Research, Germany
• Gerd Kortuem, University of Lancaster, UK
• Marc Langheinrich, University of Lugano, Switzerland
• Thomas Luckenbach, Fraunhofer Institute FOKUS, Germany
• Friedemann Mattern, ETH Zurich, Switzerland
• Alexandros Marinos, University of Surrey, UK
• Rene Mayrhofer, University of Vienna, Austria
• Tatsuo Nakajima, Waseda University, Japan
• Benedikt Ostermaier, ETH Zurich, Switzerland
• Cesare Pautasso, University of Lugano, Switzerland
• Dave Raggett, W3C, USA
• Michael Smith, W3C, Japan
• Vlad Stirbu, NOKIA, Finland
• Inaki Vazquez, University of Deusto, Spain
• Agnes Voisard, Fraunhofer ISST, Germany

(( Update 10/8: Extended paper submission deadline from 10/18 to 11/15. ))

Distribution and the Semantic Web

RPC and SemWeb have the same implicit goal of hiding distribution that somehow goes against the grain of RESTful loose coupling was an observation i recently voiced on twitter, and that might need a bit of explanation. for now, i'll focus on the semantic web part of that, but it seems to me that this general approach of trying to hide distribution is amazingly similar in both the WS-* world and the semantic web. in both cases, this makes it hard to think of how to get them better aligned with basic web principles. to stay a bit more focused, i will concentrate on RDF for the purpose of this post.

RDF is great at making statements about URI-identified things, because this is what it is all about. build graphs of things that attach, by reference, to anything that can be identified by URI. how to identify RDF triples and graphs themselves is an entirely different issue, though. RDF's abstract model leaves them dangling in the void, and while SPARQL introduces the concept of named graphs (effectively turning triples into quadruples), these names are basically namespace URIs, which means they identify named graphs, but there is no standardized way of how to interact with them (they are never dereferenced). so this means that in a typical RDF store, triples are not identified at all, and even if they are (let's say somebody manages their RDF store in a way which guarantees that every triple is associated with exactly one named graph URI), there is no well-defined interaction with those triples.

this all starts with the basic approach of many semantic web projects: people want to have and use information about things on the web, or they start with the assumption that others have information about things on the web, and then they can harvest that information. this terminology is quite interesting, and if we want to get all metaphorical, then this is what harvesting is all about: you cut stuff, separating it from its roots, and you end up with a lot of useful harvested stuff, but it's sort of dead and you will never be able to reconnect it with where it came from. it may give you useful seeds for new things as well, but again, those things will only be very loosely connected to where they came from.

so, on the semantic web, it's all about getting many RDF triples, dropping them into one big silo (which is why you see all these statements about we have converted such-and-such into x billion triples!), and then working with that silo (maybe providing one tiny hole in that silo through which SPARQL queries can be funneled). this approach makes it easy to abstract from the fact that all the information started out from different sources (and probably still lives there and may be exposed via live services), but it also makes it hard to manage things such as provenance and authenticity (which are critically important for distributed and federated systems). as patrick murray-john pointed out in his comment on my recent post about Data, Models, Metamodels, Cosmologies, RDF's biggest strength is its excellent capability to mix data together. however, this seamless blending of data from different sources gets problematic when you look at REST, which is built around the general idea of coarse-grained interactions with resources identified by URI.

so when you are treating semantic web work as the process of harvesting data, and then using it locally in some form that allows read access only and loses track of the identity and the boundaries of the original data sources, then you're not working with a web of data, but you are just working with data you harvested from the web. this assumes that the harvested data is static, and that any updates to the harvested data will not have to be propagated to where it originally came from. essentially, such an approach treats the web, in an idealized world view, as one huge RDF store, assuming that the process of collecting all the data is taken care of, and that there is no channel of how to interact with the original data sources. and this idealized world view is reflected in many projects around the semantic web, where it is assumed that problems of distribution are taken care of, and can be regarded as solved. as a side note, i think this is why there recently has been such a huge uptake of semantic web work in the government data space, because the government can be conveniently viewed as one homogeneous data source, providing one big collection of RDF data that can be accessed through centralized services. many of the problems of federated data sources, conflicting data, changing data, data authenticity, data integrity, and heterogenous data sources and services can be ignored in such a centralized scenario.

the current work around SPARQL Update does not look all that different. it looks at how to allow the full spectrum of CRUD operations for SPARQL implementations (in the same way as XQuery progressed from a read-only language to one with updates), but it still follows the same approach of looking at RDF data as living in one big silo, and standardizing a language for how to interact with that silo. it's important that such a language exists and i think SPARQL and the Update extension to it are very important specs, but this language has as much to do with the web as SQL or XQuery: not all that much. it's back-end stuff, and for me as a client of a web service, all i want is a way of how i can interact with that service through HTTP so that i can use that service effectively; whether the back-end of that service uses SQL or XQuery or SPARQL or a column store does not really interest me all that much.

so what i am currently doing (collaborating with linked data expert michael hausenblas) is trying to figure out a way how to make SPARQL more REST-friendly, so that SPARQL can be easily used as a back-end to provide RESTful services on the web. i am looking forward to our work of making SPARQL more REST-friendly, but it is interesting to me how that turns into an exercise of ignoring the subject URIs of triples as actionable URIs, and instead using the named graph URIs to give triples an identity on the web, so that they can be exposed in a RESTful way. in such a RESTful SPARQL world, it will be possible to GET a bunch of triples from somewhere, and then to PUT the exact same bunch of triples to a URI that identifies a named graph that needs to be updated. it seems to me that this kind of RESTful approach will make it much easier to expose meaningful resources on the semantic web, and to allow RESTful interactions with them.

WEWST 2009: Call for Papers

4th Workshop on Emerging Web Services Technology (WEWST 2009)

In conjunction with the 2009 European Conference on Web Services (ECOWS 2009)

November 9, 2009, Eindhoven (The Netherlands)

The Workshop on Emerging Web Service Technology (WEWST) is the premier workshop for academic and industrial communities to discuss innovative ideas and research contributions advancing the state-of-the-art in Web service technologies. Although the advantages of Web services to allow businesses to interact with each other while maintaining a loose coupling are well known, there are still many challenges to be solved in this important field of research. The wide variety of tools, techniques, and technological solutions presented in WEWST share one common feature: they suggest new directions for Web service research by introducing new and sometime controversial ideas into the field. The workshop allows participants to gain new insights and to start collaborations by discussing how their own work can be used in related but different areas.

Important Dates

• Paper submission: September 1, 2009
• Acceptance notification: October 4, 2009
• Camera-ready papers: October 18, 2009
• Workshop: November 9, 2009

Topics

The WEWST 2009 program committee seeks original, high quality papers related to emerging aspects of Web services, including but not limited to the following topics.

• Self-organizing SOA
• Dynamic service discovery
• Automated service composition
• Dynamic service binding
• Service evolution
• Coordination and business transactions
• Embedded devices and sensors as services
• Streaming services
• Event-driven architectures
• Middleware for SOA
• SLA enforcement
• Reputation mechanisms
• Technologies for social collaborations and service markets

Format and Proceedings

The workshop features regular papers of max. 8 pages and short papers of max. 4 pages. The workshop proceedings will be published as an ICPS volume by the ACM, available in the ACM digital library. Papers must be prepared according to ACM's ICPS format; the LaTeX and Word template including the ICPS volume details are provided on the WEWST web page.

Submission

Please use the online submission system: http://www.easychair.org/conferences?conf=wewst2009.

Program Chairs

• Walter Binder, University of Lugano, Switzerland
• Erik Wilde, UC Berkeley, USA

Program Committee (to be completed)

• Luciano Baresi, Politecnico di Milano, Italy
• Ciarán Bryce, INRIA Rennes, France
• Christoph Bussler, Merced Systems, USA
• Emanuele Della Valle, CEFRIEL, Italy
• Elisabetta Di Nitto, Politecnico di Milano, Italy
• Peter Dolog, Aalborg University, Denmark
• Schahram Dustdar, Vienna University of Technology, Austria
• Rik Eshuis, Eindhoven University of Technology, The Netherlands
• Boi Faltings, EPFL, Switzerland
• Luis Ferreira Pires, University of Twente, The Netherlands
• Martin Gaedke, Chemnitz University of Technology, Germany
• Daniela Grigori, University of Versailles, France
• Paul Groth, University of Southern California, USA
• Thomas Gschwind, IBM Zurich Research Lab, Switzerland
• Yanbo Han, Chinese Academy of Sciences, China
• Jörg Hoffmann, SAP Research, Germany
• Radu Jurca, Google Inc., Switzerland
• Bernd Krämer, FernUniversität in Hagen, Germany
• Philipp Leitner, Vienna University of Technology, Austria
• David Lowe, University of Technology, Sydney
• Claus Pahl, Dublin City University, Ireland
• Cesare Pautasso, University of Lugano, Switzerland
• Heiko Schuldt, University of Basel, Switzerland
• Niranjan Suri, Institute for Human and Machine Cognition, USA
• Stefan Tai, University of Karlsruhe, Germany
• Alex Villazón, University of Lugano, Switzerland
• Wolfram Wöß, Johannes Kepler University Linz, Austria
• Wolf Zimmermann, University of Halle, Germany

Contact

For more information and inquiries about the workshop, please contact Walter Binder (walter.binder@unisi.ch).

Moving Birthdays Around

a while ago, i noticed that the iPhone contacts app is not smart enough to properly handle birthdays, because it always requires years and thus only supports birthdates (and not birthdays). that was an inconvenience, but at least one that could be worked around by always using some fake year for birthdays with unknown years (and the birthday app i am using on the iPhone even supports handling one specific fake year as an unknown year of birth).

recently, i ran into another problem with the date handling of the contacts apps, and this time it is is more than an inconvenience, because date handling seems to be broken on a conceptual level. what happened is that i switched timezones (traveling from the west coast to europe), and suddenly about half of my birthdays had shifted one day forward. i did not bother to reverse engineer the exact data stored by the contacts app, but this means that apparently, the app stores the timestamp of when you have entered a birthday, and then interprets this timestamp according to the timezone you're currently in. as a result, birthdays are stored as a combination of the date entered by the user, the time when the date has been entered, and either the timezone in effect when it was entered, or no timezone information (in the latter case, it is probably interpreted as a UTC timestamp later on).

all of this means that some of the birthdays i had entered magically shifted to one day later after making the trip (it would have looked even worse when traveling to japan, i guess; almost all birthdays would have shifted). and of course there is no user interface for looking at the time associated with a birthday, which means that it is impossible to figure out which birthdays did shift, and which ones did not. welcome to the wonderful world of iPhone simplicity and usability.

the bad thing about this bug is that it is not reversible (unless the contacts app also stores the information about which timezone you were in when you entered a birthday, which is rather unlikely). the problem is rooted in a misunderstanding of what a birthday is (it is a day or a date, depending on the model, but certainly not a timestamp) and carries this misunderstanding into the app's data model. if you really wanted to be fussy about the exact time of birth, you could extend it into a timestamp, but then you would need to capture the timezone for the place of birth as well, and this would take birthday information to a level of detail probably not interesting for the majority of users. also, very few people think of their birthday as shifting around in the calendar depending on where you were born and where you currently are; it's simply a day and it's that day depending on where you are on your birthday.

after going through the substantial user interface pain of entering about 100 birthdays, i now expect these to jump back or forth one day, depending on the timezone where i entered them, and the timezone i am in. this jumping back and forth will be unpredictable, because i cannot look at the timestamp associated with the birthday entries. for being heralded as a marvel of usability and utility, i have to say this particular detail of the way the iPhone manages contact information is not quite up to what i would expect from software being subjected to use cases (such as people traveling between timezones and expecting birthdays to be stable) and systematic testing based on those use cases.

Recovery.gov Overhaul

Recovery.gov gears up for a makeover, and while the official announcement has not yet been released, this initial announcement looks a bit troubling. In our stimulus feed guidelines, we have made the point that the recovery architecture (here our first reaction, more detailed feedback, and our comments about the updated guidance) has to look at the bigger picture, and not just at the web site.

The main issue with the overhaul is that it seems to focus just on the site, probably in an effort to provide open access to stimulus data. However, if transparency is also a goal of this initiative, then the whole recovery reporting architecture must be designed and implemented in sync. In particular, there must be open and accessible data flows from the reporting entities into the recovery site. The feed approach described in the initial and updated guidance (which as of today is still not enforced, not supported by any tools or tests, and not used by the recovery site itself) would be the best way to ensure open access and transparency. The announcement reads as if recovery.gov will become another silo that is fed by opaque processes, so that it essentially is the very opposite of transparent.

For a truly transparent and forward-thinking architecture, a federal feed cloud would be the best approach. It would provide a hosted infrastructure for agencies to manage and publish their reporting (if they are not hosting their own feeds), provide tools and tests to make sure data is being published according to the guidelines, and would be a completely transparent way of how everybody could access stimulus reporting data. Recovery.gov would just be one site using this data, and others could build their own sites, if they wanted to.

In theory it is possible that the overhaul could be used to create such a transparent reporting architecture. In practice, however, the challenging deadline and the absence of specifically enforcing a feed-centered architecture make it likely that the new site will have the same intransparent data flows as the current site (which is still being fed by reports being emailed to the OMB, not by the few feeds that are actually available).

Our hope is that the overhaul process will clearly and cleanly separate the reporting architecture, which should be feed-based and fully transparent, and the publication of that data on recovery.gov. The new Recovery.gov should not be based on an intransparent submission process, but instead should finally implement the forward-looking feed architecture mandated in the initial and the updated guidance documents.

It is still not too late to design and implement such an architecture, and it could set a very important precedent for how formerly internal and opaque data flows inside of the government become accessible and transparent. Devaney's office [ the Recovery Act Transparency and Accountability Board ] received $84 million in stimulus funds, the majority of which will be used for the site maintenance and redesign. It would be an excellent use of stimulus money to design and implement an architecture that not only realized the immediate goal of providing transparent stimulus reporting, but also served as a demonstration of how openness and transparency can be implemented based on simple and accessible standards, leading the way for other e-government initiatives. Spending the money on implementing a silo with a polished interface would not only miss and important opportunity, it would also ignore the requirements set forth in the forward-looking guidance documents. It will be very interesting to read the full set of requirements for the recovery.gov overhaul when they are published.

Information Engineering

i often refer to myself half-jokingly as a web plumber, because that is what describes many of the things i am thinking about pretty accurately. on the other hand, it does not sound like a respectable thing to do as an academic, and it also has lost a bit of appeal since joe the plumber has tarnished the plumbing profession.

more generally, i am often asking myself what i am interested in in comparison to well-established academic fields with large departments associated with their names, most importantly computer science. it occurred to me that there seem to be two axes to this, one being computer and information, and the other being science and engineering. and since one of my main interests is what i usually refer to as web architecture, let's throw in some web and some architecture for good measure. so what do we end up with?

	Computer	Information	Web
Science	Computer Science	Information Science	Web Science
Engineering	Computer Engineering	Information Engineering	Web Engineering
Architecture	Computer Architecture	Information Architecture	Web Architecture

out of these combinations, computer science (the general field), information science (often associated with the library context), computer engineering (building computer systems), web engineering (building web-facing applications), computer architecture (design considerations for building computer systems), and maybe web architecture (how the web is designed as a system) may have some reasonably well-defined boundaries and are more or less well-established fields. this leaves web science, information engineering, and information architecture as not-so-well-defined fields.

• web science: the recently started Web Science Research Initiative (WSRI) has captured this term, but given it an extremely broad scope (our students half-jokingly nominated the graphical depiction of web science as the worst venn diagram ever). from most discussions i have heard so far, it seems that almost everything is included in the scope of web science, which makes its existence as a well-defined field problematic.
• information engineering: there is little to find about this term. it seems it was used as a name for some very specific method in software engineering, and for little else. i am intrigued by this term, because it is not exclusively focusing on the web, but still focuses on engineering as a term describing constraint-based design.
• information architecture: to me, it appears that this field has many different competing definitions. in many cases, my issues with these definitions is that they primarily focus on the surface of how to define and design information structures and interfaces, and that there is little focus on how this information can be most easily shared, transmitted, or transformed.

from this little survey, it appears that the term information engineering is up for grabs. and i really like it, because it shifts the focus away from the web (which should just be one well-established system for providing and consuming loosely coupled services), and focuses on the central issue of the services we look at: supporting cooperation in information-centric scenarios. i also really like the term engineering, because it is less theoretical than science, and less vague than architecture. for me, the most important facet of engineering is that it always describes design based on constraints, and not in some idealized vacuum.

so from now on i'll try to promote the term information engineering for a number of the things i am doing. it has a reasonably safe distance to anything with computer in it and thus allows to simply view computers as tools for getting information from producers to consumers. the engineering part makes clear that this is done in a way which clearly focuses on constraint-based design considerations and decisions. as a grand plan, i would hope to see information engineering to emerge as a discipline separate from computer science, one which looks at computers and computer networks as tools, focuses on information-centric scenarios, and is mainly concerned with the question of how to design and implement information-centric systems that work well in constrained environments.

Times Reader 2.0

the first version of the New York Times' Times Reader was built on the Windows Presentation Foundation (WPF) and was pretty well-done as a proprietary one-time project; the second version of Times Reader (Times Reader 2.0, ironically lacking any of the features you would expect from 2.0 products after the Web 2.0 term became a buzzword) has now been released. this time it is built on the new latest and greatest proprietary platform you can get your hands on: Adobe Integrated Runtime (AIR). the other option to do the same thing would have been to use Microsoft's Silverlight. there certainly is a pattern to that: NYT seems to believe that the most promising way to develop new and compelling ways of delivering newspaper content is to ignore the web.

given how much newspapers are struggling with economics and how to adjust to the new environment of the web, it is amazing and disheartening to see how little they actually understand about it. the WPF reader was kind of nicely done (as a standalone app) but suffered the fate of many of these apps: it required an install, which the vast majority of people will not do. it also required an initial install of the underlying framework, which for XP users meant installing the insanely bloated .NET 3.0.

on top of that, the installer was badly broken and in fact so badly broken that it was impossible to uninstall and reinstall, which rendered the application useless for many. and NYT simply stopped supporting it, because they probably ran into the problem that they had become software providers with many struggling customers, and handling this would have required substantial resources for a substantial period of time.

instead of learning from that fiasco, NYT now decided to simply switch proprietary platforms and stick with the install required model. now potential readers first have to install AIR, and then they can install the reader. of course this is a possible of doing it, but does this make this any sense? offline reading can be supported in browser-based apps with google gears and, this is the essential part, can be made optional so that people can enable offline mode if they think they will need it. this kind of design is called loose coupling and one of the hallmarks of well-done web architecture. and there is no install and this is actually a pretty important issue.

apart from that, being from Adobe, AIR is huge and resource-hungry, and the freshly installed reader quickly passes the 100mb memory consumption mark right after startup. this might be less insane than having a 100mb twitter client, but generally speaking, the question is: why choose a proprietary and install-only platform? let's look at the product manager perspective:

• choosing a proprietary platform makes the developers happy, because proprietary platforms come with nice (and expensive...) SDKs that allow developers to ignore the messy world of the web; instead they can live in the closed world of their choice.
• choosing a proprietary platform will result in nice and predictable demos, allowing the demo to ignore that the vast majority of users will never get to that point because they will not install either AIR or the reader app.

this is the recurring pattern in many of projects of this kind: product managers have little interest and incentives to switch to web-based solutions, which are less pleasant to design and develop, and don't have the slick visual effects of the proprietary platforms. who would need to step in? probably some CIO-level person, but then again, would they know enough about web and information architecture to understand the fundamental difference between AIR and the web? after all, the companies producing these proprietary platforms have gone to great lengths to capture the term Rich Internet Application (RIA) for them, which technically is correct (no web in there), but leads many people to believe that they are more or less web apps.

strategically speaking, programming yet another silo for content is what newspapers have done for a while now, and it will be interesting to see whether recent and future moves in the e-book market (such as the kindle and the upcoming kindle DX) will eventually make newspapers understand that whatever their future may look like, it most likely is not an electronic equivalent of the printed newspaper. however, the painful experience of reading newspapers on the kindle and the ongoing evidence that content producers still haven't started thinking in horizontals rather than in verticals make it unlikely to see really forward-looking products from NYT and the publishing industry in general.

maybe the ability to run simple micropayments for iPhone content through the app store will change the perspective of some content producers. but instead of seeing the potential for building an app for personalized content from a variety of sources, i am pretty sure we will just see another wave of verticals being developed. the interesting question is: will the newspaper industry's focus on verticals disappear faster that the newspaper industry? the NYT times reader 2.0 looks like an indication that the publishing industry is determined to stick to verticals. let's hope amidst all the layoffs they also hire some people who actually understand the web and web architecture.

REST and RDF Granularity

bob ducharme's recent post about Semantic web technology and humanities research and our recent WWW2009 tutorial talking about the route from SOA to REST (to be repeated in june at ICWE 2009) made me think about the fundamental tension between RDF-based semantic web approaches, and RESTful architectures.

it seems to me that the biggest problem of RESTful RDF is the lack of a well-defined notion of a document. one of the strengths of RDF is that you harvest triples from wherever you find them, take the graph, compute the closure of this graph under whatever schemas or ontologies you might have, and then process the resulting graph. on the semantic level this means you take whatever you can get as data, whatever you can get as reasoning mechanisms, and extend the data using inference. it is this general model of raw data and derived information that makes RDF so powerful.

the price you pay, however, is the loss of provenance and document boundaries. of course this can be overlaid using various mechanisms, but it is not a fundamental part of the RDF model, and it's easy to forget it or get it wrong.

this leads to problems when it comes to the rather document-centric model of REST, which talks about representations that need to be exchanged for enabling interactions. how do you use RDF, when the data you're working with for your application purpose is a mix of retrieved RDF and inferred information?

XML, on the other hand, has a rather static idea of a document. well, that's actually not entirely true, because XSD introduced the concept of the Post-Schema Validation Infoset (PSVI), which in a way is the same mix of source data (the original XML document) and inferred data (validation information, type annotations, and default values). type annotations can be regarded as a bonus that can make data processing much more robust and reliable. ironically, default values, however, are widely frowned upon in XSD best practices, because they tightly bind document processing to document validation, and that is largely perceived to be a Bad Idea.

and this is where it gets interesting: XML's very idea is that of enabling applications to GET XML and blindly process it by simply processing well-formed markup. RDF, on the other hand, is more rooted in the idea that the RDF you find blends into an existing set of other triples and schemas or ontologies. this latter model makes working with RDF more seamless and more convenient in an RDF-only world, because essentially, applications can ignore the fact that data had different origins, and they can work on what sometimes has been referred to as the giant global graph. it seems to me that this replicates the pattern of trying to hide distribution that underlies many of the middleware-inspired approaches to web services in a rather interesting way.

XML, on the other hand, makes it almost impossible to get this seamless view of the world, and requires applications to handle one XML document at a time, often steered by overlaid mechanisms such as XInclude at a very low level, or by following hyperlinks when it comes to RESTful data formats. what this means is that XML and this RESTful picture force you to work on the document level, and this also forces developers to explicitly deal with distribution, which means dealing with failures at the network or representation level.

so it seems as if RDF's virtues, the ability to transcend document boundaries and to seamlessly include data from all kinds of sources, become problematic when moving towards RESTful services, where coarse granularity and well-defined document concepts are an essential part of the architectural style.

this does not imply that RDF cannot be used for RESTful services and document-oriented scenarios; it simply means that XML makes it more natural (or you might say: less avoidable) for developers to deal with strict document boundaries, whereas in RDF, this requires special attention. i am really curious to find out whether somebody already came up with a set of best practices and design guidelines for building RESTful RDF applications, and this becomes particularly interesting when looking at issues such as SPARQL (and its basic model of accessing an RDF triple store through just one URI) and updates of RDF data.

it seems to me that the road towards a RESTful semantic web (if we take the RDF-centric view of that concept) is still not fully clear, and i am really curious to explore in more depth the fundamental tension between REST's things are diverse and distributed and you have to deal with it, and RDF's in the end it's all just triples world views.