Menu
▾
▴
Re: [Animl-develop] Allowed Values in AnIML
|
From: <Mar...@cr...> - 2004-03-15 12:33:26
|
Hi Dominik, as Gary surely told you already, we are supposed to freeze the code on Friday, hopefully having solved this issue by then. > the discussion that I started was supposed to be on the technique lay= er. Right. My mistake. > The "allowed values" won't influence the Part11 compliance issue beca= use they do not > directly restrict the AnIML file. You just use them for validation > issues. This is exactly the point: You end up having *invalid* AnIML data even though everything aside from the data range is correct! This will most likely be very unfortunate for people working in a validated environmen= t. > i.e. that the AnIML file is not > valid against that definition because the measured value is out of > range. And that is what we would want, beacause the developer of the > technique said that the results must be in a particular range, otherw= ise > the file is incorrect. This is something I definitely would not want. It doesn't even give us = any kind of benefit. Let's use NMR as an example: The chemical shift is highly dependent on = the nucleus. 1H NMR spectra are usually (!) between about -2 and +15 ppm. 1= 3C NMR is between -20 and +250 ppm. Some more "exotic" NMR techniques can easily have ranges in the negative hundreds. Which range would you allo= w for the data? To catch them all, you would need something from -500 to = +500 ppm, which is no real restriction at all because an 1H NMR from 130 to = 400 ppm would be perfectly valid although you would most probably never encounter it in reality. The other possibility would be creating multiple technique definitions = (or one very complex one) for NMR, which cannot be our goal either because = it would mean creating a lot of redundant information. The only place I could imagine such a restriction in is a user extensio= n, but most probably, no one would use this. So we might as well leave it = out. Maybe someone else on this list can contribute something here. It's jus= t you and me discussing this issue again :-) > Regarding the other mail, with the idea to allow ranges of "allowed > values," we still have the ability to set just one value (e.g., strin= g > or number), or better yet let's say any simple type. We can do this b= y > just assigning a value to the minimum tag while leaving the maximum t= ag > free, or write the same value in both tags. So this is just a questio= n > of modelling. OK, let's incorporate allowed ranges for parameters. Can you add that t= o the schema I last sent you and send me the new schema? Maren. Dr. Maren Fiege Product Manager -----------------------------------------------------------------------= ---------------------- CREON=B7LAB=B7CONTROL AG a subsidiary of Waters Corporation Europaallee 27-29, D-50226 Frechen, Germany Tel. +49 2234 9207 0 Fax. +49 2234 9207 99 http://www.creonlabcontrol.com For up-to-date information subscribe to our free newsletter at http://www.creonlabcontrol.com/news/news_archive.htm -----------------------------------------------------------------------= ---------------------- = =20 Dominik Poetz = =20 <dominik.poetz@ To: Maren.Fiege@creonlabco= ntrol.com =20 nist.gov> cc: Stuart Chalk <schalk@u= nf.edu>, AnIML Mailing List =20 <ani...@li...= forge.net>, AnIML Mailing List =20 07.03.2004 <ani...@li...= orge.net>, =20 04:23 ani...@li...= urceforge.net =20 Subject: Re: [Animl-develo= p] Allowed Values in AnIML =20 = =20 Hi Maren, the discussion that I started was supposed to be on the technique layer= . This is the only place where we can set "Allowed Values." The "allowed= values" won't influence the Part11 compliance issue because they do not= directly restrict the AnIML file. You just use them for validation issues. For example: Let's say a technique developer creates a specific parameter with an allowed value range in his technique definition. Sombody then makes a measurement where that parameter value is out of range, and after that he validates his resulting AnIML file against that technique definition= from that particular technique developer. What would happen is that the= validator will indicate an exception, i.e. that the AnIML file is not valid against that definition because the measured value is out of range. And that is what we would want, beacause the developer of the technique said that the results must be in a particular range, otherwis= e the file is incorrect. Regardless if the data is out of range or not, the original AnIML contains only the raw, measured values without further manipulation, which should be fine for Part 11. The same can be= true for vectors if we decide to add "Allowd Values" to the vectors too= . Regarding the other mail, with the idea to allow ranges of "allowed values," we still have the ability to set just one value (e.g., string or number), or better yet let's say any simple type. We can do this by just assigning a value to the minimum tag while leaving the maximum tag= free, or write the same value in both tags. So this is just a question of modelling. -- Dominik Mar...@cr... wrote: >Dear Dr. Chalk, > > > >>Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are = in >>most cases ranges of numbers. >> >> >The ability to store this is a matter of the technique definition, not= of >the Core schema (to which Dominik was referring). >As I am currently writing prototype technique definitions, I will glad= ly >incorporate this. Thank you for reminding me! > > > >>As a general note I am stating to work on implementing animl in my la= b >> >> >and > > >>I have many other questions. >> >> >Forgive my curiosity: What do you mean by "implementing"? > > > >>Would it be possible to set up CVS for animl development? >> >> >This is generally possible on SourceForge, and used to work, but as fa= r as >I know there has been some kind of problem. Some people started to try= and >make it work again after this was requested at the last working meetin= g.. >Maybe someone can update us on the current status. > > > >>When I say bugs I mean XSD issues that are either too limiting or are= not >>well enough defined. Just a thought. FYI: I can help with both.... = ;) >> >> >The animl-develop mailing list is exactly the place to discuss this. S= o >let's hear your bug reports! > >Best regards, > >Dr. Maren Fiege >Product Manager > > -----------------------------------------------------------------------= ---------------------- > >CREON=B7LAB=B7CONTROL AG >a subsidiary of Waters Corporation >Europaallee 27-29, D-50226 Frechen, Germany >Tel. +49 2234 9207 0 >Fax. +49 2234 9207 99 > >http://www.creonlabcontrol.com > >For up-to-date information subscribe to our free newsletter at >http://www.creonlabcontrol.com/news/news_archive.htm > -----------------------------------------------------------------------= ---------------------- > > > > Stuart Chalk <sc...@un...> > Sent by: To: Domin= ik Poetz <dom...@ni...> > ani...@li... cc: AnIML= Mailing List > eforge.net <ani...@li...>, AnIML Mailing > List <ani...@li...> > Subject: = Re: [Animl-develop] Allowed Values in AnIML > 05.03.2004 10:47 > > > > > > >The same is true in the parameter data for a SampleSet > >Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are i= n >most cases ranges of numbers. > >As a general note I am stating to work on implementing animl in my lab= and >I have many other questions. Would it be possible to set up CVS for a= niml >development? Then people can report bugs and have those bugs worked o= n.. >When I say bugs I mean XSD issues that are either too limiting or are = not >well enough defined. Just a thought. FYI: I can help with both.... ;= ) > >Stuart Chalk, Ph.D. **NEW** Phone:904-620-= 1938 >Associate Professor of Chemistry Fax:904-620-= 3885 >Department of Chemistry and Physics "The Flow Analysis Datab= ase" >University of North Florida http://www.fia.unf.= edu/ >4567 St. Johns Bluff Road S. "The Analytical Sciences Digital Libr= ary" >Jacksonville FL 32224 USA http://www.asdlib.= org/ > >On Thu, 4 Mar 2004, Dominik Poetz wrote: > > > >>Hi everybody, >> >> >>I hope everyone is doing well. >> >>At the last AnIML Working Group meeting, we discussed wanting to allo= w >>multiple, single "allowed values" for parameter values in the techniq= ue >> >> >layer. > > >>Instead of multiple, single "AllowedValue" values, we might do better= to >> >> >allow > > >>ranges of "AllowedValue" values. For example, with temperature it wo= uld >> >> >be > > >>better to allow this "AllowedValue" to range between a minimum value = and >> >> >a > > >>maximum value. To specify a single value we would have to put the va= lue >> >> >in > > >>both, Min and Max fields or maybe the Max field would be empty. But t= his >> >> >is a > > >>design detail that is not so important at this point. >>The usage of that could be for vendors to specify their devises in th= eir >> >> >vendor > > >>extensions if they want. >> >>On another subtopic, shouldn't we add a flag (attribute) to >> >> >"AllowedValue" to > > >>reverse it's sense and let us list non-allowed values? >>This wouldn't cost us much, and it gives us more flexibility in desig= ning >>techniques. To promote better understanding, we might choose to renam= e >> >> >the > > >>"AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." >> >>In addition, do we need a similar notation for vectors? >> >>It would be nice to get some more ideas about this. >> >>Hope to hear from you, >> >>Dominik >> >>------------------------------------------------ >>Dominik Poetz >>U.S. Department of Commerce >>National Institute of Standards and Technology 100 Bureau Drive >>227/A157, MS 8394 >>Gaithersburg, MD 20899 >>Phone: 301-975-4645 >>Fax: 301-977-0587 >>Email: dom...@ni... >>------------------------------------------------ >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IBM Linux Tutorials >>Free Linux tutorial presented by Daniel Robbins, President and CEO of= >>GenToo technologies. Learn everything from fundamentals to system >>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D= click >>_______________________________________________ >>Animl-develop mailing list >>Ani...@li... >>https://lists.sourceforge.net/lists/listinfo/animl-develop >> >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D= click >_______________________________________________ >Animl-develop mailing list >Ani...@li... >https://lists.sourceforge.net/lists/listinfo/animl-develop > > > > > > > > = |
