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