[[PageOutline]] = Open Issues in Aperture = == RDFContainer based on RDF2GO == The casting of RDFCOntainer to sesame2 to read values is unaccapteable. We should definitely move to RDF2GO, and RDF2GO will be improved to fit us. Alternatively we use ONLY sesame2. == java.io.File-Based Exctractors == We have some code-pieces (like MP3 extraction) that do not work on inputstreams but only on files. There are different approaches to solve that: === ideaA: rewrite all File-Based extractors using inputstream === Somebody writes new Extractors implementing the InputStream-based extraction interface. * issue: these have to be written completly new? * idea: have somebody else write them. * pro: They are probably more performant than the existing ones and have less overhead * con: they have to be written new === ideaB: add a new method to Extractor === This is the existing Method: {{{extract(URI id, InputStream stream, Charset charset, String mimeType, RDFContainer result)}}} We could add a new one to the Interface Extractor: {{{extract(URI id, File file, Charset charset, String mimeType, RDFContainer result)}}} * pro: no new interface * issue: looking at the Interface, it is not clear what method to use and what is implemented. Should I call first the method with InputStream and see if it fails? hm * issue: this depends on ideaC === ideaB1: create a new Interface FileExtractor === Create a new Interface FileExtractor, that implements only one method. Declare that this interface should only be used in cases, when there is no InputStream-based extraction library available and say that this FileExtractor is mediocre to the normal Extractor. {{{extract(URI id, File file, Charset charset, String mimeType, RDFContainer result)}}} * pro: developers can determine which kind of Extractor they face and which method to call * con: we need a new registry for FileExtractors * issue: this depends on ideaC === ideaC: new method getFile() to FileDataObject === Add a new method getFile(), returning a file, to FileDataObject. This is easily implemented on File-based data objects (crawling local file system). For remote FileDataObjects, the method will be implemented using a buffering of the InputStream. ideaB and ideaB1 depend on this getFile() method. * pro: optimizes the implementation for file-system-crawler * issue: on some constellations (crawling remote MP3s), there will only be FileExtractors and everything will be buffered on local harddisk * idea: this is not so much an issue, the benefit for the end user of having more data outweights it == DataOpener.open(uri) == should throw a "NotFoundException" if the element does not exist. That is a fallback: if the element was moved, the calling gui that uses DataOpener could then search for the new location of the element and suggest a new location. The new URI could then work better. This blocks: * https://gnowsis.opendfki.de/repos/gnowsis/branches/gnowsis0.9/enquire2006/src/java/org/gnogno/enquire2006/api/impl/EditorApiImpl.java == Add rdfs:label to everything == see that every resource has an rdfs:label, additionally to dc:title, etc == Relate DataOpeners to DataSources == At the end, the dataopeners are tightly knit to datasources, not to URI-scheme. The method DataOpenerRegistry.get(String urischeme) is not good. As we have the uri scheme "gnowsis://" quite often for Outlook, Thunderbird, some other stuff. Still, opening by URI scheme is a good fallback when I have a resource at hand from which i know only URI (and not the originating datasource) so I would keep it as fallback. Idea: * Add a new method to DataSource - getDataOpener which returns an instance of DataOpener (or uses the DataOpenerRegistry internally, when not defining own DataOpeners). This blocks: * https://gnowsis.opendfki.de/repos/gnowsis/branches/gnowsis0.9/enquire2006/src/java/org/gnogno/enquire2006/api/impl/EditorApiImpl.java == use reusable web-guis to configure datasources == reusable crawlers, reusable registry both gnowsis, autofocus and possible aduna metadata server need guis to configure the datasources (restrictions, passwords, setting and enableing datasources). * we could say that datasource config is done using servlets - then it is easier to reuse * we could use the same crawler / registration classes in Nepomuk, Autofocus, and AMS(what is ApertureCrawler and ApertureDataSourceRegistry in gnowsis) == Vocabulary: use DC instead of data == 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. == build.xml == remove the "init" target, everything in there can be top-level. - simplifies the ant file. = old aperture pages = * ApertureArchitecture