Menu
▾
▴
animl-develop
|
From: Chalk, S. <sc...@un...> - 2006-03-21 00:47:33
|
At last weeks PittCon working group meeting, suggestions were made regarding the converter and I have addressed those in an update today. You will find example files for download on the converter page (fad.coas.unf.edu/animl/jcampconversion.php). These are 2D data files only. In addition, I have increased the upload file size and changed the error message (sorry Maren). Through putting this converter together I have come across some issues that need to be thought about on this list. I reported some of them at the meeting last week but have thought of some more so I have summarized them below. 1) How does any converter appropriately identify that it did the conversion? Do we need a "Conversion" Action in the AuditTrail? 2) Where should any JCAMP comments be put in the AniML file? 3) Instrument Vendor specific parameters should go where? (until the vendors add their module) 4) If a piece of header information has no obvious place to go in the AnIML file where should it be put? (or does this suggest a change in the ATID is needed?) 5) If a value is required in an AnIML document but is not available in the JCAMP file (or any other source file/datasystem) what should be put there? Default value? No value (empty element)? 6) To go along with 5)...if a required field is defined with enum list what should be chosen if there is no data available? Add an "Unknown" enum value to each such list? Sorry for so much detail, but I got stimulated at PittCon ;) Stuart Chalk |
|
From: Burkhard S. <bur...@bu...> - 2006-03-26 21:35:41
|
Stuart, > 1) How does any converter appropriately identify that it did the > conversion? Do we need a "Conversion" Action in the AuditTrail? as it stands, the most appropriate Action to use would be "created", since (by performing the conversion) the converter creates the entries in the AnIML document. > 2) Where should any JCAMP comments be put in the AniML file? At the moment, we don't have an explicit facility for comments, but AnIML supports the standard XML comments format ( <!-- my comment --> ). > 3) Instrument Vendor specific parameters should go where? (until the > vendors add their module) You'd create and reference an AnIML Technique Extension document. If the parameters are known before the measurement (instrument settings, instrument info, ...), the data is stored as Parameters within the ExperimentStep. If the data was actually measured, it goes into Page Parameters. > 4) If a piece of header information has no obvious place to go in the > AnIML file where should it be put? (or does this suggest a change in > the ATID is needed?) Four possibilities: - create an Extension - file a bug report with the appropriate Technique team ;-) - use an XML comment - ignore the data > 5) If a value is required in an AnIML document but is not available in > the JCAMP file (or any other source file/datasystem) what should be put > there? > Default value? No value (empty element)? The value cannot be left blank. That's why it's required. If the data is not known, you'd have to take an informed guess. > 6) To go along with 5)...if a required field is defined with enum list > what should be chosen if there is no data available? > Add an "Unknown" enum value to each such list? Again, you need to take an informed guess. Note: Data that is typically difficult to obtain will not be made a required entry in the Standard Technique Definitions. Best regards, Burkhard |
|
From: <Mar...@wa...> - 2006-04-10 12:16:06
|
Hi Burkhard and Stuart, > > 2) Where should any JCAMP comments be put in the AniML file? >=20 > At the moment, we don't have an explicit facility for comments, but=20 > AnIML supports the standard XML comments format ( <!-- my comment --> ). In this case, a viewer will have to be able to read XML comments in an=20 AnIML file, associate them with the proper elements, and display them.=20 People will want to view these comments. =20 > > 4) If a piece of header information has no obvious place to go in the=20 > > AnIML file where should it be put? (or does this suggest a change in=20 > > the ATID is needed?) >=20 > Four possibilities: > - create an Extension > - file a bug report with the appropriate Technique team ;-) > - use an XML comment > - ignore the data We have to revisit the ATIDs anyway. While doing that, we can make sure=20 the JCAMP header info gets a place to put it. =20 > > 5) If a value is required in an AnIML document but is not available in = > > the JCAMP file (or any other source file/datasystem) what should be=20 put=20 > > there? > > Default value? No value (empty element)? >=20 > The value cannot be left blank. That's why it's required. If the data is = > not known, you'd have to take an informed guess. Unfortunately, informed guesses are not 21 CFR 11 compliant (no accurate=20 copy of records). It is the task of the technique definition groups to=20 make sure the required AnIML elements can be filled. Mit freundlichen Gr=FC=DFen / Best regards Maren.=20 Dr. Maren Fiege Product Manager =20 Waters GmbH Europaallee 27, D-50226 Frechen, Germany Tel.+49 2234 9207 - 0 Fax. +49 2234 9207-99 http://www.waters.com/informatics=20 |
|
From: Burkhard S. <bur...@bu...> - 2006-04-10 15:28:23
|
Hi Stuart and Maren, >>> 2) Where should any JCAMP comments be put in the AniML file? >> At the moment, we don't have an explicit facility for comments, but >> AnIML supports the standard XML comments format ( <!-- my comment --> ). > In this case, a viewer will have to be able to read XML comments in an > AnIML file, associate them with the proper elements, and display them. > People will want to view these comments. Yes. There's no explicit relation between an XML comment and the associated element. The same problem exists in JCAMP. It's hard to determine which data item a JCAMP comment belongs to. >>> 5) If a value is required in an AnIML document but is not available in >>> the JCAMP file (or any other source file/datasystem) what should be > put >>> there? >>> Default value? No value (empty element)? >> The value cannot be left blank. That's why it's required. If the data is >> not known, you'd have to take an informed guess. > > Unfortunately, informed guesses are not 21 CFR 11 compliant (no accurate > copy of records). It is the task of the technique definition groups to > make sure the required AnIML elements can be filled. Yes. Technique definitions should not have fields marked as mandatory where it's likely that the data will be difficult or impossible to obtain. Best regards, Burkhard |
|
From: <Mar...@wa...> - 2006-04-11 14:28:30
|
Hi,=20 > Yes. There's no explicit relation between an XML comment and the=20 > associated element. The same problem exists in JCAMP. It's hard to=20 > determine which data item a JCAMP comment belongs to. Is that so? I thought you could put a JCAMP comment into a line that=20 already has a JCAMP label in it. Robert? Mit freundlichen Gr=FC=DFen / Best regards Maren.=20 Dr. Maren Fiege Product Manager =20 Waters GmbH Europaallee 27, D-50226 Frechen, Germany Tel.+49 2234 9207 - 0 Fax. +49 2234 9207-99 http://www.waters.com/informatics=20 |
|
From: Prof. R. J. L. <rob...@uw...> - 2006-04-11 19:58:31
|
Maren it is true that you can add a $$ and a comment at the end of a header val= ue but also true that you can put in a $$ at the start of a line with a comm= ent. In the first case it is perhaps easy enough to identify what the comment referred to but not so in the second case. In fact the IR protocol had suggested that after the ##JCAMP-DX=3D label that a comment was inserted that gave the software and version that created the file. This is not always done. I note that in the Bruker "vs 6" NMR files that they have things like ##TITLE=3D ##JCAMP-DX=3D ##DATA TYPE=3D and further down may have $$ ##TITLE=3D $$ ##JCAMP-DX=3D $$ ##DATA TYPE=3D which is something I was not expecting! To try to read every JCAMP comment line and convert < and > to XML/HTML < and > is a possibility but clumsy!? Robert on 11/04/2006 09:31 AM Mar...@wa... said the following: > Hi,=20 >=20 >> Yes. There's no explicit relation between an XML comment and the=20 >> associated element. The same problem exists in JCAMP. It's hard to=20 >> determine which data item a JCAMP comment belongs to. > Is that so? I thought you could put a JCAMP comment into a line that=20 > already has a JCAMP label in it. Robert? >=20 > Mit freundlichen Gr=FC=DFen / Best regards >=20 > Maren.=20 >=20 >=20 > Dr. Maren Fiege > Product Manager > =20 > Waters GmbH > Europaallee 27, D-50226 Frechen, Germany > Tel.+49 2234 9207 - 0 Fax. +49 2234 9207-99 >=20 > http://www.waters.com/informatics=20 >=20 >=20 >=20 >=20 --=20 Prof. Robert J. Lancashire mailto:rob...@uw... Department of Chemistry Tel (876) 512 3026 University of the West Indies, Kingston 7 Fax (876) 9771835 Mona Campus, JAMAICA. http://wwwchem.uwimona.edu.jm/chrl.html |
|
From: <Mar...@wa...> - 2006-05-01 13:30:49
|
Hi Robert, sorry for the delay in replying. I've been on the road too much... "V6" is a special flavor of JCAMP that doesn't always follow the original=20 specs, so I guess it needs some special treatment. Maybe Brkhard has an idea for a less clumsy way to treat the <>s? Mit freundlichen Gr=FC=DFen / Best regards Maren.=20 Dr. Maren Fiege Senior Product Manager =20 Waters GmbH Europaallee 27, D-50226 Frechen, Germany Tel.+49 2234 9207 - 0 Fax +49 2234 9207-99 http://www.waters.com/informatics=20 "Prof. Robert John Lancashire" <rob...@uw...> wrote on = 11.04.2006 15:58:18: > Maren >=20 > it is true that you can add a $$ and a comment at the end of a header=20 value > but also true that you can put in a $$ at the start of a line with a=20 comment. >=20 > In the first case it is perhaps easy enough to identify what the comment > referred to but not so in the second case. >=20 > In fact the IR protocol had suggested that after the ##JCAMP-DX=3D > label that a comment was inserted that gave the software and > version that created the file. This is not always done. >=20 > I note that in the Bruker "vs 6" NMR files that they have things like > ##TITLE=3D > ##JCAMP-DX=3D > ##DATA TYPE=3D >=20 >=20 > and further down may have > $$ ##TITLE=3D > $$ ##JCAMP-DX=3D > $$ ##DATA TYPE=3D >=20 >=20 > which is something I was not expecting! >=20 > To try to read every JCAMP comment line and convert < and > > to XML/HTML < and > is a possibility but clumsy!? >=20 > Robert >=20 >=20 >=20 > on 11/04/2006 09:31 AM Mar...@wa... said the following: > > Hi,=20 > >=20 > >> Yes. There's no explicit relation between an XML comment and the=20 > >> associated element. The same problem exists in JCAMP. It's hard to=20 > >> determine which data item a JCAMP comment belongs to. > > Is that so? I thought you could put a JCAMP comment into a line that=20 > > already has a JCAMP label in it. Robert? > >=20 > > Mit freundlichen Gr=FC=DFen / Best regards > >=20 > > Maren.=20 > >=20 > >=20 > > Dr. Maren Fiege > > Product Manager > >=20 > > Waters GmbH > > Europaallee 27, D-50226 Frechen, Germany > > Tel.+49 2234 9207 - 0 Fax. +49 2234 9207-99 > >=20 > > http://www.waters.com/informatics=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Prof. Robert J. Lancashire mailto:rob...@uw... > Department of Chemistry Tel (876) 512 3026 > University of the West Indies, Kingston 7 Fax (876) 9771835 > Mona Campus, JAMAICA. http://wwwchem.uwimona.edu.jm/chrl.html >=20 |
|
From: Burkhard S. <bur...@bu...> - 2006-05-02 16:48:41
|
Hi, it's true, in XML you need to escape the < and > characters so that the parser won't confuse them with element boundaries. In Java, you can use two calls to the String.replaceAll method to do this. See here: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#replaceAll(java.lang.String,%20java.lang.String) Best regards, Burkhard Mar...@wa... wrote: > Hi Robert, > > sorry for the delay in replying. I've been on the road too much... > "V6" is a special flavor of JCAMP that doesn't always follow the original > specs, so I guess it needs some special treatment. > Maybe Brkhard has an idea for a less clumsy way to treat the <>s? > > Mit freundlichen Grüßen / Best regards > > Maren. > > > Dr. Maren Fiege > Senior Product Manager > > Waters GmbH > Europaallee 27, D-50226 Frechen, Germany > Tel.+49 2234 9207 - 0 Fax +49 2234 9207-99 > > http://www.waters.com/informatics > > > > "Prof. Robert John Lancashire" <rob...@uw...> wrote on > 11.04.2006 15:58:18: > >> Maren >> >> it is true that you can add a $$ and a comment at the end of a header > value >> but also true that you can put in a $$ at the start of a line with a > comment. >> In the first case it is perhaps easy enough to identify what the comment >> referred to but not so in the second case. >> >> In fact the IR protocol had suggested that after the ##JCAMP-DX= >> label that a comment was inserted that gave the software and >> version that created the file. This is not always done. >> >> I note that in the Bruker "vs 6" NMR files that they have things like >> ##TITLE= >> ##JCAMP-DX= >> ##DATA TYPE= >> >> >> and further down may have >> $$ ##TITLE= >> $$ ##JCAMP-DX= >> $$ ##DATA TYPE= >> >> >> which is something I was not expecting! >> >> To try to read every JCAMP comment line and convert < and > >> to XML/HTML < and > is a possibility but clumsy!? >> >> Robert >> >> >> >> on 11/04/2006 09:31 AM Mar...@wa... said the following: >>> Hi, >>> >>>> Yes. There's no explicit relation between an XML comment and the >>>> associated element. The same problem exists in JCAMP. It's hard to >>>> determine which data item a JCAMP comment belongs to. >>> Is that so? I thought you could put a JCAMP comment into a line that >>> already has a JCAMP label in it. Robert? >>> >>> Mit freundlichen Grüßen / Best regards >>> >>> Maren. >>> >>> >>> Dr. Maren Fiege >>> Product Manager >>> >>> Waters GmbH >>> Europaallee 27, D-50226 Frechen, Germany >>> Tel.+49 2234 9207 - 0 Fax. +49 2234 9207-99 >>> >>> http://www.waters.com/informatics >>> >>> >>> >>> >> >> -- >> Prof. Robert J. Lancashire mailto:rob...@uw... >> Department of Chemistry Tel (876) 512 3026 >> University of the West Indies, Kingston 7 Fax (876) 9771835 >> Mona Campus, JAMAICA. http://wwwchem.uwimona.edu.jm/chrl.html >> > > |
Thanks for helping keep SourceForge clean.
X