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 <nitin@borwankar.com> 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
>>
>>
>>
>>
>>
>>
>
>
>
|