Call for Lisp Developers: cl-semantic
Lisp has always been well positioned do to it’s functional programming model and list/symbol processing features to make a gigantic contribution to the Semantic web, or since people like a release number, “web 3.0″. In fact, many of you will be quick to point out that Racer Systems (which needs to hire a web designer fast) has led the charge of using Lisp’s incredible AI history to make some pretty compelling advances in reasoning systems with it’s products such as RacerPro.
The semantic web idea has been around for some time, and has in the last few years began to solidify around standards such as OWL/OWL-QL and SWRL. However, although a lot of the modeling tools for modeling ontologies and exporting them to OWL are opensource and has a vibrant community of developers (of course Protege from Stanford University being the one that comes to mind fastest), the backend reasoning systems that assembles these ontologies and creates relationships are either completely closed or free in binary form but closed source. The reason for this is obvious, the first group to build a really good OWL parsing and reasoning system will be very rich.
However, I have been looking over a lot of research from the likes of Eugene Agichtein & Silviu Cucerzan of Microsoft Research regarding speeding up extraction [Predicting Accuracy of Extracting Information from Unstructured Text Collections] and I can’t help but think that the community could use a backend that competed with, if not RacerPro directly, at least it’s object code library, RacerMaster.
I’ve been working on a side project building out some simple macros on how this could work, and think that if we all got together to work on building a great language model for expressing ontologies and manipulating them at the high level, as well as defining the relationships between them in a OWL-QL like language, we could significantly contribute to moving the semantic web environment forward.
So, I discussed the idea with a few friends with more education than me, presented it to the folks over at common-lisp.net and they decided it sounded like a great project. So, we’re up and running. Now I need your help 
This is how I see the project progressing:
- develop parsing of OWL Lite / OWL DL documents (using Wilber).
- develop easy to use macros for T-Boxes, A-Boxes, ect.
- grab a whole bunch of PhDs and get them to implement SHIQ for us.
- implement the OWL-QL query processing system for compatibility.
- implement the high-level language model for easy manipulation of the ontologies.
- give it Java wrappers or use Allegro’s and make people pay for that much.
- connect to Protege using simple TCP/IP or some protocol we can all agree on.
- beer for all the developers on me!
OK, maybe we should just start with bullet point 1 and be thankful we did that. However, I think developing this language model to compete with RacerMaster would be a great thing for the semantic web and Lisp communities.
If you want to help, visit the project page || email me using my contact info and PGP key (for adding you to the project if you are approved.)
January 31st, 2006 at 5:30 pm
[...] Help wanted advertisement. [...]
January 31st, 2006 at 11:34 pm
Sigh. To my knowledge, Bossem is not a “real” OWL DL reasoner, in that it’s just a reasoner and doesn’t purport to implement a decision procedure for any significant fraction of OWL DL. However, you are just wrong about the closedness. There are at least 7 “reasoanable” OWL DL (or close, or related) reasoners out there. Several are open source:
Racer (extended subset of OWL DL, roughly SHIQ but with aboes) (Closed, for pay)
FaCT (SHIQ, no aboxes) (In Lisp, open source but gnarly)
KAON2 (SHIQ with aboxes, sorta) (Closed, java)
FaCT (SHOIN, i.e., OWL DL, not really aboxes) (GPLed, C )
Pellet (SHOIN(D), conjunctive query, debugging) (Java, BSD/MIT licence)
Cerebra (not sure what dl; aboxes) (Closed, C )
DLP (Converse PDL, no aboxes) (Open, ML)
None of this is to discourage you implementing an OWL system! Some parts are a lot of fun and some are a pain in the ass
Feel free to come over to the Pellet list for kibbitzing or advice. We’d be happy to help out.
(For what it’s worth, I estimate that somewhere between 1 and 2 person years went into Pellet, but never in sustained bursts, and Pellet is quite respectable as a reasoner. Of course, we mostly use the OWL API for parsing, so we’re probably a little less from scratch.)
February 1st, 2006 at 12:08 am
Bijan:
Thank you for your feedback. I’ll look in to them. I do think your list is interesting in that most of them are writen in Algol based languages. A reason I think Lisp would be a better choice (although I am most familiar with Java, C ) is because of it’s ability to manage the exact kind of data relationships that a reasoner would need, and to implement the algebra in a more flexible way. However, I have been a little leery of writing something in a language that may not have as much of a developer buy-in as one written in Java would, especially one that needs a large base of developers to innovate.
I will certainly take you up on your offer to complain in your project forums, and if anyone complains I’ll tell them you sent me
February 1st, 2006 at 12:27 am
There is also a lisp based reasoner for the subboolean dl EL(I think , but maybe “H”) called CEL. It uses, IIRC, neither tableau nor resolution, but something tailored to it. Uli Sattler’s list of DL reasoners has links.
A subboolean like DL Lite or EL variants would be a very nice and reasonable first project, FWIW.
Re: choice of language. Well, I did the prototype for Pellet in Prolog and it was fine. But at my lab, accessibility and familiarity (for the main developer) really really trumped. We want to easily integrate our reasoner with our editor, SWOOP, and other toolkits that we built. Also, while a bit minority language fan (Smalltalk, Lisp, Prolog, functional languages), it’s hard to sell a minority tech written in a minority tech language.
We use the ATerm library to give us some joy (it helped with the transliteration), but really, you are better off, if you want a practical system, working on the engineering. From talking to the Racer guys, they had to rip out all their nice lispiness to get appropriate performance. Now, they were aiming for maxing it out, but Pellet is aiming more at reasonable structure and has gotten the same comments from some folks.
Pellet is rather easy to extend, though it really helps to talk to Evren Sirin if you are going to go at the internals. We have 3-6 people who are or are becoming conversant with the code base, so really, you can do a fair bit and hope for some help.
An ALC reasoner, though, is a fun and easy project, and chapter 2 of the description logic handbook is enough to get going. I had an undergrad class do one in Python as their final projecdt
February 1st, 2006 at 2:41 am
Bossam may not be a “real” OWL DL reasoner in that it is not based on a DL decision procedure that is known to be sound and complete. But there’s a separate league for*not so real* OWL reasoners like Euler, Hoolet, and Jena etc, which are similar to Bossam in approach to OWL inferencing. The approach is to have a reasoning system and then on top of it to implement OWL inference rules. This approach is known to be producing incomplete, and sometimes unsound, OWL reasoners. An important issue for the reasoners in the minor league is to provide *sound* and *practically plausible* OWL reasoning capabilities.
BTW, even though the approach has problems theoretically, it can provide features that’re not found in *real* OWL reasoners, such as additional expressivity of processing rules, non-monotonic reasoning, procedural attachments etc, which are invaluable in building real-world applications in certain domains.
Yep. I’m just adding my cents to protesting that *non-real* OWL reasoners have their own merits.
I admit that this comment does not touch the intent of the original post, anyway.
February 1st, 2006 at 12:51 pm
Minsu:
Is there any academic research on the soundness of one approach verses another? I’m thinking of research work I can do in this area, and I think perhaps a comparison between the two models of implementing a reasoning solution might be a good thing.
Your comments may just be speculation, but if there is a real example that your approach provides more complete reasoning vs. the DL decision practices already in place? If so, if we could move this in to the mathematical realm with proven results, it might help improve all the systems out there.