[Sigia-l] The 3 Factors of I/A

[John O'Donovan]

> On the web, however, (and on these mailing lists) i've seen a lot of
> examples and disscusion about grouping based on Content Similarity and not
> much based on grouping by User Task and I wondered if anyone else was
> doing some User Task driven work?
>
>  - Richard Dalton
>

Most application design and systems analysis has a very significant focus
around tasks. Content Similarity means nothing without context as has been
said here earlier, so I would step back a level and take a data modelling
approach which asks:

- What data or things do I need to know about or store information about?
- What information do I need to store about these things?
- What are the relationships between this data?
- What do I want to do with this data?

In entity data modelling relationships can be the key. You might think of
them as Facets but I think that is just re-inventing the wheel. I'm not just
talking about normalisation because relationships are semantic context
linking tables or objects in a database - linking tables, if you like
[technically how you do this all depends on what type of database and
modelling you are doing but I won't enter that discussion here...].

Relationships are just a combination of fields, links and data about those
links but in many cases relationships provide the context that turns raw
data into information relevant to the user, and it requires both data and
relationships to make up a data model

You can have different relationships that represent different things and
context is the key to deciding which relationships to create. In software
design the context usually comes from what tasks the user is able to do and
the data model is built to support this, for example:

- Identify what users want to do (goals)
- Identify what you want them to be able to do (features or business goals)
- What data do they need to do this (your data)
- What are the relationships between the data to support the tasks (your
applied context)

This is a gross over simplification of years of methodologies and data
design (forgive me those giants of thought upon whose shoulders I stand) but
the point is that even if you need to understand many relationships between
data to turn it into useful information, there will be a priority in these
relationships based on what context the user is looking in.

When presenting on searching metadata and Archives to a client, I once wrote
in a presentation that:

"Content is King" (but only if you can find the damn content!)

Maybe this makes "Context" King? Or maybe it's time for a queen?

Cheers,

jod