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 out as use-cases that don't depend on technology (but can certainly borrow ideas from various technologies). A large part of this are the cellml.org use-cases around the use of metadata in the models. While the underlying implementation of the repository is something to discuss, I think that it is a red herring at the moment. The issues seems more to do with various use-cases being difficult to represent in the current style of model naming and the difficulty of reflecting someone's local filesystem workflow/layout. I think there is too much of a rush to solve the repository issue quickly based on these idiosyncrasies of the cellml.org model naming problem. Some(!!) considerations: - how is a modelers local workspace organized? e.g. we have talked about the possible need for a manifest file; the possibility of metadata sitting separate from the model itself; etc. Is the idea of a workspace appropriate? Would people have multiple workspaces, say one for each model, or one workspace for all their models, or both? - do people want to use a single central repository? Or should they be able to work independently in their own instance of a repository and perhaps at some point transfer their project to another one? - there has been an assumption that the base unit stored in a repository should be a cellml/xml model - why is this? check the reasons why this is believed to be the way it should be. - don't try to figure out the URI scheme right now - even in use cases. The only attention to URI will be the bahviour it might exhibit in the modeling process: for example, you want someone to be able to move from tracking a volatile branch of a model in their imports to a stable one (that's all you have to say, not what the URIs might look like). - don't attach specific technologies to the repository system until the use-case space has been filled out The evolution of the repository is a non-small task (it's actually someone's PhD topic). So once there is a pretty certain idea of what the repository may be, then how does the current system in the plone site sit with respect to this? Are there technologies that take us a step closer that could be weaved into the current product? etc.. What are the priorities for cellml.org? _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
