Faces Scope

FACES Scope · Functionalities Disclaimer and Copyright Support Application Profiles Release Agreement Specification: Browse and Display · Search Albums · Users Note Pads · Versioning Related Projects: Imeji edit

Planning

The prototype of Faces will be developed in several steps (releases). In each release, the following functionalities will be implemented.

R1

• Login /Logout
• Display
• Browsing
• Search
• Metadata Sets

Functional Prototype for R1

R2

• Enhancement of the search (age group search functionality, search within an public album)
• Public (published) albums
• Selection of Pictures (adding)
• Multiple sorting
• Export
• Help functionality (linking between the help icons "?" within the application and the help page)

Functional Prototype for R2

R3

Going productive!

• User Management (Basic, via Admin solution)
• Basic statistics
• Extraction (via jhove) and saving (in a separate metadata file) of technical metadata
• Display of technical MD
• Revision of Help (texts)
• New Home Page for Faces (no special Faces logo, only the MPIB logo)
• Integration of a blog for the creation of a news box on the start page

Functional Prototype for R3

R3.2

Virtual release! - prepare FACES for a generic usage

• Surrogate items
• Enabling of generic integration of metadata profiles (NIMS, MPI zur Erforschung multi-religiouser u. -ethnischer Gesellschaften)

No functional Prototype needed for this release, as no 'visible' changes.

R3.3 (GUI Release)

• GUI V2

Functional Prototype for R3.5

R 4.0

AIM: Upload of collections to make the FACES software more interesting for other institutes!

• Surrogate item implementation

• Metadata Profile Management:
  1. Create/edit simple metadata profile (each metadata consists of one type and one label)

     Metadata profile should be under version control, therefore with a pending/publish life cycle. To be clarified if that should be done in the first step. --Bastien 12:36, 19 May 2010 (UTC)

     If we do versioning for metadata profiles, then the user should also have the possibility to view older versions of a profile. I think we should offer that not with the first implementation (keep it as simple as possible). --Kristina 10:01, 20 May 2010 (UTC)

     • Use metadata types from a list provided by the MPDL (e.g. geonames, date, cone-person, sting, integer)
     • Define labels for a metadata
     • Add/remove metadata
     • Add/remove a controlled vocabulary to the list of metadata via Cone data (e.g. add "Geonames" to cone)

     This is part of cone, not of Faces. How shall we handle it? --Kristina 10:01, 20 May 2010 (UTC)

  2. Create/update content-model out of metadata profile (done automatically via 1)
  3. Create/update default screen configuration out of metadata profile (done automatically via 1)

• Collection Management:
  1. Create collection with one md profile and a default style (what is meant by "default style"?--Kristina 10:01, 20 May 2010 (UTC))

     How will the md pofile be related to the collection (item, md record field, other)? --> Should be done via content-model. --Bastien 10:01, 19 May 2010 (UTC)

  2. Define Collection md profile:
     • Publication metadata profile + specific metadata profile for entry point style info?
     • Specific metadata profile, to be defined?
  3. Collection entry point page (md record for entry point information should be specified)
     • View entry point via direct link
     • Edit/customize style of entry point

• Upload (data ingest by the user, import workspace):

1. Web upload (upload images for one collection)
   • via selecting a folder
   • via selecting a zip
   • via selecting one single picture (or several? --Kristina 10:01, 20 May 2010 (UTC))
2. Desktop upload (upload images for one collection)
   • Upload all images dragged and Dropped into Faces Desktop box
3. Create thumbnails and web resolution and upload all 3 resolutions
4. Extract technical metadata (IPTC [1])
5. Create items with technical metadata (filename, size, ...) but empty metadata record
6. (Optional) Scan filename
   • Define pattern: how are the different md values in the filename separated (e.g. via ",")
   • Define parsing: which value should be mapped to which metadata from the schema
   • Update items with populated md-record
7. Import workspace --> I think that is part of the GUI and shall be deleted from this list. --Kristina 10:01, 20 May 2010 (UTC)
   • ?Same as Pubman?
   • ?New Concept?

• Metadata Editing:
  1. Batch editing
     • Filter/sort/search the images based on already available metadata values (e.g. technical metadata: date creation, already populated values)
     • Select images (via multiple click, batch select)
     • Edit metadata values (retrieved from related schema) of selected images from edit mask (metadata are stored in item metadata record). Keep in mind to specify 2 use cases:
       • if edit can be done under a couple of seconds
       • if not, should certainly be specified something like an edit workspace
         • I think one specification is enough. In my opinion, only the GUI has to think about what will happen when the changes needs some minutes to be visible for the user. --Kristina 10:01, 20 May 2010 (UTC)
  2. Edit metadata of a single image (is same a batch editing with only one image selected)

• Browsing:
  1. Browse by collection
     • Browse pictures within one collection (sorting by the md set)
  2. Browse by albums
     • Browse pictures within one album (sorting is not possible when the pictures within one album use different metadata profiles)
       • Technically possible: Images which don't have any value for md1 will be then sorted by md1 as last one if sorting ascending --Bastien 13:02, 19 May 2010 (UTC)
         • That I do not understand. --Kristina 10:01, 20 May 2010 (UTC)
     • Filter within the album (e.g. by metadata profile --> now sorting is possible)

• Search:
  1. General free text search (any metadata value, either in album, picture or collection)
     • Search result page should be specified: What happens when we get images, collections and albums in one search result: All displayed, only one type with possibility to switch between types, ...? --Bastien 13:06, 19 May 2010 (UTC)
       • That's also part of the GUI, not the functional specification. --Kristina 10:01, 20 May 2010 (UTC)
  2. Search for collections (e.g. which collection has a metadata field called temperature)
     • Do simple search
  3. Search for albums (album metadata)
     • Do simple search
  4. Search for pictures (metadata values)
     • Select a metadata set or a collection
     • Do advanced search for the selected metadata set or the collection

• Researchers homepage (Wordpress plugin)

• Collection portal (one entry point for all collections): See collection management point (??? --Kristina 10:01, 20 May 2010 (UTC))

Further Requirements

• Sharing of albums with other users (incl. user privileges, tracking of changes)
• Note pad for albums
• Copy album content
• Merge album content
• Cone entries for album editors and organizations (cone integration)
• Download of a single picture (and it's MD?)

Isn't this already provided, at least with no metadata? Just do a right mouseclick and download the pic.

• Fine granular access rights for released items (per picture)
• Simplified breadcrumb navigation (Last Album View, Last Image View)
• Screencast
• Integration of Digilib
  1. in a separate window
  2. fully integrated in the Faces GUI
• Versioning: View album event log
• Normstudy
• Integration of the extended pictures from Rostock
• Usage of an online application form (see Faces User Management)
• Persistent Identifier (PID) - depends on when the gwdg can provide this functionality

PIDs are now integrated

• User Management that can be managed by the institute, not the MPDL (see Faces User Management)
• Metadata ingest by user (zip+ecxel)
• Batch tagging (assignment of new metadata to the items)

Expectations

Expectations MPI B

• Faces will be a service based on the eSciDoc infrastructure for publishing digital images (incl. a user management for all users who work with faces).
• The institute’s and department-specific corporate design will be visible in the web design of the solution.
• The content of the collection Faces will be digitally preserved and persistently identified.
• The data from the currently available Faces database will be integrated.
• The data of the collection Faces is not published as open access, except for the data of the six predefined persons who gave explicit publishing permission.
• Faces will be a closed collection, so the import of further images is not possible once the application is running.
• The application will support the future integration of further attributes (e.g from the normstudy).
• Once the application is running, it can't be changed without the permission of the institute.
• The MPI has fully administrator rights for the application.

Expectations MPDL

• Faces will be delivered as an open source self-contained web application, which can be installed and run with predefined standard set-up.
• The MPDL will use the FACEs solution as showcase for demonstrating possible research data scenarios based on the infrastructure. The institute's staff will support respective outreach activities by reporting on their experiences.
• The MPDL has access to the root account of the application for administration purposes.
• The data of Faces will be hosted at the MPDL (and/or its partners like the GWDG), who are also responsible for the server administration. Details will be defined in a service level agreement.

Max-Planck-Institut für Bildungsforschung

National Institute for Materials Science Japan

Max-Planck-Institut

Graphical User Interface

Coordinated Universal Time

Max Planck Digital Library

International Press Telecommunications Council

Metadata

Persistent Identifer or Identification

Enhanced Scientific Documentation

Gesellschaft für Wissenschaftliche Datenverarbeitung Göttingen