ESciDoc Developer Workshop 2008-08-26

ESciDoc

Date: 26.08.2008 Start time: 14:30

Location: Karlsruhe, München (Video conference)

Participants MPDL: Natasa Bulatovic, Wilhelm Frank

Participants FIZ: Harald Kappus, Michael Hoppe, Rozita Fridman

=Agenda=

Search within a container
question from Harald
 * see UC_FAC_SR_03_Search_within_list
 * what does the bold part mean: 5 The system searches for the defined search criteria and creates a search result containing all pictures visible to the user according to his privileges (logged in or not).
 * according to privileges for Faces: some users have possibility to see only pictures with private visibility (depositor, privileged viewer) and some only pictures with public visibility (non-registered users)

Outcome

 * new feature
 * usage of privileges within the search
 * confusing specification on what is about privileges
 * But main issue is how to search within a container
 * List of use cases in Colab related to container search and vice versa (NBU will rework this page to provide more focused information)

Roadmap (revisit)
Some most important issues for very fast feedback:


 * Fast filtered list (still High prio)
 * MPDL: 4Q2008 is very late
 * Institutional visibility (still High prio)
 * Better insight in current status, would be very good to have something before end of Q32008
 * Shibboleth integration
 * done according infrastructure list, MPDL will make first tests and report back next 2 weeks
 * Java client library (from MPDL point of view so far Nice-to-have)
 * On last workshop we have agreed Stephen to send more information on this, at least for transparency purposes
 * Organizational units searching index (still High prio)
 * First migration of data from eDoc is planned by end of September
 * Tests on SearchAndOutput services and usage from MPI PL already run, therefore this issue is pretty urgent
 * OUTCOME: add first references as output into the tree structure and later decide if more information is needed
 * Statistics (Medium prio)
 * can be re-scheduled to Q4
 * Ingestion (Highest prio)
 * MPDL will in upcoming 2 weeks upload 1 milion objects by using Item Handler to check behavior of Fedora and core services
 * Ingestion of several collections is currently blocked
 * OUTCOME: to be checked, no further information
 * Administrative searches (still High prio)


 * Note: would be good to schedule roadmap meeting together with Malte, Matthias.

Institutional Visibility
some open issues: the list of organizational units
 * should the list be part of the item/component, so it will be versioned or should it be outside, since they are not part of the object?
 * i would think of the list is not and will not remain single visibility criteria just added. With Torsten before we agreed to enable specification of a policy that defines rules for visibility and relating this policy to each component. Other visibility criteria that are other then private, public will be : user group, IP-range etc.--Natasa 07:36, 22 August 2008 (UTC)


 * is there one list of OUs which are responsible for ALL Components of one Item or each component will have its own list?
 * see above: depends on component, each component in item can have different privileges--Natasa 07:36, 22 August 2008 (UTC)


 * if the editor is not member of one of the listed OUs, can he access the content?
 * rules on visibility apply to "logged-in-users" who are mostly readers and have no editing privileges given from collection level--Natasa 07:36, 22 August 2008 (UTC)


 * if a user is member of a child of one of the listed OUs, can he access the content?
 * yes --Natasa 07:36, 22 August 2008 (UTC)
 * what status lagl OUs have to be in?
 * all open?
 * may be some are closed?
 * also new?
 * opened or closed, see also link above on General rules --Natasa 07:36, 22 August 2008 (UTC)


 * From Matthias's email:
 * Institutional Visibility: we had some discussions whether to add the list of OUs to the item itself or to store it in a database and just reference the item from there. If we add the list to the item, it becomes part of the item (it could even create new versions of the item if changed), but is that desirable at all? My rule of thumb for this is always: do I want to keep that information for the long term (e.g., should it go to long-term archival)? Is it an integral part of the item or rather management information that is only valid for the system the item currently resides in? As you can see, it is less a technical but rather a philosophical question.

Outcome
 * visibility flag should have "public, private, policy"
 * if policy should have relation for policy object and change of policy should create new versions?
 * Policies for items/components are different?
 * create Colab discussion on this topic as it is urgent and very important

open bug org units

 * bug 597 (anonymous user cannot retrieve child org units) is still open, since FIZ is waiting for a responce
 * see also General rules for OUs

Outcome this bug was fixed with build 297 and is closed now

Outcome

 * Which migration tool?
 * Migration tool for Fedora releases?
 * Outcome:
 * 303 will be delivered with 3.0.beta tomorrow morning
 * 305 or weiter will give us also migration from 297 to Fedora 3.0
 * for the running pilot systems no migration was done but ALL objects were re-created via PubMan using the "create" methods of eSciDoc Infrastucture using build 297

Migration for production systems at MPDL

 * what was done?
 * --Natasa 07:39, 22 August 2008 (UTC)From MPDL side:
 * metadata mappings and transformations
 * definition of what is to be migrated and how
 * selected test-bed collection
 * preparation to migrate by using Item Handler interfaces as ingestion is not ready
 * see also eDoc to PubMan migration

Outcome: will be discussed with Matthias and we will have ideas (whether always all metadata records should be delivered?)
 * Issues
 * Metadata: How to migrate metadata records from eDoc? They should not be by default server from Item handler in the output. --Natasa 10:42, 26 August 2008 (UTC)
 * Yearbook: search in container? (also use cases from FACES, see Faces_Album_Management and search within an album )

new Topic technical Metadata in Component

 * should be re-designed in the near future

Outcome
 * MPDL wants Jhove to be part of the create and update methods of Infrastructure and this should be configurable "if automatically used or not"

Content Relations
why mpdl-ontologies? container-toc relation isTocOf


 * the relation for TOC is missing
 * FIZ will check and fixe it (Frank was informed via phone)
 * MPDL needs access to the ontology,
 * is there a documentation?

Content-Model-Specific properties (Content-Type-Specific properties)

 * see initial set of requirements put at Local tags handling  --Natasa 07:40, 22 August 2008 (UTC)
 * resolving issues such as tagging in another manner? semantic store queries possible to combine with searches? See mentioned use cases for Faces, YB data above.

Toc Handler
Outcome
 * we are waiting for a bug-fix of build 303 to still work with the Toc Handler and to be able to create MD records that have no DC metadata
 * when is build 303 to be delivered?
 * Build 303 was delivered on August 26, also the patched version for Fedora 3.0 Beta 1

Advanced/Administrative search requirements

 * All functional specifications are on Colab
 * Use cases regarding advanced and administrative searches are available via
 * Faces_Searching
 * PubMan_Search
 * ViRR_Searching


 * in addition see also related article and discussion pages at
 * PubMan_Func_Spec_Search
 * PubMan_Func_Spec_Search
 * PubMan_Indexing