It was hiding there is plain site for, well I am not sure how long, I guess I just missed the memo on that one.  Very interesting though.  For those of you who are curious about what a JCR is, it stands for Java Content Repository and though it uses the word “Repository” it’s really more of a connector.  The big thing about it is that it’s a Java standard, specifically the JSR-170 standard actually.

BEA(now Oracle) WebLogic as well as WebCenter(the flagship portal of the Oracle fleet) both communicate to content management systems using a JCR.  UCM and before that Stellent have both traditionally not provided a JCR, rather they provided a pretty robust API known as the Content Integration Suite.  From the new document(and of course it’s location) it appears that the JCR is more or less a wrapper on top of CIS.

The Swiss are Clever

The JSR-170 standard has an interesting history.  It was submitted by Day, a CMS vendor out in Switzerland.  Thier content managment system(and I may be messing this up a little) Communique, leverages a proprietary content repository called CRX which of course is a JCR(and most likely the first).  The thing about Day though is that they are Swiss, and so very clever.  While many CMS vendors had interesting and/or creative content repositories, Day not only touted theirs as the best, they also submitted it as a Java standard.

Since then a number of other vendors began supporting the standard.  Apache released Jackrabbit, I think Vignette uses it too, but really when BEA started adopting it in Weblogic, it became quite a bit more credible.  The Day team and of course the standards committee has since updated it, there’s now a new version known as JSR-283, though I have not seen much use yet.

My Somewhat irrational dislike of the JCR standards

I really don’t like the JCR standards and my reasons really aren’t all that good.  There’s nothing technically wrong with them.  I think they are somewhat on the simple side, but honestly for a standard simple is probably better.  My problem really stems from the fact that they are Java based in a multi-language world.  Having a CMS with a standards-based connector that oh-by-the-way only works in Java, doesn’t make a whole lot of sense.  All of your content consumers must then be in Java, and that just really limits the whole “Enterprise” piece of the Enterprise Content Management system.

The unfortunate thing I would see though was that many CMS vendors would market their support of the JCR standard as a sort of money back guarantee for buying their product.  ”Go ahead and buy our CMS and if you don’t like it you can just switch it out with another, we support the JSR-170 standard”.  While of course that was technically true from a 10k foot level, I am sure the reality of the implementation was much different from the sales presentation.  Of course overcoming the “money back guarantee” argument with “the standard should not be Java-specific” never went over very well though.

Things are looking good

Despite my somewhat irrational dislike, I am pretty excited about this new connector.  There are a number of applications that support JCRs(though most of them serve like UCM), including a Spring module.  In addition it looks like there may be some movement on getting a “Service-like” standard for content repositories and actually we would have the JCR to thank for it.  Back in December, BEA filed a patent for a JDBC-like services wrapper for the JCRs.  Though many folks weren’t too crazy about the fact that they filed a patent instead of just releasing a connector, I think this is a pretty positive move.  Oracle obviously owning BEA won’t hurt the future UCM integration either I’m sure.

However it’s done, I think their server has a huge amount of potential from an ECM perspective.  Nearly every client of mine has asked about offering some level of automation to their meta-tagging while contributing content.  While many of the enterprise vendors offer applications to automatically tag content, I find that they are usually focused on batch loading or migrating content, rather than assisting the every day contributor.  In my ideal world I’d love to see contribution forms come up pre-loaded with system recommended meta-data, allowing contributors to make only necessary edits and then simply approve thier submissions.

I was pretty pumped when I ran across Yahoo’s service, so I decided to throw together a quick component to take advantage of it for  Stellent / Oracle Universal Content Server.  Nothing too crazy here, the component basically adds an additional option to the Content Action menu called “Add Yahoo Terms”, which executes a service called “ADD_YAHOO_TERMS”.

The service then does the following:

• Performs a dynamic conversion on the document
• Reads the contents of the resulting HCST output file
• Posts the HTML to Yahoo’s Terms Extraction service
• Parses(XML) the terms returned
• Creates a comma delimited list of the best terms
• Saves the list to the binder in a predesignated memo meta-data field(the default is xComments)

The remainder of the service is basically the GET_UPDATE_FORM service, which brings up the update form.  Since the terms are in the binder as a meta-data field, the update forms comes up pre-loaded with the document’s meta-data as well as the Yahoo terms in the pre-designated field.  From there on you are on the standard Stellent / Oracle update form, so saving will commit your changes.

It’s a pretty simple integration, nothing revolutionary, but I think it’s a decent example of how one might integrate Stellent with Yahoo’s service.

Feel free to download the component here:

Yahoo Terms Extractor Integration for Stellent / Oracle

The reality of course is that content consumers also have their own subjective idea of how each piece of content should be categorised and when the two don’t mesh there’s a disconnect.  The standard ECM answer here is that if there is a disconnect like that you’re metadata model is probably broken.  But what if instead of our standard model contributors were able to add multiple different contextual records to a content item?  You’re now looking at a variety of different search paths to the same piece of content as well as the ability to provide different metadata for different uses.

The question that comes up of course is “Couldn’t we accomplish the same thing by adding more fields?”.  And the answer is probably not.  Adding more fields means that users must know where to look or must look in multiple places to find what they are looking for.  If theoretically there were multiple dimensions of metadata for a single item, there would be different paths to the same content.  Dimension one’s description may not match the search criteria, but dimension two’s does.

I started thing about this, while working with a pretty sizable taxonomy implemented as a six field dynamic choice list in then Stellent(now Oracle).  What I kept running in to were documents which could easily be assigned to multiple locations in the taxonomy.  In some of them, each paragraph was applicable for a different location.  So why not let it happen? 

In addition, having only a single record puts an emphasis on getting the metadata right the first time.  I believe that if systems could support multiple records, authors might feel more comfortable using tagging automation.  Perhaps 5-10 dimensions of metadata added through automation could be just as effective as a single record manually input?