Frontend (Javascript)

Perspectives

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

FrontendModel

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:

• Manages the RDF data, does most of the server model management work
• Example class: ClientGraph
• Further information: ​http://www.pst.ifi.lmu.de/~rauschma/cgi-bin/wiki/wiki.cgi?HyenaArchitecture

Subgraphs

Standard subgraphs (see RDFRepository.java):

• 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"

Settings

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

Issues:

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

Components

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

RDF

• 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

Scripting:

• 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.

Legacy:

• 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.

Eclipse-Only

• 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-Only

• [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 {        
            token.close();
        }

RepositoryInterface

• 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)

!IRdfResourceNaming

• 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)

ResourceListInterface

• 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

---

BackLinks(BudvaArchitecture)?