mods:resourceType is mandatory in mods, so we have to add it while migrating bibl data:

<mods:typeOfResource>text</mods:typeOfResource>

see #40
see #33

• instead of "Herausgeber" a search field "Publishing Information" searching the elements: <pubStmt> <seriesStmt> <physLoc>

• "Identifikator" will not be necessary
• the Checkbox-Option for "Role" is missing ("composer" and/or "lyricist"), which should indicate wether a relation to an expression as composer or lyricist exists

every search URL begins with: q=(category.top:"cmo_kindOfData:source" OR objectType:person) AND ...
leading to bad/no results in some scenarios

Currently the result list header is only "Suche", it should indicate the search request parameters

Caused by https://github.com/Eonasdan/bootstrap-datetimepicker

We need support for former <cmo:lyricsDesc /> tag (not used till now). For details see: http://durl.maxweberstiftung.de/cmo/manual.html#lyricsDesc

• Identifier can be removed
• "Publisher" wronlgy labelled as "Herausgeber"
• the field "Publishing information" (instead of "Publisher") should search everything in mods.originInfo like mods.publisher ; mods:place as well as mods.relatedItem type="series"

e.g. 'Kantemir' or 'Kant' should find 'Kantemiroğlu'

We need a cmo:scriptDesc - perhaps as annot element?
See http://music-encoding.org/documentation/3.0.0/physMedium/

• Identifikator should be removed

fields targeting information in related entities are missing:

• date (from lyricist)
• source type (from source)*
• date (from source)*
• checkbox "Faksimile" (= is related to a source with an attachment)*
• checkbox: "CMO edition" (= has a relation to an edition entity)

see also #37
see also the language/script fields are missing: #36

large search results do produce a long list of makam & usul facets, and therefore are hard to read/browse/use as they are sorted by occurence.
A suggestion is to switch to an alphabetical order when showing all ("mehr anzeigen..").

We have three different title types in bibl entrys. They have to be treated differently in migration:

  <title xml:lang="tur" type="main">Müzik Ansiklopedisi</title>
  <title xml:lang="tur" type="sub">Besteciler, Yorumcular, Eserler, Kavramlar</title>

should be migrated to:

<mods:titleInfo xml:lang="tr">
  <mods:title>Müzik Ansiklopedisi</mods:title>
  <mods:subTitle>Besteciler, Yorumcular, Eserler, Kavramlar</mods:subTitle>
</mods:titleInfo>

and

  <title xml:lang="eng" type="main">The Catalog of Music Manuscripts in Istanbul University
    Library</title>
  <title xml:lang="tur" type="alt">İstanbul Üniversitesi Kütüphanesi’ndeki Musiki Yazmalarının
    Kataloğu</title>

should be migrated to:

<mods:titleInfo xml:lang="en">
  <mods:title>The Catalog of Music Manuscripts in Istanbul University
    Library</mods:title>
</mods:titleInfo>
<mods:titleInfo xml:lang="tr" type="translated">
  <mods:title>İstanbul Üniversitesi Kütüphanesi’ndeki Musiki Yazmalarının
    Kataloğu</mods:title>
</mods:titleInfo>

the music type vocabulary should be labelled "genre" (search form, result lists and entity sites)

Searching for "bb-06146962-X" on http://cmo.gbv.de/cmo/ presents 2710 hits. But clicking on one of these hits leads to a white page.

error message:

line 14, column 26, cvc-complex-type.2.4.a: Invalid content was found starting with element 'mei:titleStmt'. One of '{"http://www.music-encoding.org/ns/mei":itemList, "http://www.music-encoding.org/ns/mei":componentGrp, "http://www.music-encoding.org/ns/mei":relationList, "http://www.music-encoding.org/ns/mei":extMeta}' is expected.

(Title fields have been filled.)

Currently:

<person xml:id="pp-49818454-X" xmlns="http://www.tei-c.org/ns/1.0" xmlns:cmo="http://www.corpus-musicae-ottomanicae.de/ns/cmo" cmo:doctype="pp" cmo:pubReady="false">
  <idno type="CMO">Uz, Kazım</idno>
  <idno type="GND">133572889</idno>
  <persName type="TMAS-main">Uz, Kâzım</persName>
  <persName type="TMAS-other">Muallim Hoca Sakallı Kâzım Efendi; sonra: Bey</persName>
  <persName type="TMNvE">Muallim Kâzim Bey</persName>
  <birth><date from="1872-02-21" to="1872-02-21" calendar="../ _index/calendars.xml#gregorian"><ref
    target="bb-80081264-2">TMAS/II, p. 463</ref>21.2.1872</date><date from="1873" to="1873" calendar="../ _index/calendars.xml#gregorian"><ref
      target="bb-27399586-4">MA2/III, p. 558</ref>1873</date></birth>
  <death><date from="1938-01-09" to="1938-01-09" calendar="../ _index/calendars.xml#gregorian"><ref
    target="bb-80081264-2">TMAS/II, p. 463</ref>9.1.1938</date><date from="1943" to="1943" calendar="../ _index/calendars.xml#gregorian"><ref
      target="bb-27399586-4">MA2/III, p. 558</ref>1943</date>
  </death>
  <list>
    <item></item>
  </list>
</person>

will be transformed to:

      <mei:persName xmlns:mei="http://www.music-encoding.org/ns/mei" xmlns:tei="http://www.tei-c.org/ns/1.0">
        <mei:identifier type="cmo_intern">pp-49818454-X</mei:identifier>
        <mei:identifier type="cmo">Uz, Kazım</mei:identifier>
        <mei:identifier type="cmo">133572889</mei:identifier>
        <mei:name type="TMAS-main">Uz, Kâzım</mei:name>
        <mei:name type="TMAS-other">Muallim Hoca Sakallı Kâzım Efendi; sonra: Bey</mei:name>
        <mei:name type="TMNvE">Muallim Kâzim Bey</mei:name>
        <mei:date calendar="gregorian" type="birth" isodate="1872-02-21" source="bb-80081264-2" label="TMAS/II, p. 463" />
        <mei:date calendar="gregorian" type="birth" isodate="1873" source="bb-27399586-4" label="MA2/III, p. 558" />
        <mei:date calendar="gregorian" type="death" isodate="1938-01-09" source="bb-80081264-2" label="TMAS/II, p. 463" />
        <mei:date calendar="gregorian" type="death" isodate="1943" source="bb-27399586-4" label="MA2/III, p. 558" />
      </mei:persName>

A search with 0 hits should print "no matches" or else

Search with a parameter via the search forms,
going to page 2 of results list will reset the search

Multiple terms are not seperated:
Input search field: "Term1 Term2"
Result in search request: ... AND allMeta:"Term1 Term2"
should be something like: ... AND allMeta:"Term1" AND allMeta:"Term2"

the number of search results shown per page is currentyxl set to 10
a dropdown (e.g. 10,20,100) shold allow more ...

a search with normal characters sould find diacritics, e.g. ‘a’ for ‘â’, ‘s’ for ‘ş’

We should save pages in bibl entries mir/mods conform:

<mods:part>
  <mods:extent unit="pages">
    <mods:start>181</mods:start>
    <mods:end>196</mods:end>
  </mods:extent>
</mods:part>

instead of

<mods:part>
  <mods:extent unit="pages">
    <mods:list>181–96</mods:list>
  </mods:extent>
</mods:part>

1. <relationList /> is bidirectional, atm we remove <relationList /> in source and keep it in expression. We decided to switch this and keep <relationList /> in source instead. Expression metadata may only contain the page reference:

  <relationList>
    <relation rel="hasEmbodiment" target="sc-62147348-8" label="TMKl-Ayi/XI.xvii, p. 583"/>
  </relationList>
  to
  <extent unit="page">583</extent>

2. We try to simplify SourceComponents. At the moment each sc is a child of a source, but sc has nearly no metadata. So we like to bring it together again. In simple cases we can use a <relationList />

  <relationList>
    <relation rel="isEmbodimentOf" target="ex-08837172-9" label="CMO_TMKl-Ayi/XI.xvi, p. 575" />
    <relation rel="isEmbodimentOf" target="ex-98758633-8" label="CMO_TMKl-Ayi/XI.xvi, p. 576" />
    <relation rel="isEmbodimentOf" target="ex-33596548-9" label="CMO_TMKl-Ayi/XI.xvi, p. 567" />
     ...
  </relationList>

For more structured sc we still need the <componentGrp> tag.

<componentGrp>
  <source xml:id="sc-07814903-2">
    <identifier>TMKl-Ayi/XI.xvii</identifier>
    <titleStmt>
      <title>Mein Testtitel einer SC</title>
    </titleStmt>
    <relationList>
      <relation rel="isEmbodimentOf" target="ex-79308133-4" label="CMO_TMKl-Ayi/XI.xvii, p. 582" />
      <relation rel="isEmbodimentOf" target="ex-34697765-4" label="CMO_TMKl-Ayi/XI.xvii, p. 583" />
    </relationList>
  </source>
</componentGrp>

I'm not sure if we need a source id here ...

persName/ref/text() ist missing, we should use the label attribute

<persName type="TMKl-Nef">
  Türabî <ref target="pr-30522253-4">TMKl-Nef/V.ii, p. 224</ref>
</persName>

<mei:name type="TMKl-Nef" nymref="cmo_source_00002620" label="TMKl-Nef/V.ii, p. 224">Türabî</mei:name>

The used language term in data is not clearly. Sometimes it is "en" and sometimes "eng". We should clean this up at data import.

Link to source in person name output is missing, see http://cmo.gbv.de/cmo/receive/cmo_person_00000377 (or http://quellen-perspectivia.net/en/cmo/pp-21950636-8).

Klicking on a category has no effect. Probably the links are incorrect search requests.

The search result list should be sortable either by index or by alphabet, switchable with a button

currently only DD.MM.YYYY is accepted, but specifying a specific day will be impractical, normally.
YYYY should be possible

We have tei:date and mei:date attributes in our mei dates. Please fix this mixture within data import

These are the mei:date attributes (which we support)
@startdate
- contains the starting point of a date range in standard ISO form
@enddate
- contains the end point of a date range in standard ISO form
@notbefore
- contains a lower boundary for an uncertain date
@notafter
- contains an upper boundary for an uncertain date
@isodate
- gives the value of a textual date in standard ISO form
@calendar
- indicates the system or calendar to which a date belongs, for example, Gregorian, Julian, Roman, Mosaic, Revolutionary, Islamic, etc.

We should map the following tei:date attributes:

@from      -> @startdate
@to        -> @enddate
@notBefore -> @notbefore
@notAfter  -> @notafter
@when      -> @isodate

If only @notbefore is given these persons are always found if date is greater than the given date.
<mei:date calendar="gregorian" type="death" notbefore="1510">After 1510</mei:date>

leads to:
<field name="death.date.range">[1510 TO *]</field><field name="death.date.content">After 1510</field>

But I'm not sure if this is a content or an implementation bug.

original data:

<usul xmlns="http://www.corpus-musicae-ottomanicae.de/ns/cmo" cmo:classLink="us-20798235-2 label="Hâvî">hāvī</usul>
<makam xmlns="http://www.corpus-musicae-ottomanicae.de/ns/cmo" cmo:classLink="mk-15305132-3"
 label="Sâzkâr">sāzkār</makam>

is migrated to:

<mei:classCode authURI="http://www.corpus-musicae-ottomanicae.de/api/v1/classifications/cmo_usuler" xml:id="id13ced91d"/>
<mei:termList classcode="#id13ced91d">
<mei:term>us-20798235-2</mei:term>
</mei:termList>
<mei:classCode authURI="http://www.corpus-musicae-ottomanicae.de/api/v1/classifications/cmo_makamler" xml:id="id528d80f1"/>
<mei:termList classcode="#id528d80f1">
<mei:term>mk-15305132-3</mei:term>
</mei:termList>

The text content of the elements does represent the original spelling given in the source and must therefore be kept. At least somewhere in the entity.

http://cmo.gbv.de/cmo/receive/cmo_source_00003577?XSL.Style=xml works
http://cmo.gbv.de/cmo/receive/cmo_source_00001808?XSL.Style=xml gives 503

In source we use http://music-encoding.org/documentation/2.1.1/provenance/
this must be migrated to http://music-encoding.org/documentation/3.0.0/history/ (including stylesheets for metadata presentation)

e.g.
http://cmo.gbv.de/cmo/receive/cmo_person_00000529?XSL.Style=xml
has only one mei:name with a nymref but for each ref there should be a extra mei:name with a ref!

search forms for Musikstück (expression), Quelle (source) und Liedtext / Lyrics (expression) should contain fields for

• language (rfc4646)
• script (iso15924)

according to the new data model:

<langUsage>
  <language xml:id="tur" authority="rfc4646" />
  <language xml:id="ota-latn" authority="iso15924" />
</langUsage>

a search field "contributor" is issing, (searching: mei.editor ; mei.author ; mei.respStmt ; mei.handList)

e.g. "CMO_NE207 14 NE207" should find:
http://cmo.gbv.de/cmo/receive/cmo_expression_00001437

in the Catalogue, MODS are bibliographical items (secondary literature mostly)
in the Edition, MODS are the Puplications of the Edition

• Identifikator should be removed

fields targeting information in related entities are missing:

• date (from composer)
• date (from lyricist)
• source type (from source)*
• notation type (from source)*
• date (from source)*
• checkbox "Faksimile" (= is related to a source with an attachment)*
• checkbox: "CMO edition" (= has a relation to an edition entity)
  see also the language/script fields are missing: #36

/* "from source" means from "top" source, not from the directly related source that is part of source (formerly known as source components)

Note: the search form "konkretes Musikstück" (the simple one) might be obsolete.

Notation type Early Hampartsum Notation is missing in the vocabulary and in the data.

http://cmo.gbv.de/cmo/receive/cmo_source_00001808
see: http://quellen-perspectivia.net/en/cmo/ms-63903364-7