Review recommendations and recommended actions
The following responses recommended by the LarKC management team (Fensel, Kerrigan, vanHarmelen, Witbrock).These also absorb all action items from the joint meeting with Soa4allMeeting in September, as well as Mick's June09ReviewNextSteps.
1. The lightweight ontology language (L2) is very closely related to the new OWL profiles, and consideration should be given to aligning it with the OWL RL profile.n
WP1 will make a detailed analysis of the differences between L2 and OWL RL, and based on this we decide if L2 and OWL RL will become precisely the same, or if L2 becomes a motivated subset of OWL RL.
2. Efforts should be made to identify better benchmarks; tracking the work of the EU SEALS project will be worthwhile in this regard.
Mick will organise an alignment workshop with SEALS, say in 6 months from now.
3. It is suggested that plug-ins should also give a description of their capabilities with respect to data; to do so they would do well to use http://rdfs.org/ns/voidguide .
[Note that voiD is not suited to annotate plugins with their data-capabilities. It's only suited to describe individual datasets (ie plugin data-capability descriptions could be matched against voiD descriptions of datasets). ]
In the short term WP1 will investigate to annotate our datasets with voiD or come up with an alternative.This will be reported in a new deliverable on L2 (the same one which also compares L2 with OWL RL); Dataset providers will then use this solution to describe their datasets. In the longer term we will investigate how plugins can self-describe their input-capabilities, to be reported in D1.3.2 (at M33).
4. The performance characteristics of IE systems should be part of the declaration of plug-in capabilities.
[Note: It is strange that this comment is only given for "IE systems". It just as well applies to other plugin-types which are non-IE-like].
This should be covered by the non-functional plugin-properties that we identifid in D1.3.1 (section 3). We will revisit the set of properties in the revision at M33 (D1.3.2), at which time we should also try to include anything useful that the semantic services community has come up with, through our links with SOA4ALL.
5. Advanced IR research should pick up pace in the next period, and serious consideration should be given to the use of geometric methods; paying attention to the open-source ?SemanticVectors project might be useful in this regard.
The D2.5.2 prototype (M24) will reflect this.
6. There should be better communication and collaboration between WP2 and WP3, e.g., regarding how to implement and reason over sparsely populated vector spaces.
WP2/WP3 leaders are asked to come up with a plan for implementing this recommendation.
7. It may be necessary to focus more tightly within the IR space and decide what specific contribution the consortium wants to make, e.g., how advanced IR methods really apply specifically to RDF retrieval.
WP2 leader is asked how to implement this recommendation.
8. Plug-ins for existing DL reasoners should probably be based on the OWL API rather than on the DIG interface.
In the short term we will support the OWL API. In the long term we will also look at non-Java support (since OWL API is Java specific. To be done in WP4.
9. LarKC should continue to integrate functions represented by different plug-ins closer to each other and to push more functionality into the data layer; these are promising developments that go some way towards addressing scalability concerns.
10. There is some tension between the idea of an experimental platform for rapid prototyping and demonstrating reasoning that is revolutionary in both style and scale. The consortium needs to consider this very carefully and clarify if and how these apparently conflicting ideas will co-exist.
We agree on the need to make the "hunt for scale" a priority in the next 14 months. We will do this by
(i) top-down thinking about synergy between the different component WPs; about pushing functionality into the datalayer; about a triple-space-like implementation of the datalayer (SOA4ALL-style), etc.
(ii) bottom-up stress-testing the current platform to find out where the major bottle necks are.
This effort to "optimise" the platform needs to be balanced against the desire for a flexible architecture that can easily include external components developed by others.
11. The project should decide if dynamic composition of components is necessary for or central to the goals of the project; tackling this adds to the already long list of hard problems to be addressed by the project.
We agree that self-configuring DECIDErs are not mission criticial; we will not make this the focus in the next period, but keep some work going on resource allocation and configuration (and make this better aligned with any results from the semantic web services community.
12. Some plugins such as reasoners may have internal state of substantial size and complexity; the plugin interfaces should allow for keeping such states around and incrementally adding to them.
WP5 is asked to write a short note on how internal state can currently be represented and updated. Based on that report, WP5 should decide if updates on the LarKC architecture should take this issue into account
13. An extraction plugin could use VOID to describe the resources that it has access to. This would facilitate community reuse of data sets, make the architecture still more open, and would be good politics towards the rest of the semantic community.
This is already subsumed in our response to recommendation #3.
14. More instrumentation should be added to the LarKC platform.
Together with scalability, this should be focus in the next 14-month period. It is also essential for the effort towards scalability (points 9-10).
15. Demonstrating the use of very large volumes of data in the use cases should be a high priority.
To be demonstrated in the upcoming use-case prototypes, which are D6.5, D7a.3.1 and D7b.3.1b, all in M18.
16. The contribution of the ?SaltLux partner to the Real Time City use case should be made more clear.
This was simply a miscommunication at the time of the review. Taskleader of WP6 is asked for a brief written statement to the PO (to be transmitted to the reviewers), detailing the involvement of ?SaltLux in WP6.
17. Attention should be given to making the tools developed in WP7 easier for scientists to use; we would recommend looking at the query composition technology from CYC, and machine learning expertise from WP3 might also be applicable.
The next generation of use-case prototypes (D7a.3.2 and D7b.3.2b, all in M33) should demonstrate this. SOA4ALL's process editor could also be used as a GUI for building LarKC workflows.
18. Making an Amazon EC2 image with LarKC preloaded is strongly recommended.
WP5 and WP8 are asked to take responsibility to set up public EC2 images of the platform + example workflows, so anyone with an EC2 account can run them.
19. It is also recommended to make LarKC a deployment vehicle for high volume applications like social recommendation, which could well utilize LarKC's NLP and machine learning capabilities.We choose not to follow this recommendation since if done seriously, this would turn into an additional use-case, and would stretch beyond the allocated resources.