[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Metadata, interfaces and databases
There must be a better interface for the knowledge workers who provides
metadata.
Most metadata entry applications tend to be database centric. The focus of
the application is on the actual entry of data. The user is forced to fill
in a lot of little boxes, select items out of lists, press the 'Save'
button, move to the next screen, and so on. Sound familiar?
In actual fact most people are unfamiliar, and uncomfortable, with the
whole concept of a database and the associated applications. Remember
database applications are mostly used in form processing type tasks - great
for financial and human resource applications - but of little interest to
knowledge workers. A KW presented with a bunch of fields to fill in is
just reminded of that tax return they haven't completed yet.
And why do we constrain ourselves to a specific number of characters in
describing a particular attribute? Is it because databases require fields
with defined lengths? Users should not be concerned with requirements
imposed by the database. Database applications, therefore, tend to reflect
physical database characteristics rather than the requirements of the
people who use the tool.
The current approach is to enter data (or is that metadata?) into a
database and then to generate a document to be to be searched or browsed.
Why not take the reverse approach? Why not create a document, structure it
(using something like HTML), and put the result in the repository? A new
type of application is required however, one which looks to the knowledge
worker like a word processor with structure added by applying styles to
text (sounds like Word to me). Then you could have the ANZLIC style sheet,
or heaven forbid the FGDC style sheet. The application would then know how
to interpret the styles and populate the repository.
----------------------------------------------------------------------------
--------------
Shawn Callahan and Brent Heuer