ontology visualization

8/8/2019 Ontology Visualization

1/27


2/27


3/27


4/27


5/27


6/27


7/27

Ontology visualization

Department of Computer Science Page 7

Another common type of relations is the meronymy relation, written as part-

of , that represents how objects combine together to form composite objects. For

example, if we extended our example ontology to include objects like Steering Wheel,

we would say that "Steering Wheel is-part-of Ford Explorer" since a steering wheel is

one of the components of a Ford Explorer.Facets-these are restriction on slots or role restrictions which state conditions that

must always hold to guarantee the semantic integrity of the ontology.For example

each slot has a type value or the restricted number of allowed values.Allowed classes

for slots of type instances are often called a range of slots.

Instances are the basic, "ground level" components of an ontology. The individuals

in an ontology may include concrete objects such as people, animals, tables,

automobile s, molecules, and planets, as well as abstract individuals such as numbers

and words. Strictly speaking, an ontology need not include any individuals, but one of

the general purposes of an ontology is to provide a means of classifying individuals,

even if those individuals are not explicitly part of the ontology.

3. WHY ONTOLOGY?

An ontology provides a common vocabulary for researchers who need to share

information in the domain. Some of the reasons to create an ontology are:

To share common understanding of the structure of information among people

or software agents

To enable reuse of domain knowledge

To make domain assumptions explicit

To separate domain knowledge from operational knowledge

To analyze domain knowledge

Sharing common understanding of the structure of information among people or

software agents is one of the more common goals in developing ontologies (Musen

1992; Gruber 1993). For example, suppose several different Web sites contain

medical information or provide medical e-commerce services. If these Web sites share

and publish the same underlying ontology of the terms they all use, then computer

agents can extract and aggregate information from these different sites. The agents

can use this aggregated information to answer user queries or as input data to other

applications.


8/27



Enabling reuse of domain knowledge was one of the driving forces behind recent

surge in ontology research. For example, models for many different domains need to

represent the notion of time. This representation includes the notions of time intervals,

points in time, relative measures of time, and so on. If one group of researchers

develops such an ontology in detail, others can simply reuse it for their domains.Additionally, if we need to build a large ontology, we can integrate several existing

ontologies describing portions of the large domain. We can also reuse a general

ontology, such as the UNSPSC ontology, and extend it to describe our domain of

interest.

Making explicit domain assumptions underlying an implementation makes it possible

to change these assumptions easily if our knowledge about the domain changes. Hard-

coding assumptions about the world in programming-language code makes these

assumptions not only hard to find and understand but also hard to change, in

particular for someone without programming expertise. In addition, explicit

specifications of domain knowledge are useful for new users who must learn what

terms in the domain mean.

Separating the domain knowledge from the operational knowledge is another common

use of ontologies. We can describe a task of configuring a product from its

components according to a required specification and implement a program that does

this configuration independent of the products and components themselves

(McGuinness and Wright 1998). We can then develop an ontology of PC-components

and characteristics and apply the algorithm to configure made-to-order PCs. We can

also use the same algorithm to configure elevators if we feed an elevator component

ontology to it (Rothenfluh et al. 1996).

Analyzing domain knowledge is possible once a declarative specification of the terms

is available. Formal analysis of terms is extremely valuable when both attempting to

reuse existing ontologies and extending them (McGuinness et al. 2000).


9/27



4. TYPES OF ONTOLOGY

4.1 Domain ontology

A domain ontology (or domain-specific ontology) models a specific domain,

or part of the world. It represents the particular meanings of terms as they apply to

that domain. For example the word card has many different meanings. An ontology

about the domain of poker would model the "playing card" meaning of the word,

while an ontology about the domain of computer hardware would model the "punch

card" and "video card" meanings.

4.2 Upper ontology

An upper ontology (or foundation ontology) is a model of the common

objects that are generally applicable across a wide range of domain ontologies. It

contains a core glossary in whose terms objects in a set of domains can be described.

There are several standardized upper ontologies available for use, including Dublin

Core, GFO, OpenCyc/ResearchCyc, ,and SUMO.

4.3 Task ontology

Task ontology characterizes the computational architecture of a knowledge-

based system which performs a task By a task, we mean a problem solving process

like diagnosis, monitoring, scheduling, design, and so on. The idea of task ontology

which serves as a system of the vocabulary/concepts used as building blocks for

knowledge-based systems might provide us with an effective methodology andvocabulary for both analyzing and synthesizing knowledge-based systems. Task

ontology is useful for describing inherent problem solving structure of the existing

tasks domain-independently. It is obtained by analyzing task structures of real world

problems. Proposal of task ontology has been done in order to overcome the short

comings of generic tasks while preserving their basic philosophies. It does not cover

the control structure but do components or primitives of unit inferences taking place

during performing tasks. The ultimate goal of task ontology research includes to

provide a theory of all the vocabulary/concepts necessary for building a model of

human problem solving processes.

The determination of the abstraction level of task ontology requires a

close consideration on granularity and generality of the unit of problem solving

action. These observations suggest task ontology consists of the following four kinds

of concepts:


10/27



1. Task roles reflecting the roles played by the domain objects in the problem solving

process

2. Task actions representing unit activities appearing in the problem solving process,

3. States of the objects, and

4. Other concepts specific to the task.Task ontology for a scheduling task, for example, includes:

Task roles:

"Scheduling recipient", "Scheduling resource", "Due date", "Schedule", "Constraints",

"Goal",

"Priority", etc.

Task actions:

"Assign", "Classify", "Pick up", "Select", "Relax", "Neglect", etc.

States:

"Unassigned", "The last", "Idle" etc.

Others:

"Strong constraint", "Constraint satisfaction", "Constraint predicates", "Attribute", etc.

Actions are defined as a set of procedures representing its operational meaning. So,

they collectively serve as a set of reusable components for building a scheduling

engine.

Before task ontology has been invented, people tended to understand an

ontology is often use-dependent and it has the same shortcoming of the knowledge

bases of expert systems, that is, little reusability because of its task-specificity. The

idea of task ontology contributes to the resolution of such problems. The reason why

an ontology looks task-specific is the ontology mixes up task ontology and domain

ontology. Task ontology specifies the roles which are played by the domain objects.

Therefore, if a domain ontology is designed after task ontology has been developed,

one can succeed to come up with a domain ontology independent at least of the

particular task because all the task-specific concepts are detached from the domain

concepts to form task-specific roles in the task ontology. A task ontology thus helps

develop a use-neutral domain ontology.

4.4 Heavy-weight ontology and light-weight ontology

Another viewpoint suggests us another type of ontology: Light-weight

ontology and heavy-weight ontology. The former includes ontologies for web search


11/27


12/27



language and that the XMLs data model is the nesting structure of information and

the frame-like model with slots.

5.3 Web Ontology Language(OWL)

Web Ontology Language(OWL) is also a language developed by W3C[OWL].

OWL is designed to make it a common language for ontology representation and is

based on DAML+OIL[DAML]. OWL is an extension of RDF Schema and also

employs the triple model. Its design principle includes developing a standard language

for ontology representation to enable semantic web, and hence extensibility,

modifiability and interoperability are given the highest priority. At the same time, it

tries to achieve a good trade-off between scalability and expressive power.

6.WHY VISUALIZATION?

Recently, the continuing progress in network technologies and data storage

has enabled the digitization and dissemination of huge amounts of documents. The

need for more effective information retrieval has lead to the creation of the notions of

the semantic web and personalized information management, areas of study that

exploit the semantic context of documents to facilitate their management. In many of

the proposed solutions in this field, it is common to include the use of an ontology;

The Ontology are machine understandable and thus need some means of graphical

visualization for humans to comprehend.

Visualization tools makes it easy to

understand large and complex ontology Important for easy representation of selected

parts.That is visualization allows to reduce all possibilities and to show what user

wish to view.

6.1 Good visualization tool characteristics

A good visualization tool should show the following features:

Elements of ontology should be displayed.

For a method to be eligible for the visualization of an ontology, it has to

support the presentation of ontology ingredients; classes (or entity types), relations,instances, and properties (or slots)

It should be able to load large ontology Navigational techniques can be used to move to certain region in the large

ontology


13/27



It should have efficient navigation technique like zoom , browsing option

through search etc..

Visualization of ontologies is not an easy task. An ontology is something

more than a hierarchy of concepts. It is enriched with role relations among concepts

and each concept has various attributes related to it. Furthermore, each concept mostprobably has instances attached to it, which could range from one or two to thousands.

Therefore, it is not simple to create a visualization that will effectively display all this

information and at the same time allow the user to easily perform various operations

on the ontology.

In the field of ontology visualization, there are several works, mostly in 2D.

Apart from the systems that propose visualizations especially tailored for ontologies,

there are a number of other techniques used in other contexts such as graph or file

system visualization, that could be adapted to display ontologies.

Here we present three visualization tools in Protg [Protege Project

http://protege.stanford.edu ] in terms of their characteristics and features in relation

with a set of requirements compiled for an ontology visualization tool.They are:

Protg class browser OntoViz Jambalaya

The visualization of a news paper ontology is done using these tools.

7. Protege class browser

The Class Browser is a simple visualization technique that offers a

Windows Explorer - like view of the ontology. In this view, the taxonomy of the

ontology (as dictated by the is-a inheritance relationships) is represented as a tree. It

displays the class hierarchy with the lower-level nodes presented as a list under their

parent and indented to its right. Classes with more that one parents (multiple

inheritance) appear under all their parents. The lists of child nodes may be retracted orexpanded at will by clicking or double clicking on their parent. A node may be

located using the Search feature available, which, however, only locates classes that

are already visible.


14/27



Figure 1.The Protg Class browser

Figure 2.The Protg Class Browser


15/27



Advantages and disadvantages

The main advantage is simplicity of implementation and representation and

the familiarity to user. It offers a clear view of class names and the hierarchy. In the

case of node labels, it has a clear advantage in comparison with almost all the other

techniques: there is no label overlap and it is not required to move the mouse over the

item in order to view the label.

One problem is that it represents a tree, not a graph. So it only displays is-a

relations, not role relations. Role relations are accessible only through slots. Also

multiple inheritance cases are not very obvious. Since it being not a graphical

representation it places the class under all the parent classes. But it is not always clear

to an inexperienced user. Only small portion of ontology is visible at a time. However

this performs better than any other visualization tool which is used for hierarchies .

Table1.Protege Class Browser Visualization Characteristics Summary.


16/27



8. OntoVizOntoViz is another Protg visualization plug-in using a very simple 2D

graph visualization method. The OntoViz Tab allows to visualize Protege ontologies

with the help of a highly sophisticated graph visualization software called "Graphviz"

[http://www.graphviz.org/] from AT&T. The types of visualizations are highly

configurable and include:

Picking a set of classes or instances to visualize part of an ontology. Displaying slots and slot edges. Specifying colors for nodes and edges. When picking only a few classes or instances, you can apply various closure

operators (e.g., subclasses, superclasses) to visualize their vicinity.

The ontology is presented as a 2D graph with the capability for each class to

present, apart from the name, its attributes slots and inheritance and role relations. In

graph we can see rectangle nodes with different colors. The instances are displayed in

different color. Class hierarchy is represented by placing child nodes under parent

nodes linked with is-a link and Multiple inheritance by placing child nodes under all

parent nodes. It is possible for the user to choose which ontology elements will be

displayed from the configuration panel on the left. Right-clicking on the graph allows

the user to zoom in or zoom out. No keyword search is provided in this tool.

To create a graph, select a class from your ontology in the Classes pane, click the "add class" button in the upper left "Config" area of the tab. To fine tune graph

(e.g., for showing only a part of ontology), the following options are available:

sub - subclass closure

sup - superclass closure

slx - slot extension

isx - inverse slot extension

slt - slots

sle - slot edges

ins - instances

sys - system frames

Check several of the options and click the "Create Graph" button. The same process

can be used for creating graphs of instances by using the "add instance" instead of the


17/27



"add class" button. To remove an entry from the Config table, use the "remove class"

button.

Figure 3.OntoViz visualization of newspaper ontology

Figure 4. OntoViz visualization of newspaper ontology


18/27




It is most suited to answer structural and trends related questions.But it is

making inefficient use of screen space,only less than 1000 nodes can be seen

effectively in a screen. OntoViz visualization received very negative reactions in

evaluations. It attempts to alleviate the problem of node clutter by allowing the user to

select the nodes she/he would like to display, along with their subhierarchies or

related nodes, through a configuration panel. However, several interaction issues

seemed to lead to a rather bad performance.

All users commented on the lack of interaction and had experienced problems

with the navigation, such as having to drag the scrollbars to navigate. Furthermore,

the zoom in and out commands and clicking of the item on focus. They found the

presentation poor and chaotic and commented on the lack of a search tool and the

fact that some labels are not fully visible, forcing the user to guess their meaning;

absence of sorting (instances are not presented in alphabetical or any other

deterministic order) was also negatively commented. However, some users

commented that the visualization could be effective for smaller ontologies or if the

user is very familiar with the ontology, as it seemed to them useful for the

presentation of hierarchies.

Table2.OntoViz Visualization Characteristics Summary.


19/27



9. Jambalaya

Jambalaya is a visualization plug-in for the Protege ontology tool that uses

the SHriMP (Simple Hierarchical Multi-Perspective) 2D visualization technique.

SHriMP uses a nested graph view and the concept of nested interchangeable views. It

provides a set of tools including several node presentation styles, configuration of

display properties and different overview styles.

According to this method, nested nodes are used to express the inheritance

relations between the classes, as sub-classes are nested inside parent classes. Instances

are also represented as nested nodes in their corresponding class in the graph. Instance

nodes are distinguished from the class ones by their color. Role relations between

classes or instances are represented in the graph using directed links between the

related nodes. Users may navigate in the ontology through this visualization utilizing

the selection and zoom tools. When a class or instance is selected by zooming on

it,the SHriMP view focuses (using a focus technique with animation) on the selected

node of the nested graph.

When the class or instance is doubleclicked, the view focuses on the clicked

node and opens a form with the node information, embedded in the visualization. The

visualization also offers extra navigation buttons like back or home. Jambalaya

contains a more advanced keyword search than the other methods, allowing the user

to search the whole ontology (classes and instances alike) or limit the search scope by

specifying the type of the searched item. Search refinement is also available by

searching within the results.

In addition to using arcs to show relationships as connections (arcs) between

classes and instances, the user may show a relationship type using containment. For

example, rather than drawing arcs between nodes to show the is-a relationship, we can

instead nest subclasses within their superclasses. Furthermore, it may also be

advantageous to use other user defined slot types for nesting nodes. For example, in

an anatomy ontology, the user defined part-of relationship may be a more appropriate

relationship for nesting nodes than the is-a relationship.


20/27



Figure 5: The Jambalaya plug-in for Protg. The newspaper ontology is displayed using nested view


Jambalaya in general got positive reactions. Most users commented

positively on the effective search tool and the animated transition when double

clicking on an instance or class. They liked flying together with the visualization

to locate the information. Some noted that they would like the animation to be faster

(I lose time waiting) or slower (not enough time to understand the transition) orto display the steps of the transition to the side. It was interesting that none of the

users tried to use the visible relation links and almost all noted as a negative point the

appearance of the links and the fact that after browsing some classes there come to be

so many relation links that they obstruct the view to the visualization. They also noted

that labels overlap in the case of many instances.As in Jambalaya , users had a

problem knowing which is the current parent node that had been zoomed in, or if the

node had already been visited.


21/27



10. ISSUES IN VISUALIZATION

Task Support

Based on ontology visualization characteristics, this section attempts an

analysis of tasks related to ontologies, with the aim of assessing which visualizations

best support each task type. Shneiderman [1996], presents seven high-level tasks that

an information visualization application should support. These are the following:

1. Overview . Gain an overview of the entire collection.

2. Zoom . Zoom in on items of interest. When zooming, it is important that global

context

can be retained.

3. Filter . Filter out uninteresting items.

4. Details-on-demand . Select an item or group and get details when needed.

5. Relate . View relationships among items.

6. History .Keep a history of actions to support undo, replay, and progressive

refinement.

7. Extract . Allow extraction of subcollections and query parameters. This extraction

refers to saving desired subparts of the collection and is typically supported by the

ontology management tools, not the visualization methods per se.

Not all tasks can be effectively supported through a single visualization.

This fact supports the view that more than one visualization method should be made

available to ontology designers and users. Furthermore, not all tasks may be supported

by visualization, thus supplemental information retrieval aids should be provided.

Locating a specific node, for example, may be accomplished by browsing the

ontology, using the visualization, but it is much quicker and more effortless to do so

using a search tool. This fact was proven in Katifori et al. [2006a]. Cardinality-related

tasks, for example, finding the number of class siblings or children, can be performed

using the visualization alone, but the user would have to count the nodes; certain tools

facilitate these tasks by providing the numbers (by default or on request), but thesefacilities are strongly tool-dependent, rather than visualization method-dependent.

Going back to a previously visited node could be supported by the tool if it

provided an elaborate history mechanism, but also by the visualization. If the

visualization supports learning of the ontology structure and the creation of a mental

image, then the user may easily return to previously visited nodes. Methods that are


22/27



more effective to this end are the ones that maintain a constant positioning of the

nodes and allow quick browsing at the same time. Last, tasks like Forwards-Back or

Initial View are solely tool-related.

Navigation and Interaction Issue

All static hierarchical presentations have liimits as to the quantity of nforma

tion they are capable of presenting on a finite display space Babaria [2004]. When

these limits are reached, navigational techniques must be used, creating the potential

for loss of context. In most visualizations, depending upon the drawing algorithm and

the size of the display space, a hundred or so nodes can be adequately represented on

screen without the need for panning or zooming. The various visualization techniques

differ in the level of interaction they offer to the user. Some of the methods allow the

user to only view the presented ontology as a static image. Others allow the retraction

and expansion of nodes, the movement and rotation of the presented ontology,

zooming or clicking to change hierarchy level or the node on focus. Other, mostly

tool-related, features are history functionalities, overview windows, and the use of

animated transitions.

All these features are useful for exploring the ontology to find specific nodes,

focus on nodes of interest, or examine relations between nodes. Retraction and

expansion of nodes, viewpoint movement, and rotation, and zooming, are features that

most of the visualizations support, since they are necessary to navigate hierarchies

with more than a hundred nodes. In these cases, the interaction techniques used are

essential for the success of the visualization as they greatly affect task completion.

Zooming is another important issue. According to Plaisant et al. [2002],

semantic zooming is preferred over geometrical scaling; it is important to provide the

user the means to focus on specific nodes and be able to view their details, not just

scale the visualization as an image. Another issue with zooming is the loss of the

sense of where the user is and where she/he came from. As already mentioned,

navigational cues such as informing the user of the current level of the hierarchy and

the path she/he followed to get there are essential to this end.

Another useful feature is Overview tools and Back and Forward navigation

aids. Overview tools are especially effective in zoomable visualizations where the

user may easily lose sense of his/her position. Back and Forward, on the other

hand, allow the user to retrace his/her steps during browsing. Movement and rotation


23/27



of the graph is another interaction feature that should be carefully designed. Although

it allows the user to manipulate and examine the ontology in order to locate specific

nodes or areas of interest, it may disorient the user. Furthermore it does not help the

creation of a cognitive model of the ontology as nodes continuously change position.

This is also the case of animated transitions. They are used as a means to change theview while zooming, rotating the graph, expanding or retracting, focusing on another

part of the ontology and so on, while helping the user to understand the change and

retain a clear picture of his/her previous and current locations in the graph. However,

the reaction of the users to it is not always positive and it may be conflicting. In the

case of its use for moving automatically from one place to the other, the user may find

the animation useful because it shows the transition path, or annoying because it is

time consuming.

On the whole, interaction and navigation techniques are essential for the

success of a visualization method. They form an integral part of the method, as

without them the visualization would be a static image. More research and evaluations

are needed in order to couple visualization and interaction effectively to create a

useful and easy to use tool.

Scalability issues

Current systems tend to avoid the problem of scalability by limiting the number

of visible items to about 10000. Ontosphere for example reports problems with many

nodes (more than 1000) such as occlusion and label overlap. According to Fekete and

Plaisant [2002], control panels, labels, margins, waste space, and data structures are

not optimized for speed, and the graphics libraries they employ are not sufficient.

Another issue in big ontologies is that of the node labels display, especially

important in an ontology, which is basically composed of concepts that the user

should be able to read to understand. Fekete and Plaisant [2002] state that text labels

are not preattentive but nevertheless important to understand the context in which

visualized data appear. Labeling each item cannot be done statically on a dense

visualization.

The visualization of relation links is also problematic and the display may

become cluttered very quickly. Both TGVizTab and OntoViz became impossible to

use when relation links were visible, even for an ontology for less than 300 nodes. In

Jambalaya too, users did not exploit the relation linksthey even seemed to hinder


24/27



them. A solution to the problem of relation link clutter is not to display them all on the

graph but rather allow the user to select which ones to display. Several visualizations

like the 3D Hyperbolic Browser , Jambalaya , OntoViz and TGVizTab , support

this.

Techniques based on zooming, which use different node sizes for therepresentation of the lower levels, also become illegible as the number of nodes

increases. The zoomable techniques that do not visualize all the levels at the same

time may become difficult to navigate after a point. The reason is that when the

number of nodes and hierarchy levels increases, it becomes more and more difficult

for the user to keep track of his/her position.

The more efficient techniques for large ontology sizes are most probably the

techniques that use distortion or expansion and retraction of the nodes, because they

can provide detail, maintaining at the same time the general impression of the context.

Van Ham and VanWijk [2002] propose three solutions to the problem of visualization

of many nodes:

1. Increase available display space, by either using three dimensional and/or

hyperbolic spaces.

2. Reduce the number of information elements by clustering or hiding nodes.

3. Use the given visualization space more efficiently by using every available pixel.

Such solutions have been employed by most of the presented visualizations with

varying degrees of effectiveness.

On the whole, as Munzner [1997] also states that information density should

not be the only metric in ontology visualization: when taken too far, it becomes a

clutter.Drawing for example all the links in a highly connected graph yields a picture

that can give a high level overview of the global structure but is useless for examining

the details. There is always a trade-off between maximum number of nodes displayed

and clarity and details in the visualization. Allowing the user to configure the

visualization according to his/her needs and the related task is probably the best

solution possible.

Reasoning

A very important issue related to ontologies, which are mainly knowledge

representations, is that of reasoning. An ontology is more than a simple graph, it is a

structure with rich semantics and the ability to use logic operations on it so as to reach


25/27



conclusions and produce new information. The issue of coupling visualization and

reasoning has not yet been sufficiently treated in existing literature and very few

methods support it. OntoTrack, for example, has a connection with an external

Reasoner in order to detect problems while editing, which are outlined with red on the

visualization. OZONE on the other hand, as a visual query tool allows the user toextract information from the ontology. However, this issue should be further

investigated in order to create visualizations that will support all the ontology features

more effectively.


26/27



11. CONCLUSION

Much work has been done in the field of graph and hierarchy visualization

both in 2D and 3D. The visualization of ontologies is a particular subproblem of this

area with many implications due to the various features that an ontology visualization

should present. As the results of researches done so far in this area it imply, there is

not one specific method that seems to be the most appropriate for all applications and,

consequently, a viable solution would be to provide the user with several visualize

tions, so as to be able to choose the one that is the most appropriate for his/her current

needs.

Furthermore, an important conclusion of most of the evaluations taken into

account for this work is that visualizations should be coupled with effective search

tools or querying mechanisms. Browsing is not enough for tasks related to locating a

specific class or instance, especially for big ontologies. Most users also seem to

dislike chaotic and too cluttered overviews, and tend to prefer visualizations that offer

the possibility of an orderly and clear browsing of the presented information, even if

in some cases it requires focusing on a specific part of the ontology or hierarchy. This

fact implies that visualizations should also take advantage of the semantic context of

the information and even the user profile, in order to guide and support the hierarchy

or ontology exploration.

In some applications it is preferable or more convenient to provide only a

single visualization of the ontology. In this case the designer has to make a choice

among the available methods, based on certain characteristics of the ontology, the

application, the user profile, expertise, and so forth. It is hoped that the current work

will be useful in order to make that choice.


27/27


12.REFERENCES

[1] Ontology Visualization MethodsA Survey ,Akrivi Katifori and Constantin Halastis University of Athens and Lepauras, CostasVAssilakis, and EugeniaGiannopaulo University of Peloponnese , ACM Computing Surveys,Vol. 39, No. 4,Article10,Publication date: October 2007

[2] A Comparative Study of Four Ontology Visualization Techniques in Protg:Experiment Setup and Preliminary Results , Akrivi Katifori and Constantin

Halastis University of Athens and Lepauras, CostasVAssilakis, and EugeniaGiannopaulo University of Peloponnese

[3] Protg project , Stanford University http://protege.stanford.edu/doc/ users.html#tutorials

[4] http://en.wikipedia.org/wiki/Ontology_(computer_science)

ontology visualization

Documents