Loading and storing SNOMED CT Compositional Grammar

[danka74]

Dear All,

I have implemented classes supporting loading/parsing and storing of SNOMED CT Compositional Grammar using the OWL API. What would be the best way to contribute this to the OWL API project?

https://github.com/danka74/SnomedCTParser http://ihtsdo.org/fileadmin/user_upload/doc/en_us/tig.html?t=rfg2_expression

/Daniel

[ignazio1977]

Hi, and thanks for your contribution. If I understand its purpose correctly, this tool fits well as an OWLAPITOOLS module. We're trying to make it easier to plug and unplug functionality in the core API, by adding jars to the classpath rather than building a monolithic OWL API distribution.

The simplest way I can think of for this to be integrated in OWLAPITOOLS is for you to fork OWLAPITOOLS, add your module and submit a pull request - this ensures the authorship of the commits, and if you continue making changes to your project it will be easy for me, or another of the OWLCS members, to pull in the modifications.

I don't think we can include a copy of SNOMED CT in the resources folder, because of its size. I'm not sure about whether that's acceptable for SNOMED CT license as well - do you happen to know? Cheers and thanks again, I.

[danka74]

Hi, and thanks for a quick reply. The purpose, at least my intention, was to allow the use of OWL API OWLManager.loadOntology... and OWLManager.saveOntology methods to load and store SNOMED CT expressions (which is a small subset of EL). This in turn would allow loading and storing from inside OWL API applications such as Protege. When I tried to look into the OWL API code for registering parsers and storers, it seems the formats are hard coded into the OWLManager constructor/creator. The copy of SNOMED CT in the resources folder has to be provided through other means due to licensing issues. This is only needed to run some JUnit tests. I've asked IHTSDO to be able to include a small module extracted from SNOMED CT to run those tests. Cheers, Daniel

[ignazio1977]

Up until version 3.5, adding more parsers and storers is cumbersome. In version 4, thanks in no small measure to Peter @ansell, it is much easier to add them, even on the fly, at runtime. So I would recommend to first integrate with version 4 and then work backwards for 3.5. Thinking about it, it's probably possible to backport the ServiceLoader implementation we are using in version 4 to achieve a simpler pluggable architecture for 3.5 - this would be a nice pilot.

[danka74]

Thanks, I'll look into v4 then. Cheers, Daniel

[ignazio1977]

We don't have tutorials yet, but in short what's needed is two text files in META-INF/services named after the parser and storer interfaces, containing the name of the implementing classes. There is an example of this in the rio module - all the rio parsers are added with this mechanism.