This means that specific workflows etc. are provided by specific applications on top on a fairly unconstrained database model. Likewise, as the use of the underlying database primarily is an optimization of the implementation, it is possible to support distributed data repositories by virtue of the Web.
For example, the Web Characterization request tracking system is an HTML forms based request tracking application. In the following, we describe the basic ETA concepts:
Forums are organized in a news group manner where each forum can contain a set of issues and/or one or more sub fora. However, this does not mean that this is the only way to relate issues - there can be arbitrary relationships between any issues as well as between any other document on the Web.
Schemas are used to define the set of (if any) types, states, and urgency modes an issue within a specific forum can be in. Sub-fora does not have to (although they can) inherit schema information from their parent forum.
All issues are assigned a URI which can be linked to from any other document on the Web.
An issues can have events associated with it to signify issue state transitions, oriority changes, owner assignment, etc. that either have occured or are planned to occur some time in the future. Events are associated with a status so that it is clear whether it has been triggered or not.
Any two documents on the Web can be related - and in the same manner ETA issues can be related with anything else. You can specify how issues relate using ETA relationships.
A contact is a person or a group having that ETA knows about. Contacts can create issues and they can also help resolving issues if they have the skills needed. The issue 'creator' and 'owner' are two default relationships between contacts and issues - other relationships can be registered as any other relationship as the identifier of a contact is a URI (often an email address so that we can handle email based notifications).
Contacts (either a single person or a group) can have certain skills that make them capable of resolving issues or simply because they are interested in certain issues, or specifc categories or priorities in a forum. Skills are associated with a forum (and therefore implicitly a schema) - that is, a contact can have different skills for different fora.
The skills are used as the filter for figuring out when contacts should be notified about changes in the database. Contacts can "listen" to all issues in a forum of any particular category, priority, etc. but can also listen to a single issue (for example the one they have created).
The database layer is very small. For now we only have a very simple set of functions on top of it. You can also have a look at our database layout.
Currently there is no implementation of the ETA application layer - this is expected to happen as more and more applications start using the underlying data model and find enough similarities to abstract out the needed functionality into separate application layers.
The application that we have so far is a Web Characterization request tracking system which is used to track user questions about the Web in the Web Characterization Activity. Here we use the features of the ETA datamodel in the following way:
It is (or should) be possible to use many different user interface paradigms together with ETA. Although we haven't tried this yet, it should be possible to add issues automatically and have complete sets of work flow models layed out as a function of some event occurring etc.