.. http://iswc2005.semanticweb.org/ April 30, 2005 Research Track paper submissions due Title: Topics: (select applicable) user interfaces? Keywords: Abstract: ============================== An architecture for RDF editor ============================== Introduction ============ The Fenfire project has been working on an item-based information management environment for XXX years, first as an implementation of Ted Nelson's ZigZag and later based on the W3C standards for the Semantic Web. The environment has not reached a useful state yet, largely because of the unconventional software requirements of such a system, but along the Semantic Web standards a subgoal of an RDF editor has emerged. To bring closer our gap to the Semantic Web community, we would like to report on our research to the extent it concerns an architecture for RDF editor. A general, efficient RDF editor could help bring the Semantic Web data closer to both users and implementers. - motivation - previous concepts Previous work ============= SemNet has focus+context view. BrownSauce has a navigational view for RDF. Haystack has views for properties. Gnowsis is building a Semantic Desktop. General architecture ==================== As a set of RDF triples is conventionally imaged as a graph of labelled nodes, we want the editor to let the user browse this graph, make updates to it and create new triples. However, as the amount of triples can be high, RDF is a very general model, and the level of information can be too low for the user, such a user interface is not straight-forward. We propose the use of various *views* to represent the graph model to the user, in connection with several *controllers* that allow the user to make changes to the underlying model in ways that reflect the view the user sees. This is not unlike the widely used Model-View-Controller separation of user interfaces but we use the RDF graph as the sole model, instead of several, application specific ones. Architecturally important is that the view the user sees and the controller to it are actually built from several views that separate concerns and permit combination of the views to match different kinds of user need. Larger views for RDF constructs are built from smaller views of RDF primitives. The views actually interface with other views through view type interfaces, so we can have several implementations for each type. Representation views -------------------- The smallest view in the architecture under discussion is a *representation view*. These views are able to give a graphical representation of a node that can then be used as a part of a view that shows some larger construct in the graph. The most elementary instance of a representation view in our implementation is called TextReprView. It gives a textual representation, most simply the URI of the node in question. We also keep a list of *text properties* and if there is a literal value on any of these properties, we use one of those instead of the URI. To benefit from language information associated with literals, we prefer a literal that matches the user's locale to those that don't have language information or even have another language declared. If the node in question is a literal itself, we indicate that by putting the literal value in quotes, ie. "This is not John, this is the word 'John'." Another example of a representation view would be one that in addition to the textual representation view shows any ``foaf:nick`` property of the node in parentheses. The applicability of this is highly specific to the task of viewing FOAF information about people who the user might better know by nickname than by full name. However, the choice of the additional property could be user-configurable thus making the view applicable for any parenthetical information. Our implementation also contains a graphical representation view for areas of PDF documents. It works by interpreting properties in a vocabulary for decribing such areas and displaying the associated image data. Property views -------------- The next smallest views after the representation views are the *property views*. These views give a user-interface element for the triples of a given node that have the same property as their predicate. Our implementation of a general property view employs four columns to communicate the property, its direction and its value to the user. The first column gives the inverse property, the second column gives the value of the inverse property, the third column gives the positive property and the fourth column gives the value of the positive property. If either the inverse or positive property doesn't have a value, the respective columns are left empty. This arrangement can be argued to be wasteful, but we hope to provide the user with a feeling of spatiality and navigational directions. If there is more than one value on the property, the view adds enough rows for the rest of the values. An important property view in our implementation is the *literal property view*. As a literal can only take the position of an object in a triple and is not important navigationally, we provide a full-width text area for the literal. It can be important to be able to view a long literal, so the text area has multiple lines if necessary. One more viewlet implemented is the *container property view*. Instead of using a representation view to show the container, it goes through the container to the elements and shows them as a list. To the reverse direction, for any of the elements it shows the node that has the container as a property. Spatial views ------------- The representation and property views are points in their spatial nature. With this we mean that they don't provide visual connections between views and they show a single location in the graph. For a representation view this is clear, and for a property view we ask the reader to take into consideration that a property view shows only a single property at a time. A *spatial view* in this architecture is a lot like a window that can be scrolled and that gives an arrangement of related information. One of the spatial views in our implementation is the *property list view* that builds on the property views of the previous section. It provides a simple arrangement of the neighbourhood of a node by putting a representation view of the node to the top as a heading and below that a list of property views for each property of the node. The user can scroll the list if there are more properties than fit on the screen at a time. Another spatial view is the *canvas view*. It shows a two-dimensional space around a node by interpreting an RDF vocabulary of canvases and items on it, where each item has x and y coordinates as properties. Each item on the canvas is displayed using a representation view, which allows textual items, regions of PDF documents etc. to be arranged. We have also implemented a spatial view for the PDF documents themselves. The user can read the document and scroll in it. Any regions that some node represents are shown as hollow rectangles on the document. This allows the user to discover and browse links, comments or nodes about the document. Structure views --------------- We have tried to make Fenfire useful as an RDF editor with the previous free view types. However, we want to discuss one more view type that is natural to any kind of structural data and an RDF graph in particular. Unfortunately the intellectual property status of the view type is unclear because of granted patents on it, and thus we don't have a published implementation of these views. The type of view in question is a view that shows an item, and related items around it. We call this kind of a view a *structure view*. The free implementation we would like to publish along our software shows for a node a spatial view of it. In a circle around are property values of the node in smaller spatial views. Depending on space on the screen, the performance of the computer and nature of the RDF graph in question, the number of shown properties can be limited and the user can rotate to see other properties, or we can show more properties, even properties of properties recursively. If a spatial view is like a window, a structure view is like connections between related items, *between different windows*. We think it is useful in providing the user with a better view of relations in the surroundings of the current focus. It also provides visual connections and integration between several spatial views, even those of different implementation. RDF considerations ================== As our implementation has originally been independent of RDF, we have approached RDF and other semantic web technologies from the direction of general labelled graphs. As RDF is customized for the Semantic Web scenario, it provides good concepts to build a distributed graph of real-world items and connections between them. For implementors of RDF applications the following can provide considerations similar to those from XML appliers. URIs ---- URIs are pretty much just unique identifiers for nodes in our current implementation. In the user interface, we show the URI of the currently selected node in a location bar. If a node has a meaningful URI but no text property, we can use the URI as a textual representation of the node. If a node has an http URI, the user can request that document to be downloaded and added to the graph as RDF data if it's in a supported format. One URI that requires special treatment is the URI of the document. In many RDF documents that is used to embed metadata about the document. When we save an RDF graph to a file, we need to write it as the empty relative URI ``<>`` so that if the file is moved, the metadata talks of the document even in this new location. Namespaces ---------- In addition to the set of RDF triples itself, we keep a list of namespaces declared in each document, and a union of all these namespaces for user-interface purposes. Whenever a URI is to be displayed, such as a predicate node without a text property, the URI goes through the user-interface namespace map that tries to abbreviate the URI with the most specific namespace that is present. This is very important for usability, as the representation of the node is at least as clear as it was in the RDF documents that referred to it. We feel that particulary for predicate nodes the representation such as ``rdfs:label`` or ``rss:items`` is the best for all if not the least technical users, and it keeps the representation exact with a direct mapping back to URIs. To ensure that certain central and well-known namespace abbreviations are always available, we seed the user-interface namespace list with them. Whenever a document is written back to a file, any previous namespace declarations are put back with it, and we add any namespaces from the user-interface list that can be used to abbreviate a predicate we are writing. Schemas and ontologies ---------------------- Unlike many other Semantic Web applications, the RDF editor described here doesn't need or take advantage of higher level concepts such as schema descriptions or ontologies. They can probably provide additional user interface aids, but we hope that any RDF graph could be editable without the editor having knowledge about the properties of the resources. In this sense the situation is the same as in using a plain-text editor for a structured language such as RDF, XML or Java. Something little we have explicitly programmed the editor to notice are text properties, links to other resources, and properties that are defined as functional inverse properties. Blank nodes ----------- Internally, we use a URI scheme ``bnode:`` for blank nodes, followed by a random indentifier for the graph of origin and a sequence number to distinguish separate blank nodes of that graph. Currently, we don't provide an interface to create new blank nodes. Any present blank nodes in external documents are a challenge too, as if the user describes something about such a node, they would intend the same blank node to be available in the document they later save. One possibilty for future work will be to try to create a new node when a blank node is referenced, and copy any functional inverse properties from the blank node to preserve resource identity. Literals -------- Currently all new literals created in the editor are without a language designation and type declaration. When the user edits a literal, we actually make a new literal with the previous language or type information and new content. We remove the old literal from the selected property, and add the new one to it. As RDF doesn't have explicit text content for resources, we show one of the literal values from a list of text properties as the textual representation of a node if available, or the URI of the node otherwise. If the user then edits this textual representation, the shown literal is edited instead. If a literal was not shown, a new one is created on a default property and is then edited and shown. Editor controls =============== Controls for the editor need to meet the needs of effortless data entry of a text editor and, on the other hand, the semantic richness of the underlying model. The controls should also match the display. Mouse controls -------------- We have implemented only a simple set of mouse controls because we feel that an editor that is used to enter text shouldn't require the user to switch between mouse and keyboard usage. Navigation is mostly mouse-enabled. First of all, left-clicking always navigates to the clicked element. In canvas and pdf document spatial views, left-click dragging is used to scroll the visible portion of the view. Right-click dragging controls zoom level. In the canvas view, items can be moved by dragging with Control key held down. Keyboard navigation ------------------- Because any node can have unlimited amount of property values, keyboard navigation needs to concist of the steps of first selecting a property and then navigating to its value. To enforce the subject-predicate-object model, we show subjects of inverse properties on the left, objects of positive properties on the right, and require the user to commit to this directionality by pressing an arrow key left or right to move to the value on the respective side. Up and down arrows are then free to be used to select the wanted property in the first place. Holding the Control key modifies the action so that instead of moving along the property, the triple of the property is removed from the graph. When a literal is selected, arrow keys left and right move a text cursor instead, and letters and Backspace can be used for normal typing. As was already mentioned while considering our use of URIs, the user can request data about the current resource to be loaded from the web. This action has a keyboard shortcut. The same shortcut also requests data from Gnowsis, if it is installed. Another keyboard shortcut can be used to request Gnowsis to browse the current resource. Potions ------- Structure editing is much more complicated. For example, making a new connection (ie. triple) means the user has to indicate the action, and choose three nodes. Further, a node can be the currently selected node, a node nearby, a node the user often mentions, a new resource, a new literal, a URI in a namespace or an arbitrary URI the user wants to enter. In our implementation, there is a simple language called Potions that can be used to enter expressions to achieve tasks such as the example. To make a new triple, the user should first navigate to either the subject or the object of the triple, and then issue the keyboard shortcut for either "connect" or "connect backwards", respectively. After that, a status bar is visible at the bottom of the window, indicating that a command has been selected and that the user should complete the action by issuing shortcuts to designate first the property and then the value. To designate nodes, there is a set of shortcuts. For instance, one of them lets the user fill the next missing parameter to the action by typing a URI. Another one fills the next missing parameter with a new literal. Unique property shortcuts ------------------------- To fill in a property for an incomplete Potions action, the implementation provides a three-letter shortcut derived from the URI of the property. The derivation is based on seeding a random number generator with a hash value of the URI, so even though each shortcut is seemingly random it is always the same for any given URI and we expect the user to learn quickly some of the shortcuts they need most often. These shortcuts are available only to predicates that are used in the current graph, and some well-known predicates, and the composite of a hash function and random number generator seeding is expected to distribute the shortcuts evenly, so the number of predicates in use getting the same three-letter shortcut should be relatively small. However, the clashes are inevitable, and as a backup we can switch to four-letter shortcuts for those properties, and so on. Conclusion ========== In this article, we have described an architecture for an RDF editor as implemented as a subgoal of the Fenfire project in search for an item-based information management environment. We argued that as RDF is central in the Semantic Web standards and applications, such an editor concerns the research and implementation on the field. We started by outlining the architecture of the editor as a collection of views and associated controllers on the RDF graph model. We proceeded to describe the view architecture of representation, property, and spatial view types, and discussed the possibilities of a structure view type. We continued with concerns related to the specific model of RDF as opposed to a general labelled graph. We discussed the use of URIs, namespaces, schemas and ontologies, blank nodes and literals in our implementation of the editor. Next, we described the controls implemented to allow browsing and editing that match the views. Structure editing such as adding new triples was found to be a complex task, and a small language called Potions was introduced as one solution. Last, unique property shortcuts were proposed as a specialized way to enter predicates. Acknowledgements ================ The authors would like to thank Ted Nelson for his ideas, inspiration and collaboration on Gzz the zzStructure implementation that lead to the Fenfire project. Former leader of both projects, Tuomas Lukka has guided us and performed most of the research with respect to software architecture and visualization techniques, the latter with Janne Kujala. We would also like to thank Toni Alatalo, Antti-Juhani Kaijanaho, Hanna Ollila, and Asko Soukka for their continuing support of the project.