Changes between Version 11 and Version 12 of ApertureDiscussion
- Timestamp:
- 07/24/06 11:46:28 (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ApertureDiscussion
v11 v12 7 7 8 8 We should definitely move to RDF2GO, and RDF2GO will be improved to fit us. Alternatively we use ONLY sesame2. 9 10 A 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 12 If 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 14 Also, 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 16 On the long run, to have a generic API, using RDF2GO as interface and something like sesame2 as default implementation is better. 17 18 The 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. 9 19 10 20 == java.io.File-Based Exctractors == … … 83 93 We 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. 84 94 95 Heinz 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 97 Note 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 85 99 == build.xml == 86 100 remove the "init" target, everything in there can be top-level.
