Some folks have used the dmoz data. It is in RDF, so should be fairly flexible enough to get into most databases using most languages and an RDF library.
This question sucks. Not because of the post or the person who did it, but because it is one of the gaping holes of "Enterprise" class software. I have some first hand Documentum experience, and I can only say thank heaven for Jython. It has been a serious time saver in learning the internals of Documentum's API.
As far as CMS software goes, Documentum is one of the better that I have had to deal with (compared to Interwoven, Vignette, Stellant), and the API really is simple to use once you dig through the layer of Java / OO Design cruft that some developer types like to throw in the way of getting things done.
A few questions need to be asked and answered before you can ever migrate content from other systems. First is a survey of what kind of content you are trying to pull, is it structured and tagged or categorized well, like XML in Docbook format? Or, is it old 1996 HTML crap that years of users and Frontpage or Dreamweaver have thrown out to the corporate intranet? If it is the latter I suggest looking at a nice emerging company that handles this well called Nahava. (I am not affiliated, but I think their tech is well done after working with them a bit)
After this is done, you have to decide what you want the new CMS to store. Are you going to fit all the old stuff to some fancy new taxonomy that a big brain strategerian has come up with, or is it a straight over migration, with 3 root folders, one for each of the old systems. Is it possible to do both by putting some of the Documentum features to use?
Anyway, there are a million things to answer in this process, good luck!
Curious for more about this story, the best background I found was here.. Also, this bill seems to be starting down a better path toward a publicly viewable system. Not sure about the paper trail part though.
Slashdot Mirror
Some folks have used the dmoz data. It is in RDF, so should be fairly flexible enough to get into most databases using most languages and an RDF library.
This question sucks. Not because of the post or the person who did it, but because it is one of the gaping holes of "Enterprise" class software. I have some first hand Documentum experience, and I can only say thank heaven for Jython. It has been a serious time saver in learning the internals of Documentum's API.
As far as CMS software goes, Documentum is one of the better that I have had to deal with (compared to Interwoven, Vignette, Stellant), and the API really is simple to use once you dig through the layer of Java / OO Design cruft that some developer types like to throw in the way of getting things done.
A few questions need to be asked and answered before you can ever migrate content from other systems. First is a survey of what kind of content you are trying to pull, is it structured and tagged or categorized well, like XML in Docbook format? Or, is it old 1996 HTML crap that years of users and Frontpage or Dreamweaver have thrown out to the corporate intranet? If it is the latter I suggest looking at a nice emerging company that handles this well called Nahava. (I am not affiliated, but I think their tech is well done after working with them a bit)
After this is done, you have to decide what you want the new CMS to store. Are you going to fit all the old stuff to some fancy new taxonomy that a big brain strategerian has come up with, or is it a straight over migration, with 3 root folders, one for each of the old systems. Is it possible to do both by putting some of the Documentum features to use?
Anyway, there are a million things to answer in this process, good luck!
Curious for more about this story, the best background I found was here.. Also, this bill seems to be starting down a better path toward a publicly viewable system. Not sure about the paper trail part though.