Imeji MPDL internal meeting

MPDL

2012-10-23: NIMS meeting
Mikiko, Masao, Bastien, Rike


 * New Release on server (who?)
 * To check with benjamin
 * imeji should be set up till end of year
 * Rewrite of homepage text (who?)
 * Masao
 * Exchange logo and blog
 * Masao
 * Ingest of new data (who?)
 * Together
 * Keep urls from old faces version (rewrite? 173 items)
 * All collections?
 * All albums?
 * All images?
 * Only Fiber Fuse collection from todoroki will be redirected (urls need to be accessible), other collections can be deleted
 * imeji community short presentation
 * Nims involvement
 * Community enlargement in japan
 * Release info mail spreaden
 * Rike will send altered press info
 * NIMS imeji whishes
 * check datasight.org
 * Image export
 * NIMS will come to munich next year, march or feb

2011-02-10: GUI meeting

 * Participants: Rupert, Mario, Kristina
 * Aim: define functionality and design

&middot; RUN &middot;

 * 1) main menu IMAGES
 * 2) paginator on top and bottom
 * 3) no function for edit, delete, etc. for multiple images &rArr; only browsing functions allowed
 * 4) single image edit is possible for images the user has the right to edit (his own images)
 * 5) delete singe image is possible within the detailed view of one image (where the user is the owner of and which is in a private collection)
 * 6) no checkboxes for selection
 * 7) variable cloud of facets for dynamical navigation/selection ahead of content
 * 8) system Facets (only for logged in users as for others it makes no sens):
 * 9) * all images (expect withdrawn)
 * 10) * all my images
 * 11) * all my released images (= all images within my released collections)
 * 12) * all my private images (= all images within my pending collections)
 * 13) * all my withdrawn images (= all images within my withdrawn collections)
 * 14) Metadata type facets (that are all metadata types like cone author, date, geolocation, etc., not for each collection seperately, but for the whole content of imeji together)
 * 15) cloud of collection as facet
 * 16) main menu COLLECTION
 * 17) merge submenu from collection startpage & collection imageview
 * 18) variable cloud of facets for dynamical navigation/selection/editing ahead of content
 * (e.g. Germany [x] / Munich [x] / Schwabing [x] (20): EDIT 15 selected: EDIT)
 * 1) clear selected will be part of the drop down where the user can choose, which image will be selected
 * 2) edit function on selected facets or on selected images
 * 3) footer:
 * 4) cloud of metadata as facet
 * 5) position of active album in message line
 * 6) when the user exits a collection, the selection of images will automatically be cleared
 * 7) Editing use cases
 * 8) * Following editing usage scenarios have to be implemented:


 * {| border="1"


 * width="200pt" | Number of images
 * width="200pt" | Number of MD elements
 * width="200pt" | Value of the MD element(s)
 * align="center" | 1
 * align="center" | 1
 * align="center" | same
 * align="center" | 1
 * align="center" | n / all
 * align="center" | same
 * align="center" | n (selected)
 * align="center" | 1 / n
 * align="center" | different
 * align="center" | n (selected)
 * align="center" | 1 / n
 * align="center" | same
 * align="center" | whole collection
 * align="center" | 1 / n
 * align="center" | same
 * }
 * align="center" | whole collection
 * align="center" | 1 / n
 * align="center" | same
 * }
 * }

&middot; FURTHER FUNCTIONS &middot;

 * 1) discuss on basket and his functionality
 * 2) only for creating album
 * 3) creating album (menu IMAGE & COLLECTION) & edit image selection (menu COLLECTION)
 * 4) outsourcing from upload to main menu
 * 5) main menu UPLOAD
 * 6) select collection over cloud
 * possibility for upload 1 image in x collections?
 * 1) main menu IMAGES
 * 2) multiple selection for "add to album"
 * possibility to add image(s) in x albums?

2010-07-09: Prototype presentation

 * Participants: Rupert, Denise, Natasa, Kristina, Lu, Markus, Bastien

Entities

 * Entities = Md Profile
 * Entitities should be internationalized
 * Note: For many reasons, it has been decided by run team not to offer the possibility to share a Md profile between many collections:
 * If a md profile is shared, it will affect all images using that md profile, i.e. for edit (add/remove Md) or even delete.
 * There is no technical solution in eSciDoc to browse Content Model. Md Profile are only search-able via collections.
 * Conclusion: Browsing md profile means in fact browsing collections: Makes no sens of offer 2 times the same list, with 2 different names.

Collections

 * Scenarios for Collections actions needed:
 * What means to release a collection?
 * Items are anyway already released. They could be all invisible by default so long the collection is private
 * Switch of the md profile of a collection is a very heavy and complicated process:
 * higher priority, to be able to add/remove md from it.
 * HTML attributes: Needs to be specified. Can not be too free. Complicated to store in eSciDoc,

Browse all images

 * Needs of common metadata for sorting
 * Sorting could also be done via md profile names
 * Technical problem:
 * Since all items (images)in Faces a released, they are always retrieved via filter or search. Only the content (actual images) are protected. Now Faces checks whether the current user has the privileges to see the content and then query eSciDoc with visibility index.

Md Editing

 * Is it possible to keep edit mask and images on the same page? To do: Check technical requirements
 * Md editing only possible for images of one collection (that means, a collection should be chosen first, then edit possible in browse page)

Upload

 * Add to album during upload nit needed.
 * Should not be possible to upload in many collections at once

Search

 * Working set: kind of album within a collection context.
 * Needs to be specified (who needs it, when, why...?)
 * Anyway, has nothing to do with the search mask. If needed, should take place somewhere in metadata edit.

2010-01-21: Architectural discussion

 * Participants: Malte, Natasa, Wilhelm, Rike, Markus, Bastien

Database technology

 * Some performance tests here, which conclude that:
 * For query, Jena (TDB, SAB) is faster than mySQL
 * For ingest mySQL is faster than Jena
 * But Jena fast enough in comparison to eSciDoc, it won't affect significantly ingest process
 * Jena TDB appears to be faster than Jena SAB (Can be in practice then tested during demonstrator implementation)
 * To do: Check transactions for Jena, in particular for TDB

AA implementation

 * MdStore will use eSciDoc AA directly:
 * User makes a request with an eDciDoc Handler
 * eSciDoc load from eSciDoc all user's priviliges
 * A session is created for this user
 * It will be created 2 graphs in MdSore:
 * for metadata
 * for properties: context id, public status (released or withdrawn)
 * Roles that we be supported:
 * Depositor: can ingest
 * Moderator: can?
 * privileged viewer: Can see private images
 * Collaborator (for albums or collections): can edit
 * To do :Check whether moderator is needed (previously it was needed that all user have moderator and depositor role)

Search

 * An additional index will be created. It should be feeded via stream generated by the mdStore:
 * To do: Check the feasability
 * Advantage: Allow to reuse eSciDoc REST interface. Important for external service like blog plugin
 * I it doesn't work, triple store search will be used
 * A REST interface will have then to be provided

Metadata Urls

 * Metadata URLs will be defined under coreservice path:
 * http://coreservice.mpdl.mpg.de/someNameToDefine/metadata/escidoc:123/metadata-records/md-rec-1/

Version control

 * No System version controller needed
 * A permalink system is provided which consists in a link to the last version (already possible i current Faces implementation)

Locking

 * On each update, all items of a collection will be locked (system lock, not controlled by user):
 * Tests performance of escidoc locking system
 * Show if policy can be modified to make it

Surrogate item

 * Don't have components
 * Their md are therefore only defined in the original item
 * No possibility of the owner of a surrogate item to edit it if he doesn't have the permission of the original item

2010-06-15: Specification finalization

 * Participants: Malte, Natasa, Rike, Bastien

MD Profile management

 * Create Metadata Profile: Creator can create a MD profile by adding metadata to its MD profile. To help him, the interface offers:
 * a list of metadata type: Geonames, String, Integer, cone-person, tag, etc.
 * a list of metadata (according to selected type), out of the eterms list.
 * a free text input for label
 * note label may not be needed if the eterms metadata already exists--Natasa 09:22, 16 June 2010 (UTC)


 * a menu to select cardinality (unique, multiple)
 * a menu to select if mandatory (yes/no)
 * A possibility to use an existing MD profile of another collection as template
 * The resulting metadata profile will be created as a DSP and a screen configuration
 * Each collection has a content model linking to a MD Profile
 * precisely: each collection has members of same content model. this content model contains reference to the published MD profile.
 * addition: this would mean, that when creating a collection, if there is a need also new content model has to be created.
 * Version control will not be provided for the MD profile
 * Therefore a MD profile will be unique for each collection, no possibility to share it between many collection

Collection management

 * Definition:
 * A Collection has one and only one md profile.
 * A Collection has 1 and only one creator, but one or more editors and/or ingesters
 * Do we really need two different roles here? I think one is enough that can edit the metadata values and update pictures. This way, we do not get any problems which scanning the file name (which otherwise can only be done with editor rights and not with ingestor rights) --Kristina 12:40, 14 July 2010 (UTC)
 * It will depend of the specifications. Whether we need the 2 roles or not. --Bastien 08:48, 15 July 2010 (UTC)
 * Who should be allowed to edit the md-profile (administrator?)?--Bastien 09:46, 16 June 2010 (UTC)
 * A collection has a publication md profile
 * A collection has one entry point
 * Entry point: The CSS is not specific to a collection but to solution, that means:
 * One collection could be displayed with many style
 * As discussed on 09.07.10, each collection shall have one style (defined by the collection creator); several styles does not make any sense. But the overall entry point (one level above the collection) can hav a different style for each instance. --Kristina 12:40, 14 July 2010 (UTC)
 * Of course, it was only here unwell described, but it was it is meant. --Bastien 08:45, 15 July 2010 (UTC)
 * The CSS will be defined though the solution entry point, for instance:
 * http://img.mpdl.mpg.de/ : default mpdl style
 * http://img.mpdl.mpg.de/florence : style of Florence institut
 * http://img.mpdl.mpg.de/birds : style of birds project
 * Collection will have notepads (like albums) for system entries (see Upload)
 * Actually what is meant here is a working workspace (which includes the ingest and the editing of metadata values) --Kristina 12:52, 14 July 2010 (UTC)

Upload

 * Technical metadata will always (not up to user) be ingested into eSciDoc:
 * TO DO: Define which technical metadata should be uploaded: IPTC and/or XMP and/or other (see pubman ones)
 * Technical md will be displayed only in xml (via link) like current implementation.
 * Technical metadata are stored internally in eSciDoc
 * JHove not supported anymore
 * Workflow:
 * Log in with ingester right
 * Select an existing collection
 * Select image(s) / ZIP to be uploaded
 * (Optional) Define filename pattern
 * Define upload options (visibility, etc.)
 * Upload
 * images visibility defined for one whole upload

Metadata Editing

 * Reminder: Performance goal: 20 ms pro item
 * How to manage item locking?:
 * For each update in one collection, the whole collection is locked (only for update of course)
 * Transaction will be supported for update
 * Each Update will logged into collection notepad:
 * This replace the concept of "Update workspace"
 * Log should provide enough information about which metadata have been updated on which items

Search (To be discussed in more details in a specific meeting)

 * Simple search for all types of objects: collection, album, images
 * Should we provide a generic advanced search (i.e, search for all types of objects on for instance, dates, persons, name, identifier, organization, etc.)?
 * Should the album search and collection search be only one same search (both publication metadata profile)? It could be then possible to search for both or one of the 2 types
 * See JIRA advanced search,

Other (Not discussed)

 * Should we switch whole Faces to new Filter interface and then follow pending/release workflow for images:
 * If yes, when an item is released? With the collection it belongs, on user event, etc.?
 * IMPORTANT: If visibility is changed for many images in a batch operation, we have to update escidoc items: Performance issue!!!

2010-06-11: Architectural discussion
The goal of the meeting was to define first requirements for that new architecture, second, which technical options are then possible
 * Participants: Malte, Natasa, Wilhelm, Michael, Rike, Markus, Bastien

Requirements

 * Update should take 20 ms for one item.
 * It should be possible to update 100000 items at once
 * Collaborative use cases should be managed: for example, when 2 editors should be able to edit a collection on the same time.
 * No system version system is required, but it should be offers a persistence functionality (permalink?) to allow citable collections, images.
 * A REST interface (only) will be provided.
 * Supported objects visibility will be: public, private and user group.
 * Supported objects status will: pending, released (No workflow needed)
 * A search across different collections is not necessary.

Architecture options

 * 1) Simple database with its own rights management system (based on simple requirements), and no advanced version system. eSciDoc is not used at all.
 * 2) eSciDoc used only as an archive. All Faces objects are managed on local DB, but there is the possibility to archive the objects into escidoc
 * 3) Objects stored into eSciDoc, but metadata managed externally into a database. (see draft [[Image:Batch_metadata_update.pptx]])
 * 4) All items of collection are stored as an object (item/container?) into escidoc.

2010-06-10: Kick-off meeting

 * Participants: Malte, Natasa, Kristina, Rike, Bastien

Metadata Editing
Question: Which technology to choose to edit 100000 items at once?
 * Expected/wished performance: 20 ms pro item, i.e:
 * 33 minutes for 100000 items
 * 2 s for 100 items
 * First analysis have been done by Faces team: Imeji_Metadata_Update:
 * The only 2 possibilities are:
 * Customization of eSciDoc core services
 * Development of a new service independent to eSciDoc

Decision: Run team will start to work on the first solution. The development won't be coupled directly with FIZ work (but we must take care that our development will go into core code of FIZ). FIZ should only have an adviser role.

Faces Features
Question: How to enable massive metadata editing?
 * An Edit workspace (like import workspace) will be created to enable asynchronous editing.
 * Competitive update should be avoided:
 * by locking item during editing?
 * by allowing only one editor at once? (Problem, what if the editor doesn't log out?)
 * etc.

Run organization

 * Run start officially on 14.06.2010
 * Dev Team will be split into 2 groups:
 * Features development on current eSciDoc instance
 * Which features should be first developed: To be synchronized with specification!
 * eSciDoc core service customization
 * A demonstrator should be ready for 01.10.2010:
 * To be decided: what should be the deadline for technology specification (i.e. eSciDoc or not)