Difference between revisions of "Talk:Mapping MAB to MODS"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Manual mapping ==
== Manual mapping ==


The MPIER provided us with [https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller%20Raum%20Reichsrecht/02_Exemplary_Data/ 5 MAB records] for the two books (two parent records plus three child records). These 5 records will be mapped to MODS by using the rules defined in the [http://dfg-viewer.de/fileadmin/groups/dfgviewer/MODS_Application_Profile_2008-01-09b.pdf ZVDD MODS profile]. The result ([https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/01_Documentation/MAB_MODS_v32_mapping.xml MAB_MODS_v32_mapping]) is available in the repository.
The MPIER provided us with [https://subversion.mpdl.mpg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/02_Exemplary_Data/ 5 MAB records] for the two books (two parent records plus three child records). These 5 records will be mapped to MODS by using the rules defined in the [http://dfg-viewer.de/fileadmin/groups/dfgviewer/MODS_Application_Profile_2008-01-09b.pdf ZVDD MODS profile]. The result ([https://subversion.mpdl.mpg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/01_Documentation/MAB_MODS_v32_mapping.xml MAB_MODS_v32_mapping]) is available in the repository.


'''Results & Discussion:'''  
'''Results & Discussion:'''  
Line 16: Line 16:
#* The "Bandtitel" from the Sisis file was not exported to MAB and can therefore not part of an automatic mapping to MODS. The MAB files have to be created properly so that no data will get lost.
#* The "Bandtitel" from the Sisis file was not exported to MAB and can therefore not part of an automatic mapping to MODS. The MAB files have to be created properly so that no data will get lost.
# MODS offers no property for the local signature of the book (MAB element 544). Can we loose this information or is there another possibility to represent this? --[[User:Kristina|Kristina]] 16:52, 14 February 2008 (CET)
# MODS offers no property for the local signature of the book (MAB element 544). Can we loose this information or is there another possibility to represent this? --[[User:Kristina|Kristina]] 16:52, 14 February 2008 (CET)
:: I would suggest to map this information to <code><location><physicallocation></code>, see example in [https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller%20Raum%20Reichsrecht/01_Documentation/MAB_MODS_v32_mapping.xml MAB_MODS_v32_mapping] --[[User:Inga|Inga]] 11:36, 18 February 2008 (CET)
:: I would suggest to map this information to <code><location><physicallocation></code>, see example in [https://subversion.mpdl.mpg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller%20Raum%20Reichsrecht/01_Documentation/MAB_MODS_v32_mapping.xml MAB_MODS_v32_mapping] --[[User:Inga|Inga]] 11:36, 18 February 2008 (CET)


*You map 403 (MAB) to Edition Statement (AP) but this element does not exist in the application profile, should this be integrated?--[[User:Kleinfercher|Friederike]] 15:10, 3 March 2009 (UTC)
*You map 403 (MAB) to Edition Statement (AP) but this element does not exist in the application profile, should this be integrated?--[[User:Kleinfercher|Friederike]] 15:10, 3 March 2009 (UTC)
*What do we do with RelatedItem.title and RelatedItem.Identifier?--[[User:Kleinfercher|Friederike]] 08:25, 4 March 2009 (UTC)
: Will be added to AP--[[User:Kleinfercher|Friederike]] 10:32, 4 March 2009 (UTC)
: If we have identifier and title as subelements this should be indicated in the AP.
 
===011===
*why to map this data if it is unstable? --[[User:Natasab|Natasa]] 15:24, 9 March 2009 (UTC)
*Not needed by institut
*Actually, I always expected MAB001 (= IDENTIFIKATIONSNUMMER DES DATENSATZES) to be stable. Is this due to a specific SISIS implementation? ... at least using MAB720 (STICHWOERTER) is! I would suggest to follow Natasa's suggestion and map MAB720 only --[[User:Inga|Inga]] 23:09, 10 March 2009 (UTC)
 
===720===
*why to map this data if it is unstable? --[[User:Natasab|Natasa]] 15:24, 9 March 2009 (UTC)
*Should not be editable via GUI
 
===010===
*the identifier of the parent related item in escidoc is expressed as a structural relation. It is questionable if this still has to be mapped in the metadata?--[[User:Natasab|Natasa]] 15:26, 9 March 2009 (UTC)
*And which identifier of the parent record is used? MAB001 or MAB720? --[[User:Inga|Inga]] 23:15, 10 March 2009 (UTC)
*Only consider 720!--[[User:Kleinfercher|Friederike]] 08:10, 11 March 2009 (UTC)
 
===410/412===
*Not destinguishable after mapping
*if we use originInfo type, we can create 2 separate metadata in the profile of originInfo type where one is for publisher and other for printer.--[[User:Natasab|Natasa]] 16:07, 9 March 2009 (UTC)
*Solution: see comments on content page
 
===037===
*is in here possible to use any of standard list of languages? --[[User:Natasab|Natasa]] 15:58, 9 March 2009 (UTC)
*[[ViRR_Application_Profile#Language |AP]] defines encoding schema RFC 4646

Latest revision as of 11:33, 25 April 2012

Manual mapping[edit]

The MPIER provided us with 5 MAB records for the two books (two parent records plus three child records). These 5 records will be mapped to MODS by using the rules defined in the ZVDD MODS profile. The result (MAB_MODS_v32_mapping) is available in the repository.

Results & Discussion:

  1. Hierarchical record structure
    • One record for each parent and each child record exists. The child record has an element <relatedItem type="host"> pointing to the parent record by using an identifier (URL/URN)
      The current MODS file only includes identifiers of type string (e.g. <identifier type="local">66237</identifier>). These identifiers should be replaced by the appropriate uri, after the digital objects have been ingested
    • Alternative implementation (not recommended by zvdd) I: create only one object for the work and all its parts (element <part type="constituent">)
    • Alternative implementation (not recommended by zvdd) II: provide information for parent in child record without creating an individual record for the parent (element <relatedItem type="host">).
    • Please Note: It is not necessary that the parent record points to its child records, because this information will already be stored in the eSciDoc container.
  2. Handling of subject strings ("Schlagwortketten")
    • In MAB subject strings are represented in the element 710 as strings. Further on, each subject is saved in one separate element 902.
    • In MODS we transfered each subject string in one element, several "Schlagwortketten" would be transferred to separate elements. But it would be also possible to put the subjects in separate elements.
  3. The "MODS application profile" used by the DFG viewer demands identifiers in form of URNs. The Deutsche Nationalbibliothek provides a service to assign URN (NBN).
  4. Missing Metadata in the MAB file
    • The "Bandtitel" from the Sisis file was not exported to MAB and can therefore not part of an automatic mapping to MODS. The MAB files have to be created properly so that no data will get lost.
  5. MODS offers no property for the local signature of the book (MAB element 544). Can we loose this information or is there another possibility to represent this? --Kristina 16:52, 14 February 2008 (CET)
I would suggest to map this information to <location><physicallocation>, see example in MAB_MODS_v32_mapping --Inga 11:36, 18 February 2008 (CET)
  • You map 403 (MAB) to Edition Statement (AP) but this element does not exist in the application profile, should this be integrated?--Friederike 15:10, 3 March 2009 (UTC)
Will be added to AP--Friederike 10:32, 4 March 2009 (UTC)

011[edit]

  • why to map this data if it is unstable? --Natasa 15:24, 9 March 2009 (UTC)
  • Not needed by institut
  • Actually, I always expected MAB001 (= IDENTIFIKATIONSNUMMER DES DATENSATZES) to be stable. Is this due to a specific SISIS implementation? ... at least using MAB720 (STICHWOERTER) is! I would suggest to follow Natasa's suggestion and map MAB720 only --Inga 23:09, 10 March 2009 (UTC)

720[edit]

  • why to map this data if it is unstable? --Natasa 15:24, 9 March 2009 (UTC)
  • Should not be editable via GUI

010[edit]

  • the identifier of the parent related item in escidoc is expressed as a structural relation. It is questionable if this still has to be mapped in the metadata?--Natasa 15:26, 9 March 2009 (UTC)
  • And which identifier of the parent record is used? MAB001 or MAB720? --Inga 23:15, 10 March 2009 (UTC)
  • Only consider 720!--Friederike 08:10, 11 March 2009 (UTC)

410/412[edit]

  • Not destinguishable after mapping
  • if we use originInfo type, we can create 2 separate metadata in the profile of originInfo type where one is for publisher and other for printer.--Natasa 16:07, 9 March 2009 (UTC)
  • Solution: see comments on content page

037[edit]

  • is in here possible to use any of standard list of languages? --Natasa 15:58, 9 March 2009 (UTC)
  • AP defines encoding schema RFC 4646