|
From: Burkhard S. <b_...@us...> - 2005-01-27 01:42:21
|
Hi Maren and Mark, please see my earlier email about the XYZSet container tags. It may be beneficial to keep them. > However, I'm wondering whether we really need the possibility to sign > single elements in the AnIML file, or whether it would suffice to be able > to sign the whole document. Any thoughts on that? Signing only whole documents may be too strict a limitation. The philosophy in most Part 11-compliant implementations is that everybody signs the data she/he is responsible for. So one person (i.e. a chemist) could have created the samples and somebody else (i.e. a lab technician) could run the experiment. A 3rd person is responsible for calibration, etc. So that's one thing. Another point is that parts of a document could be generated at different points in time. Here it is a critical feature to preserve the original signatures, even when data is later added in other parts of the document (not covered by the initial signature). A third, and very interesting point: In the future, we could consider instruments that directly sign their result data. I've talked to a few folks (instrument manufacturers) at the LIMS Conference in Barcelona last September, and this is something they get asked about in regulated environments. And right now, only AnIML provides a (non-proprietary) solution to this problem. > - In the Technique Schema, we have an attribute "maxOccurs" and an > attribute "modality". It would be more consistent to replace "modality" > with "minOccurs" (=0 or 1). Sounds good. > - What is the exact meaning of the attributes "inheritable" and > "upwardsInherited"? These seem rather technical to me; what do we need > them for? "inheritable" is used with nested techniques. It indicate if a technique can inherit a sample from the surrounding experiment step. Example: LC +-- MS (inherits sample from LC) Here we don't have to explicitly declare the sample consumed by the MS, because the MS ExperimentStep is attached to the chromatogram page and refers to a point (or range) of the LC time axis. So we know where the sample comes from without having to create an explicit entry for it in the SampleSet section. For this to work, the MS technique definition needs to set "inheritable=true" for the run sample. > - What is the benefit of assigning "consumed" or "produced" to a sample? It allows us to easily track the material flow in the experiment. We can see how a sample is created by looking at the ExperimentStep that "produced" it. We can also find out what happened to it by looking at all the steps that "consumed" the sample. One important consequence: If a sample is "consumed" in a step, the result data pages of that step will tell us something we measured about the sample. If a sample is "produced", that step did not measure the sample but merely produced the material; i.e. we will typically need to take additional steps to measure its characteristics. So we can chain together experiment steps using the produced/consumed concept. This very feature allows us to cover the lab workflow, so it's one of the most important attributes in the core schema. :-) > - Parameters are usually not stored as binary data. Is it useful to have > float and double data types for them? Yes. Using float and double as a data type does not mean that the data is stored in binary/base64. The digits are stored in plain text. Some instruments deliver IEEE floating point values, so having these types is certainly a good idea. > Storing non-binary data as floats or > doubles incurs a loss of precision as the decimal numbers are converted > internally to the closest binary number, which is not always exact. We > might want to be able to use the XML datatype xs:decimal as well. You are right on the rounding. Perhaps I got you wrong in the last paragraph. I've looked at xs:decimal and it seems interesting for us. From what I gather this type supports arbitrary precision numbers. This is somewhat problematic to handle in software, since there is no data type in a programming language that would directly map to it. I know that Java, C++, and .NET have classes available to encapsulate it. Nevertheless, implementation tends to be hairy. But my gut feeling would be that xs:decimal should be put in. > Another issue (which we probably can't solve in XML) is that you cannot > specify how high the precision of your data is. "1.200" is something > different from "1.2" as the two zeroes tell you that the precision is > three decimal digits. From what I've found in an XML book, however, it > looks like XML views the trailing zeroes as "non-significant". That's true. It's also in the Schema spec for the decimal type. http://www.w3.org/TR/xmlschema-2/#decimal Viele Grüße, Burkhard |