Content network
This page describes a content network of creators, repositories, and services, identifying core components needed to facilitate exchange of knowledge and the forming of new persistent connections over time within the network.
The basic elements of the network include resources, collections, activities, and services. Goals of the network include
- providing access to raw data and creative works
- providing communication and publishing tools
- allowing creators to build and share their own views and services (on top of the network. )
Terms
- Resource
- - a single element that does not provide ready access to smaller components: a file, annotation, link or other datum. This could be a single bit, a zero-length file, a disk image, or a long flash movie.
- Collection
- - a set of resources and other collections with any level of interactivity, from a directory of files to an interactive database, offering direct access to its components. For example, a browsable world atlas from 2005 [Atl2005], or a UNEP geodatabase of water pollution levels from 2002 [WPGeo-UNEP2002], or a friend's slideshow from Paris [SliP].
- Activity
- - a set of tools and interfaces that can create new resources and/or share them. usually separates data from interface and allows importing and exporting data serts. For instance a map-editor [MapEd], a geodatabase editor [GeoDBEd], or a slideshow creator/publisher [SlideShower]
- Service
- - an interface or tool that can be made available to other activities on a local system, and published to other people on the network, which will take in input and.
Example services
Repository caching
A use case in prose (moved from content repositories, originally added w/out signature):
The head page for a curriculum or cohesive set of content is just an HTML page. It can have any text interspersed in it. The document should have a tag in the header: <link rel="olpc.content_bundle" href="sitemap.xml">.
The sitemap is a Google Sitemap XML file, a simple enumeration of a set of URLs. Unlike Google's restrictions, the URLs do not have to live "on" the site where the sitemap is located -- they may cross domains. Embedded content (like images) do not have to be enumerated, but any linked content should be enumerated (for instance, if you link to a movie file from one of the documents).
Note that this head document can be constructed by anyone, and need not be hosted where the original material is located. Multiple head documents can refer to the same content, representing multiple versions of the curriculum, different target audiences, etc.
A document may contain multiple <link> tags, representing an aggregation of curricula. For instance, a teacher version of a curriculum would include the student version (the sitemap from that version) plus another sitemap enumerating all the documents intended just for the teacher.
The head page represents the collection. It may contain any text, and no special restrictions or interpretation is made of that text. The browser will detect this link tag, and when the student visits the page will offer to pre-fetch the entirety of the content. The pre-fetched content will appear to be at the same URL as it was originally, but will be served from the local cache. Additionally the school server may use this to cache data.
The student may manage their pre-fetched content, which takes up local space and may need to be purged. The head page and the head page's title represents the content in these situations.
The content may link to other documents not enumerated in the sitemap. These may not be available, since they have not been prefetched. At that time the browser should offer to fetch the content when the laptop is able to find that content, and optionally notify the student of the availability of the content. The laptop may seek that content on other nearby laptops, the school server, or the wider internet. The content will be pre-fetched at that time. An option may be provided to do deeper pre-fetching (e.g., fetching down one line, or down two links into the content).
