ESciDoc Developer Workshop 2008-04-15

ESciDoc  Restricted Access to eSciDoc group

Date: March 15.04.2008

Location: Karlsruhe, München (Video conference)

Participants MPDL: Natasa Bulatovic, Wilhelm Frank

Participants FIZ: André Schenk, Torsten Tetteroo, Rozita Fridman, Harald Kappus, Matthias Razum

Start time: 14:00 15.04.2008

Harmonizing method behavior
see ESciDoc_Infrastructure_XSD_subresource for details

Outcome
''
 * agreed with FIZ proposal. It was a requirement from before, but MPDL team at present does not see any problems with FIZ proposal.
 * ''end of April implementation will be provided together with the list solution (only for items)

Item lists, filters and authorization issue
status

Outcome

 * Filter lists are fine working 1sec/560-570 items
 * Working on synchronization with Fedora in progress, no big problems stated
 * WFR: Will the filters be also implemented for Containers?
 * - not at the moment - first items will be delivered and then containers as it is not at present clear about synchronization and how would container lists look like.
 * in meantime FIZ looks for different options (to enable the configurable filters and list formats) ( this will certainly not be delivered in april ). These options are:
 * using XML database, XPath-XQuery (Berkeley XML DB - it is not running and tested yet)
 * PostgreSQL XML/XQuery extension does not perform (up to 15 inutes for 1 mio. objects)
 * approach presented by MPDL
 * Virtuoso
 * MPDL asked for a list of criteria against which the filter list (i.e. requirements) are evaluated (MPDL will also check / add to this list)
 * FIZ (MRA) will provide initial list of criteria to server as starting point for further evaluation.
 * MPDL will extend this list of criteria/requirements
 * Important: to keep in mind that each item/container has 1 metadata record labeled "eSciDoc". This is the metadata that is to be delivered with the item lists. It is also important that for different content models, the eSciDoc metadata record can be based on different metadata profiles e.g.


 * PubItem, eSciDoc metadata record: eSciDoc Publication profile
 * FacesItem, eSciDoc metadata record: eSciDoc Faces profile
 * ScannedBook, eSciDoc metadata record: METS/MODS profile, Original imgested metadata record: MAB metadata
 * Shouldn't it be just MODS (without METS around it)? Frank 17:12, 15 April 2008 (CEST)

Both teams will have to re-think once again what is the benefit that the core services manage the metadata profiles. Search indexer had shown to be pretty generic by now i.e. it indexes any metadata provided in the eSciDoc data stream (by the XML path) - it works fine, as we were also able to make searches for items/containers that are not described with Publication metadata.
 * Discussion: to check how will one already on the metadata record be able to define the application profile. Is it necessary to create Fedora objects (i.e. application profiles as resources) in the FW? If that is the case, then the metadata record may have "objid" to the application profile associated. MPDL (NBu, WFR) think this is not necessary as the metadata profiles in the content model are declaratively defined for the core services - they in fact may have more use on the solution side.

Update after the Video conference
Input from NBU:
 * In future, we are planning to put the metadata records as RDF/XML
 * In R4, each metadata in each metadata profile will have unique URI (see work on ESciDoc_Application_Profiles)

Component property "institutional visibility"
MPDL Check: institutional visibility
 * specs needed for implementation

picked from Email from Natasa: see PubMan_Func_Spec_Submission and for better precision PubMan_Func_Spec_Submission

In fact there is no "Institutional" visibility, it is just "Organizational unit" (and user explicitly provides a list of organizational units which (actually their users) can access the component.

Outcome
''No update can be provided from MPDl at the moment. Most likely this requirement will not change, but NBU will still check with Functional experts.''