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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25.
Administration mode<br />No restrictions on editing<br />Makes all topics visible<br />Be careful!<br />

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

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

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

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

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

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

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

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

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

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