Frontend (Javascript)


A perspective is a concrete widget/view layout just as known from Eclipse.

Technically, a perspective is a tree composed of:

  • Tab
  • Split
  • Border: large center, small east, west, south, north
  • View

...with views being the leaves of the tree.

Example code to create a perspective:

var perspective = new Split("vertical", [
    new View("${jrsrc}/de/hypergraphs/hyena/web/NodeList.html"),
    new View("${jrsrc}/de/hypergraphs/hyena/web/DisplayerStack.html")

View API

View (HTML page with embedded JavaScript): The deployer configures a perspective (see above) which specifies which view are visible and how they are arranged. The frontend manages the view and during its lifecycle invokes the following JavaScript functions:

  • openView(frontendModel)
    • Description of parameters and actions missing
  • updateView(frontendModel, event): Whenever the frontendModel changes, the frontend invokes this function for all active views.
  • closeView


FIXME: What are the client-side data structures

  • node selection: store information related to selected RDF nodes
    • selected nodes
    • active displayers
  • node filter: filter the node list by type etc.
  • container path
  • RDF access (read subgraphs, write subgraph)

Standard Views

  • DisplayView: reacts to selection changes, offers displayers (which adhere to the standard view API).

Backend (Java)

API Layers

DWR layer:

  • Receives requests from JavaScript frontend
  • Handles authentication (which is a web-only feature)
  • Needs to synchronize (per container) before it can access the (mostly single-threaded) core.
  • Example class: de.hypergraphs.hyena.web.Main

Core layer:


Standard subgraphs (see

  • Main: Default subgraph, for all triples that have not been explicitly put anywhere.
  • Namespace meta-data [FILE]: RDF/XML namespaces reified as RDF nodes.
  • Settings: Subgraph for persistent settings [FILE: only saved if a marker triple is present]
  • User subgraphs: created by the user, similar to Main, but they have a name.
  • Vodule subgraphs: read-only, added on-demand by vodules.

Subgraph features:

  • Saved [FILE]: Is the data persisted somewhere?
    • inband (default: inside the saved RDF data)
    • outband (Namespaces: external to the saved RDF data, in the meta-data)
    • never (vodule subgraphs: these are read-only and provided by the vodule)
  • Removable: Can the subgraph be deleted?
    • by user (all user-created subgraphs)
    • by program (vodule subgraphs)
    • never (Main)
  • Writable (vodule subgraphs are read-only)

File Persistence

File-only features:

  • Conditional saving of settings
  • Reify namespaces as a subgraph
  • Listen if data has become "dirty"


Client (Unique per User)

  • dataSpec: How should the RDF data be accessed
    • containerPath: A pointer into the container hierarchy
    • subgraphAccess
      • readSubgraphIds: What subgraphs are currently visible (switched on by the user); this is a filter mechanism.
      • writeSubgraphId: What subgraph is written to.
  • node selection:
    • nodeRows: plain RDF nodes annotated with their types and tags.
    • selectionContext: custom object, "sent" with selection
    • allDisplayChoices
    • currentDisplayChoice
  • nodeRowFilter: Composite filter. Example filter elements: filter by type node, filter by text string in literals etc.

Server (Shared Settings)

  • Bookmarks
  • Node aliases (use as a reference instead of a URI)
  • Active vodules
  • Namespaces (encoded as RDF nodes)
  • Tags


  • Persistence of settings:
    • Continually: store new settings -> reparse
    • Serialized: keep only in RAM, serialize on demand (when?)


All of these components live inside a container and each one provides one specific editing service.


  • RDFRepository: Manages all subgraphs, registry for ReloadContributionEvent listeners.
  • ClientGraph: Main RDF API
  • TextPresentationComponent: Parsed RDF-encoded namespace definitions and uses them to display URIs as qnames.
  • WrappedNodeComponent: Simple API for RDF-OO-mapping (comparable to \textit{Elmo} from the Sesame RDF database).
  • SettingsComponent: Quick access to wrapped nodes in the settings subgraph, maybe merge with WrappedNodeComponent

User interface

  • ContextComponent: Manages a tree of context information about the currently selected node(s): applicable functions, in-links etc.
  • FilterComponent: Manages a pipeline of filters and produces a set of nodes that match all filters in this pipeline. Pipeline elements are usually added by the user and specify criteria such as the class of a node.
  • VoduleActivatorComponent: Switch vodules on/off.
  • MetaEditComponent: Manages lenses and class information


  • WikkedInterpreter
  • DatatypeComponent: Register bi-directional converters between text strings and Java objects. Used for scripting inside \hyena.
  • FunctionComponent: Register functionality that is available for the GUI and/or Wikked.


  • WebPagesComponent: old-style display of web pages
  • ConfigurationComponent: old-style display of config information
  • ShelfComponent: supplanted by bookmarks and filtering by class
  • MetaEditingComponent: Supplanted by MetaEditComponent
  • TripleSelectionComponent: Not yet sure, what to do with it.


  • WholeGraph, PartialGraph: Maybe replace completely with ClientGraph
  • RemoteEditingComponent: Defines atomic editing primitives for collaboratively editing data structures such as trees.
  • EditorComponent: Implement an Eclipse editor
  • NodeDisplayComponent: Manage Eclipse displayers
  • SelectionComponent: Manage the currently selected nodes


  • [Web displayers?]

Common API

General Mechanisms

Data Parsing

  • Reload events whose listeners reparse configuration RDF data. Examples:
    • Namespace definitions
    • Lenses

Synchronization/Access Control

Synchronize on container during access:

        // check if request is authorized to read from the subgraphs specified in dataSpec
        AccessToken token = AccessToken.openRead(request, dataSpec);
        try {
            return token.get(DisplayerComponent.class).getNodeChoices(nodeDescs);
        } finally {        


  • Core (always a parameter: named graphs to read from, named graph to write to; null (object) for reading everything, don't write)
    • listTriples(namedGraphs, subj, pred, obj): any argument can be null as a wildcard
    • addTriples(namedGraphs, triples)
    • removeTriples(namedGraphs, subj, pred, obj)
    • performQuery(namedGraphs, queryStr)


  • getShortName(uri): type-specific (often: rdfs:label), human readable, not unique, not too long
  • setShortName(uri, str)
  • getSummary(uri): type-specific, human readable, not unique, possibly several lines, give a quick idea what a resource is about. HTML!
  • getQName(uri): generate a unique string that is as short as possible
  • getLargeIcon(uri) -> URL
  • getSmallIcon(uri) -> URL
  • parseQName(str)


  • Default lens shows: uri, types, [tags]
  • Filter:
    • by class, by literal content etc.
    • constrain by property

Open Issues

  • How to hide unimportant (inner) resources?
    • list element nodes
    • "owned" resources: dates, address
  • Unify node list and projection/lens list


Last modified 16 years ago Last modified on 08/11/06 17:37:47