Network-external and network-internal

I have just written the following for other purposes:

The library community is engaged in a difficult transition: from a network-external organization to a network-internal organization. In the former case, the library makes some services available on the network, but the network remains external to how it organizes itself; in the latter, its service and technical organization is network-oriented, making the network central to how services are constructed and delivered. In practices this means constructing services from components and adapting to the network behaviors of its users. This has major impacts on how it engineers and delivers it services.

This organizational distinction corresponds to a service distinction I make elsewhere between off-web and on-web.
To be off-web is to be in a silo hidden behind a user interface. To be on-web has two levels. From a human user perspective, increasingly it means to be available for indexing in the search engines. It also means though being available in lightweight, web 2.0, intrastructural ways. RSS, RESTful web services: these are on-web in that they are easily woven into user experiences by lightweight applications.

One thought on “Network-external and network-internal”

  1. I think this is one of the core points I was trying to make in the keynote presentation I did, last week at Olybris, and which you have cited (thank you). Maybe I took the reasoning a step further, suggesting that it is essential that repository content is being made available through web service interfaces in order to facilitate the creation of end-user services. By which I mean that repositories do not necessarily need to provide end-user services themselves. The reason being that such end-user services typically present a rather limited world view, and that new value for a lot of content emerges when it is being used alongside other content (in unanticipated ways). Hence it is essential that repositories have machine interfaces that allow robots to come in to collect materials so that cross-repository value chains around those materials can emerge. Eventually, there will be user interfaces, somewhere. But those user interfaces do not necessarily sit on top of each repository. It is basically the OAI-PMH data-provider/service-provider model, but taken to the level of the real stuff, not just the metadata. In which context the paper “Resource Harvesting within the OAI-PMH Framework” is rather relevant.

Comments are closed.