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%.

PATCHing AtomPub

the Atom Publishing Protocol (AtomPub) predates HTTP PATCH, and therefore there is no way how it could explicitly allow updates to be made via HTTP PATCH instead of PUT. but instead of allowing any update method, both the edit and the edit-media link relation type hardcode the fact that updates are made by using PUT. this means that conforming implementations have to support PUT (and maybe they can support PATCH; supporting other methods is neither explicitly allowed nor disallowed by the spec).

one of the advantages of PATCH is that updates can use any kind of diff format that is deemed appropriate for the application, and thus (in case or larger resources, for examples) it may be desirable to use the general patterns established by AtomPub, but to allow updates by PATCH, maybe in addition to PUT, or as the only allowed method for updates. but what would it take to PATCH-enable AtomPub? there are (at least) three possible answers, and i am curious to see whether there is some community consensus for the best one.

1. do nothing: maybe the interpretation that updates must be made by using PUT is overly narrow and the fact that neither edit nor edit-media mention the required method allows us to stretch the interpretation of AtomPub a little and assume it is ok to also or only allow PATCH? (i guess my quotation marks make it clear that i don't think this would be the proper way to do it.)
2. add new links: it would be possible to define patch and patch-media link relations, which would be explicitly defined to use be used with PATCH. it would be a bit unfortunate to have two links instead of just having one edit link that could be used with OPTIONS to learn about the available methods, but one could argue that the fault lies with AtomPub's hardcoded PUT, and thus this has to be done to not mess with AtomPub semantics.
3. create an AtomPub profile: another approach would be to allow OPTIONS on edit and edit-media and thus allow clients to explore the available methods. this could be signaled by a profile link in the feed or entry, and clients supporting that profile would know that they could use OPTIONS. clients not knowing this profile would simply have to deal with the fact that some edit/edit-media links might return 405 (Method Not Allowed) errors, but REST clients should be able to deal with this kind of failure scenario anyway.

any opinions or comments about these three options are highly welcome, and in particular any pointers to implementations that use AtomPub and already support PATCH. if there is some community consensus, it would be interesting to see whether it would be strong enough to move forward with option 2 or 3 and turn it into a formal spec (and if everybody is fine with option 1, then no action is required anyway).

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.

Resource Profiles

one of the not-so-well-known features of HTML is the ability to specify a profile attribute for a web page. it goes right in the head element like this: <head profile=" some URI ">. here is what the HTML spec says about this attribute:

This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.

The profile attribute of the HEAD specifies the location of a meta data profile. The value of the profile attribute is a URI. User agents may use this URI in two ways:

• As a globally unique name. User agents may be able to recognize the name (without actually retrieving the profile) and perform some activity based on known conventions for that profile. For instance, search engines could provide an interface for searching through catalogs of HTML documents, where these documents all use the same profile for representing catalog entries.
• As a link. User agents may dereference the URI and perform some activity based on the actual definitions within the profile (e.g., authorize the usage of the profile within the current HTML document). This specification does not define formats for profiles.

the HTML profile attribute is defined so that it may contain white-space separated URIs, each of them identifying one profile. this is a bit unconventional, but the overall design goal is clear and reasonable: why restrict a web page to only conform to one profile? in practice, though, the profile attribute is hardly ever used, and if people know of any deployments where it is actually being used by clients, please make sure to point to this in a comment!

in our work on RESTful services, we have repeatedly run into the situation where we want to have a runtime mechanism how a resource can represent the fact that it follows additional constraints and/or rules. creating media types at runtime is not such a great idea, and it would also not allow us to represent the fact that a resource is still using a representation based on some media type, but also can be treated according to additional constraints and/or rules. a profile mechanism would be a good way of doing this, and thus we would like it to become a recognized link relation type.

seeing that profiles are a good idea, but should not be restricted to HTML and thus be represented in a more generic way, microformats.org published a proposal for a profile relation type a while ago. this is a good initiative, but there are two downsides to the current microformat proposal:

• it is not intended to register the profile link relation type in the IANA link relation type registry as defined by RFC5988. it would be useful to have this link relation type standardized at the web level.
• the proposal makes assumptions about the linked resources and the processing model for them. instead, it should be left to media types (the ones using/supporting profiles and possibly profile media types themselves) to makes these assumptions, so that the link relation is decoupled from media type specifics.

this means that it might be a good idea to push forward with an I-D proposal to standardize a profile link relation type. This relation type would state that such a link serves as an identifier that a resource representation follows additional constraints or rules, so that clients processing it could take those into account. whether the link is dereferencable at all and if so, what kind of resource it would point to, would be left open. this blog post is soliciting feedback about this idea, and any yes, this would be a good idea, please make it happen! or no, this is a bad idea and here is why comment is welcome. depending on the feedback, i'll continue with my work to publish an initial draft, which should be out in the next week or two.

[[ update 2012-04-15: there now is a draft out, draft-wilde-profile-link is available through the IETF site (and the IETF datatracker), and as of today has been updated to version 01. ]]

Atom Content Negotiation

media types are an important part of web architecture, and they even have (some) structure; the very obvious type/subtype syntax, and the maybe not as obvious "+" convention in types such as application/atom+xml. however, while that allows you to expose the fact that something is Atom and that Atom is based on XML, it does not allow you to talk about what the published entries are.

let's assume you have a collection of items that is exposed via feeds and managed in whatever back-end storage works well for you. you want to be a good web citizen and publish it as HTML, XML, JSON, and RDF. you also want to be a good web service citizen and publish any updates via feeds, so that consumers are notified whenever the collection changes. what is the best web pattern to do that? currently, there are two main approaches:

• publish different feeds. in this case, each content type is published in a different feed. one problem is that these feeds are not interlinked, so it is not possible to switch feeds easily. another problem is that there is no way how to advertise these feeds in a way that marks them as being content type variants of the same content.
• link content variants. in our suggestions for Web Services for Recovery.gov, we had just one feed that would embed reports in HTML, and an XML version would be linked in each entry as an alternate version. this clearly makes HTML primary and XML secondary, and if all you're interested in is XML, it forces you to GET all HTML, only to ignore it and then GET the XML.

both approaches have advantages and disadvantages, and both are not very pretty. in addition, when adding more advanced feed-based services such as updates and push, well-defined handling of content types across the whole landscape becomes more important.

i am wondering what the more popular approach is, and why. i am also wondering whether it might be worth the effort to have a small extension that would make this more reliable in the sense that there would be a link relation for interlinking feeds that carry the same content, but using different content types. it could be as simple as having such a link on the feed level:

<link rel="alternate-content" href="..." content-type="application/xml"/>

is that something that would be worth doing? it could become more sophisticated (and complicated) by allowing other feed parameters to be negotiated, such as feed formats (here's an RSS version of me), feed variants (here is the feed with breaking news only, here's the feed with abstracts only), and probably a variety of other things. currently, i would be tempted to do the simple version only, but i am really curious to find out in which cases these problems already have been solved, in which way they have been solved, and whether standardizing this might provide some value.

[[ a pointer to this entry has been posted to the atom-syntax mailing list. ]]

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

Web Linking

one of the main components of REST is linking (modeling applications as hypermedia, i.e. interconnected resources), and more specifically, typed linking, where a link not only specifies where it links to (in web-oriented systems this is always done using URIs), but what it links to, so that clients can choose which links to follow. in many cases, these link types are application-specific, but there also are link types which are fairly universal, and which should be reused across applications instead of being reinvented many times.

so far, link relation types were defined within the confines of applications and/or representations; both HTML and Atom/AtomPub, for example, define their own link relation types, and those are only expected to be used for these specific representation types.

the recently published RFC 5988 (Web Linking) specifies relation types for web links more generally, and defines a registry for them. it also defines the use of such links in HTTP headers using the Link header field. this means that from now on, links for RESTful application do not (necessarily) have to be embedded in representations anymore. instead, if they pertain to the requested resource, they can be communicated in a Link header field, which is specifically mentioned to be semantically equivalent to HTML's <link> element and Atom's feed-level <link> element.

the immediate advantage of this approach is that links can now be used for resources where the representation does not define a place to put them, and that resources do not have to be parsed to find links connecting them to other resources. in fact, by using HEAD requests, resources do not even have to be retrieved to find the links that link them to other resources, which means that Link-aware clients can traverse RESTful services in a much more efficient way, as long as all they need are resource-level links.

adding to my REST Programming Toolbox Requirements, i would thus expect a good REST programming toolbox to start supporting the Link header field, and to allow applications to more or less ignore the fact whether a link has been found in resource, or in a Link header field. ideally, a toolbox might even be smart enough to optimize requests, so that HEAD requests are used whenever only resource-level links are required in cases where the server supports the Link header field. this, however, requires knowledge of whether the server will reliably serialize all links as Link header fields, and this is not something that can be determined automatically; a programmer would have to configure that.

in addition to the initial link types defined by RFC 5988, RFCs 5829 (Link Relation Types for Simple Version Navigation between Web Resources) and 5989 (A SIP Event Package for Subscribing to Changes to an HTTP Resource) have added values to the registry so far, and over time the registry should grow as a place where RESTful applications can look up, reuse, and add link relation types for hypermedia-driven applications.

since RFC 5988 extends the way in which link types should be handled in Atom and can be exposed by HTTP servers publishing Atom, i have restructured the Atom Landscape Overview to start listing any RFCs (or drafts) that might add link relation types to the link relation type registry. as usual, any feedback to further improve the overview is greatly appreciated.

Feed Theory and Facebook Reality

my original plan was to write a post about how to circumvent facebook's absurd limitation that users are only allowed to import exactly one feed into their accounts. this limitation is obviously fueled by facebook's desire to pull people into the platform instead of using the platform as a hub. my goal was to show how easy it is to engineer around this limitation because feeds are standardized and thus can be mixed and mashed.

after going through the steps of creating a feed from a variety of other feeds, facebook then rejected the feed claiming it was not actually a valid feed (which it was). but after some experiments with various settings and ways of nudging facebook into accepting the feed, they finally accepted it, which means that if the instructions here are not working the first time, try a couple of times and maybe then it works...

let's assume you have a variety of feeds you want to channel into facebook. in my case it's the blog you are currently reading and my flickr photostream. both sources have feeds (blog feed and flickr feed), so the question is how to combine those (and maybe more) into one feed that then can be fed into facebook.

as usual, the 900lb gorilla of the web has something for us: google reader. the process of combining feeds is not entirely obvious, but it is fairly easy. subscribe to the feeds you want to combine (no need to worry whether they are Atom or RSS feeds, google reader handles them equally well). then, in feed settings, add the ones you want to combine into one folder. when you're done with adding all the feeds you want to combine into one folder, go to manage subscriptions and folders and tags and make that folder public. that's it. now go to view public page of that folder and on that page you will find a link to the feed for that folder. this is the feed you have to import into facebook.

all of this, of course, makes all the data you're handling here entirely public, but it very likely has been public in the first place because it has been published in feeds somewhere. but feeding it into google makes it even more public, and you might want to think about this for a minute.

the final challenge is to find the place where to import that feed into facebook, and the most important thing to keep in mind is that in facebook lingo, feeds are notes. also, facebook will make it excruciatingly hard for people to find the link to the original post (it is possible to find it, but it is very well hidden), but at least now all of the feed goodness originating somewhere else can flow into facebook.

Media Types and Resource Types

one of the central points of REST is that it is resource-centric, and that learning about new resources should be done by following hyperlinks found in previous resources. how to discover these links of course depends on the types of resources a client is dealing with, which means that the ability to understand resources plays a central role in REST.

what we've recently been running up against is the fact that understanding actually happens on multiple levels, and based on these levels, more or less sophisticated ways to use a service are possible. some examples:

• site navigation links on web sites often would allow very sophisticated understanding of the major resources the site provides, but since HTML has no good way of exposing that information, it is not possible to extract the full richness of the links contained in the typical navigation menu. the best case in this scenario would be to have something akin to sitemap in machine-readable sitemap format, but there is no such thing.
• for specific types of pages (let's consider product pages on some major online retailer) it would be possible to get more specific links regarding a product if the layout (i.e., the type of the page) would be taken into account. this of course breaks as soon as the layout is changed, but given that only few web sites are carefully managing their @class and @id, this at least works well as long as the layout remains stable withing these limits. in this case, the layout of the page provides important semantic hints.
• looking at machine-readable formats, it is interesting to look at Atom. because it is based on XML, it could be served as application/xml, but because it is well-known, it should better be served as application/atom+xml, so that clients understand it's Atom and not just XML, and so that clients can specifically request Atom. however, if it contains additional information such as GeoRSS or feed paging, this cannot be signaled by the media type, but instead it needs to be found out by inspection on the client side. and since there is no media type for these formats, there is no RESTful way to request a GeoRSS or a paged feed.

all of this means that while the theory of only looking at media types and requesting media types looks well in theory, in practice (in particular when embedding something into an existing set of resources and media types instead of starting from scratch) it often is necessary to make assumptions about resource types based on media types and additional hints. these additional hints can be resource inspection, or they can be URI pattern matching. in particular the latter makes many REST folks see red, but i am really wondering whether this isn't something to consider as well when working with existing services or simply describing them as good as possible.

in the end, we want to build an application that starts with a URI, interacts with the URI through a given protocol, processes the resource received as a result of that interaction, continues by discovering links in that resource, chooses the appropriate link type and link instance for the next interaction, and eventually continues this cycle. if the problem of better understanding a resource's semantics can be improved by inspecting the resource itself or its URI, while the primary method of designing interactions still is based on finding links and following them, then things still should be pretty RESTful, even though not in the most ideal way imaginable.

i guess the main issue here is when to promote a pattern or a property of a class of resources to mediatypeness. if some class of resources exposed by a service has useful links in them, and they are not exposed as a specific media type, then there has to be additional information that can be used to identify a resource as a member of that class, so that you can build richer interactions with it. why this may stray from the purist path of REST, for our purpose of describing RESTful services (or almost RESTful services), this is the way that seems to make most sense, pragmatically speaking.

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. ))