Re: [Bug-gnupedia] Design proposal

[Bob Dodd]

Hi Bryce,  um... where to start?

Well, I guess I would start by saying that we need a very clear
definition of the requirements of this here encyclopedia thingy. Not,
how it's going to be implemented, just what we expect it to be able to
do, what form of inputs it takes, what sort of access do we allow (e.g.
protocols to access the info). Otherwise we're all going to contine to
speak at cross-purposes (not just you and I... look at ther rest of the
postings on this list :-)) Richar Stallman wanted us to spend this week
looking at the project definition, and on reflection, I think he's
quite right. To that end I've posted a proposed TOC for our
requirements document. It's not meant to pre-select any particular
requirements, or solution, just to help us focus on "what" rather than
"how".

Coming back to the Wiki, I think Wiki's are a great idea for
collaborative writing projects when the basic content structure of the
material is well udnerstood. For example, it would be a fantastic
medium in which to write our requirements document, if Hector would be
so kind as to install one on our website. (or indeed several: it would
give people somewhere to express design solutions without relying on
external websites). 

Is this possible Hector?

As an encyclopedia tool, I have more doubts, regardless of our detailed
requirements. Do you think the Wiki is providing just the basic "core"
organisation of the encyclopedia, or do you think it's also providing
all the different views and search engines too? So, are we talking
about the same Wiki (and its front end) for inputting information, and
for searching? How would we deal with people wanting to access content
without using the existing Wiki front end? How would people be able to
filter content (e.g. to make a "children friendly" view that excludes
material inappropriate to the age group) How scaleable is the back-end?
How does it compare to other free encylopedia-line information systems
(e.g. Nupedia's own source code) Unless we can answer all of those
questions (and many more), I don't see how we can choose *any* existing
tools or platforms.

Also, to select the appropriate tools (I say select, not necessarily
*write*), we need to consider what basic organisational structure we
want, and indeed if we really want all information in the same physical
system (e.g. one for db current new submissions, one db for
searching/browsing). 

Just to illustrate the point: do we want to hold information
hierarchically, horizontally, or both? Do we want a core encyclopedia
of detailed entries, and another separate section for "summarized"
entries (where an author sets out to describe a "balanced", in their
view, view of multiple submitted entries on a particular topic. I.e.
anyone in that system can be an "editor", and there may be may
summaries on the same topic. If so, are the core and the summarised
versions organised the same?

To further illsutrate the point, there are some very standard ways of
internally representing hierarchical data, other than using a Wiki. One
of the most famous is X.500, which not only gives you hierarchy, but
within its data model allows for elaboration/entension of existing
elements in the hierarchy (basic OO), and allows (internal
cross-linking), and templates for entries to attach attributes to the
entries. And because it's a standard, there are standard tools to help
navigate and index the model. At the baic programming level, we also
have DAP/LDAP extensions to Perl that would easily allow us to attach
such a db to Apache...  

To choose whether to use, say, a Wiki, or an X.500 database, or
Nupediad encylopedia db, or anything else, we need to be first sure of
our own requirements. And to be honest I think we're still a couple of
weeks away from that. I wouldn't go rushing into using the Wiki (or
anything else) just yet.

/Bob Dodd


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/