thomas.pav...@free.fr wrote: > 'pure python' sounds good to my ears. Although one might consider > Python as a 'glue' language, ...
I consider that _one_ of its many possible uses. ;) > I'm not a fan of the JPype/Jython > technology. I had a look to the JSDAI.net website and tried to do > something within Jython. Failed. It would make me so happy if a > guy could have the good idea (and time) to port such a work to a > pure Python framework! The work required would be truly gigantic, and I would be surprised if anyone would want to do it. As I say, I have done some work in that area, so I have an appreciation of the difficulty -- EXPRESS is a rather poorly designed language and very difficult to parse properly. There are various approaches one could take, but I really think creating a Jython wrapper for JSDAI is the best approach, especially given that LKSoft has many products built from JSDAI, which is very solid, and LKSoft keeps it up to date with the latest STEP modifications and recommended practices -- which would be a _huge_ burden for a non-commercially supported open source project! Like most pythonistas, I would prefer to have as loose a coupling as possible between my python applications and any java applications, so I would try to find some way to communicate with the Jython-wrapped JSDAI by way of some protocol, preferably a very simple messaging protocol, so that the main part of my python code can run in a regular Python (i.e. C Python) process rather than Jython. >>> Such a knowledge framework could be achieved with pythonOCC; >>> your work could also, I think, easily be merged. >> Or at least be a closely-coordinated "sibling" project. :) > > For sure. Let's think about that. To be discussed! Even within my project, I would like to keep various pieces relatively loosely coupled, so that they can be used as independent packages in different application domains. >>> One solution could be to build a kind of 'super-object' >>> that would embeds a geometrical/topological description >>> (pythonOCC) and a pointer to the related ontology (for instance >>> a UID or an URI to an ontology SOA based server). This last >>> point is closely related to my research work and the specialization >>> of the STEP AP239 (or ISO 15926) generic data model. >> Sounds reasonable. Since you are working with AP239, you >> are probably already aware that the EuroSTEP folks who are >> developing AP239 are involved in developing related ontologies >> also. Some other people in the STEP community, such as Lothar >> Klein (LKSoft), are also working on STEP-related ontologies. > > I work with EuroStep french team, located near Paris. > STEP/ontologies is a wide and still opened issue... Yes, there are most definitely several possible approaches to using STEP data structures in the context of ontologies, and my sense is that none has yet become "standardized", in any sense. Steve _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
