W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > May 2011

Re: Lightweight RDF/OWL library for Java?

From: Oliver Ruebenacker <curoli@gmail.com>
Date: Mon, 2 May 2011 17:19:34 -0400
Message-ID: <BANLkTinG9iOzZviie6yx+Veh6pJeypX=TQ@mail.gmail.com>
To: Jim McCusker <james.mccusker@yale.edu>
Cc: HCLS <public-semweb-lifesci@w3.org>

On Mon, May 2, 2011 at 5:02 PM, Jim McCusker <james.mccusker@yale.edu> wrote:
> On Mon, May 2, 2011 at 4:44 PM, Oliver Ruebenacker <curoli@gmail.com> wrote:
>>  Mostly we are looking for a small library (code). Small API is a
>> plus (and tends to come with small code anyway).
> Looks like this has been discussed at stack overflow:
> http://stackoverflow.com/questions/73445/what-are-some-good-java-rdf-libraries
> One suggestion there that seems to be in line with what you want is
> JRDF (http://jrdf.sourceforge.net)

  Thanks, will look into.

>>  Strongly preferred is a library that works with JDOM, because our
>> project already uses that.
>>  Jena is very powerful and very large. I think with all supporting
>> libraries it adds up to something like 10MB, if I remember correctly.
> Is this a dependency management issue? I generally use maven to track
> dependencies for me, I just have the one entry in for Jena. 10 MB
> isn't that big anymore, in the grand scheme of things. The Stack
> Overflow post has some discussion on how to cut down on the included
> jars.

  Interesting. When I started using Jena maybe five years ago, it
depended on something like 10 libraries. I tried to remove those
libraries and got UnsatisfiedLinkException or something like that for
almost every one.

>> Part of its complexity is comes from its layered structure. Main
>> classes of the API such as Resource, Statement and Model wrap around
>> other classes (Node, Triple and Graph).
> For me, that's been a benefit of using Jena, I can work at the level
> of abstraction that I need, and ignore the stuff at the lower level.

  For my taste, an RDf data model only needs one layer. I started in
Jena with the Resource/Statement/Model level, until I wanted to use
queries, which required the Node/Triple/Graph level. Although, for
most purposes I gave up on using queries for anything more complicated
than what can be accomplished with Model.listStatements(...), because
it costed too much time.

  I like abstraction, but it has a cost when it comes to debugging.

>> A Resource links to a Model
>> which can be convenient but also very confusing if you have multiple
>> models, so I could gladly do without that.
> Almost all APIs support multiple models and/or graphs (depending on
> the API under discussion). Most of my use cases call for multiple
> models, so I'd end up shying away from an API that did away with that.
> :-)

  Misunderstanding. I meant keeping the multiple models and doing away
with resources linking to a model, precisely because the same resource
can be in multiple models at the same time.

     Take care

> Jim
> --
> Jim McCusker
> Programmer Analyst
> Krauthammer Lab, Pathology Informatics
> Yale School of Medicine
> james.mccusker@yale.edu | (203) 785-6330
> http://krauthammerlab.med.yale.edu
> PhD Student
> Tetherless World Constellation
> Rensselaer Polytechnic Institute
> mccusj@cs.rpi.edu
> http://tw.rpi.edu

Oliver Ruebenacker, Computational Cell Biologist
Systems Biology Linker at Virtual Cell (http://vcell.org/sybil)
Turning Knowledge Data into Models
Center for Cell Analysis and Modeling
Received on Monday, 2 May 2011 21:20:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:46 UTC