• Setting up your local environment
  • Add the following to the appropriate connector in your tomcat's server.xml: URIEncoding="UTF-8"
  • Ensure that the Environment Variable "sf_ontologydir" is set and pointing to /path/to/project/ontology/ (in Eclipse: Run Configurations->Your Tomcat->Environment)
  • If you want to see other user's data in your local installation, change line 51 in EditDatabase.java to "Model myModel = factsDb.model;"
• Threading model
  • There is just one big lock per user (the user's FactsDatabase instance); it's acquired immediately in de.opendfki.skipforward.ui.web servlets.
  • If you create a background thread or something similar, make sure you get the lock
• MVC
  • de.opendfki.skipforward.ui.web servlets call de.opendfki.skipforward.ui class methods; these build views (using custom beans, typically), build HTML using StringTemplate, and return the HTML
  • there are some MVC helper beans (not to be confused with the RDF beans) in de.opendfki.skipforward.ui.beans
  • bean renderers can be found in de.opendfki.skipforward.ui.st
    • these renderers are used for basic types or if Java code is needed for generating the HTML - otherwise, normal templates are used.
• RDF Beans
  • interfaces are in de.opendfki.skipforward.vocabulary
  • beans provide some convenience methods (e.g., getLabel(), etc.)
  • beans instances are built using FactsDatabase methods
  • beans are throwaway objects and do not have any internal state - every change using their setters is immediately persisted in RDF
  • beans are associated with their corresponding FactsDatabase so you cannot pass one bean instance to another user
• non-binary features
  • nb features are feature types such as "Name" or "Written by" - the full type is defined by the value(s) a feature instance uses then
    • keep in mind nb features may take multiple values per feature instance (e.g., "board game players: min X, max Y")
  • non-binary features are somewhat nasty to handle since their (rather generic) feature type isn't very helpful ("Name") - you need a feature instance to know the full type ("Name: Miller")
  • when comparing feature types for equality, you should use feature123.getFeatureTypeId() instead of feature123.getFeatureType().getUri() - the ID is the feature type URI plus added values ("Miller" in the example above)
  • same for getting labels: feature123.getFeatureType().getLabel() is not very helpful (again, "Name") - use feature123.getFeatureTypeLabel() instead.
  • thus, writing code that uses something like Map<FeatureType, ...> is most likely a mistake.