Skip to end of metadata
Go to start of metadata
Determine render-ability of displayable web objects
Detailed description To make a digital object render-able depends on standards, agreements, and understandings in interfaces and hardware, and there are strong interdependencies between these conditions. Because of these technical dependencies, the content of the web archive might not be render-able.
Generally, in order to preserver web content, it is required to be aware of new hardware expectations that arise. For example, as WebGL becomes standard, then a 3D accelerator card will probably be required for some site. Or, if multi-touch gets added to the standard, there is a dependency on having having multi-touch hardware, etc.
Scalability Challenge

Issue champion Maureen Pennock (BL)
Other interested parties
SB: <comment_missing>
KB: Low priority. This approach might be of help to improve tools for identification (scenario 1).
ONB: Would be interesting, but low priority
BL: <comment_missing>
Possible Solution approaches
  • BL:
    • One idea would be to apply a brute force approach where simply every file is passed through every renderer that is available, in order to check if the renderer can technically execute the object. If the process fails, then it can serve at least as an indicator for some difficulties with that data that require a closer look.
  • EXL:
    • I'm not clear as to how we could know if a file was rendered correctly. An application can open a file successfully but the contents might not be what we expect.
    • Mapping between formats and possible renders can be established, so not all renderers must be tested. It is not clear how to detect correct renderer automatically, the process may not fail, but the rendering can be incorrect.
  • KEEPS:
    • Watch can contribute to the solutions with the triggers:
      • Monitor new browsers, browser versions, browser plugins, or use trends
      • Monitor changes in standards (e.g. new web standards)
      • Monitor changes in standard adoption by different browsers and browser versions (e.g. Acid3)
      • Monitor agreements and understandings in interfaces and hardware (?)
      • Monitor new renderers, to be added to the brute-force tests
Lessons Learned Notes on Lessons Learned from tackling this Issue that might be useful to inform the development of Future Additional Best Practices, Task 8 (SCAPE TU.WP.1 Dissemination and Promotion of Best Practices)
Training Needs Is there a need for providing training for the Solution(s) associated with this Issue? Notes added here will provide guidance to the SCAPE TU.WP.3 Sustainability WP.


Objectives Which scape objectives does this issues and a future solution relate to? e.g. scaleability, rubustness, reliability, coverage, preciseness, automation
Success criteria Describe the success criteria for solving this issue - what are you able to do? - what does the world look like?
Automatic measures What automated measures would you like the solution to give to evaluate the solution for this specific issue? which measures are important?
If possible specify very specific measures and your goal - e.g.
 * process 50 documents per second
 * handle 80Gb files without crashing
 * identify 99.5% of the content correctly
Manual assessment Apart from automated measures that you would like to get do you foresee any necessary manual assessment to evaluate the solution of this issue?
If possible specify measures and your goal - e.g.
 * Solution installable with basic linux system administration skills
 * User interface understandable by non developer curators
Actual evaluations links to acutual evaluations of this Issue/Scenario
webarchive webarchive Delete
characterisation characterisation Delete
issue issue Delete
obsolescence obsolescence Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.