python libSBOL

[Sung won Lim]

Hey guys

I've been trying to take a look at the python SBOL library on the main page with some of my igem teammates and we could certainly use some form of documentation. Any links you can give us? 

-sung 

[Cesar A. Rodriguez]

Sung,

The python library is not being actively developed at this point.  We're presently working on a Java library:

https://github.com/SynBioDex

Once SBOL is a formally funded project the goal is to develop a C library.  The C library would breath life into a Python library project.  Using Jython, you can target libSBOLj using Python:

http://www.jython.org/

Cesar

[allan_k...@agilent.com]

How widespread would demand be for a python library?

[Sung won Lim]

Well python version would certainly be easier to use for biologists without CS background, for one thing. I know lots of gradstudents and almost all of them have experience with python, almost none (at least around wetlab) with Java. 

-sung

[Chris J. Myers]

Wetlab biologists would hopefully not be the ones writing the tools.  Hopefully, we (non-wetlab biologists) can provide useful tools.

Chris

[4phl...@gmail.com]

I was thinking more about user end of things.

Besides, I'm talking about undergrads and grads (I'm an undergrad myself by the way). If there's such a strong tech divide at that stage of education something's wrong, IMHO.

-sung

---

From: "Chris J. Myers" <my...@ece.utah.edu>

Sender: synb...@googlegroups.com

Date: Tue, 6 Sep 2011 06:43:58 -0600

To: <synb...@googlegroups.com>

ReplyTo: synb...@googlegroups.com

[Deepak Chandran]

Sung,

Can you give us use cases of how you plan to use SBOL? What Chris
pointed out in his last email in this thread is that SBOL is an
exchange format for software tools, so it is expected that anyone
using SBOL is involved in software development in some way. SBOL is
not intended for the end-user. Software tools using SBOL will provide
the end-user interface. Its difficult (not impossible) to be an expert
in everything, so you can expect "tech divide" at all stages of
education.

--
Deepak

--
Deepak

[Raik Gruenberg]

Although, I hope there is no need to ask for use cases for Python
support, is there ;) ?
After all, we are talking about one of the, at most three, most
popular programming languages in science (and I don't mean to say it
is ranking third). Anyway, the plan to support many different
languages from a core C-library is the most general and professional
approach -- nothing to add to Cesar's response really.

Sung,
while libSBOL is not yet supporting Python, there are many Python
tools that support the parsing and writing of OWL/RDF. The SBOL format
is nothing else than a (still very simple) OWL/RDF document. So it
should be quite easy to access them. I don't have hands-on experience
with the recent tools but if you find one, I can help you quickly
mapping things into python classes.

Perhaps somebody else on this list can recommend a good Python module
for OWL/RDF reading + writing?

/Raik

[Michal Galdzicki]

All the original SBOL work was done in python. Specifically because it is a great language to use to get started on a project. Python is used widely because there is little overhead to using it. That being said, if computing speed is going to be an issue, python is not a great choice. Big software project are unlikely to use it either because its harder to maintain a large python code base over time (so i've been told). 

the libSBOL, which is out of date, http://sourceforge.net/projects/synbiolib/ uses 

http://www.rdflib.net/

this RDF library is actively maintained.

other RDF python libs I've seen are:

http://librdf.org/docs/python.html

Which is a C library with python bindings.

there are others but I dont have any experience with them.

mike

[Deepak Chandran]

I was just rethinking about what me and Chris said earlier that SBOL
is primarily for programmers and not end-users. While that is true,
the boundary is probably not to sharp. There are probably several
end-users who want a scripting interface (i.e. python, perl, ruby,
matlab, etc.) for using SBOL files. I don't know whether the scripting
interface should mirror the current data model or whether the
scripting interface should provide a cleaner/conventional set of
classes and methods for using SBOL to ease the amount of learning that
the end-user needs to do.

--
Deepak

[Raik Gruenberg]

Ah, please Deepak, please get this "Python is not for serious
programmers" idea very quickly out of your mind. And lumping it into a
"scripting" basket together with Perl and Matlab is only adding insult
to injury.

A standard for the exchange of data between different software, of
course, should be supported on as many languages as possible. That's
the point of a data standard. Otherwise we could just send serialized
Java classes back and forth. Of course it's also fine to focus
resources and get things started in one language. But please keep in
mind that Java more than other languages is a kind of island solution.
For example, I cannot use any of the great work you guys put into the
Java libSBOL -- not because I don't know Java (I have programmed
extensive Java libraries myself) but because all my own software
infrastructure is based on Python and that is since long my preferred
language. For other people it will be C++ or C# or Drupal PHP. This
has nothing to do with being "professional" or not.

OK, enough language religion. If anyone on this list gets to the point
to port things to other languages (a single C library should be able
to serve all non-Java languages mentioned), I would be happy to help
with optimizing the Python side.

Greetings,
Raik

On Tue, Sep 6, 2011 at 8:25 PM, Deepak Chandran

[Deepak Chandran]

My apologies for incorrectly classifying Python. Its definitely one of
my preferred languages as well. There are (or maybe were) plans to
create a C library for SBOL, which would automatically extend to
Python and several other languages. Lack of money and time are the
limiting factors, not interest.

--
Deepak

[allan_k...@agilent.com]

We/Agilent would consider putting some resources into building a python implementation for SBOL, once the Java reference implementation is solid.

AllanK

[Cesar A. Rodriguez]

Raik and Sung,

> while libSBOL is not yet supporting Python, there are many Python
> tools that support the parsing and writing of OWL/RDF. The SBOL format
> is nothing else than a (still very simple) OWL/RDF document. So it
> should be quite easy to access them. I don't have hands-on experience
> with the recent tools but if you find one, I can help you quickly
> mapping things into python classes.

It's even easier than that. The SBOL Core Data Model will be encoded into regular XML:

https://github.com/SynBioDex/libSBOLxml

You'll be able to read in an SBOL XML file or transmission into a Python app that has a regular XML parser and start operating on the data. We've also experimented with JSON (Javascript Object Notation) encoding. For example, a list of BIOFAB constructs can be requested from the Data Access Web Service in JSON format:

http://biofab.jbei.org/services/data/constructs?format=json

You can read in this list with the standard Python library:

http://docs.python.org/library/json.html

The documentation for the Data Access Web Service is here:

http://www.biofab.org/data/docs/daws

One of the goals of the SBOL project is to make modular the data model and the encoding/decoding technology. This allows us to transmit the data in different platform-independent formats.

Data wants to be free!

;-D

Cesar

[Cesar A. Rodriguez]

Raik,

>
> OK, enough language religion. If anyone on this list gets to the point
> to port things to other languages (a single C library should be able
> to serve all non-Java languages mentioned), I would be happy to help
> with optimizing the Python side.

It's simply a matter of money and time. A C/C++ SBOL library has to be developed.

If you want to grab Mike's Python code and breathe new life into it, there's plenty of room on the SynBioDex Github site:

https://github.com/SynBioDex

SBOL has momentum, I would highly encourage the Python programmers among us to take arms and defend your territory (metaphorically speaking) and start building SBOLpy . If Agilent is willing to give a hand after libSBOLj is stable and maturing, then I'd say start the party now! All libraries go through many iterations before they stabilize.

:-D

Cesar

[Raik Gruenberg]

OK, looks like I am the one who was language-religious then ;)
I was under the impression the C library project was funded and on its way...

I browsed a bit through the libSBOLj code. With a team of two or
three, it shouldn't be too much trouble to create a Python equivalent.
The whole point of the project is of course the input / output into
the different formats. Python has XML and JSON support built-in. But
the python rdflib is quite low-level. For the java project, you guys
seem to have found a very nifty rdf -> object mapper. There are two
or three python libraries that provide something similar on top of
rdflib. But we will have to see how good they are.

Allen, I won't rush ahead by myself but if you have someone at Agilent
who would also be interested, give me a shout. Waiting for the first
official java libSBOL is also a good idea though.

Greetings,
Raik

[allan_k...@agilent.com]

Raik, let me talk with a couple of people and see if we can work something out.

Cesar, is a C/C++ SBOL library a dependency?

AllanK

-----Original Message-----
From: synb...@googlegroups.com [mailto:synb...@googlegroups.com] On Behalf Of Raik Gruenberg
Sent: Wednesday, September 07, 2011 1:20 AM
To: synb...@googlegroups.com
Subject: Re: python libSBOL

[Cesar A. Rodriguez]

Allan,

A C/C++ SBOL library would give the Python library a rock solid foundation and allow for other interpreted languages to use the library. The C/C++ libSBOL could also be used in Objective-C applications; the native language of the Mac, iPhone, and iPad. Needless to say, I'm very interested in a C/C++ libSBOL :-D

With all that said, SBOLpy can proceed without C/C++ libSBOL. Mike took the Python SBOL library pretty far before our attention shifted to Java. I've felt pretty bad about that. Seeing that library move forward would allay some of my guilt and bring a useful library to the game.

Cesar

[Timothy Ham]

On Sep 6, 12:25 pm, Raik Gruenberg <raik.gruenb...@crg.es> wrote:
> Ah, please Deepak, please get this "Python is not for serious
> programmers" idea very quickly out of your mind. And lumping it into a
> "scripting" basket together with Perl and Matlab is only adding insult
> to injury.

As a recovering Perl programmer, I am insulted. :) :)

[Timothy Ham]

On Sep 7, 9:17 am, "Cesar A. Rodriguez" <one.semin...@gmail.com>
wrote:

> A C/C++ SBOL library would give the Python library a rock solid foundation and allow for other interpreted languages to use the library.

I respectfully disagree with this precept.

If SBOLlib is an algorithm library, then using c/c++ for
implementation and python/perl/etc as wrappers would be fine. But it
is not. SBOL is a model representation, and each language would need
its own implementation tailored to its own peculiarities. For example,
in Java it makes sense to represent strand direction as Enums, which
is not appropriate for perl or python. One of the best things about
python and perl is introspection, and these users will not be happy
pushing around binary c objects.

This is why I feel that once SBOL model schema is defined and
stabilized, the second thing to work on is an agreed upon
serialization, and libraries to read-write those serializations in
each language. Yes, it is dull boring work, but if SBOL is to become
useful ASAP, I feel that should be the priority.

And yes, imagine imagine the dull, boring task of keeping them all in
sync as SBOL changes. Best of luck to us all.

Tim

On Sep 7, 9:17 am, "Cesar A. Rodriguez" <one.semin...@gmail.com>
wrote:

> Allan,
>
> A C/C++ SBOL library would give the Python library a rock solid foundation and allow for other interpreted languages to use the library.  The C/C++ libSBOL could also be used in Objective-C applications; the native language of the Mac, iPhone, and iPad.  Needless to say, I'm very interested in a C/C++ libSBOL  :-D
>
> With all that said, SBOLpy can proceed without C/C++ libSBOL.  Mike took the Python SBOL library pretty far before our attention shifted to Java.  I've felt pretty bad about that.  Seeing that library move forward would allay some of my guilt and bring a useful library to the game.
>
> Cesar
>

> On Sep 7, 2011, at 8:04 AM, allan_kuchin...@agilent.com wrote:
>
>
>
>
>
>
>
> > Raik, let me talk with a couple of people and see if we can work something out.
>
> > Cesar, is a C/C++ SBOL library a dependency?
>
> > AllanK
>
> > -----Original Message-----
> > From: synb...@googlegroups.com [mailto:synb...@googlegroups.com] On Behalf Of Raik Gruenberg
> > Sent: Wednesday, September 07, 2011 1:20 AM
> > To: synb...@googlegroups.com
> > Subject: Re: python libSBOL
>
> > OK, looks like I am the one who was language-religious then ;) I was under the impression the C library project was funded and on its way...
>
> > I browsed a bit through the libSBOLj code. With a team of two or three, it shouldn't be too much trouble to create a Python equivalent.
> > The whole point of the project is of course the input / output into the different formats. Python has XML and JSON support built-in. But the python rdflib is quite low-level. For the java project, you guys seem to have  found a very nifty rdf -> object mapper. There are two or three python libraries that provide something similar on top of rdflib. But we will have to see how good they are.
>
> > Allen, I won't rush ahead by myself but if you have someone at Agilent who would also be interested, give me a shout. Waiting for the first official java libSBOL is also a good idea though.
>
> > Greetings,
> > Raik
>

[Cesar A. Rodriguez]

Tim,

>> A C/C++ SBOL library would give the Python library a rock solid foundation and allow for other interpreted languages to use the library.
>
> I respectfully disagree with this precept.
>
> If SBOLlib is an algorithm library, then using c/c++ for
> implementation and python/perl/etc as wrappers would be fine. But it
> is not. SBOL is a model representation, and each language would need
> its own implementation tailored to its own peculiarities. For example,
> in Java it makes sense to represent strand direction as Enums, which
> is not appropriate for perl or python. One of the best things about
> python and perl is introspection, and these users will not be happy
> pushing around binary c objects.

You make a good point. I am thinking of a C/C++ foundation along the lines of it's power to execute algorithms. We really haven't put much thought into a C/C++ library since the funds aren't there. This has to be analyzed carefully.

>
> This is why I feel that once SBOL model schema is defined and
> stabilized, the second thing to work on is an agreed upon
> serialization, and libraries to read-write those serializations in
> each language. Yes, it is dull boring work, but if SBOL is to become
> useful ASAP, I feel that should be the priority.
>
> And yes, imagine imagine the dull, boring task of keeping them all in
> sync as SBOL changes. Best of luck to us all.

Another good point. Maintenance can be the killer of SBOL if we're not disciplined. This is a very valid concern. We should reserve a significant amount of time at the next SBOL workshop to discuss long term maintenance of the libraries and synchronization of the releases. As you stated, boring but critical work. To make it even more challenging, academia does not reward this kind of work.

This is a worthy challenge to surmount!

Cesar

[Lucian Smith]

There are indeed niceties in different languages it would be nice to have,
but if you want general uptake of the format, I believe it will be best to
have a single code-base, and that means C/C++, since you can wrap that
with SWIG for the other languages.

This is not to say that native-language implementations wouldn't be nice,
because they would, but that leads to a maintenance nightmare for anything
remotely complicated, not to mention that people start demanding and
expecting features from one version of the library in all versions of the
library.

There are a few reasons SBML is so well-supported by so many tools today,
but the main reason (and requirement) can be summed up in one word:
libsbml.

-Lucian

[Deepak Chandran]

I know that SWIG automatically converts C structs into python classes
and C strings to python strings. Arrays (lists, tuples, etc.) is where
we get into trouble. IF arrays can be avoided as parameters/return
types, then a C library would work fine for python users as well.
Using the C library inside python will looks just like regular python
modules.

--
Deepak

[Matthew Pocock]

On 7 September 2011 18:26, Lucian Smith <lps...@spod-central.org> wrote:

There are a few reasons SBML is so well-supported by so many tools today,
but the main reason (and requirement) can be summed up in one word:
libsbml.

This is both the best and worst thing about SBML. Having libSBML means that it's available to many SWIGable languages, which gives good penetration for low developer effort. But, it also means that in these languages you end up with something that looks and feels like a foreign C API embedded in your scripting language with the associated issues with how exceptions are handled, what happens with nulls, how collections are presented, introspection and so on. So, at the end of the day there's a value judgement about this trade off.

Matthew

 

-Lucian

[Raik Gruenberg]

Best would probably be if someone who knows how to do it (not me
unfortunately) could give it a try, create some (simple) SBOL C / SWIG
prototype and then we can all look at the issues. One could also add,
for example, some Python candy in an additional layer atop an
automatically generated library. That's still better than
re-implementing all the import, export, consistency checking, etc.

Some former colleagues of mine were working on the CCPN project for
NMR data exchange. They had a fully automatic generation of Java,
Python, and C libraries. If I remember correctly, they used some
commercial tool for that. I could ask for their experience if you
like.

[Chris J. Myers]

Welcome Lucian!

I completely agree with this. We should move next on the C++ with swig bindings.

Chris

Sent from my iPhone

[Timothy Ham]

On Sep 7, 10:29 am, Deepak Chandran <deep...@u.washington.edu> wrote:
> then a C library would work fine for python users as well.
> Using the C library inside python will looks just like regular python
> modules.

Well, not exactly.

A purely python implementation of libSBOL would work anywhere python
is installed (Win, Mac, Linux, etc). A SWIG wrapped libSBOLpy would
need a swig compilation for the architecture in addition to python.
This means a Windows, Mac, Cygwin, various flavors of Linux, would
need their own libSBOLpy compiled for them, hopefully in both 32 and
64 bit versions.

There is no really getting around the issue of either providing for
different languages, or providing C for different architectures. I'm
not tied to either, but this should be voted on before anything
happens in this direction.

I would suggest SBOL (since SBOL is a interchange format, not an
algorithm library), provide the model, a standard serialization
format, some starting points in different languages, and one reference
implementation. Updating of other languages should be done on demand
basis or by the users themselves.

Tim

[Chris J. Myers]

Tim,

I just cannot imagine that we will ever have the financial resources to do what you ask. I agree that it is ideal, but we are having trouble right now keeping one language up to date. What I think is best is that we do a C/C++ with Swig which is the golden one (like libsbml), and others can always develop others for other languages and hopefully release them to the public. However, if we are fortunate enough to get funding for SBOL soon, the priority has to be having one solid foundation to start with.

By the way, my proposal is for after we have funding. We have a start for libSBOLj, and I think we should keep that one going for the time being.

Chris

[Chris J. Myers]

Ok sounds like we are on the same page. Even with SBML, libsbml is only a reference. Some people write their own though they tend not to keep up with updates.

Chris

Sent from my iPhone

[Timothy Ham]

Well, then why are we writing the reference implementation of SBOL in
Java? Clearly, C/C++ would provide the most benefit for the buck. It
would be nice for the Editors to chime in here.

Tim

[Chris J. Myers]

Tim,

We don't have any bucks :-).

The idea is to get something quick now so we can start testing. Java seemed the best for that and early use cases.

When we have some bucks, hopefully before to long, I agree with you. I'm nervous to switch at this moment as we need something for the DARPA BAA soon.

Chris

Sent from my iPhone

[Cesar A. Rodriguez]

Raik,

>
> Some former colleagues of mine were working on the CCPN project for
> NMR data exchange. They had a fully automatic generation of Java,
> Python, and C libraries. If I remember correctly, they used some
> commercial tool for that. I could ask for their experience if you
> like.

I'm very interested in hearing about this tool.

Cesar

[Cesar A. Rodriguez]

This issue was debated before. The decision was to go with libSBOLj as the reference library. We have to complete libSBOLj first.

The discussion we're having is for the future when SBOL is a formally funded effort.

Tim, as you mentioned, SBOL is fundamentally a spec. If Raik and associates want to build a Python library that complies with the spec all I would ask is that the effort be housed at the SynBioDex site on Github so we have a central place to keep track of these efforts and encourage cross-pollination:

https://github.com/SynBioDex

Cesar