Projects/Wikislice

From OLPC
< Projects
Revision as of 11:00, 1 May 2008 by Annegentle (talk | contribs) (Audience/Actor descriptions)
Jump to: navigation, search

Project Page: OLPC/DITA/Wikipedia/Wikislice project



Team mission

To deliver a proof of concept that demonstrates how to create custom curriculum materials from Wikipedia for OLPC. Our objectives include:

  • use DITA to pull the resources from Wikipedia
  • deliver Wikipedia resources in an interchange-friendly and semantically-rich set of DITA-specialized topics
  • integrate DITA topics using a DITA map derived from a wiki slice


Team members

Members of our team include:



Team meetings

Most recent team meetings appear first.


Team meeting, 1 May 2008

Invitees: Alyson, Anne, Andy, Laura, Michael P, Michael B, Salim, Tom (regrets)

Agenda:

  1. Administrivia: (a) we've got a meeting time!; (b) user profiles/pages; (c) rotating minute-taking.
  2. Review SJ's email response to 16 April team meeting.
  3. Review homework from last team meeting -- begin work on use cases.


Team meeting, 16 April 2008

Attendees: Anne, Andy, Michael P, Michael B, Alyson

Minutes: (post-meeting comments from SJ Klein added -- look for **SJ)

  1. Draft audience descriptions for DITA/OLPC project: We're looking forward to having the information below confirmed and enhanced with input from SJ and this group -- this will be the bulk of today's discussion. As you can see, there are some questions (and I'm sure you have some, too!) that need answering.
  2. our team's goal: bundle wikipedia articles together for children to consume as curriculum (**SJ: "Perfect. Zdenek as you know has been working on generating bundle-sets. There are also a few childrens-encyclopedia projects underway."**)
  3. actors for a wikislice:
    1. content consumer.
      1. kids have to be able to read/interact with the slice, that it makes sense relative to what else they're studying (**SJ: "Interaction is important here. How does annotation reflect/pass up the chain?"**)
      2. teachers -- teach in the material in the wikislices to the kids on the XO (primary consumers)
      3. teachers also provide feedback to wikipedia -- requests for slices, requests for enhancements/functionality for slices (**SJ: "Requests are particularly important."**)
        1. Andy: they go get the slices, press a button, and out comes a bundle
        2. Michael: pure Wikipedia scenario -- situation where some of the resources they want are in Wikipedia but some are coming from another resource (ideally in DITA, DITA is the common currency), then they might start with a wikislice but will end with something that is a custom thing with pointers to some wikipedia sources but also some from other collections -- the wikislice is just a starting point for a curriculum design exercise.
        3. Michael/Andy: need to guarantee that wikislices are in synch (that everyone is teaching from the same material). The school would have the main repository with the internet connection, and the kids would connect with each others PCs and the central repository -- update would happen on the central repository and kids would synchronize from that. Potential to be an automatic update. Might want to have an automatic inform ("FYI, there are updates available, come get when ready"), rather than forced. Teachers could preview that update is appropriate.
        4. Anne: blue and red indicators that show a wikislice article has info about butterflies but article doesn't exist yet (red=not populated, blue as soon as something was there?).
        5. Michael: may be as simple as in the local DITA copy (of the wikislice or of the individual article resources), make sure we include a time stamp -- then when the kids have an internet connection run through the time stamps and compare to time stamps on remote connections. Need to optimize this. If local resources has been edited since last download, then it kicks off a comparison workflow -- "grab the updated copy but create a new version of the document and enable side-by-side viewing."
      4. New audience: local curriculum designer/deployer -- makes decision of what wikislice to grab and whether or not to edit it.
    2. content creator
      1. person with global view of subject organization who does organizing of the content of the slices
      2. person with detailed subject matter knowledge creating articles (may not even know their topic is part of a slice)
      3. question: teachers creating wikislices? teachers collaborating with wikipedia about content of a wikislice?
      4. question: who makes the indexes (subject index and title index)?
      5. (**SJ: "Teachers, students, parents, subject experts, enthusiasts, global educators."**)
    3. content maintainer
      1. someone (teacher? wikipedia people? system?) ensuring that the content of a wikislice is up-to-date and accurate and appropriate
      2. (**SJ:"Systemic prsentation of data on last-update, the existence of newer versions, etc."**)
    4. content packager
      1. person who decides that the content is ready to be packaged and deployed on the XO laptop
      2. question: not much interaction between teachers and wikipedia regarding creation of wikislices?
      3. question: wikipedia folks want primarily people experienced with wikipedia creating wikislices? (**SJ: "But to create a good wikislice, someone needs to be able to contribute in a way that is meaningful to other creators; that sort of specfic experience is a matter of fluency with the available tools."**)
  4. Wikislice examples from Anne for your awareness:
    1. Wikislice project page on Wikipedia: [1]
    2. 2007 Schools Wikipedia: [2]
  5. Administrivia
    1. Team agreed to regular meeting time of Thursdays, 10AM Central. Alyson to confirm with those who couldn't make today's call.
    2. For next time:
      1. Team: brainstorm individually on use cases based on updated audience descriptions; come to next session prepared to discuss. Store results of individual use case work in wiki.
      2. Anne: create OLPC wiki space for us to store team documents. (done, you're looking at it now)
      3. Alyson: send minutes and suggestion for regular meeting time. (done)


Team deliverables

Please use this place to store team work items and outputs.


Audience/Actor descriptions

See also descriptions and discussions in Apr 16 meeting minutes.

  1. content consumer; teachers, students
  2. content creator; teachers, students, parents, subject experts, enthusiasts, global educators
  3. content maintainer
  4. content packager; Someone familiar with existing tools

Use cases

Team, please store your work-in-progress here. Suggestion for organization below...

Use case input from your name here
  1. Use case 1: name of use case
    1. Use case details...


Useful Links

  • Wikislice project page on Wikipedia: [3]
  • 2007 Schools Wikipedia: [4]


Useful Background Information

Paraphrased from an email from SJ Klein, November 20, 2007:

"We need to implement concrete use cases, using DITA with an editor and publishing pipeline. Say, use the DITA open toolkit, a specific editor, and one of the wikiproject:wikislice slices, and trying to keep up with changes to the slices.

My default for the 'final format' of the edited work would be an html collection, one html file per article, that preserves internal links to other articles in the slice, and leaves out broken links (or converts them into external links to wikipedia).

Identify added value that can come from having this structure to the data, other than identifying red/blue links.

Then it would help to contrast using DITA as an interchange with some of the simplest options: - using no metadata at all and having a named URL that always contains the latest version of a wikislice - using a static set of metadata that get updated when things change, along with a version number that is incremented."

Michael and SJ discussed a few core use cases: maintaining and updating a stream that many people may be contributing to; and maintaining the latest version of a package that many people may be committing to, and which has some sort of 'latest' version.

Some distinctions to be made follow. It would be interesting to see specific implementations of the following notions in DITA format. 0) distinguish map updates from content updates

1) distinguish streams from patch updates to a static object that 'improves' over time

2) provide for pre- and post-filters; a pre-filter might be by keyword; a post-filter might be a transparent redirect fopr links that don't exist locally; keys that are resolved locally or externally.

3) other dimensions for feeds/streams:

- read-only v. read-write intearction with both streams and packages. Think of the latter as "two-way streams" and "distributed patch updates for packages" - linear v. distributed orderings (a single time-ordreing, or a distributed patch-ordering) - whether there are constraints that need to be applied when things are edited for read-write collections. michael : "export v feed"? perhaps the wrong term.