Introduction

The AllegroGraph web-based user interface is called AGWebView or just WebView. (This interface was introduced in release 8.0.0 and until this version was called New WebView. Starting in release 8.3.0, the new has been dropped. The older interface is still supported, though new features are not being added. It is called Traditional WebView.)

WebView is what is displayed when user navigates to the URL of a running AllegroGraph instance in a web browser. If you would rather use Traditional WebView, you can switch to it in the Login dialog displayed below. If you are already logged in, you can open a Traditional WebView tab by clicking on the Traditional WebView choice in the menu on the left side of the WebView page.

Getting to Traditional WebView from WebView

If you are using Traditional WebView, you get the new version by clicking New WebView on the right in the banner of the traditional WebView page:

New WebView button

Login dialog

When WebView is started you are presented with a login window:

Login Form

Supply your AllegroGraph username and password (or token). WebView will log you out if you are idle too long (30 minutes), but check the Stay logged in checkbox if desired to allow 30 days until being logged out.

If you prefer Traditional WebView, go there directly (without logging in) with the Traditional WebView link near the bottom.

AllegroGraph supports Single Sign-on (SSO). When SSO is configured the login dialog has a"SIGN IN WITH SSO" button. See the SSO document for details on setting SSO up and logging on using it.

Initial Display

Here is the WebView page when it starts up (the first time there will be no repositories shown but this image comes after some use):

WebView Initial Page

The exact contents depend on how WebView was initiated and characteristics and permissions of the user. Always displayed are the banner at the top and a menu list to the left. When first displayed, the main field in the center displays the repositories in the current catalog and some action buttons. Note that what works and sometimes what is displayed depends on the permissions of the current user. If the current user does not have permission to perform a certain action, that fact may be reported on the page or when the users attempts the action. Most pictures are taked when the user had superuser permission, so most illustrations in the document do not show restrictions.

The Banner

The banner, at the top of a WebView page, is always displayed. It has three active items:

As you navigate among the various WebView pages, you can always get back to the catalog/repo initial page by clicking on the AllegroGraph logo on the left in the banner.

The USER menu

To the right of the display, the current username and an icon for the user are displayed. (The icon contains the first letter of the username; the color can be set on the user's page diplayed by the admin|users menu available to superusers.) Clicking on the username or the icon displays the USER menu.

The USER menu

The exact contents of the menu depends on various factors. This menu is for a superuser (named test) who logged in using a password an so has all the choices, which are:

The repository page

As said, WebView typically opens to a page listing repositories in the current catalog (usually the root catalog). Along the top to the right are button for creating a new repository in the current catalog and a button for creating an Large Language Model playground (which also creates a new repo). See the llm document for information on the llm playground.

A search widget appears on the upper right, useful when there are very many repos.

The Menus

On the left are a list of applicable menus. The list depends on the permissions of the user. For example, if the user is a superuser, one of the choices will be Admin. The arrowhead next to the menu name points down if the menu is closed and up if open. Clicking on the menu name or arrowhead changes the state.

How to use the various menu items is usually clear once the menu is displayed so we will not go into too much detail in the document.

The catalog list

Catalogs are listed under the file folder icon to the left just under the AllegroGraph icon. There is always a root and a fedshard catalog. Other catalogs must be defined by you (our your administrator) and listed in a agraph.cfg configuration file (see the Server Configuration and Control document). Clicking on a catalog name displays the repositories (also called repos) in the catalog.

The Repository Menu

The Repository menu is only active when a repo is open. Click on an existing repo listed on the page or the Create Repository box to create a new one. (Its drop down menu also allows restoring a repo from a backup file.)

Once a repo is open and the menu is live, you will see these items:

The add, delete, import data page

Whn you click on the Add, delete, & import data item in the Repository menu, this page is displayed:

Add, delete, import data page

The choices include:

The Admin menu

This menu is only visible to superusers. It has the following items:

The Utilities menu

Available to all users

Other items

More on the Query page

The query page looks like this when displayed:

The Query page

The New Query box displays a menu when the arrow to the right is clicked, as displayed in the picture. (Just clicking on New Query is the same as choosing SPARQL from the menu.) The query types are:

Choose, for example SPARQL and the page changes like this, with untitled-NN added to the top (untitled-1 in the image):

The Query page waiting for a SPARQL query

Enter a SPARQL query (we choose one of the predefined ones listed on the right:

The Query page with a SPARQL query

Once a query has been entered, if you hover over the Execute Button, two additional choices appear: Plan and Log. Click on Plan to see the query plan (what the system intends to do when executing the query). The plan will also display warnings if there are any. Log will cause the query to be logged.

Recent queries are listed along the top, saved ones by name. (Unsaved queries have titles relating to the query type, with 'Untitled' labeling to SPARQL, Prolog, and GraphQL queries, while text search and chat stream, and chat bot queries are labeled with their type.) Unsaved queries are persistent across reloads but their dummy names (Untitled-1, Untitled-2, etc) may be changed. Users can save queries to assign persistent names.) Saved queries are also listed to the right.

You save a query by clicking on the disk icon next to the query name. This displays the following dialog. The Author and Query description fields are optional.

Query save dialog

There are three choices for the scope of the saved query:

Query save scope

You can edit and resave saved queries. All users (who can access the repo) can see and use the any user in this repo saved queries but only users with write permission can edit those queries.

Adding the PREFIX 

PREFIX franzOption_logQuery: <franz:yes>

will cause information about the query, including the query plan, to be printed to the log. Debug information will be included if the query fails.

This related PREFIX 

PREFIX franzOption_logQuery: <franz:onFailure>

will log query information only if the query fails. This information is very useful when debugging query problems. If you ask Franz Inc. about a query, be sure to send the query plan and also any debug information in the log recorded using this PREFIX.

On the right there are several menus with Query and Display options. Most are self-explanatory. The Display Option Full IRIs in results is useful if you want to see the IRIs but is off by default because full IRIs clutter the results.

Query auto-completion

When typing a query on the query page, the system will display auto-completion menus when it has the necessary information to do so. Auto-completion is provided for the following inputs:

Completions are cached. <, """, '''; will be auto-closed (e.g. entering < will also enter a > and place the cursor between them).

Here is an example. In the kennedy example in the Agraph Quick Start document we have this query: 

select ?p ?o WHERE {<http://www.franz.com/simple#person1> ?p ?o}

Here are some pictures showing completion menus displayed as the query is typed in. First sel displays choices including select:

Completion of select

Then the person1 IRI (note the closing > was added):

IRI for person1

And (finally for this example) the variable choices after entering ?:

Variable completion

Miscellaneous Tasks (managing query options, exporting or backing up triples from a repo, backing up everything)

You can do most everything necessary with some command somewhere in WebView, but it may not always be easy to find the right menu or the right choice. In this section we show how to accomplish certain common tasks. Even if the task you are looking for is not here, showing how commands for these tasks are found may assist in finding what you are looking for.

Managing Query options

The predefined query options are listed in SPARQL Query Options section of the SPARQL Reference document. A query option is enabled with a PREFIX to the query of the following form: 

PREFIX franzOption_optionName: <franz:optionValue>

where optionName names the option and optionValue specifies the option value. For example, the PREFIX, with optionName logQuery and optionValue onFailure specifies that query execution details should be logged only when the query fails: 

PREFIX franzOption_logQuery: <franz:onFailure>

You can view and manage currently enabled query options for a repo on the Query execution options page. This page is displayed by that option on the Repository control menu displayed by clicking Repository control on the Repository menu displayed on the left of the screen and searching for Query in the search box which is displayed.

Repository control menu

That displays a page that displays existing options (there are none in our illustration) and allows adding new ones. Clicking on New query options displays a from to add an option. The Name field has a drop down menu (as shown) with defined options:

Query execution options

And when a name is chosen, the Value field also has a menu of choices (if relevant -- sometimes you must specify the choice):

Query execution option values

You can also specify the scope: for you, the user; for this repo; or for all queries.

Once the values are chosen, clicking SAVE QUERY OPTIONS adds the option.

Query execution option is set

Exporting or backing up triples from a repo

Exporting data from a repo means writing a single file of a specified format (such as Ntriples or Nquads, and serval others) suitable for loading in any version of AllegroGraph or indeed any RDF database program. Backing up data means writing all data associated with a repo to a specialized file or files suitable to be read into AllegroGraph (or the same or later version than the one backed up).

Exporting data to a file

Display the Repository control menu and enter export in the search box.

Search for exporting data

Choose Export repository. This actually takes you to the Archiving choice, with the portion for downloading data displayed.

Archiving

There is a drop down menu for specifying the file type (we have chosen N-Triples) and a DOWNLOAD ALL DATA button. Clicking it displays a file dialog allowing you to specify a filename and location.

Backing up a repo

Searching for back-up displays the portion of the Archiving page that applies to backing a repo up. You have to specify a new name (not already used) for the back-up files and click "BACK-UP" (the location is part of the AllegroGraph directory).

Backing up

Backing up everything

There is no WebView command to back up all repos at once. To do that, use agtool, as described in Repository Backup and Restore.

Handling duplicate triples and attribute aggregation

One of the repository menu choices is Manage Duplicates:

Manage Duplicates

This displays the following:

Choices for managing duplicates

See the Deleting Duplicate Triples document for a detailed description of managing duplicates. See Managing duplicate triples in traditional AGWebView in the Traditional WebView document for information on the Tradition WebView interface.

The following text is repeated in Deleting Duplicate Triples.

To display the Managing Duplicates page in New WebView, choose Manage Duplicates from the Repository Control menu when a repository is open.

Managing duplicates menu item

That displays the following page:

Managing duplicates page

There are four fields on that page.

  1. Export duplicates: Allows downloading a list of duplicate triples (when the drop down list is SPO as shown) or quads (when it is SPOG). The download process is triggered by this choice.

  2. Delete duplicates: When chosen, duplicates (SPO or SPOG depending on what is specified in the drop down menu, SPO in the illustration) are deleted. If SPO duplicates are deleted, there is no control over the value of the graph on the remaining, undeleted triple. When triples are deleted, they are not actually removed, just marked as deleted. Over time, if many triples are deleted (because they are duplicates or just superseded by later data) they can waste significant space. See Purging Deleted Triples for information on cleaning up deleted duplicate and other deleted triples.

  3. Supress duplicates by specifying the Duplicate supression type. The choices, as showing in the illustration, are Off, Subject, Predicate, Object and Graph (spog), and Subject, Predicate, Object only (spo). This specifies what is to be done to duplicates at commit time (not at load time unless commits are done simultaneously with the load). If the SPOG or SPO choices are selected and attribute aggregation (described next) is not enabled, no new duplicates will be committed but existing duplicate, if any will be unaffected. The subsiduary Optional attribute aggregation strategy (described next) affects adding duplicates and existing duplicates.

  4. Optional attribute aggregation strategy: See the Aggregating attributes of duplicate triples section of the Triple Attributes document for information on attribute aggregation but in short, when you have two triples with the same SPO or SPOG (depending on which you consider to be duplicates) and both have attributes, instead of deleting one and keeping the other, you may wish to delete both (or not load one and delete the other) and create a new triple with different attributes constructed from combining in some fashion the attributes of the two triples.

    5. Here is an example: Suppose you have a modified attribute with a single value (the date of the last modification) and a modified-history attribute (listing all modification dates). The current triple has attributes { "modified": "02212023", "modified-history": [ "02212023" ] }. Now you want to add an SPO identical triple with attribute { "modified": "08252024", "modified-history": [ "02212023" ] }. But you now want the attributes to be { "modified": "08252024", "modified-history": [ "02212023" "08252024" ] } (the date of the latest modification and the list of modification dates). You would specify the aggregation stratgy of the modified attribute to be override and that of the modified-history attribute to be collect. The new triple will be as desired (except the order of modified-history may be reversed). The various aggregation choices are displayed in the menu displayed when clicking on the Aggregation box.

    Triple aggregation choices

LLM support

As said above, WebView supports creating LLM Playgrounds repositories. These repos have suitable prefixes applied to every query, such as one containing the openaiApiKey query option. This tool is described in the LLM document. However, LLM tools and magic predicates are available in any repository. Playgrounds just provide some prefixes automatically.

Other tools specify embeddings used in LLM work. The following subsections describe the relevant tools in WebView.

LLM embedding specification

LLM embedding is described in the LLM Embed Specification document. Such specifications are used when a vector dababase is created. The specification can be defined using a .def file (as is done with the the historical figures example and the Chomsky47 example). They can also be defined directly with the Create LLM Embedding dialog in AGWebView, as we describe in this section.

Let's start with the .def file used in the historical figures example (the api-key is not valid). 

embed  
 embedder openai   
 if-exists supersede   
 api-key "sk-U43SY1234567NSGmxlYbT3BlbkFJjyQVFiP5hAR7jKLMnopq"  
 vector-database-name ":10700/historicalFigures-vec"  
 if-exists supersede  
 limit 1000000   
 splitter list   
 include-predicates <http://www.w3.org/2000/01/rdf-schema\#label>

and let us see how to provide this same information using the Create LLM Embedding dialog in AGWebView, displayed when Create LLM Embedding is selected in the Repository Control menu displayed when a suitable database is open.

Create LLM Embedding dialog

Here are the fields, many of which are optional. Note that a field may become required depending on values of other fields.

The next line (Fill "Embedder", "Model", and "API key" only if you want to create the Vector Database:) is only relevant if a new database is being created, either because the named database does not exist or is being superseded.

The last entries allows specifying predicates and types you wish to include. The include fields default to <*>/*, meaning all predicates/types and the exclude fields default to none. You can specify exactly what to include and exclude with the right combination of include and exclude specifications, using wildcards where convenient.

Interface to the audit log

The following description is repeated in the audit documentation.

You can use the New WebView interface to examine auditing information. Only superusers can look at this information. There is an Audit log entry on the Admin menu to the left of the screen, as shown in the illustration:

The Admin menu on the WebView menu bar

If selected, the following page is displayed:

The Audit Log page in WebView

There are drop-down multiple-item menus for selecting the user(s) of interest and the events of interest (the beginning of that menu is displayed). There are also date widgets allowing specifying a start date and an end date which can be used to restrict the events being displayed to a specific time period. Leaving the start date blank but specifying an end date causes all events up to the end date to be displayed; leaving the end date blank but specifying a start date causes all events from the start date to be displayed; and leaving both blank causes all events to be displayed.

After we have, as superuser test, added two users (user1 and user2), we look at the updated log (looking at actions by test performing the event add user) which shows when those users were added and by whom. The information is refreshed whenever the View Audit Log button is clicked.

The Audit Log displaying add user events

The FILTER COLUMNS button allows you to hide columns in the display. The RESET VIEW button restores all columns.

Next user user1 creates a repository kennedy, to which user1 adds a bunch of triples, and test (the superuser) modifies user1's user permissions several times. Here are screens after that activity, the first showing all activity by test and user1 and the second just the change user activity of test. Clicking VIEW AUDIT LOG clears the currently displayed information and displays information based on the selections in the various lists and boxes.

The Audit Log displaying all activity

The Audit Log: test's change-user activity

user1 did add triples to the kennedy repository, but the audit log does not record adding and deleting triples so that activity is not shown.