View source for Format policy registry requirements

=Legacy FPR foundation docs=

[[File:FPR overview Oct 2012.png|border|900px|FPR overview Oct 2012]]


* developer [[Format_policy_registry|notes]]

== Mockups ==

'''Preservation Planning tab in Dashboard - Local FPR'''

[[File:1.0_PreservationPlanningFPR.png|Preservation Planning tab in dashboard]]

------------------------------------------------------------------------------------------------------

* Archivematica format ID column is populated by the "description" from the File ID table in the Archivematica database; It links to the file ID table in the Archivematica database, which is composed of the tool and tool version that identified the format.
* Command description is the "description" from the Command table in the Archivematica database
* Purpose is the same as "classification" in the Archivematica database, but is clearer to the user
* Add new -links to create new (blank) form for Archivematica format ID -or- to the create new (blank) form for the Command
* Copy - links to create new form based on this one (populated with current data) for either the Archivematica format ID -or- Command
* Edit -links to edit page for the Archivematica format ID -or- to the edit page for the Command
* Make default - makes the selected Archivematica format ID format policy or the selected Command format policy default for normalization. See Feature #4503
* Show performance and show command are modeled on the old preservation planning tab in the dashboard, available in the dev version of Archivematica at /preservationplanning/old/
'''Add new Archivematica format ID'''

[[File:1.0_FormatPolicyFormatID.png]]
--------------------------------------------------------------------------------------------------------------
'''Add new Command'''

[[File:1.0_FormatPolicyCommand.png]]

* Added https://projects.artefactual.com/issues/4568 (#4568) to add a Output file format field to this form from the outputFileFormat field in the MCP Commands table 
-------------------------------------------------------------------------------------------------------------------
'''Copy Archivematica format ID'''

[[File:1.0_FormatPolicyFormatIDCOPY.png]]
------------------------------------------------------------------------------------------------------------------
'''Copy Command'''

[[File:1.0_FormatPolicyCommandCOPY.png]]

== Data Model ==
Design from summer 2013 of the data structures in version 2 of the API.

[[File:Fpr design-2013-07-25.png|900px]]

Updated design as of March 2017

[[File:Fpr-design-2017-03.png|900px]]

== Workflow == 

== GUI ==

== API ==

== Proposed Changes ==

=== Replace VersionedModel with set of associated rules ===

January 2014

'''Summary:''' Replace the VersionedModel structure of a linear history of revisions with a collection/set of rules all associated with some 'meta-rule'.

'''Bug:'''#6192

'''Problem:'''
Currently, we track a linear history of rule modifications.  A newly modified rule is always added to the end of the chain, even if it modified an earlier rule.  All rules in the chain must be kept. Example: A <- B (enabled).  A is modified, resulting in C with history of: A <- B <- C (enabled)  B cannot be disabled, even if it never used (eg had a typo)

We need to track variations on a rule that is fundamentally the same, but not necessarily a linear version history. With a linear history, the true relationship between a rule and where it originated from is unclear, and a version history of any sort for the rules is probably unnecessary - all we care about is the currently active rule (and any newly downloaded rules that are candidates for replacing it).  The linear history also complicates things when modifications are coming from several sources (eg. Artefactual, various institutions, local modifications)

'''Proposed fix:'''
Each rule stores an Agent (the institution/person that created it) and a 'meta-rule' ID, and no longer stores what rule it replaced.   All rules that are variations on each other have the same 'meta-rule' ID and are 'rule versions'.  Potentially the meta-rule ID is a foreign key to an actual meta-rule table, but that may not be necessary.

In a set of rule versions, only one may be enabled at a time.  Rule versions can come from several sources - originally installed and FPR updates from Artefactual, downloads from a particular institution that is reputable, a local FPR server - and are conceptually linked by having a common meta-rule ID.  Agent IDs will be used to distinguish the sources, and created time used to track the most recent variation.

'''Pros:'''
* Easier to download updates to FPR rules, especially from more than one source
* Can provide the ability to delete truly unwanted rules
* ???

'''Cons:'''
* What information to display to the user? What to display if all the rule versions for a meta-rule are disabled?
* Probably backwards incompatible, or non-trivial to make it
* ???

==Early prototype==

*An early FPR prototype (called "Formatica") was developed by Heather Bowden, then Carolina Digital Curation Doctoral Fellow at the School of Information and Library Science in the University of North Carolina at Chapel Hill. 

[[File:Formatica.png|border|450px|Early FPR prototype originally called Formatica]]




[[Category:Development documentation]] 
[[Category:Feature requirements]]