Re: [cellml-discussion] curation status of models in the repository
Jonathan Cooper wrote: On Thu, Jun 21, 2007 at 02:12:38PM +0800, David Nickerson wrote: Wilfred Li wrote: Maybe instead of the star system, which may be open to interpretation at first sight, an abbreviation or a specific word may be used to represent its status? I guess that if you use something that looks fairly common and standard people will think they know what it means without looking for an actual meaning (i.e., the more stars the better), whereas if you use something a bit different (plain text or graphical) then people are more likely to look-up and try to understand the meaning and implications. The trick is that if its too different, then it may just turn people off all together... Maybe just a simple list of checkboxes with the labels: Level 1, Level 2,... would suffice? The labels could then be links to the appropriate definitions. I like that sound of that. Certainly you need some format where it is possible to say that a model is level 2 without being level 1, which a simple row of stars cannot express. Stars are probably still appropriate for the tool-specific displays though: 1 if it loads, 2 if it also runs, etc. yep - I think thats still a good idea. And eventually you'd hope that level 2 curated models also satisfy level 1, but with the huge number of historical models we'll always need to support the case described above. it might also clear things up if there is just the appropriate number of stars rather than always having three and greying out the last one or two. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Cellml website access speed and IE7 warning
1) The data reported is from a CLI in cygwin terminal, so least amount of overhead presumably. $ time wget -O - http://www.cellml.org /dev/null --02:41:34-- http://www.cellml.org/ = `-' Resolving www.cellml.org... 130.216.208.2 Connecting to www.cellml.org|130.216.208.2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 19,177 (19K) [text/html] 100%[==] 19,17720.36K/s 02:41:37 (20.32 KB/s) - `-' saved [19177/19177] real0m5.765s user0m0.061s sys 0m0.187s I must say that I'm on a 11 Mbps line at a hotel in DC, yes, they still have these evil 11 Mbps lines in our capital. Just for comparison: $ time wget -O - http://www.sdsc.edu /dev/null --02:43:00-- http://www.sdsc.edu/ = `-' Resolving www.sdsc.edu... 132.249.21.111 Connecting to www.sdsc.edu|132.249.21.111|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 17,853 (17K) [text/html] 100%[==] 17,85355.82K/s 02:43:00 (55.78 KB/s) - `-' saved [17853/17853] real0m1.965s user0m0.077s sys 0m0.123s $ time wget -O - http://www.auckland.ac.nz /dev/null --02:44:09-- http://www.auckland.ac.nz/ = `-' Resolving www.auckland.ac.nz... 130.216.11.202 Connecting to www.auckland.ac.nz|130.216.11.202|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 16,891 (16K) [text/html] 100%[==] 16,891 9.62K/s 02:44:21 (9.60 KB/s) - `-' saved [16891/16891] real0m12.403s user0m0.077s sys 0m0.155s The DNS resolution appears to be sluggish, besides the transfer rate. 2,3) Apparently IE is slower than the other browsers because it has to process this warning about MSXML 5.0 on every page. Opera 9 loads the first page very slow, maybe 10 sec, but then the other pages are quite fast. My firefox is set up with UCSD proxy, so it'll be slower, and I don't use it normally. 4) See 1). Regards, Wilfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Miller Sent: Thursday, June 21, 2007 1:07 AM To: CellML Discussion List Subject: Re: [cellml-discussion] Cellml website access speed and IE7 warning Wilfred Li wrote: Hi, everyone, It seems that the access speed from North America to the website is rather slow, Network latencies and throughputs from New Zealand - US are always going to be slower than the typical speeds within each respective country, so I'm not sure if this is normal or not. It takes just over a second to load and render http://www.sdsc.edu/ from within Auckland, as opposed to under a second for http://www.cellml.org/ (obviously, the pages don't have exactly the same amount of data required, and this is in Firefox, so this might be different than for you). I'm also not sure if you mean the network speed or the page rendering speed, so a few things to try that might narrow it down: 1) Can you give us some quantitative measure of what you mean by slow. I would recommend something like the following: time wget -O - http://www.cellml.org/ /dev/null If this is fast, perhaps the time it takes for a complete page reload in your browser might be useful (Shift + F5 in most browsers). 2) Does the slowness happen for all pages or just some? 3) Is there any difference between browsers (e.g. is it just as slow in Firefox)? 4) How long does it take for http://www.auckland.ac.nz to load in your browser? and I keep getting the warning from IE7 about This website wants to run the following add-on MSXML 5.0, ...? Does this happen when you try to open a CellML model in IE or even on normal pages? Can you narrow down when this happens? Thanks for reporting this issue, Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] Concerning the CellML Model Repository
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 doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Cheers, Tommy. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
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 each component defines a new citation). I'm guessing this would be done by adding each of the components as separate models and then importing them into a single model? Another usage example that might be interesting to look at would be a model author adding a local CellML 1.1 model hierarchy to a remote repository and how all the import href's are handled in this case (i.e., imports throughout the model hierarchy might consist of a mix of relative, http, and file URLs). And another usage example might be the searching for models built using a specific set of data. It will hopefully become standard practice to annotate variable values with their source, where the source may be some data from a different article than the model's publication. Thanks, David. 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 doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Cheers, Tommy. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
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 of the current system that are giving you grief and look to give you more grief based on the use cases and any axes of scale. 2) What are the use cases? An initial set should be extracted from the current site. You have written out some, but they only covered a small set of function of the site, especially when it comes to relations between models or workflow and curation states. I understand some of the details that are causing you pain with the current implementation, but I think the first part of this is to be charitable to the current system and adequately describe the two points above. Before rethinking the implementation of this site I think the following need to also be done: - a specification for assigning a URI to these models (as would be used by CellML 1.1 imports) - a specification for how a manifest file is to be constructed, or some set of rules for interpreting a directory structure of models, especially in those cases where there are multiple local models used in imports and we need to point to at least the top level model. - a suggested solution to the bqs problem. Research existing standards. Generally: Relational databases are useful, but so are the combination of ZCatalog and Sets. It really depends on the structure of the data and the queries you want to perform. You should write out a reasonable set of these in natural language to get the focus right. Maybe a proof of concept using various mechanisms is required. The frustration with metadata handling at the moment is a result of some difficulties in the metadata specification for the metadata you are using the most and also the use of a quite esoteric system: 4Suite's Versa RDF query interface. RDQL or SPARQL are better SQL-like equivalents and certainly have a wide acceptance. Subversion offers a nice philosophy of code management and the guess is that this would apply well to the modeling process. It also offers the potential for building URIs for versioned material - individual files and whole changesets (which is something we are after). The default webdav URI scheme may not be what we want, so it is also worth looking at others; for example, the trac browser interface to a subversion repository form quite nice URIs. Workflow and security as defined and implemented by Zope/CMF/Plone is a very nice model that should be reflected in our workflow and security use-cases. We discussed a few weeks ago that if this environment is going to provide the security layer, then there needs to be a relationship between this and the subversion repository at quite a detailed level. cheers Matt On 6/21/07, Tommy Yu [EMAIL PROTECTED] 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 doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Cheers, Tommy. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] curation status of models in the repository
No, there are no stars, anywhere, that are on by default. They are all off by default until someone, probably me, certifies that the model meets the requirements to get itself a star, or two. Or maybe three. its more whether that one star is on or off by default? ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] a detailed curation specification
I have been thinking about this and I think it's worth proposing formally. But is having a whole level all about units consistency justified? Perhaps there are other things we could add to this level that could similarly require the intervention/expertise of the model author? I can't think of anything off the top of my head right now. David Nickerson wrote: Just one comment here. That is, if you look at the level 2 curation requirements, the only one that isn't satisfied by most of the models I've given two stars is the unit checking. So what this means is that we have a bunch of models which are much better curated than the level 1 curated models, but there isn't any way to actually show that if we aren't going to let them be level two. This is related to your point about splitting up the curation levels, and there are many models which would require actually reformulating the model completely to get units consistency (which would probably require the author getting involved.) If we did move units consistency up to level three, I think it would make things more straight forward. Rather than moving units consistency up to level 3 it would probably be better to move what is currently level 3 up to 4 and make level 3 all about units consistency. I think for the time being I'm going to take a left-wing approach and spend more time fixing the models that are completely broken. which I think is the right thing to be doing, I just think we need to be careful that the status advertised for a given model matches the definition of that status. Yep. I feel like biting off something I can chew right now. David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
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 doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Hi Tommy, A few comments: 1) I am still not convinced that meta-data should not be versioned, simply because changes to metadata can be important changes to a model. In some cases, such as changes to simulation metadata, the changes might have a major impact on the final model. 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 really necessary to save disk space) rather than changing the metadata for existing models without changing the version. Making changes to metadata require changes to the model will ensure that no one gets burned by referencing a particular version of a model, only to find that the metadata in that version has changed on them. Your current unversioned, globally shared metadata approach probably also has security implications. For example, lets say that Alice submits a model which references a publication. Now suppose that Charlie wasn't an author of that paper, but he wants to add his name onto the list of authors. So he submits a completely different, bogus, model which includes metadata for the publication, and includes his name. When Bob downloads Alice's model from the repository, it would then include Charlie's name as one of the authors (assuming that the publication was referenced by PubMed ID or DOI or some sort of publication URI. Particular cases like the one I described might be able to be secured in an ad hoc fashion such as by checking that the authors are the same, but the general attack will still pervade this type of approach unless metadata is associated uniquely with a particular version of a particular model. If the assertions about the same subject cannot be identified between models in the database, then having data flow back from the relational database into the model does not carry any benefit at all). However, I do agree that there is a place for some metadata which can be changed without creating a new version (which probably is the type of metadata that you wouldn't include in the CellML file by default). Curation status and permissions would probably fit in this category, because although they may be associated with a particular version, they should not be immutable for a given version. 2) I think that there should be a directory for each mathematical model (which may include several CellML model files, documentation, and so on), so that a particular version can be downloaded / checked out in its entirety (with some directory-level manifest describing how to run or view the model). This suggests that collisions between mathematical models should be prevented at this level, not at the file level. Under this scheme, Mary would find that at usage example 3, she couldn't use the same directory name as the one John already submitted. 3) I think the 'reference by citation' needs some expansion: I think people referencing models should have the choice to refer to: = a specific version for which no files will change at all. = the latest version which aims to reflect the letter of a publication (updates will only fix mistakes in the model which prevent it from corresponding to the printed paper). = the latest version which aims to reflect the results obtained by the author (updates can fix discrepancies or omissions from the paper that were in the author's original code, if the author didn't use CellML). = the latest derivative of the current model developed by the same author / group, even if it has not yet been peer-reviewed (subject to permissions constraints). = the latest derivative of the current model, but with all imports external to the model updated to the latest versions (even if this has not been reviewed by the author). This would be the most frequently updated version, because it could be automatically created without the model author being involved. It would also be possible to search for derivatives made
Re: [cellml-discussion] Concerning the CellML Model Repository
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 really necessary to save disk space) rather than changing the metadata for existing models without changing the version. Making changes to metadata require changes to the model will ensure that no one gets burned by referencing a particular version of a model, only to find that the metadata in that version has changed on them. Your current unversioned, globally shared metadata approach probably also has security implications. For example, lets say that Alice submits I understood, and I did call for metadata in the RDBMS to be more of a snapshot. Metadata will still be versioned (revision) in the Subversion repository. The publishing of a model to the public could conceivably be done by someone other than the model creator. Also, in the scenario outlined below, you are correct that a paper referenced by PubMed would be treated somewhat differently. If Charlie were to publish a fake paper to the repository, it would result in a new references anyway: Alice - Paper title (original) Alice, Charlie - Paper title (fake) There is no way to stop users from entering bad data into the system if they were given admin rights. Fortunately Charlie wouldn't have that and so he wouldn't be able to add a new author to Alice's paper, but able to only create a new fake paper that he did not write since he can publish a model. On the other hand, if he decide to use the original publication name to publish his model, then change the reference there, he would still be prevented from doing that, but he has the option to create a new fake reference. Again, no way stopping user from publishing bad data if they were given rights. It is possible to limit where Charlie can publish his paper to (i.e. publishes to reviewers only), and there would be no visible damage. a model which references a publication. Now suppose that Charlie wasn't an author of that paper, but he wants to add his name onto the list of authors. So he submits a completely different, bogus, model which includes metadata for the publication, and includes his name. When Bob downloads Alice's model from the repository, it would then include Charlie's name as one of the authors (assuming that the publication was referenced by PubMed ID or DOI or some sort of publication URI. Particular cases like the one I described might be able to be secured in an ad hoc fashion such as by checking that the authors are the same, but the general attack will still pervade this type of approach unless metadata is associated uniquely with a particular version of a particular model. If the assertions about the same subject cannot be identified between models in the database, then having data flow back from the relational database into the model does not carry any benefit at all). However, I do agree that there is a place for some metadata which can be changed without creating a new version (which probably is the type of metadata that you wouldn't include in the CellML file by default). Curation status and permissions would probably fit in this category, because although they may be associated with a particular version, they should not be immutable for a given version. 2) I think that there should be a directory for each mathematical model (which may include several CellML model files, documentation, and so on), so that a particular version can be downloaded / checked out in its entirety (with some directory-level manifest describing how to run or view the model). This suggests that collisions between mathematical models should be prevented at this level, not at the file level. Under this scheme, Mary would find that at usage example 3, she couldn't use the same directory name as the one John already submitted. 3) I think the 'reference by citation' needs some expansion: I think people referencing models should have the choice to refer to: = a specific version for which no files will change at all. = the latest version which aims to reflect the letter of a publication (updates will only fix mistakes in the model which prevent it from corresponding to the printed paper). = the latest version which aims to reflect the results obtained by the author (updates can fix discrepancies or omissions from the paper that were in the author's original code, if the author didn't use CellML). = the latest derivative of the current model developed by the same author / group, even if it has not yet been peer-reviewed (subject to permissions constraints). = the latest derivative of the current model, but with all imports external to the model updated to the latest versions (even if
Re: [cellml-discussion] Concerning the CellML Model Repository
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 (i.e., a single model where each component defines a new citation). I'm guessing this would be done by adding each of the components as separate models and then importing them into a single model? It depends on how the model is cited. If the creator of the model that binds all the separate models together based his/her model on a published paper, that citation would be used. If not, it can only reside inside the user's directory as a filename of his choice, that imports the other models. Yes, creator of model would have to import the components. Another usage example that might be interesting to look at would be a model author adding a local CellML 1.1 model hierarchy to a remote repository and how all the import href's are handled in this case (i.e., imports throughout the model hierarchy might consist of a mix of relative, http, and file URLs). The model repository shouldn't be responsible for users importing from file:// and other non-existent URIs. I will create detail use cases for this, but in the case of http URIs, I can think of checking for a pre-approved list of hostnames that models can be imported from. And another usage example might be the searching for models built using a specific set of data. It will hopefully become standard practice to annotate variable values with their source, where the source may be some data from a different article than the model's publication. That's using the metadata, right? If the creator of the model does annotate components properly (e.g. giving some comment to cmeta:id of some component of some file) it will be searchable (provided that the creator publishes that model). Thanks for your inputs, Tommy. Thanks, David. 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 doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Cheers, Tommy. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] curation status of models in the repository
No, there are no stars, anywhere, that are on by default. They are all off by default until someone, probably me, certifies that the model meets the requirements to get itself a star, or two. Or maybe three. ok - good to know. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] a detailed curation specification
I have been thinking about this and I think it's worth proposing formally. But is having a whole level all about units consistency justified? Perhaps there are other things we could add to this level that could similarly require the intervention/expertise of the model author? I can't think of anything off the top of my head right now. Personally I think there is nothing wrong with the current levels and keeping units with getting the model giving correct results. I have little faith in a model which can give the correct results while being defined with inconsistent units. I was simply suggesting moving units to a higher level to try and ease the burden of getting models beyond level 1 curation, as you pointed out a model which does run and gives reasonable results is much better than one which does not run at all, even with inconsistent units, depending upon the task you wish to put it to. The units inconsistency issue is a legacy of the majority of models being written by hand with no way to test them. In most cases the models already in the repository can now be tested with either JSim or PyCML for units consistency, so it would be good to see those tests being done as part of your curation workflow - even if that just ends up as a comment in the model status that the units are not consistent or something. David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] a detailed curation specification
David Nickerson wrote: I have been thinking about this and I think it's worth proposing formally. But is having a whole level all about units consistency justified? Perhaps there are other things we could add to this level that could similarly require the intervention/expertise of the model author? I can't think of anything off the top of my head right now. Personally I think there is nothing wrong with the current levels and keeping units with getting the model giving correct results. I have little faith in a model which can give the correct results while being defined with inconsistent units. I was simply suggesting moving units to a higher level to try and ease the burden of getting models beyond level 1 curation, as you pointed out a model which does run and gives reasonable results is much better than one which does not run at all, even with inconsistent units, depending upon the task you wish to put it to. The units inconsistency issue is a legacy of the majority of models being written by hand with no way to test them. In most cases the models already in the repository can now be tested with either JSim or PyCML for units consistency, so it would be good to see those tests being done as part of your curation workflow - even if that just ends up as a comment in the model status that the units are not consistent or something. Sure, I'll start doing that. By the way, what exactly is a workflow? ;) David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
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] wrote: Matt wrote: 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 of the current system that are giving you grief and look to give you more grief based on the use cases and any axes of scale. Starting with what I envisioned. Who is the repository catered for? 1) People who would like to work on models, using it as a place to store work-in-progress models. 2) Reviewers to review models. 3) Website users to browse models. 1) What do the model builders want? - Their own workspace (home directory) - A place to let reviewers review their models - Also to publish their models First point is not addressed by what we have now. Second and third point is quite ad-hoc. Also, version control is very ad-hoc right now. Each of these points need to be filled out, e.g. what does it mean to have a workspace for a CellML modeller?, What are the scenarios and workflows for reviewers of CellML models? 2,3) Reviewers and website users - A centralized location to browse models. - They would like to see how models may relate to each other. How do models relate to each other? Relations between models come from all sorts of data within models, and within any associated metadata (so more than just our current cellml metadata specification). It would be useful to write out the details of the relationships that are important here as these pretty much form the basis of many of the queries that will need to be performed. First point is already addressed, but second point is definitely not possible as the current repository does not support 1.1. Why does it not support CellML 1.1? i.e. what is the technology block here to extending the current system to support it? Issues: - Flat file system. Sure, using ZCatalog it is possible to emulate users' home directories and the like, but it still does not get away from what we have now. I don't understand this. What are you aiming for in a home space and why doesn't the current system support it? - Version/Variant It already clogged up the system. There is no proper revision control mechanism, what we have now is an ad-hoc emulated system. I don't think it has clogged the system I just think it has been improperly used both by authors and by the user interface. This is no fault of the authors, there is simply a specification for versioning that is missing. The hope is that subversion applies well to this. - It's CellML Code, right? Why not put code in a real code management system, like Subversion? Subversion works well for filesystems of code and text data and to some extent binary data that we don't really need to query the contents of. If this applies well for CellML modelling, then subversion is probably a good match. Subversion will bring its own complexities when we are dealing with applying security to file objects, and security/publishing in general will get even more complex if we are proxying remote repositories - which we talked about a few weeks ago. Generally, I think the concept of cellml modelling being laid out in a filesystem and subversion versioning concepts applied to it is good, but untested. For instance, take a reasonably complex model of Andre's and work out how it will look on the filesystem and what subversion versioning would result in. While in this thread, I don't believe metadata should be treated any differently to model data. Adding special rules for versioning of some data and not others is going to complicate the versioning process and I can't see any compelling reason to do this. Remember that the subversion system is versioning file objects which will contain both metadata and cellml model data. What is important is how and where metadata is stored. Perhaps metadata should be seperated into its own document sitting next to the model in the filesystem. My inclination is that an implementation using subversion plus some subversion hooks will be ok, but we haven't worked out details or done any proof of concept for this - which should be agnositic to cellml and focussed on how to apply zope+cmf security and workflows to data objects stored in subversion repositories. - Zope has revision control Until someone packs the database. Perhaps you should look at http://plone.org/products/plone/roadmap/8 (which is now completed and merged into Plone 3). There are some other add on products - some listed in
