Some suggestions about the future of this effort:
(1) So far, meetings have been based on a small group of active
regulars, and often, not enough of them are available to have a
meeting, which causes uncertainty and frustration. There could and
should be more participants, as there are many people both in the city
and in the world who do use semantic web for biological pathways and
therefore would benefit from us and we from them. We should try to
reach out more and gain new members, both in the Boston area and
beyond.
(2) We started out with the plan to develop an OBO-compliant
alternative to the current draft ("BioPAX-DX") for BioPAX Level 3 and
chose our name - BioPAX-OBO Workgroup - accordingly. The status of the
original plan is at this time, at best, unclear. Meanwhile, I think we
are better described as a group of people exchanging ideas about
Semantic Web methods applied to biological pathways, which has more
tangible immediate benefits than the original plan. To attract new
people, it would be wiser to change our name to reflect this: Some
name that contains the keywords "pathway" and "semantic" would appeal
to many more people than our current name, which appeals only to those
who know and understand the benefits of BioPAX and OBO.
My suggestion for a new name would be "Semantic Pathway Club".
(3) All or almost all of our active regulars seem to be member of
the Health Care and Life Science Interest Group (HCLSIG) of the World
Wide Web Consortium (W3C). The HCLSIG has a handful of sub groups, and
I have long had the idea of suggesting to form a new subgroup for
pathways. I don't know what the process or the requirements are to
form a new subgroup, but my impression is that if a handful of people
show interest, it would be done. I also assume that we could continue
our current meetings as meetings of the subgroup and that it would be
possible to have the meetings of the subgroup open to non-members.
These meetings would then be joint meetings of the HCLSIG subgroup and
us (with most of us being part of both). I would assume that the fact
that something is already happening rather than building something
from scratch would sound good to the HCLSIG.
Becoming an HCLSIG subgroup has a number of advantages. They provide
great infrastructure, including Wiki and meetings that combine web
chat and phone conference. Essentially the type of things we are
using, but provided in a more unified and professional way. We might
also get a staff member of the W3C to help us, perhaps with a more
professional approach to convening our meetings than I can provide,
and perhaps with the capability to book rooms at the MIT (I always
have to ask Jonathan, which complicates matters).
But most importantly, our work would be known to a larger audience
and connect to other interested parties.
I am also planning to build collaborations on SBPAX and hope to one
day submit SBPAX to the HCLSIG for consideration as a W3C
recommendation.
Take care
Oliver
--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
> Hello Jonathan, All,
>
> What could be more philosophical than a historical argument?
>
> I am not aware of the needs of Science Commons being a factor in our
> discussions so far, but that doesn't mean we can not deliver what
> Science Commons needs. Do you have a more detailed formulation of what
> Science Commons needs and why?
Not detailed, but I can outline the general shape. The Science Commons
Data Project is trying to explain and demonstrate to the world the
value of porting data and "knowledge" to one (or, if necessary, more
than one) common 'platform' - think Linux distributions and their
populations of packages, noting that you can load packages together
into the same system build by virtue of their having and using more or
less compatible interfaces. The demonstration platform consists of
RDF, OWL, SPARQL, and other web standards, and a method for steering
'knowledge representation' so that the same information tends to be
expressed in the same or similar ways even when it comes from
different sources - this is hard, and while OBO Foundry methodology
may not be perfect, it's the best thing we've got, and it has a great
community around it, so we're pushing its use for this goal.
So for pathway information, such as that from Reactome, KEGG, Ecocyc,
etc., which we would definitely like to include in our distribution
and triple store ASAP, the best path forward we've come up with is to
do ports that are along the OWL and OBO Foundry lines. If there's a
better way that has the promise of promoting scalable data
integration, I'd like to hear about it. The bottom-up approach
advocated by Tim Berners-Lee and others (including, I would say,
BioPAX DX), where you just do whatever's easiest and wait to fix
incompatibilities until you get stuck, seems to me less efficient than
the more coordinated approach taken by OBO (GO, etc.), but only time
will tell how the mix of coordination practices will evolve.
So if you want to do something for Science Commons and its mission,
figure out how to represent Reactome et al. in a way that will
contribute to a scalable data/knowledge ecosystem, i.e. has the best
possible chance of permitting graceful connections with unknown other
information (phyolgenetic, chemical, classical genetic, anatomical,
simulation, etc.) and attempts to forestall the threat of future
refactoring crises.
My guess is that your interest is not too far off from this; I'm just
stating my project's viewpoint so as not to presume about anyone
else's needs.
We're not paying you, so anything you do that helps is a gift.
Jonathan