120 likes | 261 Views
Authenticity Capture Prototype. Matt Dunckley, STFC. Why we need tools. Demonstrable Authenticity Trustworthiness (Implies Quality) Need to capture all information deemed necessary to make an informed judgement as to the authenticity
E N D
Authenticity Capture Prototype Matt Dunckley, STFC
Why we need tools • Demonstrable Authenticity • Trustworthiness (Implies Quality) • Need to capture all information deemed necessary to make an informed judgement as to the authenticity • Provide a customisable and flexible mechanism to define what is the important PDI that needs capturing • Design is based on the Authenticity Model, which provides a standard process and framework
Authenticity Model • Framework to record pertinent information using standard terminology • Events – Capture information about an Event of importance • Protocols – Executed in response to an event occurring • Steps – Details information to capture for the event • AuthProtocolExecutionReport – Result of execution used by community member to make a judgement
Nature of the Tool • Keeping it simple to start with • GUI tool • Capture mainly textual information (Evidence) when events occur • Consistent and Standard user experience to perform capture • Where possible allow automated capture through plug-ins & external tools
User Roles – Use Cases • Project Creator/Administrator • Sets up an Authenticity project - providing detailed project information - reasons, objectives, ie. the business case • Imports the projects Authenticity model, an XML ‘protocol’ document based on Authenticity Model • Authenticity Information Capturer • Registers to Project • Edit/Add User Profile Information i.e credentials, details of their role, qualifications, affiliations, accreditations. • Creates and instance of a project, i.e for a particular digital object • Follows authenticity protocols / steps a procedure to capturing the specified information for each step • Sign off Capture as complete • Researcher/Consumer / All users • Can search for authenticity information by project • Can browse the holdings • Export Captured information in various formats
Digests • At each information capture point a digest of the information is recorded • At the point of sign-off a digest of all captured information is recorded • Example of information captured for Ionosonde station Location <capture capturer="us01" confidence="85" dateTime="09-09-2009 15:09:36" hashAlorithum="md5“ hashValue="7a1e512cef9cfd93af44832749200cc2“ pdiID="Ionosonde-01_step1_pdi2" pdiValue="BUDAPEST - HUNGARY Geographic Latitude (WGS-84) 47.00°N Geographic Longitude (WGS-84) 19.00°E Magnetic Latitude (IGRF-10(2005) 45.93°N Magnetic Longitude (IGRF-10(2005)) 101.33°E“ projectID="Ionosonde" stepID="Ionosonde-01_step1" timestamp="1252507896"/>
XML Protocol Document • Defined by XML Schema – Based on Authenticity Model
Case Study • Applied Auth Model - Ionosonde WDC, STFC • To allow us to design of the Auth Protocols • 1st Statement of policy (Authenticity Recommendation) by which we can measure if we have captured enough evidence “Record all PDI necessary to verify the authenticity and quality of received data files for long term archival within the WDC” • 2nd Identify Events • Ingestion of raw data files in varying formats • Transformation of received data files into IIWG format • Final validation and archival of IIWG file within WDC • 3rd Design Protocols and steps
Ingestion Protocol • Ingestion of raw data files in varying formats • Recommendation (Policy) “In order for this digital data to be accepted as Ionosonde data of sufficient quality the reliability of its source must be verified and recorded by a WDC accredited archivist” • Steps will capture • Source of dataset • Evidence that this is indeed the source • Archivist name and details • Ideally some form of credentials would be attached
Transformation Protocol • Transformation of received data files into IIWG format • Recommendation (Policy) “For the received data file to be deemed as sufficient quality to support data analysis it must have been successfully transformed into standard IIWG data format, the use of processing software must be recorded” • Steps will capture • Details of transformation used • Software details including name, version, source • Time/date of process • System details • Details of person responsible • Reason for believing this software is reliable • Details of Transformational Information Properties checked • Information Property descriptions • Values checked • Details of how checked • Details of who was responsible for the check
Archival Protocol • Final validation and archival of IIWG file within WDC • Recommendation (Criteria) “Successful validation of the IIWG structure and syntax must be achieved and recorded before long term archival can take place” • Steps will capture • Details of validation process • Details of checks performed • Details of person responsible • Details of transfer to storage • Details of person responsible • Checks performed on transfer e.g. Fixity checks • Details of archive and storage system • Date/time of transfer