Dyskusja_lektury: Dyskusja lektury:Dublin Core/Implementacja prosta
Skopiowano ze stron roboczych projektu Wolne Podręczniki
Spis treści |
Problemy
- Problem: potrzebujemy ujednoznacznić zawartość pól (atrybutów) DC. Chcemy wiedzieć, że w danym polu jest data śmierci, data urodzenia, tłumacz itd. -- by móc te dane łatwo eksportować (gdy w polu mamy i imię, i nazwisko, i daty śmieci, i dane identyfikujące -- "cesarz Francuzów" -- robi się to bardzo kłopotliwe).
- Inny problem: schemat wypracowywany przez polskie biblioteki zdaje się nie spełniać wymagań porządnego XML-a.
- Przykład (pierwszy przykładowy opis, do którego odsyła Poradnik redaktora zasobów cyfrowych): widać tu, że miejsce wydania jest podpolem pola wydawca. Tymczasem w źródłowym RDF/XML (źródło przykładowego opisu) oba te pola są w sensie XML równorzędne:
<dc:publisher xml:lang="pl">[Nürnberg]</dc:publisher>
<dc:publisher xml:lang="pl">Endter, Wolfgang, (sen.)</dc:publisher>
- można się tylko domyślać, że umieszczenie "Nürnberg" w nawiasach kwadratowych jakoś oznacza podrzędność tego pola względem wydawcy (???). To wygląda po prostu na bałaganiarstwo (po co XML, jeśli się takie rzeczy wymyśla?). Warto poszukać lepszego rozwiązania. (Skądinąd z tego powodu miejsce wydania nie zostało na razie uwzględnione propozycji naszego schematu).
Propozycje rozwiązań
- 0 - Quick and dirty hack zaimplementowany na stronie Lektury:Andersen/Brzydkie kaczątko - eliminujemy daty śmierci z pola dc:creator/contributor i umieszczamy je w polu <dc.rights> które nie ma sformalizowanej struktury ("ostatnia" data śmierci potrzebna jest do określenia statusu w domenie publicznej). W polu <dc.creator> i <dc.contributor> zostawiamy tylko imiona w formacie Nazwisko, Imię. Pole <dc.contributor> uzupełniamy opisem kontrybucji (<dc.contributor.translator>, <dc.contributor.technical_editor> etc). Pola <dc.subject> rozszerzamy do <dc.subject.period>, <dc.subject.genre> itd. Ponieważ (jeśli to dobrze zrozumiałem) DC jest nauczony opuszczać rozszerzenie jeśli go nie rozumie uzyskamy walidującą się i zrozumiałą implementację schematu DC która jest w miarę łatwa do obsłużenia.
- 1. Pierwsze rozwiązanie, to wymieszanie Dublin Core z innymi schematami (i, w razie potrzeby, tagami dosypanymi przez nas):
<dc:creator xml:lang="pl">
<person:last_name>Kochanowski</person:last_name>
// co z nazwiska wieloczłonowymi? Tworząc taką strukturę musimy znać odpowiedź na to pytanie
<person:first_name>Jan</person:first_name>
<person:second_name></person:second_name>
// drugie imię, inicjał, przydomek lub nick
<person:birth_date>1530</person:birth_date>
<person:death_date>1584</person:birth_date>
// można oczywiście iść na wersję ekstremalną i
// zdefiniować osobny standardowy blok zapisu daty (rok, miesiąc, dzień, rodzaj kalendarza itp.)
</dc:creator>
- 2. Zrobić to bardziej zgodnie z samym Dublin Core (oczywiście, o ile dobrze zrozumiałem ich zalecenia), czyli stworzyć jakiś schemat Dublin Core z kwalifikatorami). Kwalifikatory definiuje słownik dcterms.xsd. Przykład zapisu z kwalifikatorem:
<dc.identifier.dcterms:URl> jakiś-URl </dc.identifier.dcterms:URl>
Tak np. implementuje DC fiński system bibliotek akademickich przykładowy rekord. Wygląda to na znacznie porządniejszą implementację niż naszych bibliotek (patrz: Poradnik redaktora zasobów cyfrowych).
Kłopot polega na tym, że wielu potrzebnych nam kwalifikatorów nie ma w dcterms.xsd, np: 'ISBN', dlatego (jeszcze raz: o ile dobrze rozumiem) zdefiniować w xsd własny słownik rozszerzający standardowy słownik kwalifikatorów. Powiedzmy, że nazwiemy go wlterms.xsd i że zawierać on będzie definicję ISBN. Wtedy możemy w opisie pozycji podać:
<dc.identifier.wlterms:ISBN> jakiś-ISBN </dc.identifier.wlterms:ISBN>
Definicje wlterms.xsd powinny być stworzone analogicznie do dcterms.xsd. Ale można by wtedy zdefiniować nasze dane w jakaś porządniejszą strukturę, np.:
- autor
- nazwa
- nazwisko [albo nazwa zwyczajowa: Gal Anonim, uwaga: holenderskie 'van' razem z nazwiskiem]
- imię
- drugie imię
- elementy poprzedzające nazwisko [von, de itp.]
- tytuł [św., bł., sir, hrabia itd.]
- przydomek [albo: herb, zawołanie itd., np: Boy]
- opis
- data urodzenia
- data śmieci
- fraza identyfikująca [cesarz Francuzów, papież, wódz Hunów...]
- nazwa:alt [może powielać dowolne pola nazwy, przykład: Tadeusz Gałecki, gdy nazwa używana to Andrzej Strug]
- .......................
- .......................
- opis:alt [analogicznie]
- nick [albo adres e-mail]
- tytuł
- używany tytuł
- pełny tytuł
- itd.
- 3. Zrobić powyższe na skróty i bardzo nieporządnie, ale szybko. To znaczy robić opisy zawierające wypełnione standardowe pola Simple DC, dosypując do nich ujednoznacznień rozumianych przez nasze aplikacje. To przykładowe dane z takiego pliku:
<dc:creator xml:lang="pl">Andersen, Hans Christian (1805-1875)</dc:creator> <autor_pierwsze_imie>Hans</autor_pierwsze_imie> <autor_drugie_imie>Christian</autor_drugie_imie> ............................................... <autor_data_smierci>1875</autor_data_smierci>
- 4. A może wykorzystać też TEI? Informacje: samodzielny nagłówek metadanych: [[1]], nagłówek metadanych tekstu kodowanego zgodnie z TEI: [[2]].
Co lepsze??? Czy dobrze rozumiem???
Autor
Czy mamy jakieś istotne powody, aby rozdzielać imię (lub imiona), nazwisko oraz daty urodzenia i śmierci?
Nie! Zupełnie wystarczy nam jedno pole informacji o autorze, jeśli wzorem BN będziemy używali w miarę jednolitego sposobu jego formatowania, zgodnego z opisem z www.BibliotekaCyfrowa.pl - oto najistotniejszy fragment: "dopowiedzenia ujmuje się łącznie w nawiasy okrągłe z odstępem przed nawiasem otwierającym. Jeżeli jest więcej niż jedno dopowiedzenie, oddziela się je średnikiem z odstępami po obu jego stronach. Daty biograficzne oddziela się łącznikiem. Przykłady:
Napoleon I (cesarz Francuzów ; 1769-1821) Joanna d'Arc (św. ; 1412-1431)
Gdybyśmy jednak chcieli rozdzielać te pola, to musimy stworzyć osobną strukturę bloku dla opisu wszystkich występujących w metadanych osób (creator, contributor, editor itp.) - jak w schemacie LOM, na przykład:
<dc:creator xml:lang="pl">
<person:last_name>Kochanowski</person:last_name>
// co z nazwiska wieloczłonowymi? Tworząc taką strukturę musimy znać odpowiedź na to pytanie
<person:first_name>Jan</person:first_name>
<person:second_name></person:second_name>
// drugie imię, inicjał, przydomek lub nick
<person:birth_date>1530</person:birth_date>
<person:death_date>1584</person:birth_date>
// można oczywiście iść na wersję ekstremalną i
// zdefiniować osobny standardowy blok zapisu daty (rok, miesiąc, dzień, rodzaj kalendarza itp.)
</dc:creator>
Jest to jednak tylko hipotetyczne ćwiczenie - nie chcemy tak komplikować naszych metadanych.
Coverage
standardowy element:
<dc:coverage xml:lang="pl"> zakres </dc:coverage>
wydaje się zbędny i został pominięty w schemacie. Więcej informacji: http://forum.biblioteka20.pl/viewtopic.php?t=116
