Open Issues in Aperture: = 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. = Related 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). = 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