Talk:EDoc to PubMan migration/MPIPL

Open Questions

• How to map eDoc Collections to PubMan Org. Units?
  • see: EDoc_to_PubMan_migration/MPIPL#Migration_procedure, Karin agreed to that procedure --Nicole 14:29, 9 September 2008 (UTC)
• check "special usage" of fields like: Is Part Of. How are they used by the institute, and is there a rule on how we can map the content?
  • check the usage of relations with Karin. How important they are and how we should handle them.
  • gave eDoc IDs to Karin and she will check on a case by case basis --Nicole 14:29, 9 September 2008 (UTC)
• how to migrate that record of type "interactive resource": http://www.edoc.mpg.de/240861 ?
  • should be mapped to genre "other" --Nicole 14:29, 9 September 2008 (UTC)

Questions regarding OU for MPIPL We we are doubting we made the right decision in february regarding the org units.

Background Nicole presented the ppt with 3 options:

• Projects and Departments listed as separate org units without any relations between them
• Departments as org units, Project information in metadata
• Projects as subcategories of departments incorporated in one org unit

We choose for Option 3!

Advances as we saw then, were:

• predefined structure (controlled list)
• relations between departments and projects are visible

BUT, real data don't fit into these rigid rules.

It's already difficult to make reliable current structure of projects belonging to groups, let alone maintaining this scheme in the future. Some units don't belong to a department at all, like eg. Junior Research Groups which are being considered Projects but have no institute's department above them.

• We are seriously thinking to switching to Option 1!

Advantages of Option 1

• department and project can be chosen individually
• no need for maintaining matrix stating which project belongs to which department
• possibility to host projects under the institute's level
• no need to duplicate projects under department
• easier for migration: project=edoc collection (so there is a 1:1 mapping),

authors have one department (can also be mapped 1:1) (in our present migration procedure I would have to assign up to 8 org units for some users and we would have to delete 7 after migrating).

Disadvantages two org units have to be filled in by user, with possibility to forget one or make non-plausible choices (must be checked with workflow)

Questions:

• What does this mean in terms of metadata? I guess the xml output will change? Are there different

fields for org units as departments and org units as projects?

• How can a selection on department or project be made? Or do we simply all department A Group, B Group, etc... and

all projects A Project, B Project, etc.

• Are there any future OrgUnit developments regarding Metadata, structure, relations we should take into account?
• Do we really not mis something essential? It's kind of weird that we were so certain in february.
• It will probably mean we have to ask Zest to alter there script.

--Karin 10:53, 25 September 2008 (UTC)

Answered Questions

• shall eDoc users be moved to PubMan?

  Talked to Karin today. She thinks, that there is no need to migrate users. --Nicole 13:32, 7 August 2008 (UTC)

• who should be the owner of the migrated eDoc items in PubMan?

  Karin will be the owner

Explain

• YB workflow
• full text migration, ask if user with privileged view is needed to see full texts with private access level
  • user with privileged view is needed --Nicole 14:36, 9 September 2008 (UTC) outcome of telco with Karin
  • we will migrate all full texts, set to all full texts except for the public ones "private" visibility, create users with priv. view, set locators to eDoc (for non public full texts), the eDoc file visibility will also be put to PubMan into the component MD.
• only released eDoc records will be moved to PubMan
• duplicate problem has to be solved on eDoc, we can provide a report on possible duplicates though -
  • we looked through the list of duplicates you provided and deleted all real duplicates on eDoc. Everything which has the same title now aren't really duplicates, because they are

different titles (different authors, diff publication genres...)--Karin 14:00, 21 October 2008 (UTC)

Open Issues with QA migration

General

Indexing apparently doesn't work well, we can't find all publications which makes testing very enduring. For example in edoc MPIIPL publication year 2008 has 96 entries, only 23 are found with search.

Virtual collections from edoc have been migrated, that wasn't intended , eg. http://edoc.mpg.de/126883 from collecton endnote_import_2004_06. Haven't checked other items yet, from other virtual edoc collections.

edoc collection http://edoc.mpg.de/display.epl?col=73&grp=1332 (Categories and Concepts across Language and Cognition) hasn't been migrated due to spelling differences (capital Concepts on Pubman and small concepts on eDoc) should be fixed so that the Capital 'C' should be on PubMan

Advanced Search

Search for genre=book gives you book chapters as well with the results

Genre types

Journal article fine, apa export works fine

book data are not fully migrated, eg http://edoc.mpg.de/320760 http://qa-pubman.mpdl.mpg.de:8080/pubman/item/escidoc:36803:1 pages are missing, APA export: authors/editors, publishing place and publishers name are missing

--Karin 16:32, 13 November 2008 (UTC)

Electronic Documentation

Publication Management

Coordinated Universal Time

Organizational Unit

Max-Planck-Institut für Psycholinguistik

Telephon Conference

Metadata

Quality Assurance

American Psychological Association