Kendra Tools Project Plan
Introduction
- This document is in its early stages of development. It needs some formality. Please help! ;-)
Requirements
- Need to be able to recreate the existing Kendra Initiative website using a KendraBase solution.
- Need to modify existing (add objects and object attributes) and create new Kendra Trials easily using web interface and without having to change underlying database structure.
- Address Book needs to be operational to demonstrate KendraBase functionality and drive users to register.
- Groupware for collaborative design where people can talk in their own languages.
- See also KendraBaseScenarios.
Terminology
- I'm not using formal terminology in this project plan. I'm coming at this very much from the interface end of things with a spattering of ideas about what to do at the core.
Organisation
- Time Scale
- NeilHarris now proposes 3 months. Working 2 days a week. DanielHarris will push "go" button when project plan is more complete - August or September 2003.
- need to complete: website and trials.
- Old Time Scale - ??
- 1 month building concept.
- 3 months to build website and trials.
- 3 months to move to more generic platform.
- 1 month to document.
Further Document Requirements
Users
- Developers
- Content Owners
- Content Consumers
- Service Providers
- Press
Tools
- Profile
- Users contact information such as addresses [each entity stands in its own right so that many people can be employed by a company].
- Distributed profiles: Users can have "master" and "slave" profiles on different websites/servers. The master profiles can be updated individually and then these updates will filter down to other master profiles and slave profiles. This is really a specific instance of the way all data is organised within the system.
- Contacts
- Calendar
- Forum
- Wiki, Majordomo, web bulletin board. Email lists with web archiving like Yahoo but better. Need to know which emails are bouncing too.
- Funding
- Connecting people/orgs to funding organisations for their Kendra Participant Projects.
- Accounts
- All financial accounts will be displayed on the website.
- News
- Events And Meetings
- People organise meetings. Link in calendar. Conference organisers enter info about their conferences. This then has to be rated to make sure it passes criteria. Link in calendar.
- Development
Trials
- Network
- To bring content as close to the end user as possible for increased quality.
- Commerce
- To enable payment systems to interoperate.
- Catalogue
- To enable content owners to make their content catalogues available to kendraSystem.
- Interface
- To enable player applications to view catalogue and make commercial transactions.
- Rules
- To codify the requirements of content owners for their content [how much is it? Where can it be shown?]. To codify requirements of content owners for their content [how much will I spend? When do I want it?].
- Content
- To enable content owners to get their content published on kendraSystem.
Concepts
- Interface
- The [Principle of least astonishment]? should apply as far as possible
- Ditto [programming by example]?
- Wherever a user is on the website there should be some standard ways of accessing information. Where a person's name is shown it should always be hyperlinked to their main record. This should go for any object. In some contexts all text will be hyperlinked like to take you through to a translation page for that text. Or a comment page. Or a rate/vote page.
- Object Model
- Any object will link to any object via any link. The data structure should be able to be flexible.
- Reverse links
- So, I am a "son" of Paul and Paul is a "father" of me.
- Views
- The Tools and the Trials are views of the database.
- Language
- It's crucial to the whole project that users can speak their own language. Not only their "mother tongue" but also business language will vary from company to organisation to individual. It's important that we don't shoehorn users into a way of speaking that they don't like otherwise they'll leave the project. So, let people speak how they want. If we are going to do that then we need to be able to somehow link people's words together when they have the same meaning.
- Trust model
- A person will give access to their personal private information only to trusted people. So, a trust metric can be built up for a person from the permissions that they are granted. Also, people can be directly rate other people (or any entity) on any quality (not limited to trust).
- Bullet proof by simplicity
- Implementation should be simple. Always assume that things will go wrong so build that into the model. For example servers will go offline so allow for it and report it as a normal occurrence.
- Truth
- There is no absolute truth in this system only relative truth - "delayed opinion".
- When presenting data it will be cached somewhere. There should be metrics stating:
- When it was cached.
- When the original data was last updated prior to caching.
- How reliable the data is based on how often the data is updated.
- A person's name may be cached and not updated for a year but it is still has a high reliability since it's not likely to be changed.
Features
- Multilingual
- Initial translations of website and forums can be done by machine to get content but then must enable users to suggest better translations. This is not about having different content/areas for different languages but about having trusted translations of entities/objects (words and text) so that everybody knows what everyone else is saying even if it's in a different language. It's about breaking down the barriers rather than building them up.
- Logging
- Full user/action logging. Got to know what people are doing so we can find out if we're being effective.
- This will enable real time data mining of the logs. Also, due to the fact that they'll be going into a database they should take up less space than normal.
- Attribution
- All statements on the system must contain an identifier for the person or organization making the statement. (issues: traceability, anonymity, non-repudiation?)
- Timestamps
- All statements should be time-stamped, if possible
- Expiry times
- All statements in the system should be able to have expiry times, so that the reasonable lifetime of a statement may be expressed, and to help caching strategies
- Name Space
- Each user would have their own name space. Even within this name space there could be duplicates. For example a user could know 2 people called "John Smith". If a user wants to describe an object then they could use a word from their own or someone else's name space. If it's from someone else's namespace they could freeze definition of that name there or allow it to be modified by the owner.
- The system should also permit shared namespaces, so that groups of users can communicate more easily. Issues: should there be DisAmbiguation (I think so) or a truly [global namespace]?? (I would like to think so, but there are scaling/philosphical issues)
- Content syndication
- All website content must be made available in XML form for syndication.
- Rated users/participants/organisations
- List of translators for all languages, or just one language. Most common poster to forums. Any statistic should be able to be mined.
- Comments
- Feedback for each page. In fact, comment feedback for anything. These comments attached to forums.
- Targeted email newsletters
- Users will be directed to content relevant to them: consumers, service providers, content owners/creators, developers, press... and how often they get updates. So, that means that the newsletters are created dynamically from manually/automated edited content. Users create their own newsletter by picking up content from the website such as financial/accounts and network trial summaries.
- Email
- Every user will get a firstname.lastname@public.kendra.org.uk alias.
- Users can subscribe to other users to get every email sent by them or received by them.
- All email sent and received via Kendra aliases will be publically archived - though this is an optional feature for the system - promotes personal responsibility for what one says (?).
- Add/validate emails like Yahoo! and most other subscription services.
- Add multiple emails to system.
- Send all emails to me to this group of email addresses.
- Let me post using the following list of email addresses.
- DanielHarris wants: any email sent to daniel@kexxxxxxrg.uk to be publically archived. Senders to this email address get an auto-reply either "sorry this email doesn't exist, did you want one from this list..." or "your email is parked awaiting your authorisation/agreement to have it archived in public on the website. Click on one of the following:
- yes - link to web
- no - link to web
- yes - send email
- no - send email
- Users have to be registered to send to the private address of DanielHarris. And I reserve the right to make public anything you send to the private address. Do not send email you wish to be kept secret.
- When sending to someone@public.kendra.org.uk you'll get authorisation email saying you will continue to get this email until you set your preferences in your profile.
- Privacy
- Must enable users to set privacy levels for their content.
- Licencing
- Users must be able to set licencing levels for their content: eg: copyrighted but free to read, public domain, Kendra Licence, GPL, BSD licence, GFDL, Creative Commons licences, user custom licences... standard licence tags for standard licences?
- Different licences for different views: eg. "my catalog is GFDL, my short sample media clips are under a Creative Commons licence, my full media content is copyrighted"?
- Speed
- Speed can be optimised later.
- Security and encryption
- Security and encryption should not be a focus and can be done later if at all ever.
- URL redirects
- Every external URL entered into database so we can log who's going where and how many times.
- Tools interface
- Fully customisable! ;-)
- See KendraBaseMockups for ideas on how users rate or comment on text or whole pages.
- Auto-input
- There are many existing database and flat file Internet resources. These resources are updated by their owners sometimes. When adding or updating data from these resources into KendraBase we need to do this via automation that will check for updates and modifications and mark them as such.
- Query Builder
- Make a really nice way for people to make queries to the system with drop down menus. See KendraBaseQueryBuilder.
- Data Pivoting Everywhere
- Pervasive Hierarchical Permissions
- At the top of the user stack we have the owner or system administrator of the KendraBase. They set up users and groups and define capabilities and ranges/restriction. These users in turn can then define capabilities and ranges/restriction for users below them. Kind of like reselling...
Technology
- Associated technologies: RDF?, RSS?, RDBMS?, SQL?, ...
- Distributed Tools
- All tools must be fully distributable among different hosts and be able to communicate as if they were on the same host.
- Authentication
- Users decide the method. http or cookie or passport/.net (distributed) or another.
- Comment: Yikes! Distributed authentication frameworks are a major complexity burden at this stage. As a matter of implementation pragmatism, this should be left out of the first prototype, and made a goal for later. Also don't forget the Liberty Alliance.
- Take a look at OneClickWatchMe which I think could do some of the job quite easily.
- Coding
- PHP (with PEAR), MySQL? (4 for better Unicode support?), W3C valid XHTML strict and CSS. All content (including code) is held on the database and so can be compiled on fly. All code modules should talk to each other via webservices (soap, XML) so that they can be easily distributed over a number of servers if necessary.
- Comment: W3C Valid HTML 4.01 Transitional might be "more compatible" than XHTML Strict for now: implement both and make this a run-time option, changing the default as browser tech improves?
- Would be good if what we code can run on UNIX, Windows and Mac OS X at least. As this will drive uptake and also enable desktop machines to run code as well as servers.
- Not a "universal system"
- Strictly limited goals: things outside of the "groupware and database publishing" mission outlined above should be dealt with by other tools: indeed, the whole point of the system is to make this possible.
- Closure
- As far as possible, the system should be self-hosting, that is to say, use its own mechanisms as part of its own working. In this way, the system can get the maximum amount of power out of the minimum amount of programming.
- Off line working
- There should be no problem working offline (unconnected to the Internet) and then re-querying/syncing when one connects again. We are not relying on permanently open database connects for live updates. But we can get pretty close if needs really be, just by re-querying.
- Resource discovery
- How will each KendraBase host/server know how to find other siblings? There are lots of ways of doing this and we should be able to use them all! Perhaps to start off with we could just have a simple lookup table replicated within each KendraBase server. Other ways could be more like peer to peer networks but this takes out direct connection between servers but probably need to do this if KendraBase is to scale. Keep options open. Start simple.
KendraBase design and implementation notes
Ideas
- Mind map (of sorts) collecting ideas together for KendraBase can be found [here].
Reference websites
Other interesting projects
Targets for trialing KendraBase
Possible targets for trialing KendraBase
See also
![[Home]](/graphics/kendra-small.gif)
![[here]](http://www.kendra.org.uk/graphics/kendra-base-meeting-sketch.gif){kind=link}