Demetrius Nunes wrote: > Hi Nitin, > > Great answer. Thanks a lot. One more question... > > I am in the Javaland here, so another viable option for my application is > using JCR, such as the Apache Jackrabbit implementation. > Hi Demetrius, I am a refugee from Javaland so am familiar with the power and limitations of Java. Yes, I have looked at JCR and JackRabbit in a previous project. These days I just recoil from the verbosity and conceptual layers you encounter when coding simple things in Java. And then there's XML..... So I would have held my nose and used JackRabbit if CouchDB didn't exist - but in my mind it's a distant second in practice even if it is conceptually similar and close in theory. Personally when I see layer upon layer of abstraction in Java architecture diagrams I wonder how much of my CPU cost is going in converting from strings, to TypeA to LayeredClassB to factoryC to ORM D to EJB4 to disk and back again all the way to strings. So I am moving away from Java except when the best of breed solution is in Java ( Lucene/Solr) - so I don't hate Java - I just need to justify the overhead that it brings both in coding and in the build/install/deploy process. CouchDB has minimal overhead in roundtrip datatype translations - it's what I call "WYSIWIS" - "what you see is what you store" i.e. JSON. There are people looking at an alternative to LAMP which they call JS3 - Javascript in all three layers - browser/helma/couchdb ( helma, helma.org, is a middle tier layer written in Java, runs on Jetty, uses JS as the language for doing UI templates and also ORM ) - I personally think CouchDB + CouchDBViews just makes it JS2 - browser-CouchDB. I would suggest you download Rhino ( JS interpreter in Java) from Mozilla and start playing with both CouchDB and JackRabbit and then see. Did I sound biased ? :-) Nitin Borwankar, Project Manager, Bibliographic Knowledge Network. bibkn.org > Did you happen to take a look at that as well? I think JCR has even more > similarities with CouchDB than RDF. > > How would you compare JCR and CouchDB ? > > Thanks a lot, > Demetrius > > On Thu, May 7, 2009 at 5:04 PM, Nitin Borwankar wrote: > > >> Demetrius Nunes wrote: >> >> >>> Hi there, >>> >>> We are evaluating new technologies for managing semi-structured data and >>> documents in one of our applications. We've got tired of wrestling >>> relational databases for this. >>> >>> I would like to know why would I prefer to use CouchDB instead of a RDF >>> database, such as Sesame ou Mulgara. >>> >>> I know some of the RDF advantages, such as open standards, >>> interoperability, >>> rules engines, semantic queries, community and tool support, maturity, >>> etc. >>> >>> But I really like the simplicity of the CouchDB model. >>> >>> Can anyone enlighten me? >>> >>> Thanks a lot, >>> Demetrius >>> >>> >>> >>> >> Hi Demetrius, >> >> We ( bibkn.org) have investigated and used SQL databases, RDF store >> (Virtuoso) and CouchDB for bibliographic metadata management. I am the >> project manager and data architect for this project. >> Relnl databases are a first choice often but have many limitations in >> management of loosely typed, messy, string based data sets. So we are in >> agreement on not using that technology. >> >> We, bibkn.org, need both the schemalessness of CouchDB at one end of our >> workflow and the strongly-typedness of RDF at the other end of the workflow >> when all our data has been cleaned up and "ontologized". So we don't see >> this as an either/or between CouchDB and RDF stores. >> However we can definitely say one thing - if you need just the flexible >> schema aspect and are using RDF to give you that, then that is massive >> overkill and the conceptual overhead of the RDF (ontology, schemas, >> namespaces, completely normalized everything ie URI's for subject, >> predictae, object) , is simply not worth it. If however you want to do >> logical inference and reasoning over your data then clearly the RDF and >> semantic machinery gives you a whole lot of goodness that is worth the >> overhead. >> >> So CouchDB is not a substitute for an RDF-store, but you may be using an >> RDF-store for the lesser things it gives you (flexible schema) and in that >> case CouchDB can do a lot more for you at a much lower overhead and much >> greater ease of use and integration into existing tools. >> >> Additionally SPARQL (like SQL) is not really meant for text search which >> is critical for loosely typed data. So even at our RDF end we have a Solr >> instance for rapid text search over the RDF store. >> Additionally we have couchdb-lucene as an extension on our CouchDB instance >> and this has given us everything we need at the loosely typed data end of >> our workflow. >> >> So if semi-structured data and document management is your primary use case >> and there is no semantic/ontology/inference component then forget RDF-stores >> and just go with CouchDB. >> >> In our project we are developing a format on top of JSON to export >> bibliographic metadata for integration into JSON friendly date consumers, it >> also happens to have easy mapping to RDF. >> So even if you go to Couch now you may be able to integrate into an >> RDF-store at some later stage if the need arises. >> >> Hope this helps, >> >> Nitin Borwankar, >> Project Manager, Bibliographic Knowledge Network >> bibkn.org >> >> >> >> >> >> > > >