• 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 add a new servlet, create a background thread, or something similar, make sure you get the lock.
• Authentication
  • An HTTP cookie is given to the user after authentication. The user's session is fetched using the magic contained in that cookie.
  • For RSS, a hash (based on the user's password) contained in the URL is used to get the user session. That hash should not be used anywhere else.
• 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
• skipinions:FeatureType
  • be aware that a Feature Type may have multiple supertypes. Also, while there should be no loops in the hierarchy, algorithms traversing the hierarchy should not get stuck if loops are present (due to bugs or something).
• 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.
• skipinions:Items
  • each user has a copy of all items he has commented on in his namespace, even if the Item he commented on was initially created by someone else.
  • copied Items are linked to each other using owl:sameAs.
  • Item.getFeatures...() does NOT take owl:sameAs links into consideration; FactsDb.getFeaturesForItem() DOES.
  • be aware there are no persistent 'canonical' item URIs for any given item (as all item copies are equivalent) - for use in algorithms you can get canonical URIs that are valid at the moment though.
• Web frontend
  • paths should be absolute (but if possible without host): src="/skipforward/...". Completely relative paths do not work, see item permalinks.