Blog for work on my Masters thesis - a survey of methods for evaluating media understanding, object detection, and pattern matching algorithms. Mostly, it is related to ViPER, the Video Performance Evaluation Resource. If you find a good reference, or would like to comment, e-mail viper at cfar.umd.edu.
Archives
Media Processing Evaluation Weblog
Wednesday, May 28, 2003
AppLoader Schema Updated
I've uploaded rdf+xml files to the site, and they now validate as plain rdf. I haven't checked to make sure they are valid as rdf schema, though.
Link, Link, Link
- posted by David @ 7:19 PM
Tuesday, May 27, 2003
Preliminary Outline of an AppLoader Spec
AppLoader works by first loading a 'system RDF' file. This is currently stored in n3, but I'll probably allow it to be stored in the ugly RDF/XML format as well. I'm still not sure how to bootstrap the location of the file. The loader currently uses the lal.prefs
system property, but this doesn't seem tenable in the long run.
The system properties are simply the set of triples loaded first. The PrefsManager (really a wrapper for a Jena2 triple store) has two callbacks registered from its start: the property trigger callback and the user directory callback. This means that whenever a triple with the predicate invokes for triggers or userDirectory for user prefs is added or deleted, these call back listeners are notified. Added triggers are executed if they refer to an existing java properties, and changing the user directory causes the user preferences to be loaded. It should be noted that deleting triggers does not cause the triggers to be 'uninvoked', and that deleting the user directory, while it does remove the user triples, does not undo anything loading the user triples did.
After the triples have been loaded, and the callbacks invoked, the loader then constructs the system. This includes setting up any java beans that are described in the triple store and laying out the menus. The menu system is described on the Menu Schema page. The menus are simple, and leaves can invoke beans that implement the menu listener interface or ask for listeners from existing beans.
The beans are described with a DAG, or partial order; they are initialized in a topological order according to their requires links. (Beans have two phases, construction and initialization. Basically the only requirements for a javabean are they are serializable and they have a zero-argument constructor. And I'm not currently using the serializable aspect, although that may be added later.)
Some things that I may add later: loading beans from jar files, better handling of removing triples (including adding onRemove handlers to menu items and triggers), some system of java:// urls that allows simplification of the n3 (this would have multiple benefits, but it seems to be in violation of principles of URIs), and a system to handle keystroke preferences.
There are some ideas that I'm not going to have time to do, or are not necessary for the project. One is a script that extracts a WebStart .jnlp file from the System preferences. Another is allowing loading over the network. This would involve trust, something that is difficult to have. I think just signing the rdf files might be enough, using something like foaf whitelist trust metrics. Finally, a graphical editor is not going to be added, as it isn't that interesting to me, and would be a lot of work. (I might make one for the keystrokes, though.)
- posted by David @ 4:29 PM
Thursday, May 22, 2003
Keep in mind: The developer who uses an API is a user.
- posted by David @ 9:13 PM
Requirements for the Loader
So I'm trying to put together a set of requirements for the application launcher. I want something that works well as a generic application holder (see eclipse or netbeans), that doesn't require much installation (see Java WebStart or the Zero Install system), and is pretty easy to edit without resorting to code (see Glade, but I don't have plans to write anything graphical). With all those open and open source projects to choose from, something should fit my requirements already. Perhaps mozilla, with its cool xpi install system, but that misses out on Java.
- posted by David @ 5:27 PM
Friday, May 09, 2003
More AppLoader Progress
Alright. Now I've rewritten it using Jena2, and started adding the necessary event handling for things like window and mru menus. I still haven't written the necessary rdfs for the application-loading stuff, but I'm reaching a point of stability where I'll go back through. I'm pretty good at keeping valid schema in my head, but this is big enough that I'm sure writing it out will show some flaws, and opportunities for enhancements.
Of course, if I were really good, I'd have written it first.
Link Link
- posted by David @ 2:32 PM
Thursday, May 01, 2003
LAMP AppLoader Progress
Okay, so the application loader is loading up beans, can take command line arguments, and can handle the menuing. However, it needs an event model, so I can add a 'recently used' file list, and allow for user-loaded stuff. Again, I'll probably have to modify Jena. Also, it is designed for internationalization, but Jena1 doesn't support the "@lang" syntax in N3. So I think maybe I'll start using the CVS version of Jena2, with some of my own modifications.