From: Dagmar K. <da...@eb...> - 2009-01-23 16:35:24
|
Hej, regarding some of the issues: > A Schema issues: > -------------- > 1. According to the spec SEDBase is a superclass of all the main > classes, yest in the schema only SedML class inherits from it. This > means that notes and annotation cannot be added to other elements, > e.g., uniform time course, dataset, datagenerator etc., > In the XML Schema it is missing indeed. I will add them, probably the easiest way is by adding the <xs:extension base="SEDBase"> tag to (all) complex type definitions. > 2. Most if not all top-level elements have an 'id' attribute, > would it make sense to put the 'id' field in SEDBase? > Well, what for example about the <curve> element which might have an annotation "The following curve shows the osciallation of bla bla bla", but does not have an id!? > 3. If more than one simulation can be in the listOfSimulations, > then I think > UniformTimeCourse needs a 'max=unbounded' attribute in its declaration, > else ListOfSimulations only contains a single element. > It is in the schema (in the declaration of the listOfSimulations) - so I supposed that is what you fixed already!? > B) Coordination with model > ---------- > PRevious posts have raised this issue, is there any progress on > this? There is a lot of validation that can be done just with the > sedml file, but if we want to check that a parameter or variable name > exists, or the xpath is correct, > then we need access to the model. It seems to me that there are > different scenarios: > > 1) A model is referenced to a validated public repository e.g., > BioModels > In this case the library can download the model. This seems > the easiest solution, as revisions of Biomodels are versioned (btw, > would a version attribute for the model element be useful?) and so a > tool can make decisions on whether the model is correct or not. > Version attribute is under discussion. Probably even easier would be different URIs for different model versions!? Although we could of course not force that... so, maybe an optional version attribute then. > > 2) A model is not yet in the public domain, but for example > the client wants to share simulation info with a collaborator. In > this case probably the model and the sedml file would have to sent > together in a zip file to preserve > relative file paths, but this leaves quite an onus on the user or > tool to keep the two files coordinated. > Hmm. This is indeed not really satisfying. Probably something to think about. > 3) Could a model file be optionally embedded in a sedml file? > For the moment, no. And I would really like to avoid that. But if people want to do that they could wrap some additional XML element around a model and a sed-ml file... :-) > This gets round the need to keep sedml independent of sbml, also a > single file gets round the file coordination issue, but it raises new > problems of keeping in synch possibly multiple copies of a model. But > for non-curated models that must be an issue anyway? > Not sure I understand what you argument for here - could you elaborate on that again, please? > C Validation requirements > -------------------------- > > VAlidation against the schema offers one level of validation, but > there are many more assertions to validate, here are > some below, would be good to have a list of these somewhere to > construct a test-suite. > Validation tasks below with an asterisk are ones needing access to the model: > As you said in an earlier email, I think the syntax checker is sufficient for the moment and the following validation criteria might be for the future!? However, this list could go to the feature request on SF. Dagmar > > List of simulations (schema needs to be altered to hold 'max=unbounded'?) > Unique simulation ids > 1) Uniform time course - > outputstart time < output end time > outputst time >= initial time > algorithm = valid Kisao id > > 2) List of Models > how to check existence of model? * > source = accessible url ( e.g., BioModelsDB)* or reference to > previously defined model > No duplicate model IDs > List of changes -> Check parameter name exists * > > 3) List of tasks > > One task must be baseline? > > model reference must refer to defined model id > simulation reference must refer to defined simulation id > No duplicate task IDs > > 4) list of data generators > unique ids > variable ID exists in model, target path exists in model > task ref refers to valid task reference > > 5) List of outputs > Plot ID is unique > x and y data references refer to defined dataGenerator ID > If listOfOuputs present, at least one of plot2d. plot3d, or > report is present. > > Richard > > Dr Richard Adams > Senior Software Developer, > Computational Systems Biology Group, > University of Edinburgh > Tel: 0131 650 8281/8285 > email : ric...@ed... > > > |