A presentation that explains the new [hidden] enhancements made to Ontopoly, the Ontopia Topic Maps Editor, in release 5.0.

1. What’s up with Ontopoly? The Ontopia Topic Maps Editor, http://ontopia.wordpress.com/ 2010-01-22 Geir Ove Grønmo, grove@bouvet.no

2. What happened? A lot happened between 4.1 and 5.0/5.1 It became extremely flexible Customizable UI Embeddable Extensible Self descriptive All declarations made as topics, occurrences and associations

3. Customizable and embeddable Specific customer requirements meant that the editor had to become flexible needed a generic menu editor One can do quite a lot to customize the UI Stripped down instance editor can easily embedded uses AJAX, so no form request parameter collisions

4. Extensible Whole application built as a jar-file all resources loaded through the class loader standard Apache Wicket setup in web.xml Sub-class OntopolyApplication to customize possible now, but needs some refactoring to make it even easier to customize.

5. Why did it happen? Most of these things happened because of a particular customer that deserves credit: Bergen Kommune https://www.bergen.kommune.no/ had a lot of interesting real-world requirements and had the patience to turn them into generic Ontopoly features

6. Today It is pretty clear that very few noticed what Ontopoly can do today Many “Hiddenhancements”

7. It’s not perfect A few things are still missing But the foundation is sound

8. So, here’s an in-depth review Next slides explains the new features

9. One instance editing component All editing done through same Wicket component topic types and instances are equal so is the topic map reifier topic

10. What is a “field”? New behaviour: replaced type annotation with pattern matching agains field declarations A field is a pattern matching a subset of a topic’s characteristics matches a subset of the topic’s characteristics matching primarily by type role type, association type and other role types in the case of role fields datatype and scope when we get that far

11. Fields are first-class citizens Field definition types identity field name field occurrence field role field (and association field) Field definitions are now topics to make it easier to say things about them and make their declarations more explicit To make it possible to describe fields properly field definitions had to be come first-class avoids reification (of associations) pattern matching the stuff in “Advanced view” illustrates this

12. Shortcuts (to fields) To allow faster access to all aspects of the model not all links are enabled by default because they are confusing when you don’t need them enable shortcuts on the Description page

13. Field views Assigned to a subset of available fields Configurable per view: view mode value view Behavior can be context dependent Value view: if parent view is X then field view is Y View mode: if view is X then Embedded, Hidden, Not traversable or Read-only

14. Embedded fields Possible to nest instance editors arbitrary depth context dependent (see previous slide) locking of individual topics Not in n-ary association fields

15. Multiple topic types Only available in Administration mode For a reason Editing is done separately by topic type see “Topic types” function box

16. Configurable players Query that presents user with list of possible players takes field and current topic as parameters Search interface control uses separate query

17. Configurable player types Query that presents user with a list of possible topic types to create and instance of displayed in * drop-down if multiple

18. Configurable hierarchies Instance lists can be rendered as trees Default is to use Techquila PSIs Query can override default should return two columns: parent, child returns all parent child combination must order by parent then child enough to build and render a tree

19. Sortable field values Fields can be made sortable a check box in the advanced view stores sort key as occurrence on topic and scoped by field topic Use drag and drop to alter field value ordering

20. Edit modes What players can be assigned to a field: Existing values only New values only No edit Normal Owned values (cascading deletes) TODO: should be context dependent?

21. Create actions When creating a new topic, what should happen? Edit new topic in popup window Go to new topic None TODO: should be context dependent?

22. View modes Given a view, then display in one or more view modes: Embedded Hidden Not traversable (no links) Read-only Can select multiple

23. Value view Given current view, edit field in new view Maps a parent view to a child view

24. Ontology annotation Not really new, but useful to mention here Makes meta-ontology topics visible

25. Administration mode No restrictions on editing Makes all topics visible Be careful!

26. Improved locking Lock leasing Shorter lock periods (4 min default) Renewed every 3 min using ajax timers only when page is open Prevents object from being locked when no longer being edited Locking enforced on nested embedded instances

27. New fields editor On topic type page Drag and drop field ordering and field value ordering in sortable fields Can do the same using the instance editor but not that user-friendly

28. Association transformation Used to repair association instances when the role types change after the associations where created Button displayed on association type page

29. Other stuff Tries to protect meta-ontology unless in Adminstration mode Pluggable access strategy to support authentication and potentially authorization not complete

30. The future Plug-ins event listeners tabs interface controls triggers query for matching update for modification customizability drop the ontopoly.jar in and extend Could use jar manifests for discovery Represented as topics in the topic map?

31. The future Query fields Query tabs/menu tab or meny that displays the result of a query Batch editing by selecting the rows in the queries results Merging topics Duplicate suppression Reification Scope

32. The future Interface controls should be more prominent not only on association fields but also on names and occurrences Support identity patterns like prefixes in tolog same feature could also be used with names and occs Default values on occurrences and roles Improve CSS to make it easier to customize tableless design

33. The future Display n-ary fields as tables Tool tips with descriptions on topic links and field labels Adhoc validation (with TMCL hopefully)

34. The future REST interface that exposes JSON CRUD operations would turn Ontopoly into a document database Makes it easy to do custom editors in JavaScript External occurrences accessed through REST (e.g. CMIS) get external content and render as field value

35. The future Bergen kommune went first Features need funding Who’s next? What would you like to see implemented?