A new thread was started on Apogee list regarding the Apogee resource model. Anyone willing to participate on this topic may subscribes here: http://lists.nuxeo.com/cgi-bin/mailman/listinfo/apogee

The document describing the Apogee resource model can be found here: http://apogee.nuxeo.org/sections/documentation/apogee-global
The resource model is still under development so it may change in future.

Here is a short summary of things discussed:


Aren't files and folders model restrictive compared with CPS object model ?
Can resources have a file and a folder nature in the same time? (this means resources having content as files but also children as folders)

Files and folders are handles to real objects described by resource metadatas and that may be put in a tree structure. So that folders are nodes that may contains children and files are terminal nodes.
Real objects behind these handles are not affected by the handle type (file or folder) - this is used only to define the resource tree.
The real object may be unaware that it is a file or folder in the Apogee resource model.
Objects may be of any type. Every resource may support having content - even folders. For example a resource folder may point to a "Link", "Calendar" or wathever object you want even to a "file"having some content in a file system. The same applies for the file resource. It may points to a real folder in a file system ...

So the File and Folder properties are defined on the resource level not on the underlying object level.
Underlying object are completely described by the associated metadata.
Each ECMporvider may defines it's own objects and metadatas - so that Apogee should be able to handle any type of object.
This is why the resource model is not defining objects but only basic resources like Site, File and Folders and Metadatas objects that describes the underlying object or content.

---

About containment: How it will be managed for maximum flexibility?
Is there envisaged a virtual tree structure to create mixed tree using resources from different ECM providers?

Containement is managed at the persistence level - by ECM providers.
The resource tree is build by calling ISiteController.getChildren(folder) for each folder resource - operation that is implemented by the corresponding ECM provider - so that the resource tree will reflect the tree structure defined by the provider.

For the local ECM provider that will be implemented in Apogee we will use a db4o database. The resources will be stored as objects and the three structure will be defined explicitely by each object by keeping the parent path and the local name of the resource (relative to its parent)
Example:
Object { parentPath: "path/to/parent"; name: "myName"; }
To query for all children for a given folder we may query for all objects having the parentPath equals to the folder path.
This is an example. There are also other ways of describing the tree inside db4o.

Anyway, we can envisage to define in the resource model "Virtual Sites" owning a resource tree made by resources belonging to other sites having different ECM providers. So that we can create virtual trees of objects.
Implementing this is possible.
The virtual site should be bound to a special ISiteController implementation that delegates operations to the controller corresponding for the target resource.
For example the ISiteController.exists() method can be writted as follow:

public boolean exists(ISiteResource resource ) {
    return resource.getSite().getController().exists();
}

Also, the resource should keep a reference to its real site and NOT to the virtual site - so that it is not even aware that is used inside another site.
The containment for virtual sites cannot be defined be the ECM providers... since resources from different providers are put together in the same tree.
This can be done directly in the resource model (by the virtual site) by using RDF relations between existing resources.
Something like: "resource1_URI hasParent resource2_URI" RDF relations can also be easly stored in a db40 database.

---

Communicaion between several ECm providers? For example is publishing a resource to several ECM provider sites working?

Yes, operations may be executed between sites. For example a copy operation may allows that the resource to be copied be in other sote than the destination folder where the resource to be copied. The same thing can be done for a publish.

---

Authentication is an ECM Provider function? Using the site controller or how?

Yes, supports for authentication will be added in ISiteController API.

---

Are workflows used in the resource model core?

I want to keep the resource model core as simple as possible and functionality to be added as extensions and not directly in the core - and plugged into the operation execution logic by using the notification mechanism.
Anyway we could add some fonctionality directly in the resource core. This will be decided at the time of designing the functionality.

But for workspace or security checks I think they should be implemented by each ECM provider since they need custom workflow and security mechansims.

The UNDO/REDO manager is an example of a generic service that may directly implemented in Apogee core (and not by providers) since it manages ISiteOperation objects that are not depending on any ECM provider.

This is the project I am currently working on.

The Books Repository should be implemented in Java as an Eclipse plugin and its goal is to store and browse large collections of books.

A book repository is a tree like structure of resource objects. The resources managed by a book repository are:

• Library - a book collection. Can contains a list of Books
  
• Book - a book. A Book can contains Sections and Documents
  
• Section - a book section. A section is a logical part of a book and may contains Documents
  
• Document - a searchable text document. A document contains textual data and may contains other external documents (not necesarly text document) known as attachments
  
• Attachment - a document attachment
  
• Note - a note is an user comment that may be attached to a document
  
• Bookmark - a bookmark is a reference to a node in a Library tree structure 

Only Note and Bookmark resources are editable by the user - the rest is read only.

The resources are described by a set of properties knows as the resource METADATA.
All the resources may defines the following METADATA fields:

• id (string) - The local resource identifier
• name (string) - The Library name
  
• creator (string) The creator
  
• date (string: YYYY-MM-DD) - The creation date
  
• description (string) - The resource description
  
• subject (string) - A list of searchable keywords that describes the resource

The only required fields are: id and name
Each resource type may add custom fields to their METADATA but these fields are not yet defined. Also, the format of the id field is not yet defined.

Each resource instance is globaly identified by an URI.
Local identifiers (id field) are unique id relative to a given context.

The Library structure (e.g. the resource tree) and the METADATA is described using the RDF format
At this moment the metadata element set is not yet defined.
A possibility is to use the Dublin Core Metadata Element Set to describe our resources METADATA.
(See http://dublincore.org/documents/dces/)
The RDF description will be stored in a RDF database.
As RDF engine I choosed Sesame (see http://openrdf.org) because it's the only RDF engine I've found that embeds a Java database which increase the engine portability. It also supports external databases like MySQL, PostgreSQL, Oracle etc.
For a survey of RDF engines you can check http://www.w3.org/2001/05/rdf-ds/DataStore
Another interesting RDF engine is Redland (see http://librdf.org/)

Document, Attachment and Note resources may contains text or binary data.
This data is not stored in the RDF description of the library. Instead, we store it in a data repository on the hard disk.
The data repository may be implemented using regular files/directories or using a database. For now, I will use the file system approach. Thus data will be stored in files inside a directory tree structure that will be defined later.
Document data is stored as DocBook files and Note data is stored as plain text.

There are two kinds of search we can perform on resources:

1. Search based on resource properties (using METADATA fields)
2. Search on Document text data (using a text search engine)
   

As text search engine I choosed Lucene that is already included by eclipse
(see http://jakarta.apache.org/lucene/docs/index.html)

The DocBook files will not be displayed directly by the eclipse plugin because
this requires extra work to create a DocBook editor using eclipse SWT library.
Instead, we will convert the DocBooks into HTML files that can be viewed in eclipse using the embeded web browser.

Basically, to browse a book repsoitory, we need to create a Tree Navigator View and a HTML Browser.
The Tree view is used to display the repository structure and the HTML Browser is used to display the Documents data when a Document node from the Tree View is double-clicked.
There are also views that need to be created like: Bookmarks list, Metadata view, Notes list, Context Navigation, Search result etc.

Also, a Welcome page (Home page) needs to be dispalyed the first time the user open a book repository.
The Welcome page will be implemented as an HTML page (displayable in a HTML Browser instance)
The content of the Welcome page is not yet defined.

Another requirement of the application is to implement a method to synchronize (i.e. update) repositories with a central server.
This will be implemented using a diff/patch system (based on the unix diff tool or on a XML diff tool)
Update procedure:

1. download the update packages (a collection of diff files and attachments)
2. Apply diff files on the local versions
3. Rebuild the RDF database and the text search indexes