Implementation of plug-ins for the LarKC platform - Discussion of relevant/open issues
Some questions that we would like to discuss are the following (feel free to add more questions/comments that you think we should discuss during the Telco):
Currently [version 0.3 of the platform] the data that is passed to the reasoner (a eu.larkc.core.data.?TripleSet) is accessible through an URL. Is this the only way we have to pass data to the reasoner? or, is it allso possible to store the data locally, e.g. in same environment where reasoner is running.
- We can imagine that some of the plug-ins may need to have access to external libraries to do their work (e.g. a reasoning plug-in may implement its functionality using a standard reasoner such Pellet). The question then is where do these libraries will reside? inside the platform kernel? or will the platform call the plug-ins remotely and thus the libraries the plug-ins use are not an issue for the platform.
- If we allow to install/add external libraries to the platform implementation (becuase some plug-in may need them), how do we deal with licence issues?
- Changes from version 0.3 to 0.4 of the platform:
- Why did we drop the Jena-backed implementation of the interface RdfGraph/TripleSet/VariableBinding/RdfGRaphUrl/SPARQLQuery?
- What happen if we keep such an implementation of those interfaces?
- Currently the platform is not able to talk to reasoning plug-ins that don't provide a LarKC Reasoner interface. For example, it can't communicate with DIG reasoners. Perhaps one way to solve this, instead of wrapping those plug-ins behind the LarKC Reasoner interface, could be to provide a DIG-to-LarKC implementation that bridges the gaps between these two interfaces.
- If we want to show some examples how plugins can be used/called, where should the source codes of the examples be located at the platform?
- Is there any path for the documentary (user manual, tutorial, examples, readme, license, etc.) in the platform?
- in order to call the pellet sparql-dl reasoner, we have to convert a sparql query into a jena query, how can we do that in the platform 0.4?
The ?GraphProcessor Reasoner plugin for Urban baby LarKC (WP6): How to define the shortest path for a route planner in the LarKC Platform? What is the output format of the Plugin?
WICI’s Comments on Proposed Questions for the WP4-5 Telecon on Feb 19th, 2009
International WIC Institute (WICI), Beijing University of Technology http://www.iwici.org
[1] Currently [version 0.3 of the platform] the data that is passed to the reasoner (a eu.larkc.core.data.??TripleSet) is accessible through an URL. Is this the only way we have to pass data to the reasoner? or, is it also possible to store the data locally, e.g. in same environment where reasoner is running.
Yi Zeng (WICI): I think there is a big challenge only using current way of data access. It seems that if we consider using this way, we have to gradually download all the data (at least part of the data) from the URL so that the local reasoner could do reasoning on it. And if the data sets are huge, the time for data accessing may be much longer than the time for reasoning, and in this way, we bring more trouble for LarKC to handle. Another requirement from the LarKC user perspective is that they may just want to use LarKC to handle their own large scale datasets locally, and remote access seems not to be a good solution. But considering distributed datasets world wide, using a URL might be the most practical way. We may provide options concerning data access strategies (One example is that we can access global information through FTP and HTTP using web browser, and we also can input a local address to access the disk through the same web browser). Plus, four types of RDF files have been discussed in the page for the Data Layer API (http://wiki.larkc.eu/LarkcProject/WP5/DataLayerAPI), and local “RDF store” is listed as the first type that needs to be handled.
[2] We can imagine that some of the plug-ins may need to have access to external libraries to do their work (e.g. a reasoning plug-in may implement its functionality using a standard reasoner such Pellet). The question then is where do these libraries will reside? inside the platform kernel? or will the platform call the plug-ins remotely and thus the libraries the plug-ins use are not an issue for the platform.
Yi Zeng (WICI): If the external libraries are not wrapped into the platform kernel, then it is possible that the platform cannot provide a stable service, since the environment of the external libraries may change, which may cause a fail to call remote plug-in. Then the full process may be affected.
[3] If we allow to install/add external libraries to the platform implementation (because some plug-in may need them), how do we deal with licence issues?
Yi Zeng (WICI): we have to examine every of the installed/added external libraries. One example is that pellet uses a dual license. If LarKC is going to be an open source platform and it uses pellet as an external library, then the license for LarKC should be compatible to AGPL version 3 license. Exterial libraries with proprietary license should not be considered.
[5] Currently the platform is not able to talk to reasoning plug-ins that don't provide a LarKC Reasoner interface. For example, it can't communicate with DIG reasoners. Perhaps one way to solve this, instead of wrapping those plug-ins behind the LarKC Reasoner interface, could be to provide a DIG-to-LarKC implementation that bridges the gaps between these two interfaces.
Yi Zeng (WICI): If X-to-LarKC implementation can be made, it will be very good examples and convenient for other communities to integrate their own plug-in to LarKC platform.
[6] If we want to show some examples how plugins can be used/called, where should the source codes of the examples be located at the platform?
Yi Zeng (WICI): Another option is to provide an online package to download (or an isolated package with the platform), just like many development environments do.