What’s up with Ontopoly?

The Ontopia Topic Maps Editor, http://ontopia.wordpress.com/

2010-01-22Geir Ove Grønmo, grove@bouvet.no

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

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

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.

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

Today

• It is pretty clear that very few noticed– what Ontopoly can do today

• Many “Hiddenhancements”

It’s not perfect

• A few things are still missing• But the foundation is sound

So, here’s an in-depth review

• Next slides explains the new features

One instance editing component

• All editing done through same Wicket component– topic types and instances are equal– so is the topic map reifier topic

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

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

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

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

Embedded fields

• Possible to nest instance editors– arbitrary depth– context dependent (see previous slide)– locking of individual topics

• Not in n-ary association fields

Multiple topic types

• Only available in Administration mode– For a reason

• Editing is done separately by topic type– see “Topic types” function box

Configurable players

• Query that presents user with list of possible players– takes field and current topic as parameters

• Search interface control uses separate query

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

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

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

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?

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?

View modes

• Given a view, then display in one or more view modes:– Embedded– Hidden– Not traversable (no links)– Read-only

• Can select multiple

Value view

• Given current view, edit field in new view

• Maps a parent view to a child view

Ontology annotation

• Not really new, but useful to mention here

• Makes meta-ontology topics visible

Administration mode

• No restrictions on editing• Makes all topics visible

• Be careful!

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

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

Association transformation

• Used to repair association instances– when the role types change after the

associations where created

• Button displayed on association type page

Other stuff

• Tries to protect meta-ontology– unless in Adminstration mode

• Pluggable access strategy– to support authentication– and potentially authorization– not complete

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?

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

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

The future

• Display n-ary fields as tables• Tool tips with descriptions– on topic links and field labels

• Adhoc validation (with TMCL hopefully)

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

The future

• Bergen kommune went first• Features need funding• Who’s next?

• What would you like to see implemented?