This repository contains the SPARQL queries and Lisp code for the CODO ontology which can be found at: https://bioportal.bioontology.org/ontologies/CODO The SPARQL queries are in text files and consist of common queries that can be used to analyze the data. They can be run on any SPARQL 1.1 compliant engine. There are also SPARQL queries that transform the data but those are wrapped in Lisp functions (so that severaly SPARQL transformations can be run at once).

CODO-Lisp

Lisp files for the CODO Covid-19 Ontology

1. Configuring Lisp to Access Allegrograph: Before you run the Lisp files you need to configure your Lisp environment to work with the Allegrograph server. Make sure the Allegrograph server is running and is accessible from your Lisp client. In my environment I first run Allegrograph in Docker and then navigate to: a localhost address in Chrome.
2. In DOS navigate to the main Lisp directory. In that directory there should be a file called mlisp.exe. This is not the standard Lisp that is installed when you install Allegro Common Lisp. I think there is some minor difference having to do with case sensitivity. Hence, when you install Common Lisp you install an environment with the IDE already up and running. When you run this mlisp.exe file from DOS you need to setup your environment.
3. When you run mlisp it will bring up a basic Lisp environment with a Lisp listener. In the listener type in: (require :ide). Wait while some new windows come up then in the listener type: (ide:start-ide) to bring up the complete Lisp IDE.
4. Now you need to load the Allegro Lisp client. In the Lisp listener execute: :cd C:...\agraph-7.0.2-windows.64-client-lisp-acl10.1 Then: :ld agraph.fasl. (Note fasl files are compiled Allegro Lisp files). This fasl file is what gives you the Lisp client that connects to the Allegrograph server. BTW, normally I would include all these setups in one file but at least for me there seems to be a difference when attempting to put them all into one function and executing them from the listener. I think it may have to do with the fact that you can’t compile the following functions until you load the fasl file but for whatever reason I just execute them one by one in the listener. There aren’t many.
5. Now you setup your Lisp environment. You want to enable certain macros that make it easy to access Allegrograph objects without typing long URL’s. Again in the Lisp Listener do: (in-package :db.agraph.user) then: (enable-!-reader) then: (enable-print-decoded t).
6. Now you should be able to open a triplestore. For example I usually do: (open-triple-store "CODORealData" :triple-store-class 'remote-triple-store :server "localhost :port NNNN :user "user-name" :password "user-pw") Of course the actualport, user-name, and user-pw will depend on your installation.
7. Finally, you want to register any namespaces you will need In your code. I always register the codo namespace but sometimes others as well: (register-namespace "codo" "http://www.isibang.ac.in/ns/codo#")
8. For more details see: https://franz.com/agraph/support/documentation/current/lisp-reference.html
9. Running the CODO transformations from Lisp: There are 4 files: sparql-transforms.cl, sparql-regex-transformations.cl, sparql-cluster-transforms.cl, and city-and-admission-transforms. Make sure you set up the Lisp environment for an Allegro client as described above.
10. Compile and load the 4 files (or just load the compiled fasl files included in this repository). Then from the listener execute: (run-codo-sparql-transforms) followed by (sparql-regex-transforms). Then run: (codo-cluster-transforms) and finally (city-outdate-transforms).
11. As you run each file you should see messages in the listener as they transform various strings into objects. At this point if all goes well you should do a query in Gruff for reasonString or clusterString you should find no values (except one outlier reasonString that is blank). This indicates that all strings have been processed.
12. If things don’t seem to be processed correctly you can run (enable-test-mode) before running any of the transformations. Normally when a utility string such as a reasonString gets transformed it is deleted. In test mode the utility strings are saved to corresponding test strings. They still need to be deleted because the transforms are defined in such a way as to go from general to specific. I.e., the later transforms assume that certain kinds of patterns no longer exist and won’t work properly if those strings still exist. So in test mode the strings are deleted from their utility string properties but put on corresponding test string properties so you can still check what a utility string was when you examine an object and make sure that the string was correctly processed and created the appropriate objects and property values. If you enable test mode and you then want to delete all the test strings all you need to do is run (disable-test-mode).