Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

SetOfStatements showing up in Datalayer

2011-08-04
2013-06-13
  • At the moment we are coding our CityTripPlanner application for the LarKC challenge. We encountered some unexpected behavior of the datalayer.

    We created multiple plug-ins which have to communicate information about sets and plannings. In our application, this information should not be persistent in the datalayer, in order to be able to execute multiple queries, without reusing/inference of the same solutions.

    We tried to accomplish this through sending SetsOfStatements from one plugin to the other. We thought that we would thereby not add the data to the datalayer. However, when we send another query to the endpoint, the data appears to be added to the datalayer.

    So our question is, when SetOfStatements are used for communicating between plugins, should (and are) these triples  added to the LarKC datalayer?

    Extracts of the code we use:

    public SetOfStatements invokeInternal(SetOfStatements input) {
        try {
            loadOntology();
            loadPOIs();
            loadPreferences();
            loadParameters();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
        initDTR();
        runDTR();
    
        URI graphName = new URIImpl("DTRPointSelecter:result");
        return DataFactory.INSTANCE.createRdfGraph(result,graphName );
    }
    void writeTsetToOutput(Set<POI> Tset){
        URI setURI = new URIImpl("set:set"+ foundSets.size());
        URI containsURI = new URIImpl("set:contains");
        for(POI poi:Tset){
            URI poiURI = new URIImpl(poi.getURI().toString());
            Statement st = new StatementImpl(setURI, containsURI, poiURI);
            result.add(st);
        }
    }
    
     
  • Hi,

    In LarKC, data is typically passed through the data layer (to avoid memory problems). Namely, you should not be returning the graph itself from the plugin, but metadata about which labelled set of statements subsequent plugins should read. For an example of this look at the RDFReader plugin.

    You can avoid mixing up your data by using a different name (or even a randomly chosen name) every time, again, you can see the RDFReader for an example.

    -Spyros