As you hopefully know by now, CMIS 1.0 was released for public comment thru December 22nd, and the excitement is building in the community and the press. If you haven’t looked at it, and want to provide feedback on the CMIS standard, the time is now.
For more information on what CMIS can do for you, here are some useful references, including three of my posts on the topic (newest first):
- Three Fundamental CMIS Use Cases: A slide-show introduction to CMIS and the types of business problems it is trying to solve.
- CMIS, Beauty is More Than Skin Deep: Addressing how CMIS is more than just what you see in the spec. With some creativity, CMIS can address more use cases than the creators set out to do in version 1.0.
- Vendor Support for CMIS: Here I talk about the importance of vendor support for the standard. So far, so good.
- The Gilbane Group, with the support of OASIS and several ECM vendors, has produced a Beacon report that is freely available from their website after you register. It is a pretty solid write-up of what CMIS is and what problems it solves.
- Advanced CMIS: Written by Florent Guillaume of Nuxeo, this write-up covers many of the concepts supported by CMIS beyond your Basic Content Services.
- Three Reasons to list CMIS in your Document Management RFP: The folks over at CMS Watch, specifically Alan Pelz-Sharpe, provide some insight as to why you should care about CMIS now, even if you are just getting started. Nice to see them agree with my assertions from March.
I’ve been looking at CMIS 1.0 from a functional perspective, along with some others in the community. If I want to solve business problem X using a CMIS-based application, what do I need? What would make things easier? Using my experience from building the AIIM iECM demo and many discussions with others in the industry, I’ve come up with a few things that I’d like to see CMIS support in 2.0.
Note the assumed nature of the next version of the spec. If there isn’t another version coming, then what is the point?
Advanced Metadata Support
There are a few gaps in the metadata model support. This realization came about while trying to solve some business problems with CMIS with some others in the ECM space. We were looking at how well CMIS might support the modeling of different knowledge domains. We were also trying to think of some of the folksonomy tagging approaches in the world of Enterprise/Web 2.0.
Two areas for enhancement were readily identified:
- Hierarchical Metadata: This is roughly defined where the value of one metadata field drives the value of another metadata field(s). I personally dealt with this most often in the legal industry with the Client/Matter fields. To support this now, you have to set and save the parent field and then run the lookup on the child field.
- Tagging: Right now, CMIS does not support tagging. You can have a repeating field, but it is assigned per object and doesn’t handle different people wanting to apply different sets of tags. If I tag it one way and Sarah tags it another way, the resulting collection of tags should be aggregated and displayed as a small tag cloud. The underlying ECM system would determine the weights for each value (Authority, number of tags…), but CMIS needs to support individual tagging and the retrieval of tags that includes weighting and the set of tags the current user has set. This support would need to include strong querying capabilities.
Okay, we have some areas for improvement, but now we need to look at the gaps in managing these domain models.
Managing Metadata Models
One thing I learned from the AIIM demo was the need to be able to define and query a logical domain model that was distinct from the implemented physical model on the repository side. There is some initial support there with the localName representing the repository’s name for a field and the queryName representing the logical name, but no way to collectively manage them.
The issue is that while there is some support for a localNamespace, but no corresponding queryNamespace. I cannot create and plug-in a custom domain model.
Let’s think about this for a second. Let’s take the AIIM demo domain model, AIIMContent. Let’s say I more thoroughly defined it and published it, creating some URI. Vendors, or integrators, should be able to create a back-end implementation for the model for any desired vendor.
Then, using CMIS, I could query to see if the AIIMContent domain model is supported by the current repository. If it is, then I can create that supported object type(s) and query the objects using the universal names (queryName) of the metadata attributes without know any of the implementation details in the underlying repository.
This feature is not there. When the AIIM demo was created, I had to map, in my code, each attribute name. All three vendors implemented the model with different naming conventions within their repository. This support for common domain models would solve that problem and allow the developers of Content Applications to do that much less grunt work in their code.
Oh, and the support for an “Aspect” type of domain model does not exist either, but I consider that a 3.0 request.
Supporting Semantic Models Through Relationships
One advance feature that Florent didn’t discuss in detail was the concept of Relationships. This is basically relating two content objects to each other with a defined relationship.
Here is where the need for relationships hits the modeling world, Semantic Modeling. Looking at the different scenarios, you can actually create and navigate a nice semantic model using relationships. The only point of failure is the lack of query support.
That’s right. I can create all the relationships in the world, but I can’t include them in a query. I can create a concept as a content-less object and create a relationship from content to that concept, but I can’t create a solid way to retrieve that information without browsing.
Is That All?
I haven’t even touched on Transactions or Identity Management. Those are whole other balls of wax. Look around and throw business solutions out there and figure out how to implement it using only CMIS as in interface. Come up with your gaps.
Keep thinking on it. CMIS 1.0 is an important first step, but we need to make sure that 2.0 continues the progress by solving a broader set of problems.
5 thoughts on “Looking at CMIS 1.0, Thinking of 2.0”
First, I can assure you there is the will for a CMIS 2.0. There even is already a “Proposals for 2.0” section in the OASIS CMIS issue tracker.
I agree that Hierarchical Metadata and Tagging will need to be enhanced. No consensus (or even proposals to be honest) emerged during the 1.0 timeframe.
Regarding heterogenous domain models, I think what you want can be achieved but vendors will need to add some flexibility to the CMIS connectors. What’s needed for your example to work is for vendors to allow application developers to say that, while someone implemented the AIIMContent InfoManTopics field internally as a field “infomantop” with internal namespace “http://example.com/app/aiimcontent/v1”, it must be exposed to CMIS clients with the name “InfoManTopics”. But this has really to do with vendors, not the CMIS spec.
Regarding the ability to query relationships, I actually raised this last Monday in the TC, and it’s been agreed that it’s repository-specific to have this — meaning that a well constructed repository will give you queries on relationships (otherwise I agree with you that relationships would be pretty useless), see http://tools.oasis-open.org/issues/browse/CMIS-602. What’s missing though in 1.0 is the ability to express transitive closure of relationships, which is quite useful in semantic modeling.
Florent, thanks for the comments, here are some thoughts…
– I know there is enthusiasm for working on the next version, but we aren’t there yet and the momentum could always slow down, though I hope not.
– As for hierarchical metadata, line 477 has some confusion ” Choices MAY be hierarchically presented.”, which implies that there was some thought. However, not having it in 1.0 isn’t a failure.
– Domain models, you are right that the vendors would need to adjust their support. It would be a challenge, but it is something that would make life easier everywhere. As I think about it more, the hurdles are significant, but worth it.
– Transitive relationships can be grabbed if the query capability is there and you use sub-queries. A simpler way of doing things would be great, but it would be a challenge to add to the standard if most of the vendors don’t have underlying support.
You can express transitive relationships with JOINed queries, but you can’t express the transitive closure of them. But then hardly any databases do, so I wouldn’t hold my breath here.
Just getting the ability to query against relationships would be good enough. Thanks for contributing.
Comments are closed.