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. 2,3) Reviewers and website users - A centralized location to browse models. - They would like to see how models may relate to each other. First point is already addressed, but second point is definitely not possible as the current repository does not support 1.1. 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. - 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. - It's CellML Code, right? Why not put code in a real code management system, like Subversion? - Zope has revision control Until someone packs the database. - Zope/Plone is also quite slow. - Code we have now cannot get away from original design flaws. Might as well start from scratch. The major issue is, I cannot see how I can get the current repository to support CellML 1.1 models. Sure, a new archetype can be written, and built with ZCatalog and the like. I still find this method to be an ad-hoc slapped together with semi-mismatching components to get it working, whereas the obvious solution to use a CMS with a database that points to the data would be the much elegant solution (with a front-end written to interface that). Oh, how is it ad-hoc? I still do not have this resolved, but there is no "not" query in ZCatalog. There is a product called 'AdvancedQuery' that address that, but that's more dependency on yet more products to get something simple done. There are more, but I will end it here. > 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. Feel free to list some specific examples I have omitted like Andre and Andrew did. I do agree it is a small set, but I am starting from the basics and moving up from there. It will get quite complicated. > > 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) I've outlined a few, but more details to come. > - 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. > I did consider that, and I think OpenURL may suit our needs fairly well. It is already an established standards, it's about citations, got great support by the world (libraries and citation catalogs are using this), seems to have everything bqs describes, and here's the spec: http://www.niso.org/standards/resources/Z39_88_2004.pdf However, it's in XML only, but near the bottom of page 23 of that file, I quote: > - To support new applications, communities could introduce new XML-based > ContextObject Formats constrained by other syntactic constraint languages > (DTD or RELAX NG, for example) or semantic constraint languages (RDFS or OWL, > for example). Nothing is really stopping us from adapting that standard, aside from having to rewrite/regenerate all metadata we have now. > 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. > Will get to that. I am at the research stage still, but I did have some preliminary schemas down. > 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. > While Versa itself is not so bad, but the intricacy and gotcha's of 4Suite was quite unpleasant to deal with. I must note I did not decide to use that, I merely inherited code that used it so I am sort of stuck. If I had a choice I would be using RDFlib and use SPARQL provided by it. Yes, it has to do with frustration of both 4Suite and the metadata specification. > 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. > Yes, I am doing research into those also. The HTTP interface would built on top of that also. It is my desire to use a _real_ code management backend to manage models so I don't have to start writing a versioning mechanism into the repository like what we have now. > 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. > The workflow and security Zope/CMF/Plone will definitely be used, and will be mapped some ways into the model repository interface (abstraction layer, I called it). I will give this more thought when I have the foundations down (i.e. interface between subversion/code and the database of metadata, submitted models, etc). Thank you for your thoughts, Tommy. > 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 _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
