ICA-ISDF

Design	This page proposes a new feature and reviews design options
Development	This page describes a feature that is currently in development
Documentation	This page documents an existing feature

[edit] Requirements

Implement data-entry and display support for the fields in the ICA-ISDF standard for describing functions.

provide the ability to link authority records describing corporate bodies, persons or families with descriptions of functions (and vice-versa)

provide the ability to link descriptions of functions with descriptions of archival material (and vice-versa)

The editIsdf and showIsdf templates should be based directly on editIsaar and showIsaar
The editIsad form will need to have a seperate 'Functions' div added (above 'Access Points')
The editIsaar form will need to have a seperate 'Related Functions' added (below 'Related Resource')
One UI challendge is where to fit 'Functions' in the main menu
- Probably easiest to move 'Recent Updates' back under the 'Admin' tab and use the space to add 'Functions' menu option after 'Terms' on the 'Add/Edit' menu
  - 'Recent Updates' should probably be integrated/combined into a UI (i.e. list view) for publication workflow

use the Qubit Function object which already exists as a placeholder in the Qubit schema. However, it needs to be completely revamped. It should no longer extend the Term object. Instead it should copy the Actor object and all its fields/relations where applicable. The QubitFunction object should become a core object itself (extending QubitObject rather than QubitTerm).
- It should eventually use NestedSet for hierarchical relations with other functions, however, for the 1st implementation it should just implement the ICA-ISDF standard verbatim, which includes documenting relationships but not necessarily inferring additional UI controls (i.e. treeview) for those (until further discussed with Steering Committee and feedback from beta testers) -- this can pretty much copy the ICA-ISAAR Relationships implementation
using the Event object to connect related Functions with Actors or InformationObjects may be too academic given the simple implementation examples given in the ICA-ISDF standard (see Section 6 examples). Therefore, the Relation object should be used where the ID of the QubitFunction is always the Object and the ID of either the Actor object or the InformationObject is the subject in the relationship. That Subject ID can then be used to see if getClass() == "Actor" or "InformationObject" and show the appropriate Symfony component slot accordingly (i.e. _relatedInformationObject or _relatedActor)