Preamble
If you`ll find a better way to introduce the ideas below — feel free to change it, we will surely appreciate your contribution.

Status of this text is: delta. You can read it, you can ever believe it, but it could contain several errors. Less than in beta or gamma statuses, though.

1. Brief Overview

“Net Project Journal” (NPJ in acronym) is a distributable collaboration & communication system. It provides the abilities to manage content, to supply collaboration tools for workteams as well as to be the multiblog engine for posting periodic messages to the web. It is based on consolidation of three most-used concepts:

• cms engine — to manage the content of the site in handy manner and/or
• weblog (multiuser version) — to intercommunicate with each others in community and/or
• wiki — to collaborate with each other in the team on project-related basis.

Unifying these concepts in a single, easy-to-use, tightly bound environment allows workgroups to organize the common workspace with shared artefacts (such as documents, posts etc) to work on together.

Teamwork with documents is based on the following crucial principles:

• each document may be edited by any member of a workgroup (while the author is responsible either to set up the permissions, or to apply predefined rules);
• each document may be commented in a pretty same way;
• every version of the document is archived, being accessible for viewing and comparison with any other version (and such comparision is partially automated).

NPJ is GPL-licensed and available for download.

2. To Whom It May Concern Be Useful

NPJ is useful for almost any workgroup, whether members are located in the same office, or distributed over the world. The only claim is that members are to use computers eventually in their domain work process. Basic web skills are also required.

Here are several examples of workgroups of a sort:

• software & webware developers;
• website developers;
• system analytics (e.g., SA dpt. of Enterprise);
• technical writers & documentation teams;
• corporate entity & document workflow developers & maintainers;
• journalists, newsmakers, other media authoring teams;
• distantly studying teams;
• organizers (teams) of social, cultural & political events.

Yes, we are talking about teams — the workgroups with even relationships between members, but still having the subtle subordination. NPJ software tend to facilitate the peer relations reqiured by teamwork.

3. Key Features

3.1. Distributable Net Of Independent Nodes & CSA

Each NPJ node is an independent website (as well as http://npj.ru itself). NPJ node could be just a part of site (take a look at our neighbour node@gismo, which is located on the same site with node@npj).
Nodes could be “connected”, allowing cross-site authorization (CSA), replication features & use of unified addressing system.

After an user is logged successfully on his own “home node”, he/she can visit any “known-to-it” node from the network, still being authorized and recognized as “user of home node”. In such a case, no subsequent registration/login is required.
Owners & users of each node should explicitly set the rights for such “guest” users on their documents up.

3.2. Unified Addressing System

Instead of URLs — which is known to be annoying to keep in mind — NPJ uses its own addressing system, based on its concept of information's space separation — namely, all the infospaces are splitted into “journals”.

Unified Addressing System allows users to link every entity of information (a document, a journal, a comment) persistently unique. That syntax is URL-independent and should be treated as some kind of additional storey over URLs, making them readable by a human being.

Syntax of NPJ-address:

• login@homenode:DocumentNameInJournal

For example, this node is @npj, we are in journal node, this document`s name is EnglishDescription, so the absolute NPJ-address for this document would be node@npj:EnglishDescription.

NPJ addressing system is not tolerant for letter case & for language issues. kuso@npj:ToDo links to kuso@npj:todo links to kuso@npj:ТоДо.

3.3. Personal Infospace Concept

(infospace means information space, for short)

Let us call any human being registered on an NPJ node a “user”.
Then each user gets his own infospace after registration. That infospace includes “journal”, “document repository”, “correspondents feed”, “user profile” and many other interesting phenomenas.

User can control his own infospace the way he like it — create, edit, delete any data entry, tune it up, manage rights of other users.

3.3.1. What is Journal?

Personal Journal, web-diary, blog — are nearly synonyms. Simple analog of “personal journal” feature could be LiveJournal account.

User can write “posts” — messages of any content — and do it as frequent as he want to. Journal stores all posts user have made — if you ever wrote a post, you`ll find it in your journal (that helps to solve common livejournal issue with “post lost in community”).

Post are structured by creation date (as in Livejournal) and by roubrics/keywords. Author can prohibit any post from commenting or limit access to it (as in Livejournal, again).

3.3.2. Correspondents feed

Livejournal have friends, we here have “correspondents”. Correspondents are people (users) you`ld like to read. User can form its own list of correspondents — posts from their journals will appear in his correspondents feed in chronological order.

3.4. Collaboration

Target NPJ`s feature is technology of collaboration of a workgroup. Here we speak mostly about teamwork with documents.

Each user can create its own documents and then allow other users to comment, edit or even delete it. User can create “access groups” and assign rights on group basis. All versions of such documents are stored and there are easy ways to note differences between versions and to make a rollback.

So users can collaborate on documents without fear their contribution could be lost accidentally or not. So document maintainers could stop web-luddits from vanishing results into enthropy (actually the way wiki usually dies).

Such technology basis could be useful for documentation writing and for collecting knowledge base — for example annotated linklist, sorted by themes.

3.4.1. More on documents` security and access

NPJ` security deals with issues on shared access to documents. ?yes,

There are some common concepts again:

1. Document`s owner choose users that will be allowed to view, edit and comment that document.
2. NPJ software automatically stores history of all changes been made in documents. That allows users to restore any previous version of document.
3. There is the special tool, called diff, that allows to compare any two versions of a documents and to highlight changes (or to show changes only). That allows users easily recognize difference between versions and realize actual contribution of themselves or other users.

3.4.2. Discussions & conversations

Each “post” in journal and each “document” in document repository can be commented as we usually can do in weblogs or web portals like “slashdot” (Of course, document owner could prohibit commenting).

Commenting leads to conversation between author(s) & commentator — or between commentators, and discussion could be driven to new knowledge or to new vision of topic.

Instead of “posts” or “documents”, comments cannot be edited, but they can be deleted by author of comment or owner of document.

Tight email integration is another feature to support such discussions. Owner receives all comments by email & any other user can subscribe to following discussion. User can simple “reply” by email to answer — their email reply would be converted into comment and linked up to discussion as other comments do.

Comments could be presented as tree-like structure or in linear chronological order.

3.4.3. Communities

NPJ Community represent some topic, area of interest of some usergroup. Each member of community could publish his “posts” in community`s feed. (That is quite like Livejournal communities, but posts are not saved in communities` infospace, they are just published here and there).

Any “post” could be published in several communities and became accessible through their “community journals” — for example progress@npj or design@npj. At the same time that post is accessible in owner`s personal journal — and owner can change its publication status at once (for example, cross-post it to another community).

Community in NPJ became the focus point of users` interest, kind a common topic dictionary.

3.4.4. Workgroups

Workgroups are look like communities, but when you get inside, you realize they are much more powerful.

NPJ Workgroup represent some group of users, united by some common objective, initiative and/or project. Workgroups are creating not for communication (as communities rather do), but for collaboration. Workgroup have its own journal (which is similar to “community journal”) and its own document repository.

The workgroup owner is the user created that workgroup. He can choose how other users will join group & what roles they would be assigned on. There are “beholders”, “members” and “managers” roles in default NPJ role model (as we have in http://npj.ru).

Access rights on workgroup`s documents are assigned on role basis (but could be tuned on individual, user basis). Usually “managers” got the power to change documents` rights, “members” — to edit documents, and for “beholders” it is only permitted to look.

Document workflow could be realized through workgroup`s activity.

3.5. Rubricator / Topic Dictionary

Topic dictionary (or “rubricator”) contains “roubrics” or “keywords” to link “posts” or “documents” with. Each user have its own topic dictionary, each workgroup have its own topic dictionary. Communities are about to form common topic dictionary.

Roubrics in topic dictionary can be arranged in hierarchy. Tree of roubrics can be any reasonable level of depth (something near 120 in fact).

Any record («post» or “document”) can be assigned to any reasonable amount of roubrics (something near 1,2 billion in fact).
In fact, it is not “placed” in these roubrics, but “linked” with them.

If “post” is linked to a subroubric, it is also linked to appropriate superroubric automatically. For example, if kuso@npj:78890 linked to Npj/Documentation, it is also linked to Npj~ too.

3.6. Simplified Wiki markup (WYTIWYG)

(WYTIWYG — What You Think Is What You Get, for short)

There are two three kinds of hypertext authoring tool in NPJ:

• WYSIWYG HTML editor, with all those bold, italic shortcuts
• simple textarea that reflects only on line feeds and treats all other as plain HTML
• and Wiki editor, that uses special markup with simplified rules.

Wiki markup is based on WYTIWYG principle, it says “you got to think how it would be, and then you can do that exactly”. Or something. Rules are simple, rules are written somewhere in http://wackowiki.com/WackoFormatting. Speaking shortly, **this will make it bold**, and //this -- italic//.

3.7. Tight Email Integration

NPJ is built with a focus on tight integration with email. That allows maillist subscribers work with NPJ same way as they worked with maillist.

User can subscribe on:

• new documents or post in journal of particular users
• new posts in particular journals or communities
• new records linked to specified roubrics/topics
• new comments in particular journals or even to particular records or, or, or even to particular comments, yes 
• differences made in particular documents or even journals

User can submit new comment by replying to any of these subscription event — email replies are converted into comments and placed near other comments.

User can create new posts and new documents using email only (there are two formats of creation, one is useful for complicated scenarios, another is pretty simple and can be easily used to post via cellphone).

There are some spec on email integration — node@npj:ДокументацияПользователя/Mail2Npj (sorry, but it is in Russian).