Action View Datastream

Assigned

ABR+KFC

Prev assigned

Tasks adressed

["TaskB.2"],["TaskB.1"]

Time estimated

2md

Time used

0md

Priority

6

Status

Described, lacks review

Iteration

13

Notes

The Problem

The current system is described here: FedoraViewBlobs

There is one major outstanding issue with the technological foundation of the DOMS data model. For many purposes, it is useful to regard a number of objects as a combined whole. There are a number of ways to specify this.

In the following, the combination of data from a number of objects will be called the blob.

In the content models, we have a reserved datastream, called VIEW. VIEW lists the the datastreams from this object to include in the blob, and the relations to be followed from this object to find other objects to include in the blob. Some objects are main objects. To make a blob, you begin from a main object, and follow the listed relations, until there are no more to follow.

This has the nice feature of having the combined whole defined in the content models. No individual object can redefine how it's view looks.

The blobs visible from different angles (interfaces to the system) might not be identical. The blobs used as basis for the gui will probably not be the blobs harvested by a search engine and so on.

The problem arise when performing changes to objects. When an object is changed, by some generic means, the contents of every blob that this object belongs to, should be updated. So, there must be a way to get from an object to the main object, so that the blob can be recomputed. Unfortunately, this is not possible with the above implementation.

There are two trivial solutions.

1. There are just one kind of blobs, so that the gui and all other tools operate on the same blobs. Changes are ever only performed through a system that read in the entire blob, and so know the main object when performing the change.
2. There is no dynamical update of the blobs. The entire set of blobs is recomputed from time to time.

The second is not possible, with the interface we would like to the Summa Search System. The first have the disadvantage that all tools we use must understand the concept of the blob and the VIEW datastream.

There is a more advanced solution available as well.

1. The view datastream only lists the local datastreams to include. There are no main objects. For each blob, there exist a special aggregate object, that has a "aggregates" relation to each object in the blob. Whenever an object is changed, the aggregate object is notified, so that the blob can be recomputed.

This solution has both advantages and disadvantages. An advantage is that we can automate the blob update, so that all changes to objects notify the aggregate objects automatically, and tools do not need to understand the blob idea. The disadvantage is that we introduce new objects, which perform some of the same tasks as the old main objects. And objects which are not aggregated will not be visible to any blob-enabled tool. It does change the concepts about how to make a new object.

It will make search easier, as the search should only search in the dissemination output of the aggregation objects, which will all be of a particular type. The search output disseminator should be on the aggregation object.

The aggregation type should probably be subclassed for each of the collections, to help define the main objects.

Note: This has been heavily inspired by the OAI-ORE model for ressource maps. Look at their primer LINK.

Making a new object

The process for making a new object, with templates will be the following.

1. A new aggregation object is made, empty, but with the title of the blob, if any. The aggregation object is of the kind special to the collection, if any, or just a generic aggregation.
2. If the aggragation is subclassed, it specifies a content model for the first object. If not, one must be selected.
3. When the content model for the first object is selected, find the prototypes for objects of this content model. Make a new object from these.
4. Based on the main object ontology and contents make the other objects it should relate to.
5. Write the data objects to the repository
6. Make the aggregation object with relations to each of the objects you made. Write this object to the repository.

Progress

Conclusion

Checklist For Working On An Action

The Life Cycle of an Action:

• Assign people for action definition: Done at start of iteration status meeting. Fill out Assigned

• Define the action: Describe information about what is to be done and how. Fill out Tasks Addressed and Time Estimated.

• Review the definition: Get another project group member to review the action definition, and update it.

• Assign people for action implementation: Done by project manager, usually the same persons who wrote the definition. Fill out Assigned and Prev assigned if new persons are assigned.

• Implement the action: See details below

• Review the action: Get another project group member to review what is implemented (code and documentation), and update it.

• Finish the action: Change the status to "Finished" and update the "time used" field on the action page.

Please make sure that you address the below issues, when working on an action:

• Update the state of the action to "In Progress" when you start working on it.
• Check if the tasks addressed by this action have their status set to "In Progress". If that is not the case, then change the state of them.

• Keep track of how much time that has been spent working on the action. If it addresses more than one task, then make a note on the action page about how much of the elapsed time that has been spent on the individual tasks. Hint: Continually updating the "Time used" field will make it easier for you.

• Update the "Progress History" and documentation pages of each task addressed by this action when appropriate. This depends on the situation, but in general, the task pages should hold all important related information about the work done, experiences gathered, identified requirements and so on.