David Nickerson wrote:
Hi Tommy,
That looks good - its all starting to make sense to me now.
I'm just wondering how your system would handle a case where two authors
independently encode the same published model. The first author to
upload their encoding would get ownership of the
This is my view of where things should be heading:
The main impetus for this thread is moving the cellml.org site
forward. In this sense I would like to see a description of what it
currently does and what features have been informally slated.
Then I'd like to see a document that re-writes these
My $0.02 on this is (please forgive me if I get some of the technical
stuff mixed up):
The current naming scheme is as it translates to the web address is:
author(s)_date_versionXX_variantXX
I think it should be author(s)_date_variantXX_versionXX instead, since
IMO, one should be thinking in
On 6/22/07, Tommy Yu [EMAIL PROTECTED] wrote:
Matt wrote:
Hi Tommy,
Can you continue to update/fill out your document as well as begin
associated proposals with information contained in the replies people
are submitting. The goal of this process is a scoping document with
associated
Do we really want to proxy remote repositories? Can we start smaller for now
but keep that in mind?
I think this will be an essential feature of the model repository as we
move forward. We are trying to present model authors with a common
platform for the distribution and archiving of their
It might also be worth looking into what the folks over at
http://www.biomodels.net/ are up to. Given they seem to have curation
built into their repository and maybe some other features worth looking
into?
And if we're going to be starting from scratch, there might be some
value into seeing
Hi Tommy,
looks like a good starting point for some discussion. Just to help me
think through some of the issues, is there any chance you could add a
usage example illustrating how this system would deal with a model made
from the combination of a bunch of papers (i.e., a single model where
Hi Tommy,
I found the document seemed to be too far ahead of itself. I also
didn't find any of the pros and cons very compelling because they
don't address specific problems and those problems are not described.
1) What are you actually trying to achieve? It would be useful to
describe the parts
Tommy Yu wrote:
Hi,
I have written down some of my thoughts on how the model repository could be
put together.
http://www.cellml.org/Members/tommy/repository_redesign.html
It is still a pretty rough document. The usage example section gives a rough
outline on what I see people might be
Hi Andrew,
A couple notes:
I don't think it is a bad thing to have a one-way cache of metadata
somewhere for technical / performance reasons (perhaps in a relational
database), but I think that we should replicate data for each model
(perhaps using a deep copy-on-write approach if this is
David Nickerson wrote:
Hi Tommy,
looks like a good starting point for some discussion. Just to help me
think through some of the issues, is there any chance you could add a
usage example illustrating how this system would deal with a model made
from the combination of a bunch of papers
Hi Tommy,
Can you continue to update/fill out your document as well as begin
associated proposals with information contained in the replies people
are submitting. The goal of this process is a scoping document with
associated content.
More comments below.
On 6/22/07, Tommy Yu [EMAIL PROTECTED]
12 matches
Mail list logo
