By 'original authors' I mean people who have initially built the web site(s) hosting the resources. For example, if I build a web site dedicated to voting on the best sites available on the web, I may initially 'seed' that site by offering some of my best picks. These best picks would be offered as URLs to the original sites that I am offering as candidates to being voted on.
After the initial launch of my 'best of the best' web site, others may join and may start contributing by adding their picks. All these additional URLs will then be user-contributed resources.
In general, as the so-called participatory web keeps gaining momentum, we will start seeing more and more resources being user-contributed. In the early days of the web, most, if not all published resources, have been contributed by the original authors, or creators of the web sites. Today, we see increasing quantity of resources published on the web that are user-contributed (or, sometimes called member-contributed).
Let's examine now how do users, or members, contribute resources. Typically, there are two ways that resources get published on the web:
1. By filling out a form and successfully submitting it
2. By uploading some digitized information
Whichever the case may be, it is interesting to examine the nature of the content that is being published. For the most part, one would expect that the content is pure text. Sometimes, the content is binary, meaning a sound clip or a jpeg file (representing a photo) or a video clip.
Because the web is basically text-driven, we will now turn our attention to the text-based content. At this point, the question becomes: what is this text-based content supposed to represent?
By and large I'm sure we'll all agree that the text-based content is related to the ongoing conversation on the web. But that's not the whole story. The web as the medium isn't suitable only for enticing and recording various conversations. The web can also enable acting upon the ongoing conversations.
In order to understand in what ways can the web enable this acting upon, let's first refresh our memory on what the resources on the web are:
- Resources are abstractions, or entities, published on the web
- Resources know how to represent themselves upon request
- Resources know how to make a transition from one state to another, upon request
When a request reaches a resource on the web (routed via that resource's Uniform Resource Identifier, or URI), that event triggers a response. To provide a response is the responsibility of the resource. And, from the perspective of the consumer who had initially requested the response, it is anyone's guess what form will that response take.
It is customary to expect the resource to respond to the request by sending back a response containing the representation of that resource. Of course, a single resource can represent itself in more than one way. Often times, the mode of representation will depend on the context of the receiving request. If the request is, for example, coming from a human user, the response will most likely be in the form of a hypertext markup, which can be rendered in the user's browser. If, on the other hand, the request is coming from a machine, the response will quite likely be rendered as an XML document (although other machine-readable formats, such as YML or JSON are possible). These are merely the most generic scenarios, and there are of course different circumstances, where the resource may represent itself in a binary format, such as a PDF document, or a JPEG image, or an MP3 audio file, or even as a movie clip and so on.
Another interesting thing that deserves further examination is where is this response going to be coming from? It is almost always blindly assumed that if the request gets sent to the resource that is published in a specific domain (such as bestofthebestsites.com, for example), the response will arrive from that same domain, or URL.
However, there is nothing in the web architecture that may enforce that convention. Let me illustrate this point by providing a specific example: if someone sends a request asking for the number one best web site ever to the bestofthebestsites.com domain, that request may travel to hypothetical URL such as bestofthebestsites.com/top_site. Upon receiving this request, the top_site resource will respond by preparing its representation which will be shipped to the consumer. But in addition to that, another, more elaborate and more involved representation could be readied and sent over to some other resource, which may live in a completely different domain. From there, the original requestor may be notified by receiving yet another representation. There really are no limitations to chaining events in such fashion.
At this point, this discussion deserves a more elaborate illustration. Suppose we launch a web site that allows users to publish their own resources, such as hand-made merchandise that they put up for sale. The resource will typically be published by asking users to log in, fill out the form representing the resource, and then submitting that form. If the submitted form gets properly validated, the resource will be published on our site.
Let us now examine what could one possible representation of the resource 'merchandise' be. This resource may have a name, or a title, a description, a date when it was created, a date when it was offered for sale (i.e. published on our web site). In addition, it must have asking price (if it's for sale). It may also be offered for bidding between potential buyers, meaning that the merchandise will have an expiry date, after which it gets sold to the highest bidder.
And of course, that resource may also have a pictorial representation, such as one or more JPEG images, or video clips etc.
After filling out the form specifying many or all of the above properties of the resource, the form will be validated and, if correct, the item will get published on the site. At that point, all the information (i.e. content) will get stored on the hosting site, and the state of that resource will be persisted.
From that moment on, this resource will live in its own address (e.g. http://merchandisehost.com/items/123546). Any request arriving to this address will elicit a response from that resource. And, as we've already discussed above, the shape and form of the response will depend on the circumstances -- meaning, is the request coming from a human user or from a machine, and furthermore, are there any other constraints that could govern the specifics of that response?
So in this simplified hypothetical example, the entire interaction between the resource and its consumer is based on the assumption that the resource only knows how to represent itself by shipping the response from the http://merchandisehost.com domain.
The above constraint, however, is largely simplistic and overtly naive. It is presupposing that the resource on the web is only defined by its static content. But a web resource is not limited to only having static properties, such as textual or visual representation. In addition to having state, web resources also exhibit behavior.
The above statement may seem superfluous in the light of our previous understanding that web resources already know how to behave, by knowing how to represent themselves upon request and by knowing how to make a transition from one state to another, also upon request. But the kind of behavior specific to the web resources that hasn't been discussed yet is the user-contributed behavior. That aspect of the web resources could be the most interesting, and yet the least explored opportunity that the web has to offer.
Time for another illustration: let's say I create a series of prints and offer them for sale on http://merchandizehost.com. I supply the title of the print series, the number of available prints for sale, the item price and the photo illustrating the print. Nothing unusual so far; but suppose now the merchandize host allows me to specify what I would like to happen each time someone buys one of my prints. Even that is not unusual, as many websites today allow people to click on a checkbox saying "Send me an email or SMS when someone buys this". But that's not what I'm talking about here; I'm asking you to imagine a host which will allow us to specify the URL which will receive HTTP POST request on event, such as sales purchase.
Now what could that URL be? Why, it could be anything. It is user-contributed. And once the HTTP POST arrives at that URL, it is anyone's guess what happens next. The user who had contributed that URL is now in the driver's seat. Upon receiving the HTTP POST request, that user's code could post a Twitter update containing the tiny URL representing the item just sold. Furthermore, that same code could further elaborate by sending a request to the author's supplier requesting replenishment for the sold item. And so on, the sky is the limit.
The event when someone had purchased an item on the http://merchandizehost.com site can thus easily mushroom into all kinds of user-defined events that could continue percolating throughout the web. The user who had created the resource may then get notified about the purchase from his/her Twitter feed, or from any other source of alerts they care to set up. Also, the customer who had purchased that item may get confirmation not only from the original web site, but also from some other sources, driven by the author-contributed behavior enhancements.
We see from the above hypothetical scenario that user-contributed resources enhance and embellish not only the content on the web, but also the behavior on the web. Resources on the web put end-users in the driver's seat. Thanks to the radically distributed, fully democratized end-to-end nature of the world wide web, humans have finally achieved the ultimate freedom to fully control what happens to the resources, as they create them.
No comments:
Post a Comment