InSPECT Significant Properties Framework (SPs part 2), by Stephen Grace and Gareth Knight
Upcoming SlideShare
Loading in...5
×
 

InSPECT Significant Properties Framework (SPs part 2), by Stephen Grace and Gareth Knight

on

  • 548 views

This presentation, the second of six parts on the practical analysis of significant properties of digital objects, considers the framework produced by the InSPECT project for assessing significant ...

This presentation, the second of six parts on the practical analysis of significant properties of digital objects, considers the framework produced by the InSPECT project for assessing significant properties. The presentation was given as part of module 3 of a 5-module course on digital preservation tools for repository managers, presented by the JISC KeepIt project. For more on this and other presentations in this course look for the tag 'KeepIt course' in the project blog http://blogs.ecs.soton.ac.uk/keepit/

Statistics

Views

Total Views
548
Views on SlideShare
546
Embed Views
2

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Bicycle Pathway

InSPECT Significant Properties Framework (SPs part 2), by Stephen Grace and Gareth Knight InSPECT Significant Properties Framework (SPs part 2), by Stephen Grace and Gareth Knight Presentation Transcript

  • InSPECT Significant Properties Framework
  • Overview
    • Changing notions of value
    • Assessment framework requirement
    • Design methods as a basis for assessment of digital objects
    • InSPECT Analysis framework
    • Concluding thoughts
  • What is significant about the digital object?
    • How do you distinguish between essential, useful and superfluous?
    • Impractical to present a single, definitive interpretation of significance
      • Many stakeholders may be associated with an object
      • Stakeholders vary and change over time
      • Each stakeholder is different in their needs and knowledge base
  • Framework for determining significance
      • Formal framework required to guide process of identifying, analysing and recording elements of the Information Object that are essential/beneficial to maintain over time.
      • Assessment framework should be rational, consistent in its application, while offering sufficient flexibility.
      • Previous work performed in field, such as Rothenberg & Bikson’s Needs Analysis, InterPARES1 Diplomatics model & PLANETS Utility Analysis methodologies.
  • The (other) theory of relativity
      • Need to adopt a relativistic approach to determine aspects that are essential/beneficial based upon an interpretation of acceptable loss
      • Builds upon two philosophical approaches:
        • Teleology: study of design and purpose of object – why was it created?
        • Epistemology: Understand meaning and process by which knowledge is acquired
      • In combination, these encourage the evaluator to determine the context of creation (purpose created for, how it was created, etc.) and information necessary to communicate intrinsic knowledge to a new audience (designated community)
  • InSPECT SP Assessment Framework
    • Builds on Gero’s Function-Behaviour-Structure framework
    • FBS developed to assist engineers/designers to create & redesign artefacts
    • Three categories:
      • Function: The design intention or purpose that is performed.
      • Behaviour: The epistemological outcome derived from the function & structure obtained by the stakeholder
      • Structure: The structural elements of the Object that enables stakeholder to perform behaviour.
    • Artefact construction is product of designated function.
    • Behaviour is result of interaction between Function & Structure
  • Re-engineering the bicycle http://www.flickr.com/photos/huggerindustries/3885401876/ Attribution-Non-Commercial-Share Alike 2.0 Generic http://www.flickr.com/photos/mvjantzen/4113615243/ Attribution-Non-Commercial 2.0 Generic
  • Mapping FBS stages to DCC lifecycle model
  • Stages of assessment
    • Requirements Analysis
      • Object Analysis: Analyse representative sample of an object type, identifies a set of functions and behaviours that may be achieved, and the properties that are necessary for their performance.
      • Stakeholder Analysis: The evaluator identifies one or more stakeholders that have some relationship with the Information Object and analyses the functions that they wish to perform.
    • Re-formulation
      • Redevelopment of artefact to perform a revised set of functions or enable different behaviours suitable for Designated Community.
      • E.g. OAIS Archival/Dissemination Information Package
  • Analysis & re-formulation over time
  • 1. Object Analysis
    • Purpose:
      • Identify and analyse technical properties of digital objects
      • Associate properties with expected behaviours
    • Requirements:
      • Representative sample of objects
      • Tech. specifications or standards for composition of the object
      • Adequate characterisation tools
  • 1.1 Select object type for analysis
    • Not undertaken for a single object!
    • High-level object type (such as raster images, audio recordings)
    • Sub-type that contain specific characteristics
  • 1.2 Analyse structure
    • Obtain a complete list of technical properties via
    • Characterisation tool
    • Technical specifications or standards
    • The objective of the task is to develop an understanding of the type of technical properties and value types that are contained within the object type
  • 1.3 Identify purpose of technical properties
    • What role does the property perform in the Data Object?
    • Record the values for properties that contribute to the recreation of the Information Object
    • Classify into categories
  • 1.3 cont. Categories of properties
    • Five high-level categories
    • Content e.g. character count
    • Context e.g. date of creation
    • Rendering e.g. bit depth
    • Structure e.g. e-mail attachments
    • Behaviour e.g. hyperlinks
  • 1.4 Determine expected behaviours
    • Consider the different types of activities that a user – any type of user – may wish to perform
    • Recall original purpose, but don’t be limited by that
  • 1.5 Classify behaviours into functions
    • Group together similar behaviours into functions
  • 1.6 Associate properties with each function
    • Link the technical properties from 1.2 with the functions
    • This links the Data Object – evidenced by its technical properties – with the Information Object
  • 1.7 Review and finalise
    • Are there any other behaviours that may be exhibited?
    • Can any of the functions be decomposed into more accurate functions?
    • Are there any other properties that should be associated with a function?
  • 2. Stakeholder Analysis
    • Purpose:
      • Identify stakeholders that associate with object type and determine set of functions that they require.
      • Stakeholder functions is subsequently cross-matched to Object functions and Object may be re-formulated
    • Requirements:
      • An understanding of the stakeholder that is the target of analysis
      • Access to stakeholder representatives with whom you can discuss your conclusions.
  • 2.1. Identify Stakeholder(s)
    • Identify stakeholder category to be analysis target and obtain their co-operation
    • Stakeholders classes and sub-classes:
      • E.g. students, academic researchers, artists, legal compliance department
      • Operating in specific environments, e.g. students in Access Grid environment,
    • Information sources
      • Policies, procedures, legal documents
  • 2.2. Select object type to analyse
    • Select object type used by a stakeholder
    • Possible targets:
      • High-level object type (raster image, audio recording, e-mail)
      • Object sub-types (standalone email, threaded email, vocal recording, music recording with metadata)
    • Basis for decision:
      • Consider practicality of identifying object types using machine processing
  • 2.3. Determine actual behaviours
    • Determine activities that stakeholder will likely perform when using object type
    • Actual behaviours may represent subset of expected behaviour or previously unrecognised behaviours
    • Things to consider:
      • Knowledge base of user, expertise
    • Information gathering techniques:
      • Questionnaires, interviews, observational study
    • Example behaviours:
      • Listen to audio recording, determine recording duration, Identify context of creation, Identify recipients
  • 2.4 Classify behaviours into function set
    • Classify behaviours into function set that derivatives should perform.
      • Function refers to a specific design intent.
      • Many activities can be grouped into one overall function
      • May use Object Analysis function list as a starting point.
      • Potential for new functions to be identified as result of actual behaviour – something that was not previously recognised or need for new functionality
  • 2.5. Cross-match functions
    • Identify tech properties required to perform stakeholder functions.
    • Match stakeholder functions to functions supported by Object type
    • Likely to include core functionality (e.g. display image) and optional extras
  • 2.6. Assign acceptable value boundaries
    • Determine quality threshold of derivatives
      • ‘ Exact’ or good enough? (acceptable loss)
    • Measurement:
      • Equality /Minimum/Maximum/Range
    • Useful in situations where infeasible to maintain all aspects of artefact / greater variance allow
      • E.g. compact disc Vs. streaming audio
    • Change in quality measurement != quality reduction
      • 44.1kHz audio versus 96kHz
    • Depend upon object sub-type & stakeholder
      • E.g. opera Vs. pop music
  • 2.7. Review and Finalise
    • Review gathered information and extend/revise if necessary.
    • Have any object properties been ignored?
    • Are there other stakeholder behaviours?
    • Could behaviours be decomposed into two or more behaviours?
      • E.g. Establish provenance could be split into identify creator, identify creation environment, identify creation date
  • 3. Reformulation
    • Re-develop artefact to perform a revised set of functions /enable diff. behaviours (e.g. archive, dissemination)
  • Summary
    • Appraisal process required to identify aspects of digital object that are essential.
    • Significance is fluid – variable and subject to change
    • Analysis of functional requirements is pragmatic method for identifying ‘must have’ features
    • Design method approach provides vocabulary and framework for understanding design process.