[Zope-PTK] Zope Portal Draft
Maik Roeder
roeder@berg.net
Mon, 01 May 2000 15:12:57 +0200
Hi !
I would like to discuss this Zope Portal Draft with you.
I have already implemented the ZClasses and the Forms,
but there is still much more work ahead to make it
user friendly ;-)
Let's please discuss this on the ZDP mailing list.
Greetings,
Maik Röder
-----------
The Zope Documentation Project is determined to help all Zope stakeholders
to create a Portal to build a Zope knowledge base that allows finding,
sharing and improving knowledge.
The Zope Stakeholders can be separated into more or less overlapping
Communities.
* Product Developers
* Documentation Contributors
* Zope Developers
* Zope Users
* Newbies
* DTML Programmers
* Python Programmers
* SIG Members
* ZDP-Tools Users
* ZDP-Tools Developers
The challenge is to build a Portal that is personalized to fit the current
stakeholders's rights and responsibilities.
If all stakeholders agree, it should be an official Zope stakeholder Policy
to make all documentation primarily available through the new Portal, so it
can become the Knowledge Repository for and of the whole Zope Community.
To ensure manageability of the Zope Portal, it is important to distribute
authority, support approval workflow, and make adding content easy.
Right now the ZDP site is not the central repository of Zope documentation,
and so we need to make links to all documents that are relevant to Zope,
integrating a view on existing ZDP and Zope.org documentation.
Links will be enriched with meta-information so even though not all
documentation is available in one place, there will be one place from where
all documentation can be reached conveniently.
To allow information to be found quickly, all Zope documentation will be
enriched with the following meta information:
* Subject
* Topic
* Community
This imposes a Meta Hierarchy on the existing Document Hierarchy. For each
Portal Community, a Catalog search for the Community, Subject and Topic
properties finds all information that is interesting for the Community in
the context of the specific Subject and Topic.
A prototype of this system is going to be built by extending the ZDP-Tools,
which are developed collaboratively on-site using ZClasses exclusively.
ZClasses to be added:
* Subject (derived from Search)
nickname: Subject
In each Portal folder, there are Subjects that contain Topics. Subjects
can for example be "DTML" and "Web Server".
* Topic (derived from Search)
nickname: Topic
Topics are contained in Subjects.
* Portal (derived from DocumentFolder)
nickname: Community
Each Portal defines a special view on the information space by
filtering on the Community property of the Meta-hierarchy. The Portal
contains Subject and Topic objects that define which Subjects and
Topics are interesting for the Community.
* PortalFolder (derived from DocumentFolder)
nickname: Stakeholders
The PortalFolder contains the Community Portals for the Zope
Stakeholders.
Showing the Portal Page
A Portal shows Subjects and Topics sorted alphabetically. On a Portal page,
Subjects and Topics are collected by simply looping through all Subjects and
Topics.
Example Portal View
Subject 1 Subject 2 Subject 3
Topic 1 Topic 4 Topic 7
Topic 2 Topic 5 Topic 8
Topic 3 Topic 6 Topic 9
Subject 4 Subject 5 Subject 6
Topic 10 Topic 13 Topic 19
Topic 11 Topic 14 Topic 20
Topic 12 Topic 15 Topic 21
Topic 16 Topic 22
Topic 17 Topic 23
Topic 18
The ZCatalog search starts once a Stakeholder follows a Topic link. The
Search is performed with the following parameters:
* Subject = Subject.nickname
* Topic = Topic.nickname
* Community = Portal.nickname
This should keep the number of results rather small because we are filtering
the Document Hierarchy using three properties of the interwoven
Meta-Hierarchy.
The DocumentFolderClass from which all other ZDP-Tool ZClasses are derived
gets the following new properties:
* DocumentFolder
o Subject
o Topic
o Community
Creating Documents
When we create a new document somewhere in the Document Hierarchy, the
Subject is by default the Topic of the Parent folder. The default Subject
and Topic of the Root folder is defined as follows:
* Root (/ of zdp.zope.org):
o Subject: Zope
o Topic: ZDP
o Community: Stakeholders
The Project Folder has the Subject "ZDP", which is the Topic of the Root
folder. The Topic of the Project Folder is "ZDP Projects".
*Project Folder (nickname: Projects)
* Subject: ZDP
* Topic: ZDP Projects
* Community: Zope Users
*Project (nickname: ZDP-Tools)
* Subject: ZDP Projects
* Topic: ZDP-Tools Project
* Community: ZDP-Tools Users
*ProductDocumentation (nickname: Documentation)
* subject: ZDP-Tools project
* topic: ZDP-Tools Documentation
* Community: ZDP-Tools Developers
Please note that the Subjects are always the Topics of the parent folders.
Choosing Subjects and Topics
When we create a new object, Subjects and Topics are chosen using the
Subject/Topic Hierarchy. Let's suppose we want to add a new Project called
ZBook to the document hierarchy under the Project Folder:
* Project Folder (nickname Projects)
o Subject: ZDP
o Topic: ZDP Projects
o Community: Zope Users
* Project (nickname: ZBook)
o Subject: ZDP Projects
o Topic: ZBook Project
o Community: ZBook Contributors
When the Project is created, the Subject is already predefined. The Subject
is defined as the Topic "ZDP Projects" of the parent (ProjectFolder).
In the Subject/Topic hierarchy the Subject "ZDP Projects" already exists if
there have been other projects defined earlier. In this case we only have to
care for a new Topic with the nickname "ZBook Project".
If the Subject "ZDP Projects" does not exist as a Subject, but only as a
Topic of the Subject "ZDP", then the Subject "ZDP projects" would have to be
created as a new Subject, and inside of it, a Topic of "ZBook Project".
The Subject/Topic chain breaks in the Document Hierarchy when the documents
become too specialised for a Portal's Community. Another Community will be
interested in the more specialised documents in the Document Hierarchy. For
this reason, the ZBook with it's Parts and Chapters will be moved to a top
position in the hierarchy.
The document hierarchy is built on the principle of containment, which is to
say that we usually have no content flying around in mid-air, but always in
a context.
The Community property of new documents defaults to the Community property
of the parent if the Topic of the parent exists in the Portal of the
Community as a Subject.
If this is not the case, we search for all Portals that have the following
properties:
* meta_type: Portal
* Subject: Topic of the parent
Then all Subjects we have found will be shown below their Portals. The user
will be asked to specify the Community of the document by selecting one the
Subject under one of the Communities.
If no Community does have the Subject, there is an entry field below each
Subject List of each Portal which the user can select and fill in with a new
Subject.
When you create a document in the document hierarchy, you always get the
Subject for free from the Topic of the parent folder. The Topics can be
naturally fed from the Topics in a Subject with the name of the Subject of
one of the parent folders. The Topics are available from a selection list at
the time we create a new document in the document hierarchy.
How are Documents defined for Communities ?
Let's take the example of a Member who wants to add a News Item in a
NewsFolder somewhere in the document hierarchy. Upon creation of the
NewsItem, the largest possible Community that may be interested in the
information has to be selected.
Keeping a reasonable number of Subjects and Topics
The amount of information in a Portal must be reduced by tweaking some
parameters. Perhaps a rating of documents can be helpful here. A flat
hierarchy should be avoided by demanding at least 3 documents in each
Subject. It would also be best to have an almost equal number of Topics in
each Subject.