Content repositories: Difference between revisions
Ian Bicking (talk | contribs) (Added a read-only use case) |
Ian Bicking (talk | contribs) (added some implementation thoughts) |
||
Line 75: | Line 75: | ||
* Some strategy should be available to browse the non-core content that is not pre-fetched. If a student is interested in this content while they are not connected, there should be some way that they can revisit the content later when it is available. |
* Some strategy should be available to browse the non-core content that is not pre-fetched. If a student is interested in this content while they are not connected, there should be some way that they can revisit the content later when it is available. |
||
== Proposed Implementation for Browsing == |
|||
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: <tt><link rel="olpc.content_bundle" href="sitemap.xml">.</tt> |
|||
The sitemap is a [href="https://www.google.com/webmasters/tools/docs/en/protocol.html 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 <tt><link></tt> 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). |
|||
[[Category:Developers]] |
[[Category:Developers]] |
Revision as of 21:52, 11 January 2007
Philosophy |
Creating Content |
Curating Content |
Educational ideas |
Activity ideas |
Software ideas |
Hardware ideas |
Help Translating |
Library |
Content network |
Repositories |
Collections |
modify |
By distributing laptops and school servers with learning materials on them, and a global index of content that can be used with no modification on the laptops, OLPC is developing a network of digital libraries in a number of languages.
We are gathering a list of those materials. To add to this any materials you know of which would be free for laptop users to access, see content ideas. For more information on sharing your content if you are a publisher, author or collection holder, see Sharing your content with OLPC.
Subsets of large archives
There are some large archives available for inclusion in the content repository. Flickr and Wikimedia Commons; Project Gutenberg and Google Scholar; Wikipedia; WiktionaryZ / OmegaWiki and Dicologos; the Humanity Development Library and like collections; the list goes on.
There are tools being developed for identifying and culling subsets of large repositories. Small subsets will be needed for pre-installation of the choicest content on the laptops themselves. Larger subsets will still need curating to pick out material suitable for the laptop's audiences; classification and categorization; and checks to avoid unbalance or repetition. All content (aside from images and media that are naturally alingual) will need some processing to make localization easier.
Use cases
Conceptually, a content repository could be used in a variety of ways: to publish and share new material, to collaborate on material development over time (synchronizing online and offline contributions to a shared document or project), to search for and download material, to distribute and cache from large collections that can't be contained on one machine or at one school.
Extended use case #1
A teacher proposes a collaborative writing project for her class, and later tries to integrate the students' work with Wikipedia. Note the general issues of merging collaborations, and of integration of revision histories from the repository with outside repositories.
- Alia writes a document about daisies -- about how she thinks they are pretty and she likes picking them for her mother. She shares this on the school repository. It has no general interest.
- Bea (Alia's friend) gets the document and adds to it a picture she draws of a daisy. She shares it with her school, but not overwriting Alia's.
- Alia corrects her spelling and uploads a new version of her document, overwriting the old one.
- The teacher asks each student to write a report on a plant. Carlos chooses Daisies, and starts with Bea's document. He ends up deleting all the text but keeping the picture. Carlos is shy and doesn't share is report generally, he gives it directly to the teacher.
- The teacher likes Carlos's report and publishes it to the school.
- Later, the teacher notices that the localized wiki/wikipedia (Portuguese, say) doesn't have a page on daisies. She decides on a class project to start with Carlos's report to make a page.
- She sets up a project space for children to contribute content. She wants everyone to put all their ideas and comments together.
- Some students take pictures of daisies.
- Delores writes an article on making a daisychain garland.
- Estacio writes about where daisies grow in Brazil.
- Fidelio translates some of the Spanish wikipedia page on daisies.
- Gia finds some pictures of daisies online. Some are CC licensed, some aren't licensed at all, some are non-free stock photography images. She copies them all into the project space.
- In class they try to bring everyone's material together for a single article.
- The teacher doesn't worry about licensing and some non-free images go into the main document.
- The teacher likes Delores' article on daisychains, but it isn't really about daisies. She doesn't want it forgotten, but doesn't include it. She moves it out of the project and makes a link from the main article. The link points to the school space.
- She includes Estacio's and Fidelio's work as separate sections in the main document.
- The teacher doesn't actually "do" all of these things, but directs the students to do them together. Communication takes place (via voice) in the classroom, but the content production on the laptops. They are all directly and well connected to the school server during this process.
- After class the teacher gets the document into the right place on the Portuguese Wikipedia. She shares the link with all the students. She is proud that they put this together and would like to make sure all the parents see it... (how can she remind children to tell their parents?)
Asides
- Many parents don't know what Wikipedia is. The teacher would like to explain a little about it for the parents. She'd like to leave parent-directed comments [on the Wikipedia page?]. They aren't relevant to a larger audience... she wants to make sure parents know that it's something she wrote for them to read (as opposed to all the general stuff on Wikipedia).
- What happened to the daisychain article? (The teacher may have forgotten about it by now. Is it on the school repository? What happened to the link in the article?)
- A Wikipedia member (not a child, not using the laptop) removes all the unlicensed or non-free images in the article. That person would like to explain the reason to the contributor (who is attributed in the history tracked by the content repository, but not on Wikipedia, and has no WP page).
Read-only Use Case
- Curriculum is developed. The curriculum consists of a set of documents, with outlines, goals, etc. There is no interactive component to the curriculum (as far as the laptop is concerned -- the curriculum may include exercises, etc., but this is not guided programmatically in any way.
- Curriculum consists of a series of documents, including documents that may be "asides", that is they don't fit into any linearization of the curriculum.
- Curriculum links to an indefinite number of non-core items. Some of these might be highly interlinked and large sets of data. E.g., bibliographic links, links to Wikipedia, links to library category listings. These sets of data are from a practical sense infinite -- there is no way to enumerate or fetch the full set of documents, and no clear boundaries that would define a cohesive or consistent set of documents.
- Curriculum is viewable in the browser. Non-HTML and non-Image content is typically either viewed through plugins or as linked documents that are launched in some non-browser viewer.
- The teacher or school identifies the curriculum and schedules it for use in the classroom.
- The teacher indicates this in some way to the school server and/or individual laptops (perhaps by instructing students to follow some set of procedures). If the school server goes offline the core content for the curriculum should be available so classes can continue as scheduled. If laptops are not able to connect to the school server intermittently (e.g., when students are at home) the laptop should have the content or a strategy for getting the content.
- The teacher has additional content not intended for the students (e.g., further background material).
- Some strategy should be available to browse the non-core content that is not pre-fetched. If a student is interested in this content while they are not connected, there should be some way that they can revisit the content later when it is available.
Proposed Implementation for Browsing
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 [href="https://www.google.com/webmasters/tools/docs/en/protocol.html 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).