CMIS First Technical Committee Meeting Notes

Last week was the first face-to-face meeting of the OASIS CMIS Technical Committee (TC). From my perspective, it was a very productive gathering and allowed for a number of highly constructive discussions. In the following write-up I do my best to retrace the gist of the conversations around the topics I found most interesting, which in some cases were conversations I had with just one or two people.

The outlook from these discussions, and from the scope of the spec itself, is very positive. I believe that within a year CMIS will start to actively redefine the world of content management systems, which will be an opportunity both for big vendors who will see easier adoption of their solutions by customers concerned by lock-in or interoperability issues, and for smaller vendors whose products will be able to take advantage of a much broader spectrum of connectors to third-party systems.

[Editor's Note:  Read Alfresco's view of the TC Meeting. For those of you new to CMIS, see our CMIS Overview and browse our previous CMIS news coverage.]

Schedule

The most important news at the end of these three days is that there is enormous support in the TC for CMIS 1.0 to be released as soon as reasonably possible, as it is felt by all that a simple and solid spec that can be implemented and used ASAP by everyone is paramount.

Due to time constraints inherent in the OASIS standardization process, this is likely to be in late 2009 or early 2010 — and that's if we can polish the current draft and fix the problems within something like two months!

Existing Capabilities

During this meeting it was stressed many times that the goal of CMIS is not to define the semantics for new features that a repository could implement, but to provide access to existing features of existing repositories, so that they can interoperate.

This implies that complex features, non-standard features, or features that are common but implemented with a wide variety of semantics, have to be out of scope for CMIS 1.0. When features are exposed through CMIS, there is a duty to make sure that this can be done by almost everyone without rethinking the repository's architecture.

Retention & Hold

For those not familiar with the terms, a retention policy describes the rules along which documents will be kept for a certain time then archived or destroyed, and holds are typically put on documents for legal purposes to prevent their destruction when companies are being sued or subpoenaed.

A way to specify and discover documents that can have various holds put on them, or various retention policies, is critical to all the Records Management folks. It's not clear what can be standardized though, as there is a huge amount of possible semantics for such policies.

Note also that record management features are explicitly out of scope for CMIS 1.0 (for the very reason that variations between repositories are enormous).

Tagging

While initially it can be seen as very simple concept, tagging is more than just the setting of a multi-valued property (MVP) on a document (a la Dublin Core "subjects"). A complete tagging solution can involve the following features:

• Adding metadata to a tag: tag date and author are typical of the use case here. The tags are then seen as either a "rich" property, or as a relationship (carrying metadata) to a concept in a taxonomy.
• Tagging an object on which one doesn't have write access: this is quite common and typical of the bookmarking community, think "del.icio.us". Of course to allow this you can't use a basic MVP as you don't have write access to the document being tagged.
• Does tagging an object change its last-modification date? This may be constrained by the implementation of the tags.
• Changing many tags at the same time. This is typical of the "tag normalization" use case, where a TagMaster has determined that two tags have to be merged. Some batch modification features may be useful in this case.
• Querying tags for things like: most common tags, less used tags, tags most used together. Also querying for documents in relation to their tags, for instance documents sorted by total tag weight, documents with the most tags, documents most recently tagged. Or even people having added most tags, etc.
• Maintaining the tag cloud, or taxonomy: in a system with many tags, maintaining the tag cloud becomes a full-time job. Having relationships between similar tags, merging them, weighting them, is important.

For CMIS 1.0 this will be hard to standardize, but there's still some time left for something simple to be proposed by interested parties.

comments

Useful article?

 Email It      

Follow @cmswire

Related Articles:

• Alfresco Enterprise 4: Social, Collaborative, Mobile, Cloud Connected Content Management
• Is There A Business Case For Using SharePoint as an Enterprise CMS?
• Liferay Releases Dropbox Style Synchronization for Enterprises

Tags: cmis, cms standards, digital asset managment, document management, enterprise cms, records management

Last week was the first face-to-face meeting of the OASIS CMIS Technical Committee (TC). From my perspective, it was a very productive gathering and allowed for a number of highly constructive discussions. In the following write-up I do my best to retrace the gist of the conversations around the topics I found most interesting, which in some cases were conversations I had with just one or two people.

The outlook from these discussions, and from the scope of the spec itself, is very positive. I believe that within a year CMIS will start to actively redefine the world of content management systems, which will be an opportunity both for big vendors who will see easier adoption of their solutions by customers concerned by lock-in or interoperability issues, and for smaller vendors whose products will be able to take advantage of a much broader spectrum of connectors to third-party systems.