Changes between Version 11 and Version 12 of ApertureDiscussion


Ignore:
Timestamp:
07/24/06 11:46:28 (18 years ago)
Author:
sauermann
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ApertureDiscussion

    v11 v12  
    77 
    88We should definitely move to RDF2GO, and RDF2GO will be improved to fit us. Alternatively we use ONLY sesame2. 
     9 
     10A problem that Heinz Kirchmann found when programming catwiesel.opendfki.de was that the downcast from RDFContainer to SesameRdfContainer was not obvious. The crawlerhandler in Gnowsis is seperated from the actual processing of the data. We used RDFContainer as interface inside gnowsis, in many methods. We should have used SesameRDFContainer everywhere inside gnowsis. 
     11 
     12If sesame is the right framework for gnowsis, the passing SesameRDFContainer would have been right. But if we remove sesame and use kowari or something else, the usage of RDF2GO may be better. 
     13 
     14Also, we never used a RDFContainer besides Sesame2. So it may be the obvious choice to cast everything and define everything as SesameRdfContainer BUT this will cause troubles for projects that are based on Sesame1. If somebody that is based on Sesame1 wants to use Aperture, then using OpenRDF may be good. 
     15 
     16On the long run, to have a generic API, using RDF2GO as interface and something like sesame2 as default implementation is better.  
     17 
     18The RDFContainer interface did not include all methods that we needed at the end, only SesameRDFContainer did implement the needed methods to read data. So the Interface must be extended to implement all methods needed. 
    919 
    1020== java.io.File-Based Exctractors == 
     
    8393We are using many properties of Dublic Core, but redefining them. For compabilities sake, we should inlcude the real DC vocabularies right from the start, and not use our own uris. 
    8494 
     95Heinz Kirchmann had the trouble that our DATA vocabulary was not Dublin core, and in his project he had to write a converter. Although the converter is easy to write, using Dublin Core in the first place would have been better. 
     96 
     97Note that Leo designed the Data ontology very bad and used own properties only because the f*** generation code from Schemagen(Jena) only supports one namespace at a time. We can circumvent that now by using better tools or by other tricks. So the generation of one JAVA file named DATA with all properties in it, the propeties are then a mixture from DC and others, would be possible. 
     98 
    8599== build.xml == 
    86100remove the "init" target, everything in there can be top-level.