Page Tree:

Child pages
  • 2010-12-9 Conference Call Notes--Content Interoperability

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

Conference Call Meeting Notes

Meeting of CI, BSP and WS leads on Content Interoperability Standards for Bamboo Phase One

4:00-5:00 pm Central, December 9, 2010.

Bamboo conference call participants:

Jonathan Smith (NU)

Bob Taylor (NU)

Tim Cole (UIUC)

Steve Masover (UCB)

Bruce Barton (UW-Madison)


1. Content Interoperability Standards

* There was discussion whether during Bamboo Phase One the Bamboo Services team and CI developers should support multiple content/interoperability standards [for access to content] or, instead, just one. There seemed to be general consensus among the participants on the call that we should hew to one remediation/interoperability standard for exposing content.

* The role of standards

(SMITH) It is important to be clear about how the standards might be used for interoperability. The idea is to create multiple connectors that map whatever we may find in the wild to a standard transport and content formats. Tools would be developed to consume the standard format. The goal is to avoid a many-to-many situation where we end up having to develop connectors for each combination of repositories and consumers.

* New vs established standards for content interchange

(SMITH) The down-side of CMIS is that it is so new, tools and systems that can consume it are not yet common. I am not sure there is a simple answer to this. I would rather expose content via standards-based web services (which CMIS specifies), than target simple but non-standard services (JCR). In the long time, if well designed, the more standardized approach should win out.

* Degrees of standardization

(SMITH) We discussed the problem of standard containers (like CMIS, JCR etc) and the problem of mapping formats and categories. There is really important work to be done in attacking the problem of semantic standardization and can be done nicely for certain constrained content types such as dates and times, geographic location, etc. In many cases these problems are very challenging.

On the other hand content is stored in a great many places using different containers, so there is still work to be done in just providing access.

2. Closer Look at Specific Methodologies and Standards for Bamboo Phase One

* Discussion of the Content Management Interoperability Services (CMIS) standard. Using CMIS for Bamboo seems do-able during the next few years. But are CMIS implementations defined well enough during 2011 to support our Bamboo efforts?

* SWORD (Simple Web-services Offering Repository Deposit) and SWORD 2 tools have significant momentum in the UK with JISC support. Tim suggested that SWORD 2 offers valuable ability to get something done in the short time period of Phase One.

* CMIS looks like a good long-term solution. But CMIS would probably take much more effort to implement into Bamboo Phase One than would SWORD 2 and/or JCR. And it might not be as stable a solution during Phase One as would be the case with JCR or SWSORD 2.

* A simple format for tools to consume (such as Atom Pub)

(SMITH) There is a strong argument for this approach. We would support interoperability by providing both a full-featured container format that supports access to all of the detailed properties of content objects (without translating standard vocabularies and content formats), and at the same time provide a light-weight, more controlled format that could be used to provide enough information to be consumed by tools such as news readers, image browsers, navigation, etc.

(SMITH) Two variations on this theme:

- JCR-Connect uses a simple object model accessed via REST-ful services that provides JCR, JSON, and JPA representations. There is an advantage to an object-oriented approach: you can add new features and detail by subclassing. The JCR-Connect default content model, while simple, is pretty sophisticated in that it can support such things as image annotation and timeline annotation.

- On the other hand there are a lot of existing tools that can consume Atom, RSS2, and HTML, epub, etc. If you target some of those you can use a huge number of existing tools. It sounds as if SWORD is taking this approach.

* Discussion of the JCR Content Model and how that fits with Bamboo architecture plans, Bamboo plans for use of Java.

3. Current NU Work with JCR (this Mellon grant work on interoperability just completed)

* Current NU work with Repository JCR connectors. (1) Fedora. (2) XTF .

XTF work opens door for use of California Digital Library collections in Bamboo Phase One.

* Curent NU work with Client connectors.

* Most NU work with JCR has been with image content. Will this work apply easily to Bamboo Phase One text content?

* CMIS speaks HTTP services rather than Java.

* One might think of the Northwestern JCR work as using JCR as a bus.

4. General Discussion

* Transition from making content accessible è to problems of making content semantically operable (harder)

* It might make sense, and might be most economical in terms of limited development time in Bamboo Phase One, to use JCR connectors for Phase One Bamboo. Then, wait until there are some clear advantages to implementing CMIS for Bamboo. What would be the migration costs in the future, of a migration from JCR to CMIS???

* (MASOVER) We will declare victory if we solve a few cases of (repository and applications) content interoperability for Phase One.

* Hydra/hydrangea is ruby rails/flat// way to get Fedora repository interoperability.

5. Next Steps, particularly in preparation for the January 26-28 meetings in Berkeley

* The conference call group decided we will conduct one (maybe two) "deep dive" conference calls in January, leading up to the F2F meetings in Berkeley. Each of these conference calls in January will include wider invitations (than the December 9 conference call) for other Bamboo Partners to join the conversation. Taylor will post Doodle polls on the project wiki on December 22 for determining best days/times in January for these upcoming conference calls conducted by CI, but including BSP and WS teams.

* If these two calls are as successful as we hope in forming consensus, we (NU,UIUC, WI, UCB) will bring a set of recommended development plans to the F2F Berkeley meetings for work on content interoperability services during Q2, Q3 and Q4 of the Project. Work in Berkeley would include syncing and aligning these proposed work plans with other Bamboo work groups. And make sure we are realistically aligned with the top collections candidates that are identified at the F2F meetings.

  • No labels


  1. Unknown User (

    The following is excerpted from an e-mail exchange of December 2010, in which clarification of Jonathan Smith's assessment of CMIS emerged. These excerpts are included here in advance of (perhaps instead of) making in-line modification to the notes above:

    Masover: I had the impression that Jonathan was much more positive on the call than is represented in the notes about the advisability of utilizing CMIS as our access interoperability interface standard in Bamboo Phase One

    Smith: I am positive on CMIS. In spite of CMIS being so new, its really the only standard-based option right now that is likely to meet our needs as a general purpose container. I would much rather use a standards-based approach. Luckily its not a big jump from JCR to CMIS.

    Masover: As our two Work Spaces environments either implement CMIS interoperability for content they host (in the case of Alfresco ECM) or have been developing plans to do so based on the Mellon proposal declaration that CMIS would be Bamboo's choice for an access interoperability interface standard, I would like to see serious consideration given to how a shift to JCR or SWORD would affect work plans and resource allocations in the Work Spaces area; Bruce (and, by proxy, Noah) can probably shed a bit of light on this.

    Smith: I agree.

    1. I recommend against a shift to JCR. We can easily adapt our current work to CMIS web services, and we should. I would have used CMIS from the start it if had been released a couple of years ago.

    2. I am interested in Atom and JSON (simplified) representations to supplement CMIS – mainly because there is so much software out there that use those. However, having said that, the approach we used for the Connect project would both supply the basic need and much of the spirit. Here is how I described it:

    JCR-Connect uses a simple object model accessed via REST-ful services that provides JCR, JSON, and JPA representations. There is an advantage to an object-oriented approach: you can add new features and detail by subclassing. The JCR-Connect default content model, while simple, is pretty sophisticated in that it can support such things as image annotation and timeline annotation.

    The object model, in effect, provides a series of simplified basic conventions for CMIS (or JCR) content to supplement (not replace) the raw detailed information provided by a participating repository. Having the basic model always to hand though, means there is a common denominator that applications can depend on. And an easy translation to and from POJOs when that is useful.

    A (fairly straightforward) common object model could still have multiple representations. Those might eventually be something like: CMIS, JSON, and Atom with CMIS being the reference. I am also getting the feeling that there may be interest in an RDF representation.

    1. Unknown User (

      I notice that Drupal has a CMIS project ( ) that lists Alfresco and Nuxeo among the participants. Also Ruby ( [ ) and Python ([ ) client libraries.