Changes between Version 22 and Version 23 of ApertureDiscussion


Ignore:
Timestamp:
11/21/06 10:15:41 (17 years ago)
Author:
sauermann
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ApertureDiscussion

    v22 v23  
    22= Open Issues in Aperture = 
    33 
    4 most of these features would be fine if fixed before ISWC2006, 5th November 2006. 
     4see also ApertureClosedIssues for a list of things that have been completed. 
    55 
    66== CrawlerHandler vs. RDFContainerFactory == 
     
    1212data in the source code. If have a Repository in the CrawlerHandler and generate RDFContainers backed by this repository, it might be non-obvious where does the data in the repository 
    1313actually comes from. 
    14  
    15 == RDFContainer based on RDF2GO == 
    16  
    17 The casting of RDFCOntainer to sesame2 to read values is unaccapteable. 
    18  
    19 We should definitely move to RDF2GO, and RDF2GO will be improved to fit us. Alternatively we use ONLY sesame2. 
    20  
    21 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. 
    22  
    23 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. 
    24  
    25 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. 
    26  
    27 On the long run, to have a generic API, using RDF2GO as interface and something like sesame2 as default implementation is better.  
    28  
    29 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. 
    30  
    31 ''' Discussion ''' 
    32 pros: 
    33  
    34  * bindings for various RDF stores that we get for free 
    35  
    36 cons: 
    37  
    38  * is RDF2GO still using java.net.URIs? That would mean a lot of  
    39 conversions that are potentially not necessary, e.g. when using a Sesame  
    40 Repository: org.openrdf.model.URIs get translated to java.net.URIs and  
    41 back to org.openrdf.model.URIs. 
    42  
    43  * RDFContainer lacks full RDF graph access. A simple getStatements  
    44 method with a subject parameter would solve this though. I've also read  
    45 comments by Gunnar about having to cast RDFContainer to  
    46 SesameRDFContainer in code he wrote, I guess he had the same problem? 
    47  
    48 Gunnar and Leo are happy with this: 
    49  * We keep RDFContainer as it is and only switch "getModel()" to return a RDF2GO model. 
    50  * We switch the methods of RDFContainer to use RDF2GO interfaces (RDF2Go's predicate, resource, etc) for the setProperty(property, value) methods. 
    5114 
    5215== java.io.File-Based Exctractors ==