Sean Bechhofer. The dig description logic interface: Dig/1.1. In Proceedingsof the 2003 Description Logic Workshop (DL 2003), 2003. 1 IntroductionMost description logic (DL) systems present the application programmer with a functionalinterface, often defined using a Lisp-like syntax. Such interfaces may be moreor less complex, depending on the sophistication of the implemented system, and maybe more or less compliant with a specification such as KRSS [11].The Lisp style of the KRSS syntax reflects the fact that Lisp is still the most commonimplementation language for DLs. This can create considerable barriers to theuse of DL systems by application developers, who often prefer other languages (inparticular the currently ubiquitous Java), and who are becoming more accustomed tocomponent based software development environments. This is of increasing importancegiven current interest in Web Services and service based architectures.In such an environment, a DL might naturally be viewed as a self contained component,with implementation details, and even the precise location in which its code isbeing executed, being hidden from the application [3]. This approach has several advantages:the issue of implementation language is finessed; the API can be defined insome standard formalism intended for the purpose; a mechanism is provided for applicationsto communicate with the DL system, either locally or remotely; and alternativeDL components can be substituted without affecting the application.This approach was adopted in the CORBA-FaCT system [5], where a CORBAinterface was defined for a description logic reasoner. This wrapping of the FaCTreasoner facilitated the successful use of the reasoner in applications such as OilEd [4]and ICOM [6].Although useful, CORBA-FaCT suffered from a number of inadequacies. The conceptlangage does not cover concrete domains, and as the interface was largely basedon the FaCT reasoner (which did not support an A-box at the time), functionality relatingto Aboxes was missing. In addition the identifiers allowed were closely tied to theunderlying Lisp implementation (case insensitive strings of essentially alphanumericcharacters). This introduces problems when trying to reason over languages such as1DAML+OIL where classes are referred to using URIs1.The RACER [8] system adopted a slightly different mechanism, providing a socketbased interface for use by client applications. This again provides a language neutralAPI, but the lower-level interface places more onus on the client programmer.As part of the activity of the Description Logic Implementation Group (DIG2) anew interface for DL systems is being defined.The specification described here should be considered as a Level 0 specification –in its current version it contains just enough functionality to enable tools such as OilEd[4] to use the reasoner. Later version of the specification will address issues such asstateful connections, transactions, reasoner preferences and so on. There may also bethe possibility of extending the concept language.There is nothing inherently new in this specification – it is effectively an XMLSchema for a DL concept language along with ask/tell functionality. Along with thedefinition of this interface, however, there is a commitment from the implementors ofthe leading DL reasoners (FaCT [9], RACER [8] and Cerebra3) to provide implementationsconforming to the specification. This will truly allow us to build plug and playapplications where alternative reasoners can be seamlessly integrated into our systems.
阅读全文(4038) | 回复(0) | 编辑 | 精华
)