Object updating and rule resolving

Overall goals

• Check if an object already exists in the repository, during non-update ingest.
• Improve the ingest package to handle updating of existing objects.
• Prepare the ingest package for object validation, by resolving rules from the repository.

Measurable goal

A new test-package that is to be ingested before one of the existing test-packages. The new test-package should fail, as one of its objects was already ingested by the previous package.

A sample update object, which is an update of one of the objects from the other test-object packages. The content of the new object should replace the old one.

An output of a specific datastream (probably just DC) from all the rules coupled to a sample object. This includes rules referenced by other rules (graph traversal).

Estimated time allocation

2 man-days for the object update code, including testing of object existence.

2 man-days for rule resolving.

Deadline for product: Thursday january 4. 2007.

Postponed tasks (fourth ingest iteration?)

• Validation rules (given the object specification)
• Actual validation as part of ingest
• Example invalid objects for testing

Update

The goal

• Improve the ingest package to handle updating of existing objects.

has been postponed to next iteration, as Fedora does not support this out of the box. We need to consider the implications of either replacing existing objects (and thereby loosing a lot of information) or performing a diff and update the changed parts of the object.

Notes on rule resolving

There will normally be more than one rule belonging to each digital object. This is normally through indirection: The object will point to a single type, which will contain one or more rules, as well as pointing to other types with rules.

The rules are at this stage undefined. Returning an array with the content of a specific datastream from the rule objects is the goal.