Databases and Hypertext Sep-90

This is a collection of thoughts on a potential product which combines some aspects of hypertext with some of databases - lets call it Hyperbase (HB).

The market for the product would be wide based - just about anyone who has a PC. This means that it must be easy to use and understand. It is not intended as a product for software houses or other developers to use to develop add on products, although there is always a possibility that it may end up being used in this way to some extent.

Nor is it envisaged as something for 'hypertext authors' to use to prepare hyperbases for readers to peruse. Rather I see it as a tool for anyone who wants to store a variety of information which he wants to have access to in a variety of ways. He may well want to use this information to prepare normal printed documents for distribution, and he may also want to share all or part of his information with other PC users. Maybe this access would be simultaneous on a network. I see the hyperbase as a changing, dynamic complex with info being added, modified, moved, deleted as time goes by.

Maybe our user would like to link in to another hyperbase at some stage, perhaps temporarily, or maybe permanently.

The basic idea behind the product is this:

As data accumulates relating to any new activity or area of concern, there gradually develops some structure to the data (OK, it may be apparent from the beginning, but not always, and it may not be apparent to the end user, and thats what I'm focussing on here). The structure comes in (at least) two forms - hierarchical, and relational. Thats why hierarchical databases were invented, and why hypertext is used, but also why relational DB's were invented. In fact, its probably more messy than this, connections probably form loose semantic nets, and some sort of structure becomes apparent in this mess, but sometimes the structures overlap etc.

All sorts of natural questions arise in relation to this data -

What was the name of that xxxx Indexed Query

How many zzzs match this description Match search

Where did this information come from History

Where else is this information used Where used

What else does this information depend on Dependencies

Is this information part of something else Structural Schema

What else relates to this information Relational schema

OK, everything can be in terms of relations, but then so can natural numbers be objects, and I don't think either is natural or useful. People work and think in terms of small structures (records, file cards..) quite often, but there are also cross links between items in these structures with other structures or items elsewhere. And there is often natural hierarchy superimposed..

Let's define some terms, a Document is part of a Hyperbase, a button is an item which links to other Documents, and a Hyperbase is a set of linked Documents.

Let's introduce a specific example to illustrate my thinking:

Let's suppose the user is browsing / interrogating some in a Hyperbase. Suppose he has asked for all occurrences of some item within some domain of the data - such as all references to 'Hypertext'. Up on the screen come the references (maybe stepping thro each text entry, or listing them by 'extract'). OK, he thinks, that's interesting, I'd like to make this a permanent feature of my data so that I/other people can use it later to explore each reference. Maybe I'd like to add some annotation or explanation to each/some references. So he does this, and then says 'hey presto' and this collection of references is then stored, with appropriate links into the referenced data. In other words, the whole thing becomes a hyperbase Document with buttons linked into each reference.

Another example:

The user is creating a document (not unlike this one). He realises that the section headings could be turned into buttons in a top level index document with links to separate documents for each section. This could be done on several levels, with a main index and several sub indexes and so on. OR the headings could be linked to each section still within one document.

So - he identifies the headings by some means (perhaps a 'pattern match'), produces a list of headings, and converts to an index document, either maintaining the whole document, or 'breaking' it into section documents at each button/link.

Another:

The user is entering a table of information (in free format text) when he realises that this table is a 'generic' table whose form is/will be repeated elsewhere AND/OR that operations may be needed on the table as a whole - possibly totals, Possibly 'where used' lists.

Note that the Table may contain buttons.

Perhaps he could create a Table in a document - either a blank one, or superimposed on existing text. Tables could have a number of columns of varying width, and a number of rows of varying height. Each position in the table could contain free text (which might be a numeric) and the text could contain a button. Tables should be extendable in number of rows or columns as simply as possible - maybe treat as a text block, and if user adds a line, then he's adding a row. Similarly for inserting rows, columns.

A single position button could be used as a cross reference, or it could link to a document which is referenced in the Table - normal hypertext stuff, except in a table. So what's new ? Well, maybe we could ask for a list of all referenced documents in a table, or in a table column or row.

Doesn't sound too exciting ? Well, how about this -

Suppose we can make a complete Table Column a type of button (a link?). Maybe each column should have a column name at its head (separated from table by blank line or --- or something). The name could then be identified as a link. Then each entry in that column is a button to another document.

So for instance, a person's name in a table could link to a page full of notes relating to his history etc.

OR maybe the name itself could be a link to another table in another document. Then each entry in the column would link to the corresponding entry in the other table. What I'm trying to get here is a relational join, implemented using hypertext buttons. I think some experimenting is necessary. I can't see all the implications. I don't expect HB to compete with relational DB's, but to give some simple means of hooking information together in an ad hoc relational way.

Perhaps each entry in a column could link to a document containing a (sub) table, this would give a hierarchical type structure. Pointing at an entry in the column would then bring up the document table relating to that entry - similar to above example of 'notes' attached to a table entry, but using another table instead.

HYPERBASE CREATION FACILITIES

Create new button in current document

Create new document linked to button

Move text between documents

Push document down one level (insert button & document)

Remove button and absorb document

Delete button and document / tree

Remove all links to document from the HB

Link button to existing document

Create 'index' using pattern search

Make 'index' into button list document

Indexing will find a list of locations in the current hyperbase which contain a match for a text string (or pattern - ab??.* etc.).

The user has the option to show this as a list of document names with a sample piece of text containing the string, or to visit each location in turn, showing the relevant pages from each document.

Now comes the tricky bit. Making an index implies that one button can link to a number of places (thats what the search found) - this after all is what an index usually tells us.

An index document could contain several index button references - just like a normal index. Pointing at a button in context then takes the user to the index page, with cursor on the relevant key word, which has a number of buttons following it. User can then select from these, or other, buttons.

This is nice - it's like real life, and also flexible and uses only standard mechanisms. I think this has to be done from an index list - it would be messy to do it using a "visit".

The user does a search, asking for an index list. He gets a temporary document with a list in it. Hitting the "make index" command turns each entry into a button, and makes the document permanent, and linked back to an index button at the previous location (from which the search was instigated). The index document can then be edited before returning to the previous location (using backtrack). The "make index" can specify an existing (index) document, in which case the list is added to the existing document.

NAVIGATION METHODS (of hyperspace)

Scroll up/down document, Page up/down document

Skip to next Button, Jump to linked document, Go to selected document

Find text match and jump, Go to top of Hyperbase

Quit this Hyperbase, Open new Hyperbase, Go back to previous Hyperbase

Display history data for this document

Display list of documents that link to this document, and allow jump to selected one (This is a where used list)

Display tree of documents that this document links to, and allow selected jump (This is a dependency list)

Maybe all these lists should be created as a Hbase document, and linked into a button inserted in the current doc. Each document name in the list could then be a button to that document, so the user could create his own 'navigation pages'.

HYPERBASE STATISTICS

History - list of documents in date order

Tree - documents and links (/types)

LINK TYPES - PROTECTION / SECURITY

Link types already identified are:

Null link

Local link to (top of) other document

Local link to within other document

Link to document within other Hyperbase

Link to Application with data file

Link to ASCII text file

In addition, for each link there is a protection code:

Read access only, or Read / Write access

This could be used for network access: if current active users have read access, then another network user can get write access. Each link could have a Date/Time stamp for last access - could be useful for finding out if links are actually any use. Each Document can have a Date/Time stamp for creation/edit - I'm not sure why, but it sounds a safe thing to do. Could get a History of the Hyperbase in chronological order.

CONTEXT DOMAINS (High level separation - or horizontal ?)

The vague idea behind this is that the user might find it useful to have a broad brush distinction between classes of data that he is pumping into his hyperbase. For example, he might want to separate then into HOME, OFFICE.

Of course, there might be some overlap, or he might want to move data from one category to the other.

So why not have a 'Desk Top' top level document with home and office buttons, which link into the various documents beneath them ?

Well, we could make the context domain act as a filter, separating out data in a 'horizontal' manner. This could simplify hyperbase navigation. Data could 'belong' to one or more contexts. Buttons to documents not relevant to the current context would be hidden.

I dunno, maybe its just an added complication. On the other hand, users who didn't want to use context would hardly know it was there - all data would be under a global default context. If the user wants to, he can define a current context, then anything added is in that context, and only links belonging to that context (or global context) would be shown. He could switch to another context, or return to global context.

Another use for Context Domains would be to separate one Hyperbase into a number of User Groups - each group would use one domain, and the Global domain would be accessible to all.

LINKS TO OTHER HYPERBASES

Whats this all about? Well, suppose two or more users (or even one user) have created Hyperbases using HB. Then they may think - Hey what a good idea if I could put a button in my Hbase and link to document(s) in this other Hbase.

What happens if document is deleted by other user ? Well, he could be warned (this doc is referenced elsewhere. Attempts to access it get a 'Sorry, no longer there' message.

This actually raises the whole issue of access / protection for external links. Access rights will be treated as per local rights. External links will always be 'read only' - so obviously no deletion of linked files. Absence of files will always give the user the option of looking elsewhere (other directory, disc, network).

Note: hbase files will carry identification (version etc.) naturally!

INTERFACE TO OTHER APPLICATIONS

Have 'launch' links/buttons which load application/data.

Why ? - Well, we might want to link in something which cant be handled by HB, maybe a circuit diagram, maybe a spreadsheet. So the button could in effect say 'load Lotus 123 with MSALES (.WK1), and return here on exit from (Lotus).' Hey, not bad when you think of it. Also, could use as a gateway to a DOS shell (just have DOS as a launch button).

We could also allow links to plain ASCII files, so they could be 'embedded' in the Hyperbase and viewed (and edited ?), but no buttons could be inserted. This is quite a nice facility, since it would save space for including standard info (e.g. network notices, on line user manuals).

There is a time (and space) penalty for linking in applications, but it extends the power of HB into areas that it couldn't possibly cope with. For example, it would be nice to have a built in 'Viewer' like 'Magellan' or 'Norton Commander', but this is a lot of work. So why not let them do the work for you

USER INTERFACE

Its very tempting to specify multiple windows for a Hyper application, since you can then stack windows on each other, each one relating to a 'level' in the hyperspace. This can help with the problem of 'getting lost', since it shows the path you have taken to get somewhere

In addition, we need some mechanism for helping the user if he's lost, and wants to see the path he's taken to get where he is.

This could take the form of an 'audit trail' showing each document visited, or possibly a display of the hyperbase tree, with the path taken highlighted. I think this needs some experimentation. I'm not convinced these ideas are actually all that useful. So long as the user can backtrack, jump to 'home', or jump to some other place selected by document name/number, or a text search, then this may be enough.

Backtracking needs some thought. Is it actually useful to be able to backtrack indefinitely ? (i.e. to all previous locations in the hyperbase in this session). If the user has got lost and returned to home for another excursion, is it useful to backtrack past the last home. Well, maybe it is. A common problem is the 'I've seen that before recently, now where was it' syndrome. Where it was maybe before the last home, and anyway, making backtrack work for the whole of the session is no more difficult than making it work to the last home or something

I think the user should be able to go forward thro the stack as well as backward (without adding to the stack.

Another possibility is the "mark here" and "return to mark" type of jumping - you can have a list of marks. I don't like this much - it just gets confusing, and after all, why not make buttons if its worth keeping, or use text search if its not.