Triple20: an RDF triple viewer and editor
Jan Wielemaker
Human-Computer Studies (HCS),
University of Amsterdam
The Netherlands
E-mail: wielemak@science.uva.nl
|
This document describes Triple20. Triple20 is a visualisation and
editing tool for data stored in the SWI-Prolog semweb triple
store. Triple20 has been designed not to limit the expressiveness of the
triple data model, to scale comfortably to several millions of triples
and deal with triples associated to multiple sources at the same time.
As the internal interfaces stabelise they will be fixated and documented, providing an extensible toolkit whose components can be reorganised to build dedicated semantic web tools. Based completely on XML/RDF and fairly crash-proof the system is usable as visualisation and editing tool. Both is internal interfaces and UI however are under active development and change frequently, which is why we only explain the basics in this document. |
Most ontology editors have their own view on the world that dictate both the internal data model and the UI. Such systems provide import and export filters to other formats. Triple20 on the contrary uses RDF/XML and the RDF formal triple data model directly, providing a range of visualization primitives that interpret the triple store at different level of abstraction ranging from access to the RDF/XML source via triple-tables and RDF diagrams to dedicated RDFS and OWL views. Using triples directly, these views can co-exist in the same application and the toolkit can easily handle anything that can be expressed in triples.
Modularity and scale are other important aspects of the semantic web. Triple20 keeps track of the source of each triple which enables it it view and edit several RDF documents in a unified view. It has been designed to view and edit models with several millions of triples on standard office equipment.
The interface is too unstable to document in any detail. This section only provides some hints to get you started.
Many edit operations require two arguments, making drag-and-drop an attractive interface technique. Drag and drop is associated with most objects on both the left- and right mouse button. While dragging, the system indicates the action taken in the status window. On left-drag it executes the indicated action. On right-drop it displays a menu with alternatives. Some actions
Note that File/New window creates a new view on the triple set that fully cooperates and synchronises with the other views. Drag and drop between multiple views is a suggested technique to deal with larger ontologies. Notable the user can exploit search in a small window to locate relevant resources.
If the text-field is coloured blue, this indicates there is at least one resource in the database that exactly matches the typed string.
Most objects have a context menu associated with the right mouse-button that act on the represented resource, possibly in relation to other resources on the same row (table) or related in the hierarchy. Sub-menus are described as Menu/SubMenu/...
rdf_db
library.
rdfs:subClassOf or a
subproperty thereof. Resources that become disconnected from the
hierarchy are deleted completely.
rdf:type, default associated file
and default namespace are the same as the super class.
rdfs.
?- go..
icon. Note that computing the OWL class extension
is very incomplete.
rdf:type
triple belongs.
rdfs:label triple to each non-anonymous resource
that has no defined label. The default label is the local name of the
resource.
The top-right window allows searching resources with certain literal properties. The Search in menu specifies the properties searched. Two entries have special meaning.
The search-field itself allows for the syntax ns:string, where ns is a namespace abbreviation. This causes the search to be executed in the given namespace only.
The hierarchy is collapsed and the first 100 matches of the search are added to the hierarchy. Using shift-click, collapsing of the hierarchy is skipped and the hits are added to the current view. This makes it easy to add resources to the hierarchy, preparing drop operations. Similar results can be realised by creating a new window using File/New window.
Using the View/Label menu the system
can identify resources in three ways. Label only only displays
the label. The label is either the first value for the rdfs:label
property, a subproperty thereof or the last part of the resource name. Namespace
and label displays the namespace identifier (see section
5.2) before the label. This is the default. Resource
displays the namespace identifiers in front of the local resource name.
In most situations the label is preceded by a small icon. The icons depend on the classification of the resource. In the hierarchy view, labels may have two icons. In this case the first icon represents the relation to the parent and the second represents the type classification.
Triple20 provides unlimited undo and redo using toolbar buttons. Note however that some operations, notably file merge
Triple20 uses the Model-View-Controller design. Edit operations only modify the triple database. The GUI monitors the changes to the triple database and updates the display. Unfortunately the view has a very indirect relation to the triples. Generally labels register themselves to be updated whenever a property of the represented resource is changed, added or deleted. Complicates relations such as expressed in the hierarchy and table use a registered query which is re-evaluated on every change in the background. If the result changes the background thread triggers the UI to update.
This deals with most changes, but sometimes the system will miss the proper update. When in doubt collapse and re-expand the hierarchy and/or switch the table to another resource and back to force proper update. Please report inconsistencies you think can be avoided.
There is very limited support to print graphical representations. The main tool has a Print hierarchy menu, which prints the current expansion of the left hierarchy window on a single sheet of paper. The RDF graph viewer, started with View diagram also provides a print option.
Note that not only the visible part of the window, but also the invisible parts are printed. The result is scaled down to fit a single page.
A very common modeling practice is to use classes as property values. For example, people are tempted to describe the colour of an object as red by selecting the class red from a colour ontology. A commonly seen mistake is to define a property colour with its range set to the root of the colour hierarchy of the domain ontology. This construct however allows for individuals of colours to be placed in the property, not subclasses. The W3C best practices group's current position on this issue is to fill the property with an anonymous individual of the class, in our case an anonymous individual of class red. At first this may appear odd, but think about it. The colour of an object is not `red', but some unspecified form of this colour! Representation as an anonymous individual is a clean solution to express this.
Triple20 supports this practice by creating an anonymous individual
whenever one tries to define a property where the value is a subclass of
the range of the property. Such objects are identified with the
icon.
The current version of Triple20 does not know much about OWL. It supports OWL at the following places:
owl:Restriction can be accessed in
the hierarchy below the class node. Restriction that have an anonymous
resource have a dedicated label that clearly visualizes its contents. If OWL/Class extension
is active (default) it shows the resources that satisfy the restriction
prefixed by the
icon.
rdfs:subClassOf, the
reverse of owl:intersectionOf.
icon. To suppress this feature, switch the dialect to RDFS.
OWL reasoning uses a subset of OWL/Full, inferring properties that
can be inferred fairly quickly. Supported reasoning includes:
owl:sameAs and the property attributes owl:inverseOf,
owl:SymmetricProperty and owl:TransitiveProperty.
It also derives the value of a property if one of the types of a
resource defines owl:hasValue.
Triple20 deduces the class extensions of restrictions and descriptions. If property values are to be considered it uses the above described features to infer property values.
Triples in rdf_db are actually quadruples. The last part registers the origin of the triple, so the tool can load ontologies from multiple files, present the joined view and still save the modified triples to a specific file. As Triple20 provides an integrated view and editing capabilities on all triples loaded from all sources it requires some machinery and defaults to define the source assigned to newly created triples. The File/Statistics menu gives access to an overview of the loaded files and allows to inspect and edit properties thereof. Defined properties are:
ro if they are loaded as a base ontology
or they are loaded from a read-only file.
all, new triples are added
to the same source as already existing triples on the same subject. New
subjects are ---by default--- added to the same source as their context,
but this may be overruled by the user.
fallback or all
property. Enabling fallback or all enables rw.
The menu File/Merge files allow the user to move all triples associated to some file to another file. This can be used to merge ontologies. The File/Save file submenu allow for saving modified files. The View/Show roots of/... submenu can be used to show the roots of classes and properties defined on a file.
Triple20 has an internal table of well-known namespaces and their
common abbreviation. This table is in the file rdf_base.pl.
If possible it will use the abbreviated form in the UI. Namespaces can
be added through the File/Names paces
menu option. Registered namespaces are stored in the project file.
A project file .rdfj is a journal of
executed edit operations. This approach has several advantages over the
normal load-modify-save cycle.
There are various alternatives for handling the loading of ontology files in the journal. One is to simply add the fact that a file is loaded. This can be attractive because the journal acts as a set of edit operations that can be executed on a modified version of the same file. Unfortunately it also easily leads to problems if the file is saved from the tool. For this reason Triple20 maintains a snapshot directory where it stores snapshots of ontology files loaded into projects. The name for these files is created from the original file as well as an MD5 digest constructed from the triples. The journal contains information on the original file (name, time modified, size, number of triples) as well as the MD5 digest. If the journal is replayed it will first try to locate the snapshot from the MD5 digest and name, loading exactly the same file. If this fails Triple20 tries to locate the ontology file itself.
Triple20 can be used in two modes: as a stand-alone applicationn and
as a Prolog library. Section 7 discusses
installation as a stand-alone executable. This section discusses the
steps to use Triple20 as a GUI in another Prolog program. This usage
aims at non-GUI RDF applications based on the library(rdf_db.pl)
library that wish to have a GUI for exploring the triple-set. Note that
it is possible to load and Triple20 only in a debugging version.
Triple20 uses the file-search path triple20 for locating
its components. Add the following to your project load-file, adjusting
the path to reflect local installation:
:- multifile
user:file_search_path/2.
:- dynamic
user:file_search_path/2.
user:file_search_path(triple20, '/staff/jan/src/Triple20/src').
|
Now, Triple20 can be loaded using the directive
:- use_module(triple20(load)). |
Triple20 provides the following predicates:
triple20([]), starting the default Triple20
GUI.
library(rdf_edit.pl) library.
Applications using library(rdf_db.pl) directly should
inform Triple20 that the database has changes, forcing Triple20 to flush
its caches.
table
or hierarchy.
The current snapshot of the Triple20 toolkit can be downloaded from SWI-Prolog CVS server. As the system is under active development, the HEAD revision is often unstable. We use the symbolic (sticky) tag STABLE to reflect the latest usable version. The CVS download commands are:
% cvs -d :pserver:pl@gollem.science.uva.nl:/usr/local/cvspl login Logging in to :pserver:pl@gollem.science.uva.nl:2401/usr/local/cvspl CVS password: prolog % cvs -z 9 -d :pserver:pl@gollem.science.uva.nl:/usr/local/cvspl co -r STABLE Triple20 |
This command both downloads the software and the basic ontologies. Alternatively you may checkout the CVS module Triple20-Full, which also download RDF versions of WordNet, OpenCyc and SUMO (total ± 47 Mb).
After installing Prolog, double click setup.bat to
register
.RDFJ project files to start Triple20. Optionally also
associate .RDF, .RDFS and .OWL to
lauch Triple20 and load the file.
To make Triple20 accessible from the Windows desktop, create a
shortcut from the desktop to src/triple20.pl or
write a .BAT file by adjusting the template given below.
@echo off "C:\Program Files\pl\bin\plwin.exe" "C:\Program Files\Triple20\src\triple20.pl" |
Edit triple20.pl, adjust #! path to point
to the SWI-Prolog executable and file_search_path/2
with an absolute path to the directory where you installed the sources.
Now copy (or make a symbolic link) triple20.pl to a directory in your $PATH
environment variable as triple20.
After this you can run triple20 option ... file ....
Using
triple20 --help for a list of commandline options.
Although the current system is in active use for browsing ontologies for some time and the first users start to edit ontologies with it, it should first of all be regarded as a prototype. Some remaining issues are:
The small type-icons are partly copied from and partly inspired by the Protégé project.