Hi Peter,
I decided to CC Miguel on this too, since you mention the happiness of the Jmol team...
Feel free to repost this discussion to Jmol list.
I can't speak for Miguel, but I think Miguel is OK with this. I assume that initially it would be another way of getting input into Jmol. I am not sure whether, if it all works out well, he would be willing to completely go this way. Keeping the java-code based interpretation available could be good for more complicated cases. I'm not sure.
I just quickly looked at some RDF and OWL stuff. I am a simple chemist, so all this ontology stuff gets to be a bit confusing (and computer scientists do talk in very different ways it seems). I did not get the idea that it supports computations based on resources. When looking through the differences between OWL Lite, DL and Full, I noticed the mention of the computability of conclusions, but I don't think that that really means that one can calculate things. Also they only mention cardinality (only 0,1 in Lite and full in DL and Full). I have the feeling that it has more to do with counting the number of resources that match something, as opposed to doing floating point arithmetic on the interpreted value of a property. So I think some scripting language may be needed....
I am not sure how to interpret your statement:
This is not required for JUMBOMarker, so don't worry
If you have real applications that you will definitely use then we may be able to helpI would think that Jmol would be the real application. Or if you mean the application of the approach, then the implementation of the currently supported computational chemistry inputs (e.g., NWChem, Gaussian, FoldingXyz, Gamess, GhemicalMM, Hin, Jaguar, etc.) into Jmol could be what you are looking for.
Yes. I was simply saying let's start with the most popular/tractable one to give us experience rather than trying to do all.
I am not sure whether I would be able to implement this, though.
If I were the one that needs to do this (and again, that may not be the best person for the task), I would probably try to get JUMBOMarker to run properly
yes
and see whether I can develop a template.xml for some of the Jmol supported filed formats,
yes
do the conversion and see how well Jmol's CML reader is able to handle it.
yes
I assume that that will give a me a sense as to how feasible it is for me to come up with those templates.
Seems fine. I think the main questions will be:
- what info other than molecules does Jmol wish to process
- what should Jmol do with multiple molecules (e.g. optimsation and dynamics).
What do you think?
Ren�
PS Miguel, should we throw this in the Jmol developer's list? I am not sure how many people there are thinking about the readers...
PPS sorry that I used JMol as opposed to Jmol. I am a Mac person, and I am used to capitalizing the beginning of words...
On Feb 22, 2005, at 2:37 AM, Peter Murray-Rust wrote:
At 16:51 21/02/2005 -0500, Ren� Kanters wrote:Hi Peter,
Yes, great idea
I had an off-line discussion with Miguel about JUMBO and JUMBOMarker. Based on that he thought it might be a good idea for me to get in touch with you and see what you think/are willing to do.
When I was working on the NWChemReader in JMol it occurred to me that it was tedious to have to write 'parsers' for each type of input file for JMol (i.e., output file from a computational package) and wondered about trying to come up with a regular expression based approach. It turns out that the old VMs don't have libraries for that, so if we go that way, we'd have to add a library for that to JMol, but Miguel thinks that that would be fine.
The Regexps can probably be easily managed with other regex libraries. That is how we used to do it.
When I saw your email about JUMBO and in following up saw in you pdf file of the paper what you do with JUMBOMarker, I realized that you had done just that.
What I was wondering about: Do you think it would be useful to create a new 'ModelAdapter' that basically works like JUMBOMarker in that it can take a template xml file for a file format and parse it based on that. Internally that could either go to a CML stream that is then interpreted by a CML parser, or it could go directly into mapping the result in JMol's internals
Yes - I think it is an excellent idea as long as the Jmol team are happy
The advantage could be that if JMol uses this, more template files may be developed for the translation, and the two communities could share them...
Also having JMol with this mechanism allows for direct visualization of the resulting file, making development of the templates (fine-tuning) a bit easier.
Finally if the JMol application then also allows one to save the file, we'd basically deliver a nice, visual checkable CML converter, and one that keeps the proper hierarchy (based on the template).
Miguel suggested that I play around with it and see whether that would work, but I am pretty busy with other stuff too (my job gets in the way of having fun some times). Also I am not familiar with the details of JUMBO and you are :-). On the other hand it may be a lot easier if some of the JUMBOMarker code could be used. Is it maybe even available as a nice package?
If you have real applications that you will definitely use then we may be able to help
There was one major thing that did cross my mind that this approach may not be able to do: In some cases it is necessary to calculate one value based on something else. For example: NWChem does not report the atomic charge in a calculation, but the total number of electrons for that atom, so that the charge is really the atomic number - total number of electrons. In this case the same line has both values in it. So the question becomes: can the template describe that kind of operations to be performed? If not, going to direct java code for the interpretation of comp-chem output files may still be needed....
Good question. We are looking for a semantic language. Maybe OWL/RDF provides enough. Otherwise we have to add some simple scripting.
In haste - look forward to hearing more.
P.
Ren�
-------- Ren� P.F Kanters, Ph.D. Director of Computer Assisted Science Education Department of Chemistry University of Richmond, Virginia 23173 Phone: (804) 287-6873 Fax: (804) 287-1897 Email: [EMAIL PROTECTED] Web: http://www.richmond.edu/~rkanters
Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069
Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
