• LarkcProject
• WP5
• docs
• platform
• ApiCurrentStatus

LarKC Plug-in API - Current Status of Development

1. Introduction

This page will describe the LarKC plug-in API in it's most current form. Information relating to previous revisions can be found in the 'history' section towards the bottom of the page. Plans for the immediate future are in the 'next steps' section.

To restate: You will find a lot of information about how the API got to its current state by following the links under 'history'.

While this page is intended as a summary of the current state of the API, the following pages are intended for discussion about various aspects of the API and how it will evolve in the future:

• General discussion of the continuing evolution of the LarKC plug-in API

• Discussion of programming models to realise 'anytime' behaviour

RFC: I'm not sure what the best format for this page should be. What would help more: UML diagrams, bare-bones java interfaces/classes, better English descriptions of classes? Please email Barry or Mick with suggestions or leave comments here:

<comments-for-better-presentation>

Note: Javadoc is (mostly) missing from the current interfaces due to the rather volatile nature of what is going on at the moment. More complete javadoc is expected after a couple more revisions.

2. Plug-in API

   1 public interface Plugin {
   2         public String getIdentifier();
   3         public QoSInformation getQoSInformation();
   4         public void setInputQuery(Query theQuery);
   5         public MetaData getMetaData();
   6 }

Interface supported by all plug-ins.

   1 public interface Identifier extends Plugin{
   2         interface Contract {}
   3 
   4         public Collection<InformationSet> identify(Query theQuery, Contract contract);
   5 }

Given a query (of some appropriate sub-type) identify resources that can be used to answer a query.

   1 public interface DataSetTransformer extends Plugin{
   2         interface Contract {}
   3 
   4         public InformationSet transform(InformationSet theInformationSet, Contract contract);
   5 }

Transform an ?InformationSet in one representation to another. No examples yet.

   1 public interface QueryTransformer extends Plugin {
   2         interface Contract {}
   3         public Set<Query> transform(Query theQuery, Contract contract);
   4 }

Transform one kind of query to another, e.g. extract a keyword query from a SPARQL query.

   1 public interface Selecter extends Plugin{
   2        interface Contract {}
   3 
   4         public TripleSet select (DataSet theDataSet, Contract contract);
   5 }

Chooses/samples/merges triples from one or more identified resources and returns them represented as a single triple set.

   1 public interface Reasoner extends Plugin{
   2         interface Contract {}
   3 
   4         public VariableBinding sparqlSelect(SPARQLQuery theQuery, TripleSet theTripleSet, Contract contract);
   5          public RdfGraph sparqlConstruct(SPARQLQuery theQuery, TripleSet theTripleSet, Contract contract);
   6          public RdfGraph sparqlDescribe(SPARQLQuery theQuery, TripleSet theTripleSet, Contract contract);
   7          public BooleanInformationSet sparqlAsk(SPARQLQuery theQuery, TripleSet theTripleSet, Contract contract);
   8 }

Execute a query against the supplied set of data.

   1 public interface Decider extends Plugin{
   2         public VariableBinding sparqlSelect(SPARQLQuery theQuery, QoSParameters theQoSParameters);
   3          public RdfGraph sparqlConstruct(SPARQLQuery theQuery, QoSParameters theQoSParameters);
   4          public RdfGraph sparqlDescribe(SPARQLQuery theQuery, QoSParameters theQoSParameters);
   5          public BooleanInformationSet sparqlAsk(SPARQLQuery theQuery, QoSParameters theQoSParameters);
   6 }

Responsible for controlling (possibly instantiating) plug-ins of the other types in order to fulfill a user query. Implementations could be anything from hard-coded and very simple to highly intelligent, dynamic meta-reasoners.

3. Data Structures

   1 public interface InformationSet {
   2 }

Base interface for all data containers.

   1 public interface NaturalLangaugeDocument extends InformationSet{
   2 }

For some use cases, it is possible to imagine that we might need implementations of this interface.

   1 public interface RdfStatement {
   2         Object getSubject();
   3         Object getPredicate();
   4         Object getObject();
   5         Object getContext();
   6 }

The basic unit of structured data within LarKC. This has been implemented, however, so far we have not had to use it.

   1 public interface RdfGraph extends InformationSet, Iterable <RdfStatement> {
   2         Object getName();
   3 }

Interface for named graphs of triples, whether they are internally stored or just conceptually represented.

   1 public interface DataSet {
   2         public void addGraph(RdfGraph is);
   3         public Iterator<RdfGraph> iterator();
   4 }

Interface for grouping together a single unnamed graph and a set of named graphs.

   1 public interface TripleSet extends InformationSet{
   2 
   3 }

Interface for specifying a subset of a dataset to be reasoned over.

   1 public interface VariableBinding extends InformationSet{
   2         List<String> getVariables();
   3 
   4         Iterator<Binding> iterator();
   5 
   6         public static interface Binding {
   7                 List<Object> getValues();
   8         }
   9 }

The results of a SPARQL select query.

   1 public interface BooleanInformationSet extends InformationSet {
   2         boolean getValue();
   3 }

The results of a SPARQL ask query.

   1 public interface Query {
   2 }

All query types implement this interface.

   1 public interface SPARQLQuery extends Query{
   2         public boolean isSelect();
   3         public boolean isConstruct();
   4         public boolean isDescribe();
   5         public boolean isAsk();
   6 }

A fully fledged SPARQL query.

   1 public interface TriplePatternQuery extends Query {
   2         public List<Triple> getExpressions();
   3 }

A query that is based on patterns of triples, e.g. "* foaf:knows *"

   1 public interface KeywordQuery extends Query {
   2         public List<String> getKeywords();
   3 }

A query that is just a list of keywords, e.g. for sindice or swoogle (or even google).

4. Implemented Plug-ins

Here is a list of (prototype) plug-ins that have been implemented as part of the activities to flesh out the API.

4.1. Identify

4.2. Transform

4.3. Select

4.4. Reason

4.5. Decide

5. History

This section will chronicle the continuing evolution of the LarKC API in terms of decisions taken during meetings and notes accompanying different prototype versions.

• 12.08.2008 - Frank and Annette created a detailed brainstorm of what behaviour the API must support.

• 19.08.2008 - The contents of an API was discussed in detail during the workshop in Ljubljiana.

• 22.08.2008 - A first draft of the API as agreed in Ljubljiana was published (initially to the WP5 mailing list).

• 09.09.2008 - Prototype v01 - Mick and Barry tested out the first draft of the API by creating simple plug-ins in order to run end-to-end tests.

• 08.10.2008 - Prototype v02 - Some experiments to explore various approaches to 'anytime' behaviour.

6. Next Steps

This section sets out a broad and highly volatile short-term plan for how to address missing functionality.

• Prototype v01 - ORDI/OWLIM data store component to be added in the next few days, after which development on this version will be stopped.

• ?Prototype v03 - Will start to incorporate quality of service parameters.

• ?Prototype v04 - Will address parallel/distributed execution of plug-ins.