↑0. Bevezető

↑0.1 Az ajánlás célja

Ez az ajánlás a digitális formában, szöveges illetve képi tartalommal szolgáltatott időszaki kiadványok (köznyelven: elektronikus folyóiratok) public domain környezetben való publikációjával kapcsolatban fogalmaz meg egyszerűen kivitelezhető, ésszerű megoldásokat.

A public domain kontextusban való publikálás alatt azt értjük, hogy a kiadvány

• olyan, pl. HTML-ben megírt héjszerkezetben jelenik meg, mely ugyanúgy böngészhető, mint pl. egy weblap
• hozzáférése korlátozások nélkül lehetséges adott környezetben

Ez a szöveg a könyvtári módszertan szolgáltatás-centrikus elvei alapján készült. Azaz az itt leírtak nem kiadvány-szerkesztési tanácsok, és nem számolnak olyan publikációs megfontolásokkal, mint például az arculat, design, vagy egy nyomtatott változat megjelenésének elektronikusan stilizált tükrözése – nem is zárják azonban ki az ilyen elképzeléseket, amennyiben azok nem ütköznek a megfogalmazott módszerekkel. Az ajánlott eljárások tehát kizárólag funkcionálisak, és a tartalom szolgáltatásának megfelelő módjaira figyelnek, az alábbi fő elvek szerint:

• azonosíthatóság
• szerkezet
• hozzáférhetőség
• megőrzés

↑0.2 Célközönség

Az ajánlás a közgyűjteményi szakmának, elsősorban digitalizálással foglalkozó könyvtárosoknak készült. Tartalma feltételez némi tapasztalatot az időszaki kiadványok könyvtári kezelésében, valamint használatához nem árt az internetes publikációban használt specifikációk (pl. megjelenítési formátumok) és az azokhoz kapcsolódó szoftverek alapvető ismerete.

↑0.3 Mire nem tér ki ez az ajánlás?

• Az ajánlás nem tartalmaz részletekbe menő technikai megoldásokat minden kérdésben. Csak olyan technikai specifikációkat nevez meg, illetve mutat be részletesebben, melyek
  • nem, illetve csak nagyon nehezen megkerülhetők (HTML, URL, PDF, JPG stb.)
  • melyek kevéssé ismertek, de az adott feladat kiküszöbölésére nem ismerünk egyszerűbb vagy gazdaságosabb megoldásokat. Ebben az esetben tehát csak olyan technológiai eljárásokra térünk ki, melyekkel kapcsolatban közelebbi tapasztalatokkal rendelkezünk.
• Az ajánlásban az egyes szoftveres megoldások ismertetése semmiképp sem a szoftver dokumentálása. Az ismertetett megoldások egy-egy gyakorlati szempontra világítanak rá a szoftver használatában, nem ismertetik a teljes munkafolyamatot és semmilyen tekintetben sem helyettesítik a szoftver dokumentációját.
• Az ajánlás nem foglalkozik a publikáció tárgyával pl. tartalmi szempontok szerint. Nem nyújt szelekciós szempontokat arra nézve, hogy mit, milyen mélységig kell digitalizálni.
• Az ajánlás nem foglalkozik a folytatódó kiadványok digitális változatához kapcsolódó jogi, illetve szerzői jogi kérdésekkel.
• Az ajánlás nem cikk-alapú rendszerek tervezéséhez készült. A cikk-inventóriumok építéséhez ajánlatos bonyolultabb adatbázis-alapú rendszerekre természetesen más megfontolások érvényesek, melyek kívül esnek jelen dokumentum céljain.
• Továbbá, az ajánlás az „időszaki” kiadvány fogalmában gondolkodik, nem tartja tehát szem előtt az integrálódó kiadványok szempontjait. Integrálódó kiadványok publikációja nehezen oldható meg adatbázis-támogatás nélkül. Meg kell jegyezni ugyanakkor, hogy az itt megfogalmazottak részleteiben (pl. a cikkszintre vonatkozó javaslatoknál) megfontolandók az integrálódó kiadványok publikálói számára is.
• Az ajánlás csak szöveges és képi információra épülő kiadványokkal foglalkozik, a multimédiás, valamint FLASH-alapú publikáció például meghaladja a határait.

↑0.4 A digitális időszaki kiadvány meghatározása

A dokumentumban leírt tevékenységek tárgya a digitális időszaki kiadvány.

Ez lehet csak digitális formában létrehozott és olvasható kiadvány, de lehet egy időszaki kiadvány retrospektív digitalizálásának szolgáltatási formátuma, azaz használati végterméke is. (A használati végtermék itt azt jelenti, hogy a digitalizált anyagnak az a része és változata, amit pl. az olvasó is használni fog.)

Megjegyzés: Az ajánlás szövegében a digitális időszaki kiadvány és az elektronikus időszaki kiadvány szinonim kifejezések.

Ami közös ezekben a kiadványokban:

• megjelenésük időbeli kiterjedéssel bír, azaz folytatódó jellegűek
• megjelenésük folyamán közös azonosító adatok tömörítik tartalmukat egy kiadványba
• megjelenésük részegységekben történik, ezek a részegységek elkülöníthető egységként adódnak a tartalom egészéhez, mint pl. füzetek, számok, különszámok
• azonosítható a részegységek viszonya a kiadvány egészéhez képest (tehát egy „szám”-ról meg lehet állapítani, hogy a kiadvány melyik évéhez, évfolyamához tartozik)

Felmerülhet a kérdés, hogy miért kötjük magunkat ehhez a hagyományos struktúrához, mikor az elektronikus formátum adta lehetőségek rugalmasabban is kezelhetnék a kiadványok megjelenését.

Az indoklás gyakorlati jellegű: jelen helyzetben valószínűbb, hogy olyan kiadványok publikációjáról beszélünk, melyek egy nyomtatott kiadvány megfelelői, vagy digitális változatai. Az elektronikus változatok presztízse ugyanakkor még nem megalapozott a jelenlegi könyvtári univerzumban. Az egyik fontos lépcső az elektronikus formátum hiteles dokumentumként való elismertetése felé a hivatkozási etika elveinek figyelembe vétele, azaz annak szem előtt tartása, hogy mindig pontosan megállapítható legyen az adott tartalom forrása. Ez az időszaki kiadványok esetében még mindig stabilan a kiadvány és az azon belüli rész azonosításával történik. Jelenleg nincs okunk arra, hogy ettől az elvtől eltérjünk, sőt betartásával nagyban javulhat az elektronikus források minősége és így elismertsége is.

↑0.5 Verziók

A tárgyalt kiadványcsoporttal kapcsolatban ki kell emelni még egy nagyon fontos jellemzőt. Digitális időszaki kiadványok kétféleképpen jöhetnek létre:

Egy hagyományos hordozón létező kiadvány digitális felhasználási célra készült reprodukálásával, mely lehet

• retrospektív
• párhuzamos az eredeti megjelenésével
• kizárólag digitális felhasználási célra készítve

Az 1. pont esetében a kiadványunk az eredeti dokumentum verziója. Egy eredetinek több elektronikus verziója is létezhet.

↑1. Azonosíthatóság

↑1.1 A digitális időszaki kiadvány felépítése

A digitális időszaki kiadvány dokumentum-tipológiailag nem különösebben tér el a hagyományos periodikumoktól. A szakmai gyakorlat megkönnyítése érdekében tehát célszerű úgy gondolni rá, mint a már megszokott dokumentumformára.

A digitális időszaki kiadvány létrehozásában igyekezzünk azt megfeleltethetővé tenni a hagyományos hordozón elérhető verziók szerkezetével. A szerkezet minden eleme legyen önálló egységként azonosítható.

Fontos szerkezeti elemnek tekintendők:

• címoldal
• évfolyam
• szám
• tartalomjegyzék
• impresszum (vagy hasonló funkciójú elem)
• cikk

Hasznos, de önállóan nem feltétlenül azonosítandó szerkezeti elemek:

• rovat
• illusztráció
• mutató

↑1.2 A digitális időszaki kiadvány címoldala

Ha a kiadvány egésze felől közelítünk, akkor először a nyitólapot (azaz címoldalt) látjuk. Itt találhatók a kiadványt mint egységet azonosító adatok, illetve innen elérhetők a kiadványra mint egészre vonatkozó adatok. A nyitólapról kezdhetjük meg a navigációt a dokumentum egészén belül, tehát az évfolyamok és számok között. Hasonlatképp gondolhatunk a hagyományos címoldalra, mint a könyvtári leírás alapforrására.

↑01.1 Ajánlás: Az internetes környezetben közzétett, elektronikus időszaki kiadvány (továbbiakban kiadvány) rendelkezzen önálló nyitólappal.

A nyitólap egyben a kiadvány címoldalául szolgál. A címoldal (a hagyományos könyvtári értelmezésben) a kiadványt alkotó elektronikus dokumentum-szerkezet kiindulópontja, tehát egyben nyitólapja.

A nyitólap akkor tudja betölteni a címoldal funkciót, ha közzéteszi a kiadványra jellemző adatokat. Ezek közül legfontosabb a főcím, ezért fontos tényező az azonosíthatóság és elérhetőség szempontjából. A bibliográfiai feldolgozás szempontjából a címoldal képviseli az egész kiadványt mint bibliográfiai egységet.

[Ld.: 2.1.4.1]

Ha kézbe veszünk egy hagyományos időszaki kiadványt (pl. egy folyóirat-számot), akkor láthatjuk, hogy a címoldal minden részegység elején megtalálható, és az ott található adatok változhatnak a kiadvány élete során. Ezt a folyamatot lehetséges ezen kiadvány elektronikus változatában is tükrözni, tehát lehet önálló nyitólapja pl. minden számnak, de az elektronikus publikáció szempontjából fontos, hogy legyen egy közös címoldala az egész kiadványnak, és ez csak azokat az adatokat tartalmazza, melyek a kiadvány minden egyes részegységére igazak. Ez fogja biztosítani az elektronikus számok összetartozását (ahogy hagyományos keretben például az tenné, hogy egymás mellett találhatók egy gyűjtemény polcain.)

A címoldalból úgy lesz nyitólap, hogy a kiadványt alkotó digitális dokumentum-egység legkülső szintjén helyezkedik el, tehát pl. a tartalomra utaló linkek ahhoz képest „befelé” (pl. alkönyvtárakba) fognak mutatni. Ezek a linkek értelemszerűen a nyitólapon találhatóak.

↑1.3 Azonosítás és elérés a világhálón

Ha az elektronikus időszaki kiadványt public domain közegben közzétesszük az interneten, akkor fontos, hogy ne csupán a tartalomra, hanem a hozzáférésre nézve is egyértelmű azonosító adatokat biztosítsunk (ahogy pl. egy hagyományos kiadvány jelzet alapján található meg egy gyűjteményen belül, vagy ISSN-szám alapján az időszaki kiadványokat azonosító nemzetközi rendszeren belül).

Az interneten használatos azonosítók közül a legelterjedtebb az URL, mely az „Uniform Resource Locator” (egységes forrásmegjelölő) kifejezés rövidítése. Ez nem más, mint annak az oldalnak (a nyitólapnak) a webcíme, amelyen keresztül a kiadvány megtalálható.

↑01.2 Ajánlás: Az interneten publikált elektronikus kiadvány azonosítója legyen egy URL-cím, mely a kiadvány nyitólapjára (azaz a címoldalra) mutat. Az így azonosított nyitólap mindig csak egy kiadvány szerkezetébe vezessen.

Ha interneten publikáljuk tehát a kiadványt, az egy olyan honlapként fog megjelenni, melynek URL-címe beírásával a címoldal (nyitólap) jelenik meg. Ha olyan lapon tesszük közzé a kiadványt, melyen keresztül például több folyóirat tartalma is elérhető, már nem azonosítottuk egyértelműen azt az adott URL-címmel.

Megfelelő URL-ek például:

https://efolyoirat.oszk.hu/Mercurius_Veridicus

vagy

https://efolyoirat.oszk.hu/html/vgi/ujepa_borito.phtml?id=904

Előfordul, hogy ha egyszerre több kiadványt digitalizál, a publikáló közös honlapot készít az egész gyűjteménynek. Ez jó gyakorlat, amennyiben a gyűjtemény nyitólapjáról elérhetők a kiadványok egyedi nyitólapjai. Ha egy URL tartalmazza több kiadvány címoldal-adatait, vagy elektronikus szerkezetének legkülső szintjét, akkor az a kiadvány már nem lesz egy az egyben azonosítható, mint internetes forrás, lévén egy URL-címet több főcímhez lehet rendelni. Lehet, hogy ez az olvasói gyakorlatban nem okoz problémát, de ha például internetes forrásokat leíró rendszerben akarjuk katalogizálni őket, szinte lehetetlen lesz azok önálló kiadványként való kezelése, mivel a legjellemzőbb azonosító – az URL – nem lesz egyedi, hanem az összes ott található kiadvány leírásához hozzá kell rendelni.

↑01.3 Ajánlás: A kiadvány összes fontos szerkezeti egysége az interneten URL-en keresztül legyen azonosítható.

Hogy az interneten elérhető kiadvány összes fontos szerkezeti egysége önállóan azonosítható legyen, rendeljünk a nyitólaphoz hasonlóan önálló URL-t mindegyikhez, természetesen a kiadványt azonosító nyitólapi honlapcím szerkezetén belül.

Pl.:

• Statikus szerkezetű kiadványoknál:
  • Az 1900-as év első száma: http://konyvtarunk.hu/folyoiratunk/1900/01/
    A folyóirat generikus impresszuma: http://konyvtarunk.hu/folyoiratunk/impresszum.html
    ez esetben az önálló egység külön alkönyvtár illetve külön fájl
• Dinamikus szerkezetű kiadványoknál:
  • Az 1900-as év első száma: http://konyvtarunk.hu/folyoiratunk.php?ev=1900&szam=01
    A folyóirat generikus impresszuma: http://konyvtarunk.hu/folyoiratunk.php?id=impresszum
    ez esetben az önálló egység külön adatbázis-tétel

[Ld.: 02.1.A Ajánlás]

↑1.3.1 Az URL kiegészítő lehetőségei

Az URL-es azonosítás problémái abból fakadnak, hogy az URL lelőhelyet azonosít. Gyakran fordul elő, hogy egy weblap és vele együtt a hozzá tartozó dokumentumok más szerverre költöznek, vagy az eredeti szerveren megváltoztatják helyüket a könyvtárstruktúrában. Ilyen esetekben, a helyét megváltoztató dokumentumra mutató, korábban elhelyezett hivatkozások hibaüzenetet („HTTP 404 - File not found”) adnak vissza. A gyakorlatban lehetetlenség minden ilyen helyváltozás alkalmával értesíteni a külső hivatkozásokat elhelyező személyeket, és automatikus indexelő robotokat. A problémát az is súlyosbítja, hogy egy interneten elérhetővé tett dokumentumra mutató összes külső hivatkozást gyakorlatilag lehetetlen kinyomozni. Ezért legjobb a bajt megelőzni.

Az alább tárgyalt azonosító szisztémák, az URL-től eltérően, nem a dokumentum lelőhelyét azonosítják, hanem magát a tartalmat. Általában egy központi szolgáltatás keretében biztosítanak a hipertexthez hasonlóan „kattintható” azonosítókat. A weboldal létrehozóinak pedig az adott központi szolgáltatónál kell jelezni, ha az URL megváltozik. Így azok a külső hivatkozások, amelyek ezt az alternatív azonosítót használják, továbbra is működőképesek maradnak.

Az URN (Universal Resource Name)

Az URN szintaxisát az RFC 2141-es számú ajánlása rögzíti. Magyarországon az Országos Széchényi Könyvtár vezette be az URN egyik altípusát a URN:NBN (National Bibliography Number) azonosítót. Az URN:NBN azonosítók az URN azonosítók egy olyan altípusába tartoznak, amely felett minden országban a nemzeti könyvtár rendelkezik.

http://nws.iif.hu/ncd2003/docs/ehu/EHU-16.htm

http://nbn.urn.hu

PURL (Persistent URL - Állandó URL)

Az Egyesült Államokban működő OCLC (Online Computer Library Center) által kifejlesztett technika az interneten gyakran változó URL címek nyomon követésére.

http://purl.oclc.org

DOI (Digital Object Identifier)

Magyarországon az Adatbázis Jogvédő Egyesület (AJE) végzi a DOI azonosító regisztrációját. A DOI szintaxisában helyet kaphatnak már létező nemzetközi azonosítók, mint az ISSN vagy ISBN stb. DOI regisztrálásakor kötelező jelleggel meg kell adni bizonyos metaadatokat. 

Linkajánló:
The Digital Object Identifier System
http://www.doi.org
DOI-leírások
http://www.aje.hu/html/l22.html
EDitEUR - Co-ordinating the development, promotion and implementation of Electronic Commerce in the book and serials sectors
http://www.editeur.org

ISSN (International Standard Serial Number – Nemzetközi szabványos sorozati azonosító)

Az időszaki kiadványok nemzetközi rendszerben történő azonosítására szolgáló szabvány. Funkciója a nyomtatott kiadványoknál elsősorban a terjesztésben volt (melynek az elektronikus kiadványoknál nagyjából a „hozzáférés” fogalma felel meg.). Az ISSN-nyilvántartás alapján – melynek kontrollját a nemzeti ISSN-irodák látják el, a párizsi Nemzetközi ISSN Központ felügyelete alatt – bármely beszámozott kiadvány rögtön felismerhető.

Az ISSN-szabvánnyal kapcsolatban jelenleg éppen az azonosítás terén fedezhetők fel problémák. Gyakran előfordul ugyanis, hogy egy public domain elektronikus kiadvány nyomtatott megfelelőjének ISSN-számát tünteti fel impresszumadataiban. Ennek oka, hogy szakmai tekintetben még nincsen megnyugtató szabályozás arra nézve, hogy milyen feltételek mellett szükséges egy elektronikus változat önálló ISSN-nel való azonosítása. Ugyanakkor könnyen belátható, hogy a hagyományos és digitális formában megjelenő változatok több kulcsfontosságú tulajdonságban eltérhetnek. Ha az ISSN nem alkalmas megkülönböztetésükre, akkor ez szabvány nem tekinthető azonosítható értékűnek a digitális kiadványok közegében.

↑01.4 Ajánlás: Az interneten publikált kiadványukhoz az URL-azonosítón kívül biztosítsunk legalább egyféle alternatív azonosítási lehetőséget.

Az itt felsorolt szabványok magyarországi működése még nem teljesen olajozott. Ennek ellenére célszerű az URN-címek létesítése, mert a szabvány használatának és ismertségének terjedése visszahathat az üzemeltetés biztosabbá tételére. Főként a közgyűjteményi szféra érdeke a minőségi és főként biztos internetes azonosítási technológiák meghonosítása. Jelenleg a nemzeti könyvtár üzemeltet URN-szervert, melyen lehetőség van online források stabil bejegyeztetésére.

Linkajánló:
URN szolgáltatás az Országos Széchényi Könyvtárban
http://nbn.urn.hu
Horváth Ádám (OSzK): URN használata a hálózati dokumentumok azonosításában (prezentáció)
http://nbn.urn.hu/share/presentations/oszkkm_030612/UrnOszkKm_01.pdf

↑1.4 Az elektronikus kiadvány azonosíthatósága

Adott kiadvány azonosításának másik dimenzióját képezik a bibliográfiai adatai. Egy kiadvány bizonyos jellemzőinek összessége által azonosítható egy kiadványként. A könyvtári katalógusokban egy kiadványt egy katalógustétel képvisel. Nem elég tehát önálló szerkezeti egységeket képeznünk a kiadvány építőelemeiből, beszédessé is kell tennünk azokat, azáltal, hogy minél elérhetőbb formában feltüntetjük rajtuk a kiadványt leíró adatokat.

Az időszaki kiadvány esetén bizonyos adatok a kiadvány minden részegységére nézve igazak. Például, függetlenül attól, hogy a kiadvány melyik részegységét (pl. számát) tekintjük, a főcím mindig ugyanaz lesz. Ez az adat a kiadvány egészére érvényes, ezért annak minden szintjén ki kell derüljön. Ha egy olvasó az interneten böngészve téved be például egy elektronikus időszaki kiadványban közölt cikk szövegéhez, az esetben ki kell hogy derüljön számára, hogy ez pl. valamely folyóiratban megjelent tanulmány – még ha nem is annak nyitólapja felől jutott el a cikkig. Fontos tehát az is, hogy a kiadványt alkotó dokumentumstruktúra bármely pontján állva világos legyen, hogy mely kiadvány, mely egységét olvassuk éppen.

↑1.4.1 Metaadatok

↑01.5 Ajánlás: Minden azonosítható szinthez rendeljünk metaadatokat. A metaadatokat közöljük egységes, más ágensek számára is értelmezhető és az általunk választott formátumhoz igazodó adatsémák szerint.

Egy helyesen szerkesztett digitális időszaki kiadvány felhasználója számára minden ponton világos, hogy mi az a kiadvány, amelyet épp böngész, és annak épp melyik részegységét tanulmányozza, hiszen a természetes intelligencia számára egyértelmű formában elhelyeztük a lap kezdetén, a hivatkozásokban, illetve minden lehetséges kiemelt helyen.

Nem elég azonban csak a felhasználó számára befogadható formában rögzíteni ezeket az adatokat. Előfordulhat, hogy automatizált rendszerek fogják használni a dokumentumot, melyek számára esetleg semmit sem mond az egyértelműen elhelyezett, tipográfiailag kiemelt címadat.

A digitális formátum egyik előnye, hogy közvetlenül a dokumentumban elhelyezhetünk gépi rendszerek számára értelmezhető, illetve azok segítségével könnyen kezelhető információkat. Erre alapulnak olyan kezdeményezések például, mint az Open Archives Initiative (OAI), melynek célja a digitálisan feltárt leíró adatok minél hatékonyabb automatizált adatcseréje a digitális gyűjtemények, adatbázisok és könyvtári adatbázisok között.

Számos szabványos, illetve ajánlott megoldás jött létre arra nézve, hogy minél egységesebb formában helyezzük el a lényeges leíró adatokat a kiadványokban, és így minél több rendszer tudja azokat egységesen kezelni. Ilyenek a könyvtári kezdeményezésre született Dublin Core (DC), vagy az Adobe Systems által létrehozott XMP-adatsémák.

Természetesen sok tekintetben nem született még megnyugtató és mindenütt elterjedt megoldás. Egyes digitális formátumok esetében – mint pl. a HTML-ben publikált szöveges tartalom – ugyanakkor már kézenfekvőnek mondható eljárás, hogy a dokumentum leíró adatait a HTML-fájl fejlécében helyezzük el, legegyszerűbben a Dublin Core-szabvány segítségével.

[Ld.: még: H.2.5 Ajánlás]

A Dublin Core  tulajdonképpen egy alapjaiban nagyon egyszerű, de egyéni igények szerint könnyen módosítható adatséma. Szabályai szerint könnyen leírhatunk egy elektronikus dokumentumot, és az adatokat el is helyezhetjük abban, mégpedig az adatcsere szabványos formájában. (Ahogy pl. régebben a könyvhöz katalóguscédulán mellékeltük a szabványos bibliográfiai leírást.)

A Dublin Core előre definiált adatkészletet biztosít, melyekben leírhatók az olyan alapvető adatok, mint pl. a cím, a szerző, a jogtulajdonos stb. Ezeket közölhetjük önmagukban, pusztán a funkció megjelölésével.

Ez például:

dc_title="Nyugat"

már egy elfogadható címközlés, amennyiben elhelyeztünk mellette egy hivatkozást egy meghatározott Dublin Core adatsémára.

A Dublin Core alapelemeit a minősítők használatával finomíthatjuk. Ezek mentén sok specifikált Dublin Core-változat alakult ki. Ha ismerünk, és használhatónak találunk egy ilyen variációt, akkor hivatkozzunk arra és fejezzük ki abban az adatokat. Ha nem, akkor maradjunk a lehető legegyszerűbb szinten az adatelemek leírásánál, így minél több rendszer számára érthetőek maradunk. Igyekezzünk elkerülni, hogy a szabvány rugalmasságát kihasználva saját adatstruktúrát készítsünk gyűjteményünk sajátosságaihoz igazodva. Ez megkönnyítheti feldolgozó munkánkat, de éppen a Dublin Core egyik fő létokát, a rendszerek közötti adatcserét teszi nehezebbé.

A Dublin Core mellett hasonlóképp használható, de fejlesztésben némiképp nagyobb erőfeszítéseket követel a MARC-formátum. Ennek használatát akkor javasoljuk, hogyha elég pontos képünk van arról, hogy milyen egyéb rendszerekkel, például metaadatbázisokkal akarunk együttműködni adataink átadásával, és tudható, hogy melyik MARC-szabványra lesz szükség. Több formátum együttes fenntartása egy gyűjteményen belül nem kifizetődő.

Az adatséma kiválasztásában a legfőbb szempontjaink legyenek

• egyszerűség – csak a kiadványunk illetve, több kiadvány esetén, gyűjteményünk jellege által megkívánt legfontosabb adatok leírására vállalkozzunk
• interoperabilitás – igyekezzünk megmaradni már kész megoldásoknál, azokat csak akkor szabjuk testre saját igényeinkhez mérten, ha az mindenképp szükséges

↑01.6 Ajánlás: A kiadvány metaadatainak közlésében használjuk a céljainkhoz képest lehető legegyszerűbb, lehető legszélesebb körben elfogadott adatsémát.

Elektronikus kiadványunk Dublin Core-leírásait elkészíthetjük a Magyar Elektronikus Könyvtár fejlesztésében készült DC-generáló szolgáltatás segítségével, mely a https://mek.oszk.hu/dc/ címen található.

Ez a szolgáltatás lehetővé teszi, hogy az elkészített leírást elhelyezzük anyagaink fejlécében (már amennyiben a formátum ezt lehetővé teszi), valamint elmenthetjük XML formátumban, további feldolgozásra.

[Ld.: még: 4.2.4]

↑01.7 Ajánlás: A metaadatokat minden szinten tegyük hozzáférhetővé a tartalomtól függetlenül is.

Ha időszaki kiadványt szeretnénk publikálni, akkor legalább kétféle dokumentumtípus adatairól kell számot adnunk. Ez a kiadvány egésze (összefoglaló) valamint az abban található részegységek és/vagy közlemények (analitika) szintje. Egy elektronikus időszaki kiadvány esetében nem ajánlatos pl. csak a kiadvány címét közölni a metaadatokban, mert így nem lesz elérhető információ arra nézve, hogy az adott tartalomrész hogyan is viszonyul az egészhez. Ezért a közlendő leíró adatok eltérőek lesznek a kiadvány különböző pontjain (pl. más-más számokban megjelent, különböző cikkekre vonatkoztatva). Erre tekintettel kell lennünk az adatsémánk megfogalmazásánál is. A különböző szinteken mást fog jelenteni pl. a „cím”, hiszen a kiadvány nyitólapjába ágyazva a "dc_title" elem tartalma a kiadvány főcíme lesz, egy cikk esetében azonban már a cikk címe, a kiadvány címe pedig a kapcsolatot jelző elembe fog kerülni. Az elemek értelmezése tehát dinamikus.

Ajánlott adatstruktúra:

Kiadvány szintjén:

dc_title="főcím" (nem ismételhető)

dc_contributor="szerkesztő vagy közreadó (személy vagy testület)" (ismételhető)

dc_publisher="kiadó ill. digitális formátum előállítója" (ismételhető)

dc_subject="téma" (ismételhető)

dc_format="formátum" (ismételhető)

dc_identifier="URL" (nem ismételhető)

dc_relation="kapcsolódó kiadvány URL-je" (ismételhető)

dc_language="tartalom nyelve" (ismételhető)

dc_rights="jogtulajdonos" (ismételhető)

Részegység szintjén (pl. egy szám tartalomjegyzékénél)

dc_title="főcím" (nem ismételhető)

dc_contributor="szerkesztő vagy közreadó (személy vagy testület)" (ismételhető)

dc_publisher="kiadó ill. digitális formátum előállítója" (ismételhető)

dc_date="megjelenési adat, keltezés" (nem ismételhető)

dc_identifier="URL" (nem ismételhető)

dc_relation="kapcsolódó kiadvány URL-je" (ismételhető)

dc_source="forráskiadvány kezdőlapjának azonosítója (pl. URL)"

dc_language="tartalom nyelve" (ismételhető)

dc_rights="jogtulajdonos" (ismételhető)

Közlemény szintjén:

dc_title="cím" (nem ismételhető)

dc_contributor="szerző, közreműködő" (ismételhető)

dc_publisher="kiadó ill. digitális formátum előállítója" (ismételhető)

dc_subject="téma" (ismételhető)

dc_format="formátum" (ismételhető)

dc_identifier="URL" (nem ismételhető)

dc_source="forráskiadvány kezdőlapjának azonosítója (pl. URL)"

dc_language="tartalom nyelve" (ismételhető)

dc_rights="jogtulajdonos" (ismételhető)

Példa a kiadvány leírására a MEK rendszerében:

<link rel="schema.DC" href="http://purl.org/dc/elements.1.1/" />

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />

<meta name="DC.title" content="Természet" />

<meta name="DC.creator.personalName" content="Kunoss Endre" />

<meta name="DC.publisher.corporateName" content="Országos Széchényi Könyvtár" />

<meta name="DC.publisher.corporateName.Address" content="http://www.oszk.hu"/>

<meta name="DC.identifier" scheme="URL" content="https://epa.oszk.hu/termeszet" />

<meta name="DC.relation" content="https://epa.oszk.hu/lombok" />

<meta name="DC.date.dateDigitized" content="2007-12-02" />

<meta name="DC.date.issued" content="2008-02-28" />

<meta name="DC.format" scheme="IMT" content="application/pdf" />

<meta name="DC.format" scheme="IMT" content="text/html" />

<meta name="DC.format" scheme="IMT" content="image/jpeg" />

<meta name="DC.type" content="Text" />

<meta name="DC.type" content="StillImage" />

<meta name="DC.subject" scheme="ETO" content="508" />

<meta name="DC.subject" scheme="ETO" content="550" />

<meta name="DC.subject" scheme="ETO" content="570" />

<meta name="DC.subject" scheme="ETO" content="580" />

<meta name="DC.subject" scheme="ETO" content="590" />

<meta name="DC.subject" scheme="ETO" content="630" />

<meta name="DC.subject" scheme="ETO" content="910" />

<meta name="DC.coverage.spatial" content="Buda" />

<meta name="DC.coverage.temporal" content="1838" />

<meta name="DC.language" scheme="ISO639" content="hun" />

<meta name="DC.rights" scheme="URL" content="http://efolyoirat.niif.hu/static/copyright.html" />

<meta name="DC.date.X-MetadataLastModified" scheme="W3CDTF" content="2008-01-22"/>

Linkajánló:
Dublin Core metadata editor
http://www.ukoln.ac.uk/metadata/dcdot
Dublin Core Metadata Templates
http://dublincore.org/tools/#creatingmetadata
DCMI Tools and Software
http://dublincore.org/tools

Dublin Core specifikáció (ISO 15836-2003)
http://dublincore.org/documents/dces/

Magyar fordítás (Magyar Szabvány MSZ ISO 15836)
Információ és dokumentáció. A Dublin Core metaadat elemkészlete
https://mek.oszk.hu/dc/szabvany/134715.pdf

MEK Dublin Core generátor dokumentáció
https://mek.oszk.hu/dc/sugo.html

↑1.4.2 A bibliográfiai egység

Ha időszaki kiadványt publikálunk, akkor úgy kell kialakítani az így előálló dokumentum-struktúrát, hogy egésze egy kiadványnak feleljen meg. Ez esetben a feldolgozás alapja a kiadvány, és az egyik fontos feladat, hogy egyértelműen azonosítható legyen: mi is ez a kiadvány. A dokumentum-struktúra minden elemére ugyanazon alapvető adatok érvényesek, és ezek az adatok azonosítanák a kiadvány egészét, mint egy egységet, ha azt például egy katalógusban vagy bibliográfiában le szeretnénk írni.

[Ld.: még 1.4.1]

Hogy ez egyértelmű legyen, a következőképpen ajánlatos eljárni:

↑01.8 Ajánlás: A kiadvány nyitólapján legyenek feltüntetve a legfontosabb bibliográfiai adatok (főcím, verzió, azonosító, kiadó, szerzői jogok, bibliográfiai kapcsolatok), melyek jelentős megváltozása esetén bibliográfiai értelemben új kiadványról, új bibliográfiai egységről beszélünk:

Főcím:

A kiadvány egyik legfontosabb adata; a címoldalon tipográfiailag kiemelt karaktersorozat

URL:

A címoldal elérésére szolgáló internet-cím. A HTML-fejlécben való feltüntetésének módját ld. a vonatkozó fejezetben.

[Ld.: H 2.4.3]

Az alábbi adatok szintén fontosak, de változásuk nem feltétlenül jelent új kiadványt:

Kiadó:

Fontos, hogy azonosítható legyen a forrás elérhetővé tételéért felelős intézmény vagy magánszemély.

Szerzői jogok tulajdonosa:

Jogtulajdonos neve, jogkezelésre vonatkozó megjegyzés.

Verzió:

Ha a dokumentum egy létező kiadvány verziója, mindig tegyük egyértelművé, hogy mi az a kiadvány, amelynek megfeleltethető, és mi a változatok közötti viszony.

Egyéb bibliográfiai kapcsolatok:

A kiadványhoz valamilyen formában kapcsolódó folyóiratok, források adatai (előzmény, folytatás, repertórium stb.)

↑1.5 Egyéb fontos információ-források

A kiadvány nyitólapján, vagy arról webes hivatkozással közvetlenül elérhető helyen célszerű elhelyezni egyes kísérő információkat. Ilyenek az impresszum-adatok, valamint, amennyiben retrospektív digitalizálásról van szó, ajánlatos információkat elhelyezni a kiadvány sajtótörténeti hátterével kapcsolatban. Ezen kívül az impresszumban, vagy önálló dokumentumban közöljük a kiadvány használatával kapcsolatos esetleg fennálló jogi megkötéseket is.

↑1.5.1 Impresszum

Amikor impresszumról beszélünk, nem feltétlenül szigorú értelemben a hagyományos kiadványoknál megszokott tartalomrészre gondolunk. Ezt kiválthatja bármiféle, információtartalmában egyenértékű megoldás, pl. visszatérő fejléc vagy lábléc, önálló menüpont a kiadvány honlapján, vagy akár a tartalomjegyzékben elhelyezett információ is (bár ez utóbbi nem mindig szerencsés). Az impresszumadatokat azonban mindig tegyük elérhetővé emberi felhasználók számára is értelmezhető formában legalább a címoldalról, vagy az egyes számok nyitólapjáról, ne korlátozzuk ez ilyen információt kizárólag pl. a fájlfejlécekre..

↑01.9 Ajánlás: A kiadványban mindig helyezzünk el a nyitólapról elérhető, naprakész és következetes impresszum-jellegű adatokat.

Kurrens kiadvány esetén fontos, hogy az impresszumadatokat is frissítsük az állomány gyarapodásával párhuzamosan (természetesen, csak ha változnak).

Amennyiben egy impresszumot helyeztünk el az egész dokumentumegységre vonatkozólag, akkor annak tartalmát kell naprakészen tartani.

Amennyiben minden újabb számnál közöljük ismét az impresszumot, ott mindig aktuális adatokat közöljünk.

↑01.10 Ajánlás: Az impresszumban – illetve az azt helyettesítő tartalomrészben – közöljük az azonosításhoz szükséges adatokat.

Az alábbi adatokat ajánlatos közölni:

• a tartalmi részért felelős személyek neve és közreműködésük jellege (főszerkesztő, felelős szerkesztő, szerkesztőbizottsági tag stb.)
• a technikai megvalósításért felelős személyek neve és közreműködésük jellege (tördelőszerkesztő, elektronikus változat készítője stb.)
• a tartalomért felelős testület(ek) és elérhetőségeik
• a kiadó és jogtulajdonos, és elérhetőségeik
• általános elérhetőségi adatok (címek, e-mail címek, telefonszámok)
• technikai tudnivalók
• jogi kitételek

↑1.5.2 A kiadvány bemutatása

A digitalizálás állományvédelmi funkciója mellett fontos odafigyelni az így előállt források információs kapacitására is. Egy digitális változat különösebb erőfeszítés nélkül foglalhat magában kísérő információkat a kiadványról, szakmai hátteret, a sajtótörténeti kontextus bemutatását, így válhat archiváló módszer mellett tartalmilag értéknövelt szolgáltatássá.

↑01.11 Ajánlás: Amennyiben retrospektív digitalizálásról van szó, mindenképp kívánatos a kiadvány történetével, sajtótörténeti jelentőségével kapcsolatos információk feltüntetése.

Ajánlatos ezen kívül beszámolni a digitalizálás gyakorlati körülményeiről, a digitális változat technikai jellemzőiről is:

• digitalizálás eszköze
• eredeti példány jellemzői és lelőhelye
• digitalizálás felelőse
• keletkezett anyag mennyisége és formátuma

↑2. Szerkezet

A több egységből álló dokumentum-struktúra használatánál nagyon fontos, hogy mind a felhasználó, mind az esetleges feldolgozó (gépi illetve emberi) eligazodjon a tartalmon belül. Ebben a fejezetben az ilyen jellegű tájékozódás módjairól lesz szó.

Elektronikus időszaki kiadvány szerkesztésénél mindig ügyeljünk arra, hogy a kiadványt alkotó dokumentum-szerkezet kövesse a tartalmat képező részegységek (pl. évfolyam, szám, cikk) struktúráját. Ez a struktúra egyrészt legyen világos a felhasználó számára is – azaz az olvasó mindig tudja, hogy éppen mely kiadvány mely egységét olvassa (struktúra), és hogy mennyi és milyen egyéb tartalomhoz férhet még hozzá (navigáció). Célszerű továbbá tükrözni a kiadvány szerkezetét a dokumentum-struktúrában is. Ez alatt azt értjük, hogy a kiadványt alkotó egységek (statikus szerkezetnél például a könyvtárak-alkönyvtárak) felépítése és az azok közötti kapcsolatok (pl. az egyes állományokban található hiperhivatkozások) tükrözzék a tartalmi felépítést. Az alábbiak figyelembevételével mind az emberi felhasználók, mind a gépi rendszerek (pl. mirror-szoftverek) jobban tájékozódnak a kiadvány tartalmában.

Ha jól átgondoltuk a kiadványunk leendő szerkezetét, akkor azzal párhuzamosan azt is el kell döntenünk, hogy az internetes megjelenéshez milyen technikai megvalósítást választunk. Erre háromféle megoldás létezik:

1 Statikus könyvtárstruktúra

Ebben a megoldásban minden disztinkt egység önálló fájlt alkot, és a kiadvány egységét a fájlok közötti hiperhivatkozások adják meg.

• Előnyei:
  • nem igényel speciális kompetenciákat (pl. programozói ismereteket)
  • nem igényel speciális rendszerfeltételeket (meglévő webszerverünkre feltölthető)
  • könnyen migrálható
  • időtálló
• Hátrányai
  • elkészítése időigényes és nagy következetességet igényel
  • a keresési funkciók korlátozottak
  • nem lehetséges a hozzáférési szintek kezelése

Mindent összevetve a könyvtári szakma szempontjából sok szempontból ez az ideális megoldás kisebb intézmények számára.

2 Kész digitális dokumentum-kezelő rendszerek alkalmazása

Számos ilyen rendszer született a könyvtári szakmához közeli körökben, és napról napra újak jelennek meg. Ezeknek az alkalmazásoknak többsége nemcsak publikációs, de dokumentumkezelési megoldásokat is biztosít. A legjelentősebb – többnyire nyílt forráskódú – intézményi fejlesztések:

Eprints

http://www.eprints.org/

Fejlesztő: Joint Information Systems Committee (Egyesült Királyság),  National Science Foundation (USA)

A hagyományos publikálás elveire épülő publikációs rendszer, különösen cikkadatbázis-jellegű szolgáltatások körében elterjedt.

Dspace

http://www.dspace.org/

Massachusetts Institute of Technology Library (USA), Hewlett Packard

Sokoldalú gyűjteménykezelő alkalmazás, szemlélete túlmutat a hagyományos dokumentumkezelést modellező szerkezeten.

Fedora

http://www.fedora-commons.org/

University of Virginia, Cornell University (USA)

Intézményi gyűjtemények és digitális könyvtárak számára készített háttér-alkalmazás, saját felhasználói felület nélkül.

Greenstone

http://www.greenstone.org/

New Zealand Digital Library Project University of Waikato (Új-Zéland), UNESCO, Human Info NGO

Kifejezetten digitális könyvtárak üzemeltetésére készített szoftvercsomag.

A fentebb soroltak csupán a legelterjedtebbek a számos elérhető alkalmazás közül. Ennél egyszerűbbek és a közintézményi szférán kívül is szélesebb körben elterjedtek a tartalomszolgáltató rendszerek (Content Management System, CMS). Ezek bemutatása nem része az ajánlásnak, a legteljesebb magyar forrás ezekről a szolgáltatásokról a http://cms.lap.hu/ honlapról érhető el.

• A kész dokumentumkezelő-rendszerek előnyei
  • a kész struktúra jelentős szakmai tapasztalatot ötvözve biztosít számos alapértelmezett szolgáltatást
  • egységes és időhatékony munkafolyamatok
  • hozzáférési szintek kezelése
• Hátrányai:
  • konfigurálásuk üzemeltetésük programozói kompetenciát igényel
  • speciális rendszerigényekkel jár
  • a gyűjtemény esetleges migrációja járulékos programozói munkával jár
  • szoftveres háttere miatt gyorsabban elavulhat

3 Saját fejlesztésű adatbázis-támogatott rendszer

Ennek elkészítését a gyűjtemény nagyon speciális jellege indokolja. Jelenleg a legtöbb rendelkezésre álló kész megoldás fel van készülve minden eshetőségre, ugyanakkor lehet olyan intézmény, mely a meglévő rendszerek komplikált bekonfigurálása helyett a saját fejlesztés mellett dönt.

• Előnyei
  • testreszabott lehetőségek
  • egységes és időhatékony munkafolyamatok (a fejlesztés minőségétől függően)
  • hozzáférési szintek kezelése
• Hátrányai
  • fejlesztése és üzemeltetése jelentős programozói kompetenciát igényel
  • fokozottan ügyelni kell a rendszer dokumentálásra
  • speciális rendszerigényekkel jár
  • a gyűjtemény esetleges migrációja járulékos programozói munkával jár
  • szoftveres háttere miatt gyorsabban elavulhat

↑2.1 Egy ajánlott szerkezet

Kiadványunk adatbázisban való elhelyezésével sok járulékos funkciót és lehetőséget biztosíthatunk. Ilyenek a különböző keresési opciók, böngészési nézetek. A tartalomszolgáltatási tendenciák ilyen rendszerek irányában mozognak. Ez a megoldás ellenben kockázatos, ha az így előállt tartalmak fenntarthatóságára gondolunk. Az adatbázisban történő publikáció mindig eggyel több rétegű kompetenciákra épül: programozói ismeretek kellenek hozzá. Mindig mérlegeljük tehát a következőket:

• hosszú távon biztosan rendelkezésünkre fog-e állni ez a kompetencia? Ez függhet intézményünk financiális ill. strukturális helyzetétől.
• meg tudjuk-e oldani az általunk készített dinamikus struktúra, ill. annak részei migrációját nagyobb rendszerekbe, ha erre szükség adódik?
  Itt az együttműködési kilátásainkat és terveinket kell átgondolni.

↑2.1.1 Könyvtárstruktúra

Az elektronikus kiadványunk szerkezetét egészen egyszerű eszközökkel, egymásba épülő könyvtár(directory)-hierarchiával is kialakíthatjuk, úgy, hogy ez megfeleljen a tartalmi felépítésnek. Ezáltal már a dokumentum formájában, illetve rendszerszintű kezelésnél (pl. ha kötegelt parancsállományokkal akarunk módosítást végrehajtani) lehetséges az orientáció.

Az alábbiakban egy olyan szerkezetet ajánlunk, mely erre az egyszerű modellre épül. Ebben a megoldásban a dokumentum gyökere maga a kiadvány, a böngészés annak kezdőlapjával kezdhető meg.

↑02.1 Ajánlás: A kiadvány egésze alkosson következetes könyvtárstruktúrát. Külön könyvtárba a kiadványnak önálló száma, tényleges melléklete, különszáma illetve kapcsolódó segéddokumentuma – pl. repertórium, bibliográfia, kumulált index – kerüljön.

↑02.1.A Ajánlás: Struktúra –
Alapszint, a kiadvány gyökérkönyvtára:

A gyökérkönyvtárban találhatók az egyes részegységeket tartalmazó alkönyvtárak, valamint esetleg a kiadvány-szintet egészében jellemző fájlok pl.: címoldal, impresszum, a kiadvány egészéhez kapcsolódó segéd-dokumentumok – amennyiben nem akarjuk azokat is külön könyvtárban elhelyezni. Az állományonként ismétlődő, az arculatot meghatározó képi fájlokat, stíluslapokat a kiadvány gyökér-szintjén kell elhelyezni, elkerülve azok számonként való megismétlését, és elősegítve ezzel, hogy a kiadványon globális változtatásokat lehessen elvégezni.

Amennyiben szükségesnek tűnik (mert pl. a kiadvány viszonylag sűrűn jelenik meg), csoportosíthatjuk a kiadvány-számokat évenként külön könyvtárba.

↑02.1.B Ajánlás: Struktúra –
Az egyes részegységek szintje:

A kiadvány gyökérkönyvtárán – vagy az abban létrehozott évenkénti könyvtárakon – belül mechanikus sorszámozással, vagy más, de következetesen felépített elnevezésekkel követik egymást az egyes számok alkönyvtárai. Praktikus elnevezési mód például: számozási (év, évfolyam, szám) adatok ékezet és szóköz nélkül. Ezekben a könyvtárakban helyezzünk el minden fájlt ami adott számhoz tartozik.

Ne készítsünk külön alkönyvtárat a legújabb vagy aktuális szám számára, ahonnan később áthelyeznénk azt, mivel ez változó jellemző, s nem magát a részegységet, hanem egy kiadvány ideiglenes állapotát azonosítjuk vele. Az így elhelyezett egység elérhetősége nem lenne állandó, így nem is lesz azonosítható.

↑2.1.2 A kiadvány szintjei és a navigáció

Az időszaki kiadvány részegységek összefüggő halmaza. A részegység a hagyományos hordozónál „szám”, „kötet” stb., és amennyiben a digitális kiadvány szerkezete lehetővé teszi, tartsuk meg és tegyük világossá ezt a struktúrát. A számok, részegységek folytonos egymásra épülése alkotja a kiadványt, ezért fontos tudni, hogy az adott közlemény pontosan a kiadvány mely helyén és mikor jelent meg.

↑02.2 Ajánlás: Tegyük mindig világossá, hogy hol is állunk a kiadványon belül (bárhol is nyissuk ki épp a dokumentumot).

Ha a felhasználó kívülről (pl. keresőszolgáltatás segítségével), szabadszöveges információ nyomán jut el a tartalomhoz, legyen rögtön egyértelmű számára, hogy milyen jellegű forráshoz, s azon belül mely részhez jutott el. Ez az igény túlzónak tűnhet, de fontos a betartása, annak érdekében, hogy javuljon a hivatkozási fegyelem az elektronikus kiadványok estében. Ez hosszú távon az elektronikus tartalom minőségi fejlődését segítheti elő.

A szerkezeten belüli tájékozódás elősegítésének két, egymást kiegészítő módja:

↑02.3 Ajánlás: Helyezzük el a kiadvány szintjének megfelelő leíró adatokat minden egyes fájlban szabad szemmel olvasható módon, valamint a választott fájl-formátum erre szolgáló adatmezőjében.

Ha a leíró adat magát a tartalmat hordozó fájlon belül is megtalálható, akkor az adat nem „idegeníthető el”, azaz megmarad, még akkor is, ha adott fájlt mozgatjuk (pl. a felhasználó lementi a számítógépére).

[Ld.: még: 3.2.1.3 D Ajánlás; H 2.4.3; 4.2.4]

Egy időszaki kiadvány olvasásánál legalább háromszintű hierarchiával kell számolnunk: egy kiadványon belül vagyunk, annak egyik száma valamely cikkét olvassuk.

↑02.4 Ajánlás: Tegyük lehetővé a biztos navigálást a szerkezeti egységek között.

Adjunk módot arra például, hogy az olvasó az éppen előtte levő egységről közvetlenül a szám tartalomjegyzékére, vagy a kiadvány nyitólapjára léphessen. Indokolt esetben ennél több szintet is azonosíthatunk, és hasznos, ha ezek között egyszerű a közlekedés.

Lehetséges azonosítható szintek:

• kiadvány
• mutató
• év
• részegység
• tartalomjegyzék
• rovat
• cikk
• jegyzetek
• rezümé

Az ideális navigációs struktúra a következő funkciókat foglalhatja magában

• Mindig legyen lehetőség a struktúrában egy szinttel feljebb lépni pl.: cikkről tartalomjegyzékre, tartalomjegyzékről évfolyamra.
• Minden szintről el lehessen jutni közvetlenül a kiindulópontra.

Cikkek, vagy részegységek szintjén lehessen lépegetni az adott szint egymás után következő egységei mentén pl.: évről következő/előző évre, számról következő/előző számra, cikkről következő/előző cikkre.

Cikk szintjén biztosítsuk a kétirányú navigációt a törzs (pl.: cikk szövege vagy mutató felsorolása) és a referenciális egységek (pl.: lábjegyzet vagy mutatóban hivatkozott cikk) között.

↑2.1.3 Fájlnevek

Statikus fájlrendszer használatával mi dönthetünk arról, hogyan nevezzük el az egyes állományokat (szemben az adatbázis-szerkezet bonyolultabb, paraméterezett azonosítóival). Itt használhatunk beszédes elnevezéseket (sőt, ez kifejezetten szerencsés), de az ajánlásban megfogalmazott korlátok figyelembevételével. Erősen ajánlott, előre rögzített szabályok alapján, az egész kiadványban következetesen elnevezni a közleményeket tartalmazó fájlokat.

↑02.5 Ajánlás: A fájlnevekben ne használjunk ékezetes karaktereket, szóközöket, és kerüljük az egyéb speciális karaktereket is annak érdekében, hogy azok minden operációs rendszeren, bármely internet böngésző alkalmazással elérhetők legyenek.

↑02.5.A Ajánlás: A fájlnevekben elfogadható karakterek: az angol ABC 26 betűje (kisbetűk), arab számok 0-9-ig, alávonás (_), rövid kötőjel (-).

Gyakori megoldás, hogy az egyes cikkeket tartalmazó dokumentumok neve a szerző nevének kisbetűs, ékezet nélkül leírt változata, pl.: "madach.html". Technikailag ez teljesen megfelelő, de nem bír azonosító jelleggel, ugyanis ez a név többször visszatérhet kiadványon belül. Célszerűbb, ha az egyes részegységeket numerikus jellegű (pl. a számozásra, keltezésre utaló) állománynevekkel látjuk el.

pl.:

1999_05_14.html - azaz: az 1999. évi 5.szám 14. cikke,vagy

2003_01_222_230.pdf - azaz: a 2003. évi 1.szám 222-230 oldal közötti tartalom.

↑2.1.4 Az elektronikus időszaki kiadvány szerkezete

Az alábbiakban arra vonatkozó javaslatok olvashatók, hogy az egyes szerkezeti egységeket milyen formában fejezhetjük ki legegyszerűbben a kiadványstruktúrán belül.

↑2.1.4.1 Címoldal

Mivel public domain megjelenésről beszélünk, a felhasználó mindig honlapként fogja megközelíteni a kiadványunkat, ezért fontos, hogy ez az oldal mindig szöveges alapú hipertext (HTML, XHTML stb. szabványok) formájában jelenjen meg.

↑02.6 Ajánlás: A kiadvány címoldala mindig legyen önálló egység a kiadványszerkezeten belül, formátumára nézve pedig legyen weben hivatkozható hipertext-dokumentum

↑2.1.4.2  Év, évfolyam illetve egyéb tömb

Főleg hosszú életű kiadványoknál okozhat navigációs problémát, ha nincs lehetőség az év- illetve évfolyam-egységek közötti mozgásra. Ajánlatos hiperhivatkozásként kifejezni ezeket az egységeket, melyeket követve az egyes éveken, évfolyamokon belüli részegységek listáját kapjuk.

↑02.7 Ajánlás: Az év- illetve évfolyamegységeket ajánlatos elkülöníteni önállóan hivatkozható navigációs egységként.

Ezt megoldhatjuk úgy is, hogy a címoldalon helyezünk el hivatkozást az évfolyamegységekre, amennyiben ezt az ott elhelyezett egyéb tartalom mennyisége lehetővé teszi.

↑2.1.4.3  Szám

Ez az időszaki kiadvány egyik legjellemzőbb szintje, két adatdimenzió jellemzi:

• Számozás, keltezés
• Tartalomjegyzék

Számozás és keltezés

A számozás és keltezés határozza meg a részegység pozícióját a kiadvány egészén belül. Ez az adat a kiadványszámot alkotó összes állományban fel kell hogy tűnjön, ha lehet látható illetve szoftveresen olvasható formában is. A számozási adatok közlése nagyon fontos például a hivatkozási etika szempontjából is. Gondoljunk arra, hogy egy public domain kiadvány bármely pontjáról elérhető az interneten, például keresőmotorok segítségével. Ha a felhasználó egy cikk-egységnél lép be a kiadványba, nem feltétlenül egyértelmű számára, hogy pontosan milyen dokumentumon belül jár. Elterjedt gyakorlat, hogy például a cikk címe és szerzője megtalálható a dokumentumban, de a forrásadat – a kiadvány címe és számozási, keltezési adatai – nem. Ez nem teszi lehetővé a dokumentum bibliográfiai azonosítását.

↑02.8 Ajánlás: A kiadvány-számokat alkotó összes adatállományban szerepeljen a kiadvány címe és a részegység számozási és keltezési adata. Amennyiben az állomány formátuma lehetővé teszi, az adatok egyben legyenek hivatkozási pontok a kiadvány megfelelő szintjére.

A kiadvány címénél a címoldalra, a számozási és keltezési adatoknál a tartalomjegyzékre helyezzünk el hivatkozást.

↑2.1.4.4 Tartalomjegyzék

Ha a számnak nem készül önálló nyitólapja, akkor a tartalomjegyzék-állomány képviseli a részegységet. Itt megtalálhatók a számozási és keltezési adatok, valamint a szám struktúráját reprezentáló adatok és hivatkozások.

↑02.9 Ajánlás: A tartalomjegyzék mindig legyen önálló egység a kiadványszerkezeten belül, formátumára nézve pedig legyen weben hivatkozható hipertext-dokumentum. Amennyiben a tartalom megköveteli, a tartalomjegyzék legyen szöveges adat.

A szöveges tartalomtól a következő esetekben tekinthetünk el:

• nagyon komplikált struktúrájú, szegmentált tartalom (pl. napilapok, illusztrált humoros lapok, bibliográfia ill. mutató-jellegű kiadványok)
• nagyon egyszerű struktúrájú, illetve tagolatlan tartalom (régi újságlevelek, egy közleményből álló kiadványszámok, mellékletek)

↑02.10 Ajánlás: Az adott részegység összes leíró adata – cím, számozási és keltezési adatok – szerepeljenek a tartalomjegyzékben szöveges és szoftveresen értelmezhető formában, akkor is, ha a tartalomjegyzék szöveges kifejtésétől eltekintünk. A közölt leíró adatok egyben legyenek hivatkozási pontok a kiadvány megfelelő szintjére.

Ha az egyes számokhoz szöveges tartalomjegyzéket készítünk, mindig mérlegelnünk kell, hogy milyen mélységig adjuk vissza a részegység struktúráját. Ezt általában az határozza meg, hogy milyen dokumentumtípusról van szó (pl. folyóirat, napilap, magazin, diáklap stb.) Az adott típus szintjén releváns egységeket fejezzük ki önálló elemként a tartalomjegyzékben.

Példa: Egy szabályos struktúrájú szakfolyóiratban például fontos információ, hogy az adott közlemény melyik állandó rovatban helyezkedik el, vagy milyen illusztrációk tartoznak a közleményekhez, ezért a tartalomjegyzékben feltüntetjük a rovatokat illetve a fontosabb illusztrációs mellékleteket is. Egy diáklapban azonban a rovatszerkezet lehet informális, ötletszerű, az illusztrációk pedig nem rendelkeznek önállóan azonosítandó tartalommal, így külön jelölésüktől el lehet tekinteni.

A kiadvány tartalomjegyzéke a következő tipológiai szinttel alkot metszetet, a közlemények, cikkek szintjével. Mivel önmagában is struktúraképző, illetve egy további réteg adatait közvetíti, indokolt, hogy szabályozott formában közöljük, hogy például kommunikálható legyen nyilvántartások, adatbázisok felé.

Dinamikus publikációs struktúránál gyakori megoldás hogy tartalomjegyzék-adatokat adatbázisban tároljuk el. Ennél a megoldásnál is alkalmazható, valamint a statikus szerkezetekben tárolt adatok továbbhasznosítására alkalmazható áthidaló megoldás a címkézett szöveges adatformátum, legfőképpen az XML.

Az XML legelőnyösebb tulajdonsága ezen a ponton az, hogy a gyűjteményünkhöz szabható struktúrát definiálhatunk benne a cikkadatok tárolására.  A következő alpontban egy olyan megoldás található, mely a kiadványok nagy részénél elegendő mélységű tartalomjegyzék-struktúrát eredményez.

↑2.1.4.4.1 A tartalomjegyzék struktúrája

A tartalomjegyzék egésze (TOC = table of contents). Tartalmazza a formai leíró adatokat és a tényleges tartalomjegyzék-információt.

• Formai adatok:
  • A kiadvány címe
  • A kiadvány internetes elérhetősége
    (A címoldal URL-je illetve perzisztens azonosítója)
  • A kiadvány azonosítószáma a leíró gyűjteményen belül
    (Amennyiben több kiadvánnyal foglalkozunk)
  • A szám keltezési és számozási adata a kiadványon feltüntetett formában
    (igyekezzünk úgy leírni, ahogy a kiadványon szerepel. A speciális karaktereket transzliteráljuk illetve kódoljuk, a római számokat minden esetben írjuk át arab számra)
  • A szám keltezési és számozási adata formailag szabályozott (automatikus sorba rendezést lehetővé tevő) formában
    (Ezzel szabályozhatjuk például a listázási sorrendet, mivel a számozási adatok természetes formája nem minden esetben értelmezhető automatikusan)
  • A szám (tartalomjegyzék) internetes elérhetősége (URL)
• Tényleges tartalomjegyzék
  • Rovat
    (Amennyiben a kiadványnak van visszatérő rovatstruktúrája, és a különböző rovatokban található cikkek funkcionálisan és tartalmilag sajátosak. Nem ismétlődő rovatoknál a nagyobb tematikus blokkokat képviselő egységeket érdemes felvenni)
  • Rovatcím
    (Amennyiben a rovat egész tartalmáról ad tematikus információt)
  • Szerző neve
    (Érdemes tagolni névelemekre. Elég nagy gyűjteményeknél célszerű a névegységesítést is megoldani)
  • Cikk címe
    (Kiegészítő címadatokkal)
  • A cikk nyelve
  • A cikk tartalmi összefoglalója
  • A cikk kezdő és záró oldalszáma
    (Amennyiben az elektronikus változat megtartja a nyomtatott változat formai jellemzőit)
  • Tematikus szám
    (A mennyiben releváns tematikus információt jelent a szám egészével kapcsolatban)
  • Melléklet, képmelléklet
    (Amennyiben a szám teljes tartalmához kapcsolódik.)

A fentebb leírt szerkezet kifejezése egy lehetséges XML dokumentumtípus-definícióban:

<?xml version="1.0" encoding="utf-8"?>

<!ELEMENT Pack (TOC+)>

<!ELEMENT TOC (Head, (Contents|NoContents), Notes?)>

<!ELEMENT Head (dc_title, Issue, dc_identifier, URIEPA, ev_szam_URL)>

<!ELEMENT dc_title (#PCDATA)>

<!ELEMENT Issue (#PCDATA)>

<!ELEMENT dc_identifier (#PCDATA)>

<!ELEMENT URIEPA (#PCDATA)>

<!ELEMENT ev_szam_URL (#PCDATA)>

<!ELEMENT Contents (Section | Article)+>

<!ELEMENT Section (Link?, SectionTitle?, Article+)>

<!ELEMENT SectionTitle (#PCDATA)>

<!ELEMENT Article (Language+, Link*, Author*, Title, Range?, Description*, Note*)>

<!ELEMENT Language (#PCDATA)>

<!ELEMENT Link (#PCDATA)>

<!ELEMENT Author (#PCDATA | FamilyName | GivenName)*>

<!ELEMENT FamilyName (#PCDATA)>

<!ELEMENT GivenName (#PCDATA)>         

<!ELEMENT Title (#PCDATA | br | em | strong)*>

<!ELEMENT Range (#PCDATA)>

<!ELEMENT Description (p+)>

<!ELEMENT p (#PCDATA | br | em | strong | a)*>

<!ELEMENT br EMPTY>

<!ELEMENT em (#PCDATA)>

<!ELEMENT strong (#PCDATA)>

<!ELEMENT Notes (themeTitle?, Note*)+>

<!ELEMENT themeTitle (#PCDATA)>

<!ELEMENT Note (p+)>

<!ELEMENT NoContents (#PCDATA | Link)*>

<!ELEMENT a (#PCDATA)>

<!ATTLIST
a href CDATA #REQUIRED>

<!ATTLIST Author        
invert (yes|no) "no"
type (extracted) #IMPLIED
>

<!ATTLIST Section       
type (supplement|insert) #IMPLIED>

<!ATTLIST Description
lang CDATA "hu">

<!ATTLIST Issue
year CDATA #REQUIRED
number CDATA #REQUIRED
type (html|pdf|jpg|gif) "html"

>

A tartalomjegyzékeket tároljuk erre vagy ehhez hasonló adatstruktúrára épülő XML-állományban, melyből egyszerűen előállíthatjuk a felhasználók számára a HTML-formátumú tartalomjegyzékeket, például az XSLT-technológia segítségével XSL-stíluslapot rendelve a tárolt változathoz. Ennek a megoldásnak további előnye, hogy egyaránt hasznosítható statikus illetve dinamikus rendszerű kiadványstruktúrákhoz.

↑2.1.4.5 Cikk

Az intellektuális tartalom szempontjából ez a dokumentum legfontosabb szintje, hiszen a digitális publikálásnál a magát a tartalmat akarjuk előállítani. Ehhez képest a többi szintnek tehát inkább formai jelentősége van.

Ezen a szinten van a legnagyobb szabadságunk arra nézve, hogy milyen megoldást választunk a tartalom közlésére. Ez a digitális állományok kérdésköre, mellyel az ajánlás teljes 3. fejezete (Hozzáférhetőség) foglalkozik.

↑2.1.4.5.1 Cikken belüli szerkezet

Az egyes közlemények szintje természetesen tovább bontható annak saját belső struktúrája alapján. Mi jelen ajánlásban nem foglalkozunk a cikk struktúrájával, mivel az inkább a cikk-adatbázisok készítésének alapvető kérdése.

Ugyanakkor természetesen dönthetünk úgy, hogy visszaadjuk a közlemény szerkezetét teljes mélységében. Az ilyen információk tárolására és kinyerésére egyszerű megoldás az XML illetve címkézhető PDF.

A cikk-szerkezet meghatározásához készíthetünk saját sémát, illetve használhatunk elterjedt, XML-technológiát hasznosító dokumentum-sémákat is. Ilyen a TEI (Text Encoding Initiative) keretében készült szövegkódolási nyelv, mely számos dokumentumtípusra nézve ajánl szerkezetleírási megoldásokat.

A Magyar Elektronikus Könyvtár forrásai között elérhető egy meglehetős részletességgel kidolgozott struktúra-definíció, főleg tudományos folyóiratokban megjelent publikációkhoz, mely a TEI-Lite szabványra épül:

TEI Lite XML DTD folyóirat-rovathoz és folyóiratcikkhez
https://mek.oszk.hu/mekdtd/article/TEI-MEK-article.dtd

Inkább szaktudományos és technikai jellegű tartalomhoz pedig ajánljuk az OASIS fejlesztésében készült, valamivel összetettebb szerkezetű DocBook dokumentumkezelő sémát.

Linkajánló

OASIS
http://www.oasis-open.org/home/index.php

TEI
http://www.tei-c.org/index.xml

DocBook
http://www.docbook.org/

↑2.1.5 Mobilitás

↑02.11 Ajánlás: Az elektronikus időszaki kiadvány tartalmán belül csak relatív hivatkozásokkal kössük össze az azt alkotó állományokat.

Elképzelhető az a helyzet, hogy a teljes elektronikus kiadványnak költözni kell egyik szolgáltató környezetből egy másikba. Ez a migráció. Hogy ez technikailag ne okozzon problémát, a kiadvány szerkezete mindig legyen önmagába záródó, azaz a legfelső szint alatt elhelyezkedő strukturális egységek csak egymáshoz képest legyenek meghatározva. A kiadványban és az esetleges mutatókban szereplő hiperhivatkozásokban csak relatív útvonalakat adjunk meg.

Az egyes szintekhez tartozó kiegészítő tartalmat (pl.: a cikkekbe ágyazott ábrák, multimédiás elemek, indexek) azonos szinten helyezzük el, vagy ugyanazon a szinten belül erre kialakított könyvtárban. Vagyis például a cikk szintjén egy adott adategység (pl. alkönyvtár) tartalmazza a cikk összes alkotóelemét.

↑3. Hozzáférhetőség

↑3.1 Általános ajánlások

Hozzáférhetőség alatt azt értjük, hogy a kiadványunkból álljon rendelkezésre egy olyan változat, amely különösebb erőfeszítés nélkül elérhető tartalmat biztosít a felhasználók minél szélesebb körének, minél többféle körülmények között.

Milyen speciális helyzetekre kell itt felkészülnünk?

• a felhasználó nem rendelkezik nagysebességű vagy állandó internet-kapcsolattal, illetve korlátozott az átvihető adatmennyisége
• felhasználó nem tud, vagy nem óhajt speciális szoftvereket vagy szoftverkomponenseket használni a tartalom megtekintéséhez (kereskedelmi szoftverek, plug-inek)
• a felhasználó további feldolgozás céljából használja az anyagot
• a felhasználó online szeretné használni a tartalmat
• a felhasználó offline szeretné használni a tartalmat
• a felhasználó ki szeretné nyomtatni a tartalmat
• a felhasználó nem tud vagy nem óhajt vizuális megjelenítést használni
• a felhasználó testi fogyatékossággal rendelkezik
• a felhasználó nem a nyitólapon kezdi meg a böngészést

A fenti – csupán illusztrációs céllal felsorolt – szituációk nem fedik le mindazokat a lehetséges nehézségeket, melyek az elektronikus dokumentumok használatával kapcsolatban felmerülhetnek. Nem is célunk ezek tételes és teljes körű számbavétele, ez ugyanis a tartalom akadálymentesítésének kérdéskörébe vezetne át. Ezekkel kapcsolatban rendelkezésekre állnak további ajánlások, melyek átfogóan körbejárják ezeket a kérdéseket. Ezeket mindenképp tanulmányozásra ajánljuk:

Felhasználói ágensek hozzáférhetőségi irányelvei 1.0

https://mek.oszk.hu/egyesulet/palyazatok/vakbarat/uaaghunabc1.htm

– ha programfejlesztéssel kell foglalkoznunk

Webes tartalmak hozzáférési irányelvei 2.0

https://vmek.oszk.hu/vmek2/wcag_20hu.phtml

– ha tartalomfejlesztéssel foglalkozunk

Megjegyzés: A fentebb hivatkozott két magyar fordítás nem az ajánlások hatályos verziójáról készült.

Összefoglalva a fenti példák kérdéskörét, a következő egyszerű javaslatokat tehetjük, melyek alkalmazásával a lehetséges problémák nagy részét elkerülhetjük:

↑03.1 Ajánlás: Alkalmazzunk közvetlenül böngészhető formátumokat (melyekhez nincs szükség kereskedelmi és/vagy platformfüggő szoftverek telepítésére).

A legegyszerűbb olyan formátumok használata, melyek webes kliens-szoftverrel (pl. böngészővel), ill. abba épülő kiegészítő alkalmazások segítségével megnyithatók.

Ilyen formátumok: HTML, XML, PDF, JPG, GIF, PNG.

↑03.2 Ajánlás: Ne korlátozzuk a tartalom ill. egyes tartalmazó részek elérhetőségét kliens-oldali scriptes mechanizmusokra.

A felhasználóknak egyre több lehetőségük van a kliens-oldali scriptek vezérlésére. Sok szoftver alapértelmezett beállításaiban korlátozza az ilyen műveletek futtatását, és csak külön felhasználói beavatkozásra engedélyezi azokat. Ha egyes tartalmi elemek (pl. bélyegképek kinagyított változatai) csak ilyen megoldással nyithatók meg, a letiltott scriptek esetén ezek a tartalomrészek nem lesznek elérhetőek.

Kerüljük a kliens-oldali scriptek alkalmazását a tartalom közvetlen eléréséhez, azaz az alábbi esetekben:

• hivatkozás megnyitása
• hivatkozás kimenetének szabályozása (pl. kisablakok, pop-up ablakok)
• navigáció a dokumentum szintjei között
• visszajelzés bevitele
• letöltés

Kliens oldali scripteket biztonsággal alkalmazhatunk olyan funkciókra, melyek egyéb úton is elérhetőek, vagy pusztán kiegészítő funkciókat szolgálnak, és nem befolyásolják a tartalom elérhetőségét. Ilyen funkciók:

• szövegméret beállítása
• stílus beállítása
• képmegjelenítés grafikus megoldása (de nem a képmegjelenítés maga)

↑03.3 Ajánlás: Törekedjünk a lehető legkisebb fájlméretre.

Bár nagy általánosságban elmondható, hogy az internetezés sebessége nő, és egyre kevesebben rendelkeznek olyan alacsony átviteli sebességgel, hogy a képek betöltése túl sok időt venne igénybe, új technológiai megoldások és az internetezők nagy száma miatt előfordulhat, hogy a forgalmi korlátok számottevően befolyásolják a webes szolgáltatások igénybevételét. Nem ildomos nagyméretű (500 kB-nál nagyobb) állományok elhelyezése a méret feltüntetése nélkül.

A legtöbb online böngészhető formátum alkalmazása többnyire kezelhető méretű állományokat eredményez, főleg ha az egyes szerkezeti egységeket külön fájlban szolgáltatjuk. A legtöbb fájlformátum esetében beépített lehetőségek vannak a méret racionalizálására:

HTML

Kerüljük az automatizált formázást alkalmazó felhasználói szoftvereket a végső változatok mentésére. Tervezéskor az olyan szoftverek, mint pl. az Adobe Dreamweaver, Microsoft Word hasznos eszközök, de a befejezett terveket mindenképp szűrjük meg forrás-nézetben, és töröljük a redundáns jelölő-elemeket. A formázási információkat emeljük át a stíluslapokba.

[Ld.: 3.2.2]

Megjegyzés: Ha a Microsoft Office használata mellett döntünk, HTML-kimenet készítéséhez ne használjunk a 2000-es csomagnál korábbi változatot. A Microsoft Office 2000 csomaghoz készült az ingyenesen letölthető  Office Filter 2.0 kiegészítés (az ennél újabb változatokba pedig alapértelmezett funkcióként elérhető), melynek segítségével kompakt méretű „szűrt” HTML-ben menthetjük ki a dokumentumunkat. Ez annak fényében mentesít a további korrekció alól, hogy mennyire használtuk következetesen a formázási stílusokat.

PDF

Használjuk az Adobe Acrobat 7.0 verziótól elérhető „Fájlméret csökkentése” opciót.

A fájlméret szabályozására vonatkozó további tanácsokat lásd: a PDF-formátumról szóló szekcióban.

KÉPFORMÁTUMOK

Vegyük figyelembe a tartalom által kívánt színmélységet. A szolgáltatási formátumnál nem az eredeti részletes reprodukciója, hanem az átláthatóság és az olvashatóság a fő szempont. Ennek eléréséhez nem feltétlenül van szükség nagyon részletgazdag és árnyalatos kivitelre, így használhatjuk a színmélység terén kisebb kapacitású, de mérettakarékos formátumokat, mint például a GIF és a PNG.

Ha részlet- és színgazdag képre van szükségünk, például színes fotók, színezett metszetek reprodukciójához, akkor a JPG-be mentsük az állományainkat. Ez esetben alkalmazzunk kompressziót, a kívánt minőség fényében.

A felhasználói képformátumok specifikációit a készülő képfeldolgozással kapcsolatos ajánlás tárgyalja majd. [Digitális Könyvtári Füzetek 2.]

Ha a tartalomegységeink még így is túlságosan nagyok, akkor daraboljuk fel azokat, természetesen egyértelmű navigációs és orientációs mechanizmusokkal nyilvánvalóvá téve, hogy azok egy tartalmi egységet alkotnak.

Linkajánló:

Microsoft Office 2000 HTML Filter 2.0 letöltés

http://office.microsoft.com/downloads/2000/Msohtmf2.aspx

↑03.4 Ajánlás: A kiadvány navigációs héjszerkezete és főbb azonosító szintjei mindig készüljenek HTML-ként megjeleníthető formátumban, még akkor is, ha a kiadvány tartalma maga nem HTML-formátumú, hanem például kép vagy PDF.

Erre azért van szükség, mert az 1.3 fejezetben az azonosítással kapcsolatban megfogalmazott ajánlások és szintek közötti navigációs kritériumok leginkább weblap-jellegű hivatkozási struktúrában valósíthatók meg. Másrészt lehetnek olyan tartalmi egységek is, melyekre nem tudunk közvetlenül érzékelhető azonosító és leíró adatokat helyezni (ilyenek például képfájlként publikált oldalak). Az ilyen esetben elengedhetetlen olyan keretbe ágyazni az állományt, melyből könnyen leolvashatók ezek az információk. Erre nézve is ideális a HTML amely lehet statikus vagy dinamikusan generált.

↑03.5 Ajánlás: Amennyiben lehetséges, biztosítsunk megfelelő minőségű szöveges változatot.

Ha pl. egy retrospektíve digitalizált kiadványt teljesen a nyomdai forma (oldalképek és tipográfia) képi tükrözésével szolgáltatunk is, kíséreljük meg elérhetővé tenni amellett a tartalom szöveges változatát.

Ehhez a ponthoz a digitális világban ritkán emlegetett kiadási elv kapcsolódik: a szövegkritika kérdése. Képi bemenetű (tehát szkennelés vagy fotó útján keletkezett) digitális anyagból szöveget előállítani bizonyos felelősséget támaszt a tartalomra nézve. Míg a szabad szemmel a képformátumról leolvasott szöveg közel ugyanolyan értékű, mintha az eredetit olvasnánk, ez korántsem mondható el a mesterségesen (pl. optikai karakterfelismeréssel) kinyert szövegváltozatról. Az ily módon előállított szövegváltozatot csak akkor tegyük közzé, ha

• a felismerés pontossága garantáltan legalább 90%
• a felismert szöveg mellett közvetlenül elérhető az eredeti kép
• tudatjuk a felhasználóval, hogy a szöveg pontossága nem 100%-os

Ha a szöveges változatot külön szeretnénk szolgáltatni (pl. HTML-kimenetként), mindenképp vessük alá korrektúrának. Ugyanez áll a begépeléssel előállított szövegekre.

↑3.2 Formátum-ajánlások

A továbbiakban a három legegyszerűbben használható és viszonylag könnyen előállítható publikációs megoldással foglalkozunk kicsit részletesebben:

• a PDF-fel
• a HTML-lel
• és a képformátum/HTML kerettel.

A mondandónk a saját tapasztalatainkon alapul, tehát az alábbiakban csak olyasmit ajánlunk illetve nem ajánlunk, aminek a hasznáról vagy káráról elektronikus időszaki kiadványokkal kapcsolatos munkánk kapcsán meggyőződtünk.

↑3.2.1. A PDF-formátum

↑3.2.1.1 Mi a PDF?

A PDF (Portable Document Format)-formátum az Adobe Systems fejlesztésében 1993-ban jelent meg. A cél az volt, hogy számítógéptől és operációs rendszertől függetlenül, bárki meg tudjon nézni, ki tudjon nyomtatni egy adott dokumentumot, anélkül, hogy a létrehozó szoftvereket és betűtípusokat telepíteni kellene gépére. Erre az igényre a cég a 80-as évek elején már kifejlesztette a PostScript lapleíró nyelvet, de hátrányai miatt (hatalmas méret, lassú, kényelmetlen nézőprogramok, kereshetetlen, másolhatatlan szöveg stb.) csak a nyomdai előkészítés és a tudományos-műszaki dokumentálás területén terjedt el. Új igények is jelentkeztek: metainformációk, hiperlinkek, multimédiás tartalom tárolása-megjelenítése.

Mindezen lehetőségek beépültek a PDF-szabványba, mely, tekintettel arra, hogy általában a nyomdai előkészítéssel párhuzamosan készül, ideális forma a nyomtatásban és elektronikus formában is megjelenő időszaki kiadványok online publikálására.

↑3.2.1.2 Sajátosságok és problémák:

Első látásra a PDF kiválóan alkalmas a hagyományos dokumentumtípusok elektronikus változatainak tárolására és szolgáltatására. Jelen ajánlás céljait figyelembe véve hangsúlyozottan javasoljuk használatát.

Előnyei:

• platformfüggetlen
• webhivatkozások helyezhetők el benne
• dinamikus dokumentum-megjelenítés (belső hivatkozások, bélyegképek, méretezhetőség)
• jól olvasható, ergonomikus megjelenítés
• annotálható

A megfelelően elkészített PDF-állomány minden szükséges információt tárol, ahhoz hogy jól jelenjen meg a monitoron, a nyomtatón, vagy adott esetben a nyomdai nyomólemezen. A szöveg, a grafika és betűk is az állomány részévé válnak. Ehhez szükséges, hogy a PDF-írás az igényeknek megfelelő beállításokkal történjen. Az alábbiakban felsoroljuk, hogy melyek a PDF-írás problémás pontjai, és ismertetjük azt az általunk kidolgozott elfogadható megoldást, melynek segítségével jó minőségű és használható PDF-állományokat állíthatunk elő.

Az alábbi pontok lehetnek kritikusak:

• karakterhűség
• a tárolt szöveg további feldolgozása
• fájlméret
• metaadatok

Linkajánló:
Adobe PDF szabványok
http://www.adobe.com/enterprise/standards/index.html

PDF-referencia:
http://www.adobe.com/devnet/pdf/pdf_reference.html

↑3.2.1.3 A PDF készítése:

PDF-állomány többféleképpen keletkezhet:

• szöveg- illetve kiadványszerkesztőben létrehozott szöveget konvertálunk a szoftver beépített virtuális nyomtatójával;
• minden programból elérhető, önálló virtuális nyomtató segítségével;
• PDF-szerkesztő programcsomagokkal;
• képállományokat (pl. szkennelt képet) mentünk el PDF-formátumban (szkennelő, ill. képkezelő szoftver segítségével)

↑3.2.1.3.A Ajánlások: A. Szöveges állományokra

Az ajánlás ezen része főként az úgynevezett „digitálisan született” („born digital”) kiadványokra vonatkozik, tehát amikor elektronikusan szerkesztett szöveget mentünk ki PDF-formátumban.

↑03.6 Ajánlás: PDF készítésekor virtuális nyomtatóinkat, PostScript-meghajtóinkat állítsuk be a True Type fontok helyes kezeléséhez.

Az Adobe Systems a PostScript nyelvvel egy időben dolgozta ki a Type 1-es (T1) névre keresztelt, magas minőségű méretezhető betűtípusát, ezek használatakor ritkán adódik a PDF-állománnyal probléma, de szinte csak a kiadványszerkesztők körében használatosak. A méretezhető betűtípusok másik családjával, a True Type fontokkal a mai napig nehezen „fér össze” az állomány. Amennyiben True Type típusú fontot használunk dokumentumunkban, nyomtatóink alapértelmezett beállítása ezek helyettesítése eszközbetűtípussal. A nyomtatómeghajtókhoz mellékelt Type 1-es eszközbetűtípusok nem kelet-európai kódolásúak, ezért ilyen esetekben „sajátos” betűink helytelenül, kalapos-hullámos ékezettel jelennek meg a PDF-állományban.

Virtuális nyomtatónk „Tulajdonságok” / „Nyomtatási beállítások” / „Speciális” menüjében állítsuk be a letöltést az alábbi ábra szerint:

1. ábra (PDF nyomtatási beállítások)

↑03.7 Ajánlás: PDF készítésekor az alkalmazott betűkészleteket ágyazzuk be (embed) a készített PDF-dokumentumokba.

Amennyiben PDF-készítő alkalmazásunk lehetővé teszi, feltétlenül állítsuk be a „Minden betűtípus beágyazását”, a „beágyazott betűtípusok részhalmaza...” opciót viszont kapcsoljuk ki. Igaz, ez megnöveli a PDF-állomány méretét, viszont szükség esetén lehetővé teszi a szöveg apró javításait. A „Soha be nem ágyazandó” listát töröljük ki, ne szerepeljen itt egyetlen betűtípus sem.

2. ábra (PDF betűtípus beágyazása)

 

↑03.8 Ajánlás: PDF készítésekor használjuk ki a kiadványszerkesztő szoftverek online használatra optimalizált opcióit, annak érdekében, hogy minél kisebb méretű fájlok keletkezzenek.

A kiadványszerkesztő-szoftverek a nyomdai feldolgozás szempontjából megfelelő PDF-állományokat állítanak elő. Elsődleges szempontjuk a nyomdai publikálás, a hordozhatóság és további feldolgozás igényeire nincsenek tekintettel. Felbontásuk igen nagy, képállományaik alig vagy egyáltalán nincsenek tömörítve, számunkra felesleges információkat hordoznak (pl. vágójelek). Ilyen esetekben kérjük újra generálni az eredeti kiadványból a PDF-et, vágójelek, színrebontás nélkül, ún. standard beállításokkal (figyelembe véve a True Type fontok beállításánál és beágyazásánál leírtakat):

3. ábra (PDF megjelenítési beállítások)

4. ábra (PDF tömörítési beállítások)

Számos ingyenes, ill. takarékos PDF-gyártó szoftver és alkalmazás született. Az általunk kipróbált programok közül ékezetes betűinket egyikük sem tudta megfelelően kezelni, megbízhatóságukról nem tudunk nyilatkozni.

↑03.9 Ajánlás: Ha biztosan szolgáltatható változatokat szeretnénk készíteni, akkor mindenképp az Adobe Acrobat PostScript-feldolgozóját, az Acrobat Distillert használjuk a PDF generálására, ill. az Adobe Acrobatot a további feldolgozásra.

Ez a megoldás elsőre nem tűnik költséghatékonynak, mivel az Adobe szoftverei nem épp a legolcsóbbak. Természetesen megkerülhető ez a megoldás, ha rendelkezésünkre áll olyan szakértelemmel rendelkező munkaerő, aki biztos tudással rendelkezik a PDF tulajdonságairól és biztosan tud használni egyes olcsóbb, vagy ingyenes megoldásokat. A program további előnye, hogy gazdaságos méretű fájlokat készíthetünk általa.

↑3.2.1.3.B. B. Képi állományok

A PDF-formátum nem ideális megoldás kifejezetten képi információ közvetítésére, mivel a részletes grafikus megjelenítés használhatatlanul nagy fájlméretekhez vezet. Ugyanakkor, a képi alapból (pl. digitalizált fotó vagy mikrofiche) feldolgozott szöveges tartalom előállítására ez a leggazdaságosabb megoldás. Az optikai karakter-felismerő (OCR) technológia segítségével egyre nagyobb hatékonysággal nyerhetjük ki a szöveges tartalmat képi információból is.

A képi tartalmú PDF-formátum alternatívája a Lizardtech fejlesztésében készült DjVu fájlformátum. A Document Express szoftvercsomag segítségével előállított állományok nagy rugalmasságot biztosítanak a dokumentumot alkotó képek felhasználói kezelésében, és az állományok fájlmérete is racionális. A DjVu a legújabb fejlesztések eredményeképpen a PDF-hez hasonlóan képes kép és szöveges index kezelésére is. Hátránya, hogy használatához egy kevéssé elterjedt plug-int kell letölteni.

Linkajánló

DjVu
http://djvu.org/

Lizardtech Document Express
http://www.lizardtech.com/download/dl_options.php?page=doc

↑3.2.1.3.C. OCR PDF kimenettel

↑03.10 Ajánlás: A képként digitalizált szövegoldalakat OCR-szoftverrel való feldolgozás után mentsük el PDF-formátumban.

A PDF legelőnyösebb tulajdonságai közé tartozik a többrétegű tartalom kezelése. Ez azt jelenti, hogy beszkennelt oldalképeink elmentése mellett az azokból optikai karakterfelismeréssel (OCR) kinyert szöveget és annak pozícióját is eltárolhatjuk a fájlban.

Így megoldható, hogy úgy mentsük el a tartalmat, hogy annak képi megjelenését megőrizzük, mögötte azonban – következetes elrendezésben – eltároljuk az OCR-folyamat során felismert szöveges információt. Az így előállított fájlok kezelhető méretűek, a képi megjelenítésben általában elegendő a 150 dpi-s felbontás. A jól eltárolt szöveges állomány további feldolgozásra alkalmassá teszi az állományokat.

Hogy egy anyagot OCR-folyamatnak vetünk-e alá, azt maga az anyag formai és tartalmi jellemzői határozzák meg. A következő szempontokat érdemes itt kiemelni:

1. A tartalom kora

Az OCR-szoftverek nagy része a jelenkori nyomdászati konvenciókhoz igazodik. 150-200 éves dokumentumok esetében sem a helyesírás, sem a tipográfia nem rendelkezett egységesen kikristályosodott elvekkel, ezek esetenként nehezen áthágható akadályokat képeznek. A magyar nyelv estében ilyen lehet

• ékezetes magánhangzók nem következetes jelölése (í, ú, ő, ű)
• névelő aposztrófos formája
• mediális (hosszú) s (ſ)
• a „c” hangot reprezentáló cz
• ligatúrák

2. A tartalom típusa

A karakterfelismerő szoftverek nem minden esetben tudnak megbirkózni a heterogén tartalmú anyagokkal. Ilyenek, ha kisebb arányban is, de előfordulhatnak folyóiratokban:

• bibliográfiák, melyek sok számadatot (dátum, hivatkozás), valamint tulajdonnevet tartalmaznak, és tipográfiai megoldásuk általában nagyon összetett
• többnyelvű szószedetek (különösen ha fonetikai kiegészítő magyarázatokat is tartalmaznak)

3. A tartalom nyelve

Nem minden nyelvre nézve készültek beépített szótárak az OCR-szoftverekhez. Emellett probléma lehet a kiadvány esetleges archaikus nyelvezete, mely szintén a szótárból hiányzó alakok miatt rontja a felismerés pontosságát.

4. A kiadvány tördelése

A többhasábos újságjellegű tördelés már nagyrészt kezelhető egyes eszközökkel, a rendhagyó oldalelrendezésű kiadványokat viszont csak akkor OCR-ezzünk tömegével, ha meggyőződtünk róla, hogy a szövegszakaszok logikai kapcsolata megmarad. Ugyanez vonatkozik a gazdagon illusztrált, képaláírásokkal ellátott kiadványokra.

↑03.11 Ajánlás: Az OCR szoftverrel előállított PDF elsődleges nézete a képi formát, a szöveges háttér a logikai struktúrát tükrözze.

Az optikai karakterfelismeréssel feldolgozott állományok szöveges tartalmát a PDF készítésekor mentsük a kép mögé. Így a dokumentum eredeti megjelenési formájában lesz elérhető az olvasó számára.

A PDF fejlődését figyelve észrevehetjük, hogy a formátum egyre több ponton kapcsolható az XML-technológiához. Az újabb PDF-szabványok (PDF 1.7, ISO 32000) már lehetővé teszik a tartalom elemjelölését, más szóval a címkézést. Ez azt jelenti, hogy nemcsak a szöveg tartalma, hanem a szöveg struktúráján belüli funkciója is letárolható. (pl. cím, lábléc, képaláírás). Javasolt olyan OCR-szoftver használata, mely ezeket a funkcionális információkat is figyelembe veszi és tárolja a mentés során, címkék vagy stílusok formájában.

Mindezek figyelembevétele nagyban hozzájárulhat az így keletkezett tartalmak időtállóságához. Ahogy az OCR-technológia fejlődik, nő a felismerési pontosság, ugyanúgy növekszik az igény és potenciál a dokumentumstruktúra megőrzésére különböző fájlformátumokban.

[Ld.: 04.6 Ajánlás]

↑3.2.1.3.D Ajánlások: D. Minden típusra:

A PDF-állományok azonosítására a szabvány nagyon egyszerű megoldásokat tartalmaz.

↑03.12 Ajánlás: A PDF-dokumentum tulajdonságait tároló információs mezőkbe helyezzük el a dokumentumra vonatkozó bibliográfiai információkat.

A „dokumentum tulajdonságai” (document summary) fület kitöltve helyezhetjük el a PDF állományban a leíró adatainkat.

5. ábra (PDF dokumentum tulajdonságai és leíró adatai)

Ami nehézkesebb lehet, az a metaadatok elhelyezése egy olyan gyűjteményben, mely esetleg PDF-fájlok százaiból áll. Amennyiben az Adobe eszközeit használjuk PDF-írásra, a leíró adatok egységesen módosíthatók az Acrobat 5.0, 6.0 illetve a Creative Suite csomagok beépített (batch processing), illetve komponensként telepíthető (Adobe Bridge), kötegelt feldolgozást lehetővé tevő eszközeiben, melyek lehetővé teszik a formátum leíró adatmezőinek csoportos kitöltését és módosítását.

Ellenkező esetben némi programozói ismeretek birtokában elhelyezhetjük a tömeges metaadatokat a fájljainkban olyan csere-szoftverekkel, melyek képesek bináris módban megnyitni és módosítani a PDF-állományokat.

[Ld.: még: 4.2.4]

↑03.13 Ajánlás: Ha nem a szerző kifejezett kérése, ne korlátozzuk a PDF-állomány szabad használatát.

6. ábra (PDF biztonsági beállítások)

Ez a beállítás fontos ahhoz, hogy az állományon további módosításokat lehessen végrehajtani. Ilyen lehet például a leíró adatok módosítása, esetleges átméretezés. Továbbá a biztonsági beállítások érinthetik a mentés, nyomtatás lehetőségét is.

↑03.14 Ajánlás: A PDF-formátumban szolgáltatott kiadványunknak is készítsünk HTML-szerkezetű héjrendszert.

A PDF-formátum lehetővé teszi, hogy egész kiadványt egy PDF állományban tegyünk közzé, a formátumban rendelkezésre álló strukturális és navigációs funkciók segítségével. Ez azt jelenti, hogy az ilyen kiadvány megnyitásakor a PDF-állományon belül navigálhatunk a címlapról a tartalomjegyzékre, onnan az egyes cikkekre és vissza. Ez a megoldás nagyon elegáns sok szempontból praktikus, jelen ajánlás szempontjai szerint azonban nem ideális. Bár az ilyen állományok könnyen kezelhetők egyenként, egy teljes gyűjtemény mozgatása, illetve esetleges konverziója problémás lehet.

Ezért az a javaslatunk, hogy digitális időszaki kiadvány esetén a cikkjellegű egységeket mentsük el önálló PDF-formátumban, és a köztük lévő navigációt, tehát a számok tartalomjegyzékét, a részegységek struktúráját és a címlapot építsük fel HTML-szerkezetben.

Linkajánló:
PDF File Creation
http://www.pdfzone.com/article2/0,1895,1766452,00.asp
Adobe Type Technology
http://partners.adobe.com/public/developer/opentype/index.html

↑3.2.2 A HTML-formátum:

↑3.2.2.1 HTML

A webes környezetben való publikáció megkerülhetetlen eszköze a HTML-nyelv. Bármilyen adatformátumot is választunk, legalább a legkülső szinten alkalmaznunk kell ezt a nyelvet.

A HTML használata rendkívül egyszerű, az alapvető szótár és szintaxis 1-2 nap alatt bárki számára elsajátítható, aki rendelkezik szövegszerkesztői ismeretekkel.

A formátum egységes kezelése példaértékű, a legtöbb HTML-parser (azaz értelmező szoftver, pl. web-böngésző) ugyanazzal az eredménnyel fog feldolgozni egy jól megfogalmazott kódot.

Megjegyzés: Ebben a fejezetben a szabvány kifejezést időnként a World Wide Web Consortium elfogadott specifikációira is használjuk, mivel az internetes környezet szempontjából a W3C szabályozásait előírásos értékűnek fogadjuk el.

↑03.15 Ajánlás: HTML-formátumnál, amit csak lehet, igyekezzünk a HTML-nyelv strukturális elemeinek segítségével kódolni a tartalomból.

A HTML jelölőnyelv, alapvető funkciója tehát, hogy különböző tulajdonságokat társítson a tartalom elemeihez, legyenek azok karakterek, bekezdések vagy egész állományrészek. Ezek a tulajdonságok lehetnek formaiak (pl. a vizuális megjelenítésre vonatkozók), illetve funkcionálisak, azaz azt fejezhetik ki, hogy mi az adott elem szerepe és súlya a tartalmon belül. A stílusnyelvek terjedésével egyre kevésbé szerencsés a megjelenítésre vonatkozó utasításokat a HTML-kódban kifejezni.

↑03.16 Ajánlás: A HTML-forrás lehetőleg szerkezeti elemeket és osztályokat tartalmazzon. Minél kevesebb formázási utasítást helyezzünk el a kódban.

A HTML-szabvány legújabb változatai (a 4.0 változattól kezdve az XHTML-verziókig) egyre inkább azzal számolnak, hogy a HTML-szerkezet azt fejezi ki, hogy az egyes tartalomrészek milyen szereppel bírnak, mely egység részei, mihez tartoznak, fontosak-e, és ha igen, miért.

Hogy a megjelenítésben ez hogyan tükröződik, azt célszerűbb stíluslapokban meghatározni.

↑03.17 Ajánlás: HTML dokumentumoknál a formai tulajdonságok meghatározására használjunk stíluslapokat.

Miért fontos ez?

1. A HTML-nyelv formai jegyeket tartalmazó kifejezései nagyrészt a vizuális megjelenítésre korlátozódnak. A felhasználók azonban nemcsak vizuális úton, a képernyőről olvasva tanulmányozhatják a tartalmat, hanem előfordulhat, hogy jobban kedvelik a papírformátumot, ezért kinyomtatják azt, esetleg alternatív jelrendszerekbe kódolják (pl. Braille), vagy hangzó formában használják azt.

A stíluslapokban használt szabványok, mint például a CSS nyelv, fel vannak készítve az ilyen jellegű tulajdonságokra is, képes a vizuális mellett pl. nyomtatási (print), ill. hangzó (aural) tulajdonságok kezelésére, valamint a hagyományostól eltérő megjelenítő környezetekre is (handheld).

2. Ha a HTML-forrás tartalmazza a formázási utasításokat, akkor egy esetleges változtatásnál tetemes mennyiségű kódot kell átírnunk. A stílusok alkalmazásával lehetőségünk van arra, hogy egységesen vizuális (és egyéb úton) megjelenített külsőt tulajdonítsunk egyes strukturális elemeknek, azokat stíluslapokban rögzítsük, s ezeket a tulajdonságokat megváltoztathatjuk anélkül, hogy a tényleges dokumentumtesthez jelentősebb mértékben hozzá kellene nyúlnunk. Sőt, a tulajdonságok akár használat közben is módosíthatók, a felhasználó igényei szerint.

↑03.18 Ajánlás: Igyekezzünk tekintettel lenni a HTML-szabvány újabb változataira. Legalább a HTML 4.01-ben bevezetett újításokat kövessük.

Mondhatjuk, hogy nekünk tökéletesen megfelel az elfogadott és bevett 3.2-es szabvány. Sok tekintetben egyszerűbb, egyértelműbb és könnyebb benne a részmegoldások kidolgozása. Ráadásul szinte minden böngésző támogatja.

Ez mind igaz, de a web világa sokat változott a 3.2-es szabvány óta. Nagyon sokat szélesedett és gazdagodott, főleg a közvetítők és hordozók terén. A HTML kódban bevésett utasítások nehezen igazíthatók a különböző környezetekhez és felhasználási módokhoz. Ezért hagyatkozik a szabvány újabb változata inkább a stílusokra.

Másik érvünk az újabb változatok mellett, hogy támogatni kell az automatikus transzformáció lehetőségét. Nem tudjuk, merre fejlődnek a webes formátumok, azt sem tudjuk, hogy meddig lesz HTML-nyelv, de az bizonyos, hogy a legújabb változatok vezetnek a szerves és zökkenőmentes átmenethez az újabb szabványokhoz. Ez a digitális megőrzés egyik fontos alapelve.

Ha az alábbiakban azt mondjuk egy elemről vagy attribútumról, hogy „elavult”, az nem azt jelenti, hogy használata tiltott, csupán nem ajánlatos, ugyanis a megjelenítő programoktól többé nem várható, hogy azt a jövőben támogatni fogják.

↑H.1 Ajánlás: A tartalom struktúrájának kifejezésére használjuk a HTML által felkínált strukturális elemeket. A HTML-ben ne fejezzünk ki formázási utasításokat.

Megjegyzés: A HTML fejlesztéséért felelős World Wide Web Consortium szóhasználata szerint ezeknek az elemeknek és tulajdonságoknak "el kell halványodniuk" ("phase out") a használatból, mielőtt a szabványból is kiiktathatók lennének.

Linkajánló:
Bevezetés a HTML-be
http://htmlinfo.polyhistor.hu/raggett/start.htm
HTML 4.01 Specifikáció
http://www.w3.org/TR/html4/

↑3.2.2.2 Hogyan használjuk a HTML-nyelvet?

Ezt a fejezetet azoknak szánjuk, akik az elektronikus időszaki kiadványok állományainak HTML-formázással foglalkoznak. Azt fogjuk leírni, hogy mely HTML-elemek használatát láttuk célszerűnek, illetve problematikusnak eddigi munkánk során.

Elemről elemre, a nagyobb egységtől a kisebb felé haladva mutatjuk be az egyes egységeket, valamint hogy használatuk ajánlatos-e, és ha igen, hogyan. Nem szándékunk azonban a HTML-nyelv bemutatása – az alábbiakban következők már feltételezik annak ismeretét. Nem is térünk ki minden elemtípusra és szintre, hanem említés szintjén felsoroljuk a tapasztalataink szerint fontos, illetve kérdéses elemeket. Csak olyan pontokra fogunk kitérni, melyek egy szöveges formában közzétett közlemény (hír, update, folyóirat-cikk) szempontjából jelentősek lehetnek. (A HTML-keretben képként közzétett állományokkal a következő nagy fejezetben foglalkozunk.) Mindezek tehát egy adott állományon (*.htm, *.html) belüli viszonylatokra vonatkoznak. Nem foglalkozunk pl. a keretekkel, illetve a felhasználói input-mechanizmusokkal.

↑H.1 Három nagyon fontos attribútum

A tapasztalataink során hasznosnak bizonyuló HTML-elemek tulajdonságait attribútumokkal szabályozhatjuk. Régebben az volt a gyakorlat, hogy a megjelenítési információkat minél részletesebben megadtuk az attribútumokban:

<p><b><font face="Times New Roman" color="#FF3333">Ez egy bekezdés. Meg van formázva.</font></b> </p>

Újabban a formázási utasításokat a HTML-től eltérő, de azon belül értelmezhető, gazdagabb lehetőségeket kínáló nyelven, stílusokkal közöljük:

<p style="font-family: Times New Roman, Times, serif; font-style: normal; font-weight: bold; color: #FF3333; text-align: center;">Ez egy bekezdés. Meg van formázva</p>

Az eredmény ugyanaz, és ezzel nem igazán jutottunk előbbre, hiszen ha minden bekezdésnél újra és újra meg kell adnunk ezt a stílusinformációt, akkor azt akár tehetjük a HTML alkalmazásával és továbbfejlesztésével.

A stílusinformációt azonban el is tárolhatjuk az úgynevezett stíluslapban, és ha ezt tesszük, a dokumentumunk egészére nézve igaz lesz, hogy minden <P> (bekezdés elem így fog kinézni).

<style type="text/css">

p { 
font-family: "Times New Roman", Times, serif;
font-style: normal;
font-weight: bold;
color: #FF3333;
text-align: center
}

</style>

Ha azonban többféle, azonos szintű elemhez szeretnénk különböző stílusokat rendelni, akkor általunk definiált osztályokba kell sorolnunk azokat, illetve azonosítóval ellátni őket. Ezek segítségével teremthetünk összeköttetést a HTML-elemek és a rájuk szabott stílusok között.

Minden elemben használhatók:

1. style attribútum – ezzel közvetlenül a HTML-tagen belül írhatunk stílus-utasítást. Ez csak nagyon egyedi esetekben célszerű, általában kerülendő.

<div style="text-align: left"><p>Balra rendezett tartalom</p></div>

2. class attribútum – ezzel osztályokba sorolhatjuk az elemeket. Akkor használjuk stílusmegjelölésre, ha ismétlődő egységről van szó.

<div class="balra"><p>Balra rendezett tartalom</p></div>

AHOL

.balra {
text-align: left;
}

3. id attribútum – egyedi előfordulású elemekhez társíthatunk segítségével stílust.

<div id="balra"><p>Balra rendezett tartalom</p></div>

AHOL

#balra { 
text-align: left;
}

↑H.2 Gyökér, fejléc

H.2.1 Dokumentumtípus

↑H.2 Ajánlás. Mindig  közöljük, hogy a HTML- illetve XHTML-szabvány mely verzióját használjuk.

A <!DOCTYPE> elemben hivatkozunk a HTML-szabvány általunk használt változatára. Ez főleg akkor fontos, ha a dokumentumunkat szeretnénk megfeleltetni különböző ajánlásoknak, vagy szándékunkban van további feldolgozása és rendszerszintű konverziója.

Jelenleg a következő dokumentumtípusok közül választhatunk:

1. Strict

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

    "http://www.w3.org/TR/html4/strict.dtd">

Ezt csak akkor használjuk, ha a megjelenítésünk rendkívül egyszerű és csak a legalapvetőbb elemeket tartalmazza.

2. Loose

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

    "http://www.w3.org/TR/html4/loose.dtd">

Ennek a változatnak a használata jár a legkevesebb kockázattal, mivel kevesebb, stílusokkal is kifejezhető  formázási eleme van kiszorítva a definícióból. Mivel az elterjedt böngészők többségénél problémák tapasztalhatók a stílus-szabványok értelmezésében, átmeneti megoldásként ez a dokumentumtípus használandó.

3. Frames

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"

    http://www.w3.org/TR/1999/REC-html401-19991224/frameset.dtd">

Ha kereteket (frames) szeretnénk használni a megjelenítéshez, akkor ezt a deklarációt kell elhelyezni a dokumentumunkban. Ez a változat nem ért el W3C-szabvány státuszt, és a keretek használata ellen számos egyéb érv is szól, ezért ezt a megoldást nem javasoljuk.

4. XHTML Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Főleg dinamikus és generált szolgáltatások számára ideális a HTML XML-kiterjesztése, az XHTML.

5. XHTML Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

6. XHTML Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

Megjegyzés: a hivatkozás második sorában található hivatkozás maga a HTML dokumentumtípus-definíciója, pl.:

    "http://www.w3.org/TR/html4/loose.dtd">

H.2.2 Gyökérelem

<HTML> ez az elem a dokumentum gyökere.

Mindenképp használjuk, és zárjuk is le, mert ezzel megkönnyítjük a dokumentum további szerkesztését.

Egynyelvű dokumentumoknál célszerű és a legegyszerűbb itt megadni a dokumentum nyelvét a "lang" paraméterben (valamint természetesen a fejlécben tárolt metaadatokban),

<HTML lang="hu">

mert a "lang" információt olyan felhasználói ágensek is értelmezik, mint pl. a hangosböngészők.

Itt ne használjuk a "version" attribútumot (elavult.)

H.2.3 Fej

<HEAD>

A dokumentum fejléce. Kötelező lezárni a dokumentumtörzs megkezdése előtt. Itt közöljük a dokumentum technikai adatait, a feldolgozó protokollnak illetve keresőmotoroknak címzett információkat, a tartalom leíró adatait, a stíluslapokat és scripteket, illetve az azokra vonatkozó hivatkozásokat.

Amennyiben kihasználjuk a HEAD-en belül található megfelelő elemeket metaadatok közlésére, akkor már itt meghatározhatjuk, hogy milyen adatsémához igazodó adatokat közlünk:

<HEAD profile="http://purl.org/metadata/dublin_core_elements/">

A fenti adattal például azt fejezzük ki, hogy a Dublin Core adatséma szerint közöljük a metaadatokat.

A HEAD elemet továbbá mindenképp ki kell használni a következő információk közlésére:

↑H.2.4 Leíró adatok

<META>

A metainformációk közlésére alkalmas.

Ebben az elemben először meg kell határoznunk, hogy milyen jellegű információt közlünk a dokumentumról, azután megadni azt. Gondolunk itt a leíró adatokra, technikai jellemzőkre, karakterkódolásra stb.

A"name" paraméterben nevezhetjük meg az információ jellegét.

A"http-equiv" paraméterben kifejezetten a http-protokoll felé szánt információkat közöljük.

A"scheme" paraméterben a metainformációban használt adatsémára utaljunk.

A"content" paraméter tartalmazza a tényleges információt.

A tartalomra vonatkozó metainformációk és a vonatkozó adatsémák tárgyalását ld. 1.4.1 fejezet.

Mindenképp itt közlendő metainformáció:

H.2.4.1 Karakterkészlet-deklaráció

Különösen fontos, hogy megfelelő karakterkészletet válasszunk a szöveges információ közléséhez. Ha ezt elmulasztjuk, akkor a szövegünk nemcsak nem lesz tetszetős, de tartalmában is sérül (karakterek veszhetnek el.)

A "http-equiv" paraméterben így jellemezzük a karakterkészletet:

http-equiv="Content-Type"

A karakterkészlet nevét a "charset" attribútumban adjuk meg.

↑H.3 Ajánlás: Mindig közöljük a fejléc megfelelő elemében, hogy milyen kódlapot használunk karakterkódoláshoz. 

Általános magyar nyelvű szöveghez (pl. szépirodalom) használhatjuk az iso-8859-2-es kódlapot, mert ez tartalmazza a legtöbb kifejezetten magyar beszédhangnak megfelelő karaktert.

Célszerűbb azonban az utf-8-as kódolást választani, mivel minél terjedelmesebb szövegről van szó, annál nagyobb az esélye annak, hogy olyan karakterek tűnnek fel benne, melyet az iso-8859-2-es szabvány nem támogat. Ha van módunk az ilyen karakterek kiszűrésére, akkor megtarthatjuk ezt a karakterkódolást, és a hiányzó elemeket numerikus UNICODE-entitással fejezhetjük ki.

Pl. a gondolatjel karaktert kifejezhetjük így: &#8211;

Megjegyzés: Numerikus UNICODE kódolásnál ne használjuk a 130-159 közötti tartományt, mert ezek már nem szabványos entitások. Ne használjunk továbbá csak numerikus UNICODE-ot (vagy HTML-entitásokat) a teljes szöveg kifejezésére, mert a fájljaink aránytalanul nagyméretűek lesznek.

Ez a megoldás azonban problémát jelent, ha az állományt például forrásszinten (tehát nem kifejezetten XML-szerkesztő szoftverrel) akarjuk XML-formátumban menteni, ugyanis ekkor minden entitás rontott karakterláncot eredményezhet.

A másik érv az utf-8 kódolás mellett, hogy az esetek többségében nem lesz módunk tudni az összes speciális (tehát pl. a iso-8859-2-es vagy egyéb választott kódlapon kívül található) karakterről, mely a szövegünkben előfordulhat. Jelenleg az utf-8 az a legbővebb halmaz, melyet a legtöbb környezet támogat, s így ezzel áll fenn a legkisebb veszély a szövegromlásra.

↑H.4 Ajánlás: Használjunk UTF-8-as kódolást.

Az utf-8-as kódolású állományok használatánál azonban ügyeljünk arra, hogy forrásszinten csak utf-8-kompatibilis szövegszerkesztőkkel nyúljunk hozzájuk, mint például a BabelPad, SC Unipad vagy a YUDIT.

Linkajánló:

UTF-8 és UNICODE szabványok
http://www.utf-8.com/

Babelpad
http://www.babelstone.co.uk/Software/BabelPad.html

SC UniPad
http://www.unipad.org/main/

Yudit
http://www.yudit.org/

H.2.4.2 Létrehozó ill., szerkesztő szoftver:

Az esetleges további feldolgozáshoz mindenképp hasznos tudni, hogy milyen szoftver segítségével készült az eredeti HTML-dokumentum, illetve mivel szerkesztették azt. (Az egyes generátorok és szerkesztők kódjában sajátosságok figyelhetők meg, és ezekre tekintettel könnyebb is lehet az állományokkal végzett munka.)

pl.:

<meta name="GENERATOR" content="Microsoft Word 11">

Megjelölhetjük azt is, hogy milyen szoftvert használtunk az állományok további feldolgozására:

<meta name="FORMATTER" content="Arachnophilia 4.0">

H.2.4.3 Szabványos metaadatok

↑H.5 Ajánlás: Mindig közöljük a kiadvány leíró adatait a META elemben és mindig hivatkozzunk pontosan a használt leírási sémára.

A META elem alkalmas részletezett, szabványos adatsémák befogadására is. Így pl. használhatjuk a Dublin Core leíró adatok közlésére is.

Pl.:

<meta name="dc_title content="főcím">

<meta name="dc_contributor content="szerkesztő">

<meta name="dc_publisher content="kiadó neve">

<meta name="dc_subject" content="téma">

<meta name="dc_format" content="formátum">

<meta name="dc_identifier" content="URL">

<meta name="dc_relation" content="kapcsolódó dokumentum">

<meta name="dc_language" content="tartalom nyelve">

<meta name="dc_rights" content="jogtulajdonos">

Mindennek természetesen csak abban az esetben van értelme, hogy ha a metaadatok mellett a fejlécben hivatkozunk a leírásban használt adatszabványra is. Az e nélkül közölt Dublin Core-adatok egyébként egyszerű szöveges adatok maradnak.

Az egyik hivatkozási módszer például, amikor a LINK elem segítségével adjuk meg az adatsémát:

<link rel="SCHEMA.dc" href="http://purl.org/dc/elements/1.1/”>

De megtehetjük ezt a HEAD elemben is:

<HEAD profile="http://purl.org/dc/elements/1.1/">

[Ld.: még: HEAD]

H.2.5 Címadatok

<TITLE>

Ezt az elemet eredetileg a fájlban található tartalom főcímének közlésére találták ki. Az időszaki kiadványok esetében azonban ajánlatos a forrásinformáció megadása, mert

• ha ez az állomány valamilyen okból (pl. böngészővel való lementés) elkülönül a forrásdokumentumáról, az eredeti forrás legalább utalás szintjén kitüntetett helyen szerepel;
• egyes feldolgozó mechanizmusok (pl. teljes szövegű keresés) számára egyszerű a kiemelése az állomány tartalmából, így a tartalom jellege és a forrás rögtön egyértelmű lesz pl. egy keresőmotorral (Google, Yahoo stb.) történő megjelenítés során is, mivel a találati listában a TITLE adata fog szerepelni.

Ez az elem az elsődlegesen és legkönnyebben elérhető metaadat-információ – a felhasználó szempontjából. Ha mást nem is, ezt az elemet mindig töltsük ki a fejlécben.

↑H.6 Ajánlás: A TITLE elemben mindig közöljük legalább a kiadvány főcímét és a részegység adatait.

A legtöbb vizuális böngésző az ablak címsorába helyezve jeleníti meg a TITLE adatát. Az adat hosszúsága elvileg nem korlátozott, gyakorlatilag azonban böngészőfüggő, hogy mennyi jelenhet meg belőle. Általában 60 karakternél hosszabb ne legyen az itt közölt információ (szóközöket is beleértve.) Folyóiratcikkek esetén itt a hivatkozási információ megadását javasoljuk (mivel az szöveges formában általában nem szerepel a dokumentum szövegtörzsében).

Példa:

Helytelen:

<TITLE>Verebes István: Az önkéntelen dühkitörések ideiglenes feloldása a szocialista realizmus talaján 3. rész- Hócipő, 1989. 14. szám</TITLE>

Ebből nagyjából ennyit lát a felhasználó:

"Verebes István: Önkéntelen dühkitörések ideiglenes feloldása a sz"

és esetleg nincs információja arra nézve, hogy mi a dokumentum forrása.

Helyes:

<TITLE>Hócipő, 1989. 14. szám</TITLE>

A szerzőség és a cím a szövegtörzsben amúgy is szerepel, valamint egyéb, kitüntetett helyen is tárolható.

A TITLE elem csak a HEAD-be ágyazva használható.

Nem keverendő össze a "title" attribútummal, melynek használata a legtöbb HTML-elemnél megengedett, szintén az elem tartalmára vonatkozó információ közlésére.

H.2.6 Stílusinformáció

<STYLE>

↑H.7 Ajánlás: A dokumentum formázási utasításait fejezzük ki stílusokkal, a CSS2 vagy XSL szabványok segítségével.

A <STYLE> elemben írjuk le, hogy a dokumentumunk milyen stílusokat használ. Ez az elem nagyon fontos, mert itt van lehetőségünk meghatározni a fájlunk egészére érvényes stílusokat. Ennek három alapvető módja, ha

1. Az utasítást külön fájlban helyezzük el, és a <LINK> elemben, a "rel" attribútumban közöljük, hogy a dokumentumhoz külső stíluslap tartozik.

• Ebben az esetben meghatározhatjuk, hogy az adott stíluslap alapértelmezett
  <LINK href="stilus.css" rel="stylesheet" type="text/css">
• ajánlott
  <LINK href="stilus2.css" rel="stylesheet" type="text/css" title="legjobb">
• illetve opcionális
  <LINK href="stilus3.css" rel="alternate stylesheet" type="text/css" title="ez is jo">

2. CSS stíluslapoknál a STYLE elemen belül a CSS-szintaxisból átvett import paranccsal. Ezt csak akkor érdemes használni, ha a dokumentumszerkezetünk különböző részei számos különböző stíluslapra építenek.
<STYLE TYPE="text/css" MEDIA="screen">
<!--
@import url(/stilus/ezastilus.css);
-->
</Style>
Ezt sose használjuk egyéni stílusutasítás részeként.

3. A STYLE elemen belül közvetlenül közöljük a stíluslapot
<STYLE TYPE="text/css" MEDIA="screen">
<!--
body {margin: 0; width: 800px; overflow: auto;  color: black; }
div, p, li { padding: 2em; text-align: left ;}
-->
</Style>

Megjegyzés: a HTML komment (<!-- … -->) használatával a stílusinformációt elrejthetjük olyan böngészők elől, amelyek nem ismerik az adott stílus-szabványt, és egyszerű szövegként jelenítenék meg a stílus-utasítást.

A stíluslap típusára a "type" attribútumban utalhatunk, ahol is MIME-típust kell közölnünk ("text/css", "text/xslt").

A <STYLE> elem további fontos jellemzője a "media" attribútum. Ezzel jelezzük, hogy az adott stíluslapban meghatározott megjelenítési módokat milyen médiára szántuk. (Ezt nem kötelező megjelölni, hiszen a parser – működjön az bármilyen percepciós csatornán – csak azt fogja végrehajtani, ami számára értelmezhető. A további szerkesztés céljából azonban célszerű elkülöníteni a médiát, főleg ha a dokumentumhoz egyszerre több stíluslap is tartozik.) A "media" attribútumban megadható értékek pl.: aural, braille, handheld, print, tty stb. 

[Ld.: még: 3.2.2.3]

H.2.7 Scriptek

<SCRIPT>

A <STYLE>-hoz hasonlóan ebben az elemben is egy másik nyelv utasításait közölhetjük. A scriptek segítségével előre meghatározott módosításokat hajthatunk végre a dokumentumban, annak használata közben. Változtathatunk a megjelenítésen, transzformációkat hajthatunk végre, vagy hivatkozásokat nyithatunk meg a számunkra megfelelő módon.

A scriptek használatával ebben a dokumentumban egyáltalán nem foglalkozunk. Azt viszont mindenképp kihangsúlyozzuk, hogy nem célszerű a tartalmat, vagy annak részeit csak scriptek segítségével elérhetővé tenni (mert pl. egyes böngészők nem támogatják az adott scriptnyelvet); a scriptek csak kiegészítő opciókat biztosítsanak.

[Ld.: 03.2 Ajánlás]

A <SCRIPT> elem kötelező paramétere a "language", melyben a használt scriptnyelvet jelöljük meg.

Scriptet a dokumentumba ágyazva is meghatározhatunk, de hivatkozással is beköthetjük, akárcsak a stíluslapokat.

Ha a <SCRIPT> elemet használjuk, helyezzük el mellé a <NOSCRIPT>-et is, melyben alternatív információt közölhetünk scriptnyelvet nem támogató böngészők számára. Ezt azonban természetesen csak tartalmi szempontból nem releváns elemekre nézve alkalmazhatjuk.

Megjegyzés: Az itt elmondottak főleg a kliens-oldali scriptekre vonatkoznak. A szerver-oldali scriptekkel egyáltalán nem foglalkozunk, mivel nem térünk ki a webes programnyelvek jellemzőire.

↑H.3 Dokumentum-törzs

H.3.1 BODY

<BODY>

A dokumentumtörzs gyökérelemének attribútumaiban régen gyakran előfordultak az oldal egészét meghatározó formázási információk:

• background: háttérkép
• text: szövegszín
• link: hivatkozás színe
• vlink: meglátogatott hivatkozás színe
• alink: aktív hivatkozás színe

Ezek a jellemzők hangsúlyozottan kerülendők, mivel a stíluslapokban meghatározott utasítások nagy részét felülírják. A legjobb megoldás, ha a BODY semmiféle formázási utasítást nem tartalmaz, legfeljebb stílus-osztályt, ill. azonosítót.

H.3.2 Karakter-szintű elemek

H.3.2.1 Whitespace-elemek (szóköz, sortörés a forrásban)

A dokumentum további feldolgozásának megkönnyítése érdekében kerüljük az úgynevezett whitespace-ek variálását. A karakterszintű elemjelölésnél ügyeljünk arra, hogy ne hagyjunk láthatatlan karaktert (szóközt, sortörést) a tag és a jelölt elem között. Pl.:

Helytelen:

Vissza a <A> tartalomjegyzékre </A>.

Nagyon helytelen:

Vissza a <A> tartalomjegyzékre

</A>.

Helyes:

Vissza a <A>tartalomjegyzékre</A>.

Ha állományaink forrása következetes és áttekinthető marad, akkor azzal megkönnyítjük azok jövőben történő bárminemű feldolgozását (konverzióját, migrációját, szerkesztését stb.).

A HTML-ben nem törhető szóköz jelölésére használjuk a   elemet. Ennek használata végső soron nem káros, de ha sokszor lenne rá szükség, használjuk inkább a "whitespace: nowrap" stílus-utasítást.

A  -t  ne használjuk behúzás növelésére. Erre a helyes megoldás:

Helytelen:

<p>&nbsp;&nbsp;&nbsp;Magyarország történetének eseményes évtizede volt...

Helyes:

<p>Magyarország történetének eseményes évtizede volt...

 ahol: 

p { text-indent: 0.6em }

H.3.2.2 Karakter-szintű funkcionális elemek

Előfordulhat, hogy a dokumentumunkban a szövegen belül meg akarunk különböztetni egyes elemeket, mert sajátos funkcióval, vagy különleges fontossággal bírnak. Ha ezt formai (stilizáló) elemekkel tesszük, mint például a félkövér vagy dőlt szedés, esetleg a szövegméret növelése karakterek szintjén, akkor azok ki fognak tűnni a szövegből, de előfordulhat, hogy egyforma megjelenítési módot kell adnunk különböző okból kiemelt karakterláncoknak. Továbbá, a félkövér és hasonló kiemelési módok csak vizuálisan érzékelhető sajátosságokra utalnak, a hangzó ágensek többnyire nem tudják értelmezni, és figyelmen kívül hagyják azokat. Ellenben ha a kiemelést funkcionális jelölőkkel hajtjuk végre, akkor az elemjelölés azt fogja tükrözni, hogy milyen szempontból kell kiemelni azt az elemet. Ezekhez a különböző kiemeléseknek aztán különböző megjelenési, nyomtatási, ill. hangzó jellemzőket tulajdoníthatunk a stíluslapok segítségével, illetve egyszerűen módosíthatjuk is azokat.

H.3.2.2.1 Anchor

Az <A>-ral jelölt szakaszok a tartalom egyes részei közötti aktív kapcsolatra utalnak.

Fő attribútumai a "href", illetve a "name".

A href-ben mindig megnyitható URL vagy egyéb paraméterezett hivatkozás szerepel. Aktiválásával a jelölt helytől eltérő helyre ugrik a megjelenítés, mely lehet a dokumentumon belül, de attól egészen eltérő helyen is.

Fontos, hogy az A href="" elemkombináció mindig vizuálisan elkülönülő tartalmat fogjon közre, ellenkező esetben a hivatkozás láthatatlan marad.

Ha dokumentumon belülre ugrunk, akkor a célban nem kell fájlnevet megadnunk, csak az elérni kívánt pont azonosítóját, mely elé a hivatkozásban mindig tegyük ki a "#" jelet.

Pl.:

<A href="#footnote">Lábjegyzet</A>

Ha a hivatkozás a dokumentum-struktúrán kívülre, egy másik forrásra utal (azaz abszolút hivatkozás), akkor mindig tegyük ki a kommunikációs protokoll megjelölését is.

Helytelen:

<A href="www.litera.hu">Itt lehet a kortárs irodalomról tájékozódni.</A>

Helyes:

<A href="http://www.litera.hu">Itt lehet a kortárs irodalomról tájékozódni.</A>

Fontos továbbá a "target" attribútum, melyben meghatározzuk, hogy a megjelenítés hogyan kezelje az aktív kimeneteket (amelyeken a dokumentumot használjuk). Ez keretes (<FRAME>) szerkezetnél nélkülözhetetlen, ha azonban nem használunk kereteket (frame), alkalmazásuk kifejezetten ellenjavallt. A legtöbb vizuális böngésző most már többféle opciót kínál a felhasználónak, hogy az adott hivatkozást ugyanazon kimenetben, új ablakban, illetve új fülön ("tab") kívánja-e megnyitni. A target attribútum azonban korlátozza a felhasználót abban, hogy a hivatkozások az általa preferált kimeneten jelenjenek meg. Különösen veszélyes, ha számos hivatkozást irányítunk a target-tel ugyanazon ablakba, melyet a felhasználó éppen inaktívvá tett (MS Windows környezetben például lekicsinyítette a tálcára). Előfordulhat, hogy így nem fogja megtalálni a keresett tartalmat.

Az <A href=""> jelölést minden böngésző megkülönbözteti valamilyen módon. HTML-ben az ilyen hivatkozások megkülönböztető jeleit csak a stíluslapban adjuk meg.

A hivatkozás elem másik fontos tulajdonsága a szövegesen megadott tájékoztatás a link célpontjáról. Ezt a title attribútumban közölhetjük. Vizuális böngészőknél a title tartalma megjelenik a hivatkozási pont felett, ha a kurzort odamozgatjuk; fontosabb azonban, hogy a hangos böngészők ezzel az elemmel tájékoztatják a felhasználót a hivatkozás irányáról, ha az nem derülne ki az <A> elem által közrefogott tartalomból. A title attribútumban egyszerre mindig csak egy természetes nyelven közöljünk adatot.

Az <A href=""> elem nagyon fontos attribútuma az accesskey. Ebben egy billentyűértéket kell megadnunk, melynek lenyomásával a megjelenítés továbblép a megjelölt hivatkozásra. Hangos illetve karakteres böngészés esetén e nélkül nagyon nehéz a navigáció.

A name attribútummal olyan nevet adhatunk a kijelölt résznek, mely alapján az hivatkozással azonosítható. A name értékében ne használjunk ékezetes karaktert vagy szóközt.

Az azonosított hely így fog kinézni a forrásban:

<A name="footnote"><H4>Lábjegyzet</H4></A>

Az <A name=""> kombináció esetében a nyitó és zárótag közé nem feltétlenül kell tartalmat elhelyezni, mivel az információt nem feltétlenül kell szabad szemmel is látnunk. Ez a megoldás tehát elfogadható:

<A name="footnote"></A>
<H4>Lábjegyzet</H4>

H.3.2.2.2 Kiemelő elemek

Vannak olyan elemek, melyek egy karaktersor különböző jellegű kiemelésére szolgálnak, hasonlóan a korábbi, például szedést befolyásoló formázóelemekhez (B, I). A régebben elterjedt ilyen elemekkel szemben azonban ezek a kiemelési utasítások a közrefogott szövegszakasz általános megkülönböztető jellegét határozzák meg, nem egyszerűen tipográfiai utasítást adnak, és a hangosböngészők is képesek kezelésükre. Megjelenítésükre tetszőleges utasítást adhatunk a stíluslapban.

↑H.8 Ajánlás: A karakterszintű elemeknél csak funkcionális jellegű kiemelési módokat alkalmazzunk.

EM: hangsúlyos szövegrész (Az alapértelmezett vizuális megjelenítése általában a dőlt szedés. A beszédszintetizátorok kissé erősebb hangerőt és nyomatékot használnak.)

STRONG: fokozottan hangsúlyos szövegrész. (Az alapértelmezett vizuális megjelenítése általában a félkövér szedés. A beszédszintetizátorok jóval erősebb hangerő és nyomatékot használnak.)

CITE: idézet vagy hivatkozás (nem tévesztendő össze a "cite" attribútummal)

CODE: program- ill. forráskód-részlet.

ABBR: rövidítés – (a "title" attribútumban adjuk meg a rövidítés feloldását)

ACRONYM: betűszó, mozaikszó – (a "title" attribútumban adjuk meg a betűszó feloldását)

Q: az ezzel jelölt szövegrész idézet. Használatánál figyelembe kell venni, hogy ez az elem megjelenítésénél kiteszi a szükséges idézőjeleket, így azok a forrásban nem láthatók. Ellenben, a "lang" attribútum kitöltésével lehetővé válik, hogy a böngésző az adott nyelvnek megfelelő írásmódban jelenítse meg vizuálisan az idézőjeleket. Pl.:

<Q lang="hu">empiriokriticizmus</q>

megjelenítve: ”empíriokriticizmus” ;

valamint:

<Q lang="hu">valaki azt mondta: <Q lang="hu">valami</q></q>

Megjelenítve: „valaki azt mondta: »valami«”

Megjegyzés: Ez a funkció csak utf-8-as kódolású dokumentumokkal működik helyesen.

Bár a "SUB" és "SUP" elemek mind vizuális megjelenésre utalnak, használatuk indokolt, mivel bizonyos helyesírási rendszerek és írásrendszerek előírják ezeknek a formázásoknak használatát.

SUB: alsó indexben elhelyezett kisméretű szöveg

SUP: felső indexben elhelyezett kisméretű szöveg

A "SUP" elemet gyakran használják a lábjegyzet-hivatkozás jelölésére. Ez azonban önmagában nem mindig elég, célszerű erre formai osztályt létrehozni a stíluslapban.

H.3.2.2.3 Vizuális stílust jelölő, vagy bizonytalan kiemelő elemek (nem ajánlott)

B: félkövér szedés (Ne használjuk, megjelenítési módja bizonytalan a nem grafikus böngészőknél.)

I: dőlt szedés. (Ne használjuk, megjelenítési módja bizonytalan a nem grafikus böngészőknél.)

DFN: első előfordulás és/vagy definíció. (Ne használjuk, kiszámíthatatlan megjelenési mechanizmusokkal jár).

CENTER: középre rendezett szöveg. (Ne használjuk, elavult, a szabvány későbbi változatai nem fogják támogatni.)

U: aláhúzás (Ne használjuk, elavult, a szabvány későbbi változatai nem fogják támogatni.)

STRIKE: áthúzott, törlendő rész. (Ne használjuk, elavult, a szabvány későbbi változatai nem fogják támogatni.)

H.3.2.2.4 Karakterek

<FONT>

Ezzel a közrefogott szövegrész karaktereinek megjelenését határozhatjuk meg, három tulajdonság révén:

• size: méret. Értéke lehet abszolút illetve relatív szám, 1-től 7-ig (illetve 0).
• color: szín. A betűszínt megadhatjuk RGB-kódban (pl. #FFFFFF), illetve szabályos névvel (maroon, blue)
• face: betűtípus. Itt karakterkészletek neveit adhatjuk meg. Ha többet is megjelölünk, akkor az elöl szereplőnek lesz elsőbbsége, ha az nem elérhető (mert az a fontkészlet nincs az adott számítógépre telepítve), akkor a sorban következőt veszi figyelembe.

A FONT elem használata a fenti attribútumokkal a stílusok bevezetésével elavulttá vált. Alkalmazása megnehezíti a szöveg további szerkesztését és az esetleges konverziót. Ha a szövegen belül egy-egy szót, szövegtöredéket szeretnénk kiemelni, célszerűbb előre meghatározott stílusra hivatkozni a SPAN elemben.

↑H.9 Ajánlás: A HTML-kódban ne közöljünk betűtípus-utasításokat.

Tartsuk szem előtt azt is, hogy ha betűtípust határozunk meg a dokumentumunkban, akkor lehet, hogy annak megjelenése nem lesz megfelelő más környezetben, ahol esetleg az adott betűtípus nem elérhető. Ezért érdemes a legtöbb számítógépen elérhető alaptípusokra szorítkozni.

Hogy a HTML-szöveg olvasását megkönnyítsük, célszerű opcionális stíluslapok segítségével felajánlani egy serif-es (pl. Times New Roman, Times, Garamond stb.) és egy sans serif (pl. Arial, Helvetica, Verdana stb.) megjelenítési módot, mivel változó, hogy egyes emberek melyik típust olvassák könnyebben.

H.3.3 Bekezdés-szintű strukturális elemek

H.3.3.1 Bekezdés, szakasz

<DIV>, <P>

A <DIV> a szakaszt, a <P> a bekezdést jelentő alapvető elem. Működésük nagyjából hasonló.

A <DIV>-et a böngészők alapértelmezésben általában nagyobb behúzással jelenítik meg. Ebbe érdemes stíluslapokkal beavatkozni, és a megjelenítést nagyrészt DIV-ek egymásbaágyazódásával illetve egymásutánjával helyettesíteni. A CSS2 szabvány megjelenésével a DIV-ek gyakorlatilag teljesen kiválthatják a korábbi táblázatos honlaptervezési módszereket.

Mind a P, mind a DIV esetében elavult a régebben gyakran használatos align attribútum (left, right, center, justify értékekkel), ezért használatát kerüljük. Pozícionálásra a CSS stíluslapokban többféle lehetőség nyílik, pl.:

• a text-align illetve vertical-align
• a position
• a float
• és a margin illetve padding tulajdonságokkal.

H.3.3.2 Idézet behúzással

<BLOCKQUOTE>

Ez az elem bekezdésszintű idézetek jelzésére jött létre. A használata abban az esetben volt indokolt, ha sok, önálló bekezdésben szereplő átvett szöveget tartalmaz a forrásunk. Egyes böngészők azonban alapértelmezésként megnövelik a <BLOCKQUOTE> szövegmargóját, ezzel zavarhatják a stílusok használatát. Az azonban nem mondható, hogy a <BLOCKQUOTE> mindig margónöveléssel jár, így semmiképp se használjuk csak ennek a formázásnak a tükrözésére! Mindent összevetve, ne használjuk a <BLOCKQUOTE> elemet, ha elkerülhető. A bekezdésszintű idézést jobban megoldhatjuk a <Q> és stílusok kombinációjával.

H.3.3.3 Címsorok

<H1>, <H2>, <H3>, <H4>, stb.

A szöveg – pl. közölt folyóiratcikk, tartalomjegyzék vagy hír – fejezetrészeit formázási utasítások helyett jelöljük címsor-elemekkel. Így az egyes fejezetcímek és azok hierarchiája nemcsak automatikusan megjeleníthető, de követhető is a dokumentumon belüli hierarchia. Ha nem rendelünk külön stílust az egyes címszintekhez, a böngészők akkor is alkalmaznak majd alapértelmezett kiemelési mechanizmusokat (dőlt szedés, relatíve növelt szövegméret, lassabb beszédtempó stb.). Egyes konverzióknál automatikus tartalomjegyzék-generálásra is használhatók (mivel a címsorokat nemcsak a HTML-szabvány ismeri, hanem például a szöveg- és kiadványszerkesztő szoftverek is.).

↑H.10 Ajánlás: A kiadvány címadatait csak strukturális elemekkel jelöljük.

A címsorokat mindig zárjuk le a címadat végén. A címsor-tageken belül ne helyezzünk el egyéb elemeket, és a címsor elemeket se ágyazzuk más címsor- vagy bekezdésszintű elembe.

Pl.:

helytelen:

<h3><a href="02.html">Második alfejezet</a></h3>

helyes:

<a href="02.html"><h3>Második alfejezet</h3></a>

A címsorok szintje számozódik, 1-től 6-ig terjedő értékekben.

Ilyen lehet pl. egy átlagos struktúra:

<H1>Főcím</H1>

<H2>Alcím</H2>

<H3>Első fejezet</H3>

<H4>Első alfejezet</H4>

<H4>Második alfejezet</H4>

<H4>Harmadik alfejezet</H4>

<H3>Második fejezet</H3>

<H4>Első alfejezet</H4>

<H4>Második alfejezet</H4>

<H3>Függelékcím</H3>

H.3.3.4 Listák

A felsorolások funkcionális megjelöléséhez többféle listaelemet használhatunk. A listák használatánál megjelöljük a lista jellegét, majd az egyes tételeket a listaelem (<LI>, <DT>) jelölőkkel ágyazzuk be, melyeket mindig lezárunk a tétel végén. A listákon belül a vonatkozó listatételen kívül nem szerepelhet más, mint esetleg egy másik lista, többszintű felsorolások esetén. Ilyenkor nagyon ügyelni kell a helyes elemjelölésre (pl. a lezáró tagekre.)

Olyan felsorolásoknál, ahol a listaelemek sorrendbe állíthatók (fontosság, időrend) használjuk az <OL> elemet.

Ez sorszámozott listát eredményez.

A "start" attribútumban megadhatjuk, hogy mi legyen az induló sorszám, a type-ban pedig megjelölhetjük a felsorolás típusát (az alapértelmezés az arab számozás):

type="i" kis római számok

type="I" nagy római számok

type="A" nagybetűk abc-rendben

type="a" kisbetűk abc-rendben

Egyenértékű elemek felsorolásánál használjuk az <UL> elemet.

Itt a listaelem grafikus jelölőjét állíthatjuk:

type="disc" (pötty, alapértelmezett)

type="square" (rombusz)

type="circle" (karika)

CSS stílus segítségével elérhetjük azt is, hogy semmiféle grafikus elem ne jelenjen meg, valamint további opciókat is beállíthatunk.

Pl.:

<ul style="list-style-type: none">

Meghatározások felsorolásánál, szómagyarázatoknál használjuk a definíciós listát <DL>, melynek építőkövei a <DT> (definiált terminus), valamint az abba ágyazott <DD> (meghatározás). Bár a szabvány nem írja elő a <DT> lezárását, célszerű mégis gyakorolni, arra az esetre, ha stílust rendelnénk hozzá.

H.3.4 Nagyobb belső elemek

H.3.4.1 Táblázatok

Fokozottan strukturált típusú adatok (pl. számok, szöveges ábrák, összehasonlító adatok) közléséhez az adatokat célszerű táblázatba rendezni.

Táblázatot a <TABLE> elem segítségével hozhatunk létre. A TABLE elem nem érvényes a belső struktúrát meghatározó elemek a sor <TR> illetve a cella <TD> nélkül. Ha egy oszlopnak sajátos szerepet tulajdonítunk a táblázaton belül, akkor azt a <COL>, illetve <COLGROUP> elemmel tehetjük meg. A táblázat címét a CAPTION elemben célszerű közölni. A SUMMARY elem alternatív tartalom közlésére alkalmas, melyben a táblázat tartalmát foglalhatjuk össze olyan böngészők számára, melyek nem tudnak táblázatokat megjeleníteni.

A colspan és rowspan attribútumokkal összevont sorokat, illetve oszlopokat illeszthetünk a táblázatba. Ezzel az adatokhoz igazítjuk a táblázat megjelenését, viszont megnehezítjük a további feldolgozást, mert összevont sorokat és oszlopokat tartalmazó táblázat további szerkesztése meglehetősen bonyolult.

Lehetőség van arra is, hogy a nagyon összetett szerkezetű, összehasonító, súlyozott, vagy egyéb szempontból strukturálandó adataink közléséhez még jobban megkülönböztessük a táblázat egyes elemeit. A következő további strukturális elemeket határozhatjuk meg:

• <THEAD>
• <TFOOT>
• <TBODY>
• <TH>

A fenti elemek használata lehetséges külön-külön is, de igazából célszerű vagy az összes strukturális szintet megjelölni, vagy megmaradni az egyszerű szerkezetnél. Ha valamit például csak a gazdaságosabb térkitöltés vagy elrendezés miatt ágyaztunk táblázatba, akkor ezek az elemek feleslegesek.

A táblázatokat meghatározó elemekben nagyon sok attribútum áll rendelkezésre, melyek különböző elhelyezkedési, méretezési illetve megjelenítési utasításokat fejeznek ki. Itt mérlegelnünk kell, hogy mennyi formázási utasítást írunk bele a HTML-kódba, és mennyit adunk meg stíluslapban.

Ha az állományaink csak egy-két, eltérő jellegű táblázatot tartalmaznak, akkor beleírhatjuk a megjelenési utasításokat a vonatkozó elemekbe (eltekintve a kifejezetten ellenjavallottaktól). Ha viszont sok táblázatunk van, és szerkezetük releváns és hasonló, akkor jobb azonosítóval (id) illetve általunk definiált osztállyal (class) ellátni a táblázat építőköveit, és stíluslapban meghatározni a vonatkozó formázást.

A HTML-ben a következő formázási utasítást adhatjuk a táblázatot alkotó elemekben.

Elhelyezkedés:

• align: az oldaltükörhöz képest viszonylagos horizontális elhelyezkedés (left, right, center). A szabvány újabb változatai nem támogatják, kerüljük a használatát.
• valign: az oldaltükörhöz képest viszonylagos vertikális elhelyezkedés (left, right, center). A szabvány újabb változatai nem támogatják, kerüljük a használatát.

Méret:

• width: szélesség. Megadhatunk abszolút, és relatív értéket is.
• height: magasság. Megadhatunk abszolút, és relatív értéket is.

Háttér, keret:

• background: háttérkép. Nagyon kevés böngésző támogatja, kerüljük a használatát.
• bgcolor: háttérszín. Nagyon kevés böngésző támogatja, kerüljük a használatát.
• border: keret szélessége. "0" értéknél nincs látható keret.
• bordercolor: keret színe
• bordercolor light: világos ("fényoldali") keretszín. Nagyon kevés böngésző támogatja, kerüljük a használatát.
• bordercolor dark: sötét ("árnyékolt") keretszín. Nagyon kevés böngésző támogatja, kerüljük a használatát.

A fenti, illetve további, táblázat megjelenését befolyásoló tulajdonságokat megbízhatóbban közölhetjük stíluslapokban.

A jelenleg megszilárduló webszerkesztési elvek kifejezetten kerülendőnek tartják táblázatok használatát a grafikus megjelenés szerkezetének kialakításához. Ez a megoldás szinte kizárólag monitoron megjelenve működik, a kézi illetve hangos eszközök nem tudják kezelni.

↑H.11 Ajánlás: Táblázatot csak kifejezetten ilyen formázást igénylő adat közlésénél alkalmazzunk, ne használjuk mint a grafikus megjelenítés szerkezeti alapját.

Fontos figyelembe venni, hogy a forgalmazott képernyőméretek egyre nagyobbak és többféle aránnyal jelennek meg, ezért ésszerűbb tetszőlegesen átméretezhető arculatokat tervezni. Ilyen megoldásnál a táblázatok használata korlátozó tényező lehet.

A táblázatos megoldás helyett használjuk a stílusokkal meghatározott DIV elemet a honlap strukturális bázisaként. Az ilyen tervezés több odafigyelést igényel, de hosszú távon sokkal megbízhatóbb.

H.3.4.2 Képek

Ha a dokumentumok tartalma szöveges is, szükség lehet kiegészítő, illusztráló jelleggel képek beszúrására is. (A teljes terjedelmükben képként közölt állományokkal a következő fejezet foglalkozik.)

A szöveges kiadványba beszúrt képek számánál legyünk tekintettel arra, hogy a képek letöltési ideje még mindig lassíthatja a böngészést. Ezért a következőket ajánlatos megfontolni:

• Csak annyi képet használjunk, amennyi tartalmi és esztétikai szempontból feltétlenül szükséges. Ha egy weboldal túl sok grafikus elemet tartalmaz, akkor csak vizuális böngészők számára biztos a használata, és az oldal betöltési ideje is jelentősen nőhet.
• Mindig használjuk a kép céljainak megfelelő legkisebb méretet lehetővé tevő formátumot, ilyen a PNG, JPG és a GIF.

A képet a lehető legkisebb méretben jelenítsük meg. Ha a kép megtekintése nagyobb méretben és felbontásban elkerülhetetlen, akkor készítsünk belőle kicsi bélyegképet, melyre kattintva betölthető a nagyobb változat.

A képek beszúrása az <IMG> elem segítségével lehetséges, melynek attribútumai:

• src: forrás. Nélkülözhetetlen, itt adjuk meg, hogy hol is van a megjelenítendő kép a dokumentumunkhoz képest.
• alt: szöveges helyettesítő. A nem grafikus böngészők ezt az információt közlik a kép helyett, mindig töltsük ki, ha a kép tartalmi információt közöl. Üresen hagyni nem célszerű, ezért a csak dekoratív céllal, informatív érték nélkül beszúrt képeket inkább illesszük be háttérképként. Az  alt elemben egyszerre mindig csak egy természetes nyelven közöljünk adatot.
• longdesc: hosszú leírás. Itt hivatkozhatunk egy olyan fájlra, mely részletesen, szöveges formában közli a kép tartalmát.
• hspace: kép széle és a tartalom többi része közötti horizontális távolság. A szabvány újabb változatai nem támogatják, kerüljük a használatát. (CSS-helyettesítője pl. a padding tulajdonság.)
• vspace: kép széle és a tartalom többi része közötti vertikális távolság. A szabvány újabb változatai nem támogatják, kerüljük a használatát. (CSS-helyettesítője pl. a padding tulajdonság.)
• align: az oldaltükörhöz képest viszonylagos horizontális elhelyezkedés (left, right, center). A szabvány újabb változatai nem támogatják, kerüljük a használatát. (CSS-helyettesítője pl. a float, ill. margin tulajdonság.)
• valign: az oldaltükörhöz képest viszonylagos vertikális elhelyezkedés (left, right, center). A szabvány újabb változatai nem támogatják, kerüljük a használatát. (CSS-helyettesítője pl. a float, ill. margin tulajdonság.)
• border: keret szélessége. "0" értéknél nincs látható keret. 

A kép megjelenítési méretét is megadhatjuk az IMG elem attribútumaiban. Nem célszerű azonban itt az src-ben hivatkozott kép méreteitől eltérő adatokat megadni. A kép böngésző általi felnagyítása általában rossz minőséget eredményez. A lekicsinyítéssel pedig az a probléma, hogy a háttérben a kép teljes méretében betöltődik, így nem takarítunk meg vele letöltési időt.

A képméret megadása:

• width: szélesség, pixelben.
• height: magasság, pixelben.

Nagy képek megjelenítéséhez ágyazzuk a szövegbe a kép kisméretű változatát, és helyezzünk rá a nagyobb változatra mutató hivatkozást. Ilyenkor célszerű az IMG elem border attribútumát "0" értékre állítani, mert a legtöbb böngésző bekeretezi a képet, ami időnként zavaró. A nagyobb képre való hivatkozást nyissuk meg új ablakban, hogy a szöveg olvasása mellett vissza lehessen térni a tanulmányozásához.

Példa:

<a href="images/nagykep.jpg" target="_blank"><img src="images/kiskep.jpg" alt="Az idegsejt felépítése" border="0"></a>

↑3.2.2.3 A stílusokról

Ha egyszerű és világos struktúrájú HTML-forrást használunk, nem akadályozza semmi, hogy igényeink szerint alakítsuk ki a szöveg megjelenítését. Ezt a stíluslapok segítségével tehetjük.

↑H.12 Ajánlás: A HTML-ben csak funkciókat határozzunk meg, minden formázási utasítást stílusokkal kell kifejezni.

A stíluslapok lényege, hogy az egyes elemekre nézve egységesen határozzák meg annak formáját (nem pedig megismételve a jellemzőket az elem minden előfordulásánál). A stíluslapok használatával nagyobb szabadságot biztosítunk mind a dokumentum előállítóinak, mind a felhasználóknak, ugyanis az egyes elemek formai tulajdonságai egy ponton egyszerre megváltozathatók, átmenetileg illetve akár véglegesen is.

Az átmeneti stílusváltáson azt értjük, hogy eleve többféle stíluslapot csatolunk a dokumentumunkhoz, és a felhasználás során döntjük el, hogy ezek közül melyiket akarjuk használni. Ezzel gyakran találkozhatunk pl. weboldalaknál, mikor egy hivatkozásra kattintva az adott dokumentum nyomtatható változatát kapjuk meg. Ilyenkor az esetek többségében a megjelenítés-barát stílust meghatározó lap felcserélődik egy, a nyomtatás számára értelmezhetővel.

Végleges stílusváltást általában szerzői oldalon végzünk, ha a dokumentumokat pl. más formátumba konvertáljuk, a tartalom migrációjánál, esetleg korszerűsítésénél. Ilyenkor nem kell újraformáznunk az egyszer már feldolgozott tartalmat. Gondolunk itt pl. az XML-ből HTML-be exportált állományok esetére.

A HTML-nyelv esetében a legkézenfekvőbb a CSS (Cascading Style Sheet) szabvány használata. Ilyenkor a HTML-forrásban kijelölt elemeket feleltetjük meg a CSS-nyelv szabályai szerint megfogalmazott formátummal. A megfeleltetéseket a CSS-stíluslapban rögzítjük. A CSS-szabvány további előnye, hogy XML-formátumú állományok megjelenítésére is közvetlenül alkalmazható. 

↑03.19 Ajánlás: HTML-formátumú dokumentumaink megjelenítési utasításait tároljuk CSS stíluslapokban.

A CSS jelenleg legkidolgozottabb specifikációja a 2.1-es verzió. Ez számos innovatív lehetőséget tartalmaz, de a bevezetett újdonságok egy részét számos böngésző nem támogatja. Ilyenek az Internet Explorer és az Opera legtöbb változata.

A stíluslapot elhelyezhetjük a HTML-dokumentum fejlécében is (a <STYLE> elemben), de a legrugalmasabb megoldás az, ha külön fájlban tároljuk ezeket a megfeleltetéseket, melyre minden érintett állományban hivatkozunk.

[Ld.: H.2.6]

Ilyenkor a HTML elemek ú.n. „szelektor”-ként is működnek, ugyanis az általuk jelölt tartalmat összekötik a megjelenítési formával, azaz a stílusdeklarációval. A HTML elem és a stílus közötti kapcsolatot a bármely elemben elhelyezhető "class", "id" illetve "style" attribútummal tehetjük.

A stíluslapban szorítkozhatunk arra, hogy csak a HTML-nyelv alapját képező, előre definiált elemekre nézve adunk meg stílusokat, tehát meghatározzuk, hogy milyen legyen pl. a címsorok, a bekezdések formája, vagy például a háttér. Ezen felül azonban meghatározhatunk egyéni formai osztályokat is, az egyes elemeken belül önállóan meghatározott csoportok definiálásával megkülönböztethetjük a megjelenítés szempontjából elkülönítendő elemeket. Így lehet például többféle bekezdésünk, listánk vagy fejlécünk, mindegyikük külön-külön definiált stílussal. 

↑03.20 Ajánlás: Fontos, hogy HTML dokumentumoknál tartalmi információt sose fejezzünk ki a stílusban, és ügyeljünk arra, hogy a stíluslap eltávolítása ne tegye értelmezhetetlenné a tartalmat.

Nem célszerű pl. csak stílus segítségével jelezni, hogy adott tartalomrész idézet, jegyzet, stb. Amire a HTML-ben találunk formai elemet, arra ne hozzunk létre önálló formai osztályt, hacsak nem feltétlenül szükséges

A stílus a használat (kimenet, illetve megjelenítés) szempontjából jelentős, a tartalomra nem hathat vissza. Ezért sose hivatkozzunk a tartalomhoz tartozó elemekre (pl. információt tartalmazó beszúrt képek), a stíluslapon keresztül.

↑03.21 Ajánlás: Tegyük mindig nyilvánvalóvá a felhasználó számára, hogy lehetősége van többféle megjelenítési mód közül választani.

A megjelenítési módok közötti váltás általában a stíluslapok cseréjével történik. Ilyenkor a változtatandó elemre vonatkozó stílust is kicserélhetjük, vagy akár az egész dokumentumra vonatkozó stílusdefiníciót. Ez általában hivatkozásra való kattintással, illetve ezáltal életbe lépő script-utasítással történik. Miután az egyes stílusok használata sokkal könnyebbé teheti a dokumentum használatát bizonyos felhasználók számára, illetve bizonyos környezetekben; a megjelenített tartalomban kitüntetett helyre, egyértelmű jelöléssel helyezzük el azt az elemet, ami a változtatást lehetővé teszi.

[Ld.: még: H 2.6]

Miután a formázást stílusok segítségével határozzuk meg, itt jut szerep a megjelenítést befolyásoló mértékegységeknek is. A vizuális megjelenítéshez háromféle mértékegységet használhatunk:

Relatív

gyakoribb relatív mértékegységek:

• em = az aktuális elemen belüli fontméret alapján generált hosszméret
• px: képpont (pixel), mérete a kimeneti eszköztől függ

A fenti lehetőségek közül a px egységet csak nem skálázandó elemek, az em egységeket pedig skálázandó tartalomrészek (például a szöveg) méretezésére használjuk.

Abszolút

gyakoribb abszolút mértékegységek:

• in: hüvelyk (inch).
• cm: centiméter
• mm: milliméter
• pt: tipográfiai pont
• pc: pica (1 pica=12 pt)

Az abszolút hosszmértékekkel nagyon nehéz flexibilis oldalakat készíteni. Az így megadott szövegméret egyes böngészőkben nem lesz skálázható.

Százalék

Ebben az esetben a böngészők mindig a befoglaló elem méretéhez képest számolják ki az adott értéket. Ideális megoldás többféle grafikus mintát nem tartalmazó dokumentumokhoz.

Miután ezek a mérettípusok szabad szemmel látható értékeket befolyásolnak, figyelembe kell venni, hogy a felhasználóknak különböző igényeik lehetnek ezen a téren. Ezért legalább a tartalom szöveges részénél lehetővé kell tenni, hogy a felhasználó igényei szerint, információvesztés nélkül nagyíthassa illetve kicsinyíthesse a szöveget. Ezt rugalmas mértékegységek használatával érhetjük el.

↑03.22 Ajánlás: A formázási utasításokat mindig fogalmazzuk meg úgy, hogy legalább a szöveges tartalom átméretezhető legyen.

A legjobban skálázható megoldások: százalékos érték, em. Jó megoldás például, ha a szövegjellegű elemek – pl. H1, P – méretét százalékban, a doboz jellegű egységekét és tulajdonságokét – pl. DIV, margók – em-ben adjuk meg.

Linkajánló:
CSS 2.1 Specifikáció
http://www.w3.org/TR/CSS21/
CSS2 Specifikáció (magyarul)
http://htmlinfo.polyhistor.hu/css2ref/cover.htm

↑3.3 Képként szolgáltatott kiadványok

↑3.3.1 Mit szolgáltassunk képként?

Képként való szolgáltatás alatt azt értjük, amikor magát az időszaki kiadvány tartalmát a szolgáltatott állomány semmiféle, gépi úton értelmezett formában nem tárolja, tehát a szöveges információ például csak szabad szemmel olvasva értelmezhető. Ebben az értelmezésben tehát nem jelent képként való szolgáltatást a kétrétegű (kép és szöveg) PDF, illetve a METS/ALTO beágyazott TIFF.

Miután ez a szolgáltatási forma arányaiban kevesebb hasznosítható információt tartalmaz, ellenben nagyobbak lehetnek a méretigényei, csak indokolt esetben folyamodjunk ehhez a megoldáshoz.

A képi szolgáltatást az indokolhatja, ha a kiadvány szöveges tartalmának kinyerése nem valósítható meg racionális keretek között az elvárt minőségben, mert

• A kiadvány korából fakadó helyesírási és tipográfiai jellemzők nem dolgozhatók fel megbízhatóan.
• A rendelkezésre álló digitális nyersanyag rossz minőségű, nem korrigálható és nem reprodukálható (ez a három tényező egyidejűleg fennáll).
• A kiadvány olyan nyelven íródott, melyen nem rendelkezünk a biztos feldolgozáshoz elegendő kompetenciával. Ez nem pusztán az idegen nyelvű kiadványokra értendő, régi, anyanyelvünkön készült kiadványoknál esetenként olyan szövegkritikai problémák merülhetnek fel, melyek megoldása meghaladja egy digitalizálási projekt kereteit.

A fenti tényezők természetesen a rendelkezésre álló erőforrások és a kiadvány terjedelmének dimenzióiban rugalmasan értelmezendők. Ha tehát bővében vagyunk az erőforrásoknak, illetve a kiadvány kis terjedelmű, de tartalmilag nagy jelentőségű, akkor a karakterfelismerést járulékos munkafolyamatokkal – korrektúra, szövegkritika – kiegészítve elkészíthetjük a szöveges változatot is.

↑03.23 Ajánlás: Amennyiben a többi ajánlott formátum elkészítése megvalósíthatatlan a rendelkezésre álló erőforrásokból, kiadványunkat tegyük elérhetővé pusztán képi állományokban.

Előfordulhat az is, hogy a képi változat többletinformációt nyújt a szöveges formátumokhoz képest. Ilyenkor megfontolandó, hogy a kiadványt képi változatban is közzétegyük. Erre a következő esetekben lehet szükség:

• A kiadvány látható jellemzői önmagukban információt hordoznak. Ez a helyzet például a korai kiadványokkal, melyek formai jegyei fontos nyomdatörténeti, művelődéstörténeti információt közölnek. Ennek közvetítésére legcélszerűbb a jó minőségű képi reprodukció, mely például megőrzi a nyomdatechnikai sajátosságokat tükröző részleteket, a papírminőséget és egyéb tulajdonságokat.
• A kiadvány nagymértékben és kiemelkedő minőségben illusztrált. Amennyiben az illusztrációk nem ágyazódnak a szöveges tartalomba, elégséges lehet csak az illusztrációk képi formátumú szolgáltatása, tartalmi összefüggés esetén ellenben szükséges lehet a teljes képi reprezentáció is.
• A kiadvány nagyobb arányban tartalmaz csak képként értelmezhető disztinkt (tehát nem egyes közlemények tartalmát kiegészítő) információt, mint pl. térképek, képversek, rejtvények, karikatúrák.

↑03.24 Ajánlás: A képként értelmezhető többletinformációt tartalmazó kiadványokból készítsünk az eredeti látható jellemzőit legjobban visszaadó képi változatot legalább kiegészítő jelleggel.

[Ld.: 3.2.1.3]

↑3.3.2 A képi formátum

Míg a képi megjelenítés nyilvánvaló korlátokat jelent a szöveges formátumokkal szemben, ez esetben is fontos, hogy az állományok minél használhatóbbak legyenek a webes környezetben. Ennek érdekében két összefüggő, de ellentétes tényező között kell megtalálni az egyensúlyt: a fájlok mérete és a képi minőség.

Az elfogadható képminőség természetesen mindig a kiadvány tartalmi és formai jellemzőitől függ. Abban az esetben például, ha éppen a vizuális jellemzők tükrözése indokolta a képi formátumot (pl, régi, ritka, gazdagon illusztrált kiadványok), engedményt tehetünk a minőség javára. Oldalanként 500 kB feletti képméret esetén azonban inkább biztosítsunk alternatív hozzáférési lehetőséget (pl. letöltés), kevésbé részletgazdag előnézet biztosításával.

Amennyiben a tartalom nem követeli meg az aprólékos részletek visszaadását, természetesen racionalizálható a megjelenítés a színmélység csökkentésével, vagy a kontraszt növelésével. Nem jó megoldás ellenben a képek szürkeárnyalatos vagy fekete-fehér módban való közzététele, az ilyen képek általában szembántóak, és a kelleténél több részlet veszhet el a konverzióval.

Az ajánlott, közvetlenül webes környezetben elérhető képi formátumok (GIF, JPG illetve PNG) kezelhető méretben képesek digitális folyóiratok képoldalainak megfelelő oldalképeinek szolgáltatására. Mindig a tartalom és szolgáltatás lehetőségeinek fényében kell mérlegelni, hogy a digitális létrehozás (szkennelés, fotó vagy kiadvány-, illetve képszerkesztő szoftver) során előállt formátumból melyik közvetlen online használatra alkalmas formátumba mentjük ki a szolgáltatott változatokat.

Ebben az ajánlásban nem térünk ki a szolgáltatott képformátumok jellemzőire és a kapcsolódó konfigurációs lehetőségekre, ezek önálló dokumentum tematikáját alkotják. Hozzá kell tenni még, hogy várható a FLASH felzárkózása ehhez a körhöz, mivel a formátum egyre szélesebb körben támogatott és számos olyan kérdésre kínál megoldást, melyekre a jelenlegi képformátumok nem birkóznak meg, ilyen például a beépített veszteségmentes átméretezés illetve a folyamatos tartalom tárolása.

[Ld.: 03.1, 03.3 Ajánlás]

↑3.3.3 A képalapú digitális kiadvány szerkezete

A képi formában történő publikálás egyik fontos sajátossága, hogy vizuális kiterjedése miatt gondot okozhat együttesen biztosítani a tartalom, valamint a navigációs és azonosítási mechanizmusok elérhetőségét. Az önálló, képi alapú dokumentumokkal ellentétben ugyanis az időszaki kiadványoknál egy kép általában csak egy oldalt jelent a dokumentumból, mely önállóan, a kiadvány egészéből kiemelve elveszti tartalmi és funkcionális jelentőségének nagy részét.

Ezt figyelembe véve, indokoltnak mondható, hogy az egyes képi oldalképek önállóan azonosíthatóak legyenek weboldalként, valamint lehetséges legyen a kiadvány egységeit alkotó egységek közötti navigáció.

↑03.25 Ajánlás: Az időszaki kiadványt alkotó képi oldalakat foglaljuk egyenként önálló keretbe, HTML-ként megjeleníthető formátumban.

Ezt a gyakorlatot a főként az indokolja, hogy bár egy képi állomány általában akadály nélkül megtekinthető webes környezetben, ezen a módon nem lehetséges

• közvetlenül (pl. vizuális úton) észlelhető leíró adatok elhelyezése
• szöveges helyettesítők feltüntetése a képi állományoknál
• navigációs mechanizmusok elhelyezése.

Ennél a formátumnál a legnagyobb problémát általában az jelenti, hogyan alakítsuk ki a megjelenítést úgy, hogy mind magának a tartalomnak, mind a navigációs és az azonosítási részleteknek megfelelő elhelyezést biztosítsunk. A folyóiratok oldalankénti böngészése során több dimenzió mentén kell gondolkoznunk:

1.

azonosítás: az oldalak egymásutánisága, azaz a kiadvány fizikai felépítése

navigáció: lapozási lehetőség az előző és következő lapra

2.

azonosítás: az adott oldal szerepe, mint egy közlemény, cikk vagy egyéb alegység, tehát részegységen belüli tartalom

navigáció: ugrás az adott közlemény kezdőpontjára

3.

azonosítás: az oldal viszonya a kiadványegységhez, tájékoztatás arról, hogy mely egység részét képezi

navigáció: közvetlen ugrás az adott részegység tartalomjegyzékére vagy kezdőlapjára

4.

azonosítás: az oldal viszonya a kiadványhoz, tájékoztatás arról, hogy mely kiadvány részét képezi

navigáció: közvetlen ugrás a kiadvány nyitólapjára

↑3.34 Ajánlás: Képi formátumoknál az oldalak egyedi HTML-ként megjeleníthető keretei a következő azonosítási és navigációs lehetőségeket tartalmazzák:

A fenti modell egy lehetséges kivitelezése látható az alábbi sematikus ábrán. Ez egy olyan szerkezetet ábrázol, melyen igyekeztünk a lehető legtöbb azonosítási és navigációs pontot feltüntetni, és figyelembe venni az olvashatóság és áttekinthetőség szempontjait is.

Az egyes tartalmi egységek elrendezése természetesen opcionális, de a jelen lehetőségek mellett ajánlatos az alábbi elrendezést használni, mivel a használatos képernyők – tehát a formátum esetében alapvető megjelenítési eszköz – orientációja túlnyomó többségben „fekvő” (azaz a vízszintes oldalai hosszabbak), így célszerű az oldalak közötti böngészést segítő navigációs sort és magát a képet tartalmazó blokkot egymás mellett elhelyezni, kihasználva a vízszintes tértöbbletet. Az azonosító információkat (kiadvány címe, számozás, keltezés stb.) pedig célszerű az oldal tetején feltüntetni, mivel így akkor is rögtön nyilvánvaló, hogy milyen tartalomról van szó, ha a felhasználó egy véletlenszerű oldalon kezdi meg a böngészést.

↑3.3.3.1 Képi megjelenítés tartalomjegyzék nélkül

3.3.1 ábra: Képi formátum megjelenítésére ajánlott szerkezet tartalomjegyzék nélkül

Ez a megoldás a kisebb terjedelmű kiadványszámok esetében ideális, ahol a közlemények terjedelme sem haladja meg az 1-2 oldalt, illetve erősen szegmentált az oldalak tartalma (régi újságok, napilapok vicclapok stb.).

A modell 1024x768-as képernyőfelbontás figyelembevételével készült.

Jelmagyarázat:

1. Maga az oldalt tartalmazó képfájl, a szolgáltatott teljes változat. A kép elem szöveges helyettesítőjének tartalma: "Kiadvány cím, számozás keltezés (lehet rövidített), oldalszám." Kivételes esetben, illetve ha még kisebb felbontásra optimalizáljuk a szerkezetet, megoldható, hogy a képre helyezett hivatkozás mögé egy még nagyobb változatot helyezünk el, mely önálló képként, HTML-jellegű keret nélkül nyílik meg. Itt két megoldás lehetséges:
   1. Nagy méretű, de 3000x2000 pixel felbontást meg nem haladó képfájl. Ez akkor ajánlott, ha igazán részletgazdag képre van szükség, melynek megjelenítéséhez hasznosnak bizonyulhat a legtöbb böngészőben elérhető automatikus zoom-funkció. (Ennek figyelembevételével nem ajánlunk itt újabb HTML-jellegű keretet a nagyobb képhez.)
   2. Ennél nagyobb, extrém méretű képeknél a hivatkozás mögött elhelyezhetünk FLASH-alapú képzoom animációt. Ez esetben azonban a képi változat keretében a formátumra vonatkozó figyelmeztetést kell elhelyeznünk.
2. Az adott kép oldalszáma (az oldal sorszáma). Hivatkozást nem tartalmaz.
3. Az előző oldal sorszáma. A hivatkozás az előző oldalt tartalmazó HTML-jellegű keretre mutat. A title tulajdonságba a navigáció irányát írjuk (pl. "előre", "vissza")
4. A következő oldal sorszáma. A hivatkozás az következő oldalt tartalmazó HTML-jellegű keretre mutat.
5. Bélyegkép. Minden egyes bélyegképen hivatkozás található a megfelelő képoldal HTML-jellegű keretfájljára. A kép elem szöveges helyettesítőjének tartalma: "Kiadvány cím, számozás keltezés (lehet rövidített), oldalszám."
   1. Nagy oldalméretű kiadványoknál, valamint ahol a bélyegkép irreleváns – például napilapoknál, ahol kis képméretnél az oldalak nem különböztethetők meg egymástól – a bélyegképek helyett elegendő az oldalszám feltüntetése, és az azokon elhelyezett hivatkozás a vonatkozó oldalak keretfájljaira. Ez esetben a hivatkozás title tulajdonságában helyezendő el az információ: "Kiadvány cím, számozás keltezés (lehet rövidített), oldalszám."
   2. Szintén megfontolandó a bélyegképek feltüntetése terjedelmesebb kiadványok esetén. A bélyegképek ugyanis minden lapozásnál betöltődnek, ez pedig semmiképp sem hasznos, ha azok száma 50-100, vagy még több lehet. Ilyen esetekben szintén maradjunk az oldalszámok feltüntetésénél.
6. Az elérhető oldalak sorszáma. A számokon elhelyezett hivatkozás a vonatkozó oldalak keretfájljaira mutat, a link title tulajdonságában ezekkel az adatokkal: "Kiadvány cím, számozás keltezés (lehet rövidített), oldalszám." Indokolt esetben a szövegesen kiírt oldalszámok helyettesíthetik a bélyegképeket (ld. 5.a pont).
7. Amennyiben a kiadványt gyűjtemény részeként szolgáltatjuk, feltehető, hogy az rendelkezik valamiféle grafikus azonosítóval (pl. logo). Ennek elhelyezése azonnali tájékozató értékkel bírhat arra nézve, hogy kinek a kezelésében van a digitális kiadvány. A piktogramra (illetve grafikus elem híján a gyűjtemény ill. kiadó nevére) elhelyezett hivatkozás mutasson a szolgáltató gyűjtemény nyitóoldalára vagy a kiadó honlapjára, ennek híján a kiadvány nyitóoldalára. A kép szöveges helyettesítőjébe, vagy a title tulajdonságába írjuk be a következő információkat "szolgáltatás ill. kiadó neve – nyitólap".
8. A kiadvány címére tegyünk hivatkozást a teljes kiadvány nyitólapjára, title tulajdonságba írjuk be a következő információkat: "Kiadvány címe – nyitólap". Ezt az adatot megismételhetjük az oldal alján is, ha kényelmi szempontok indokolják.
9. A számozás és keltezés feltüntetett adatára tegyünk hivatkozást az adott szám tartalomjegyzékére, annak híján a szám képként böngészhető tartalmának kezdőoldalára. A title tulajdonságba írjuk be a következő információkat: "Kiadvány címe, számozás, keltezés (rövidítve) – nyitólap". Ezt az adatot megismételhetjük az oldal alján is, ha kényelmi szempontok indokolják.
10. A „Kiadvány leírása” elem megnevezése attól függ, hogy mit helyezünk el mögötte hivatkozásként: lehet az szabványos bibliográfiai leírás, önállóan, vagy adatbázis részeként, különböző leíró adatokat (pl. bibliográfiai leírás és szöveges ismertető) ötvöző oldal. A title tulajdonságot töltsük ki ennek megfelelően. Ezt az adatot megismételhetjük az oldal alján is, ha kényelmi szempontok indokolják.
11. A szerzői jogi tudnivalókat akkor tüntessük fel, ha a „Kiadvány leírása” elem nem tartalmazza azokat. A hivatkozás a digitális kiadvány használatát érintő jogi tudnivalókat tartalmazó fájlra mutasson.
12. Az ábrán a piros vonal jelzi, hogy normál méretű megjelenítés körülbelül hol található a képernyő alja. Ez láthatólag azzal járhat, hogy a kép teljes egészében nem fér el a kimeneten. Bizonyos kiadványok esetében természetesen ennél kisebb képméret is elegendő a tartalom részleteinek megőrzése érdekében. Figyelembe kell venni azt is azonban, hogy a személyi számítógépek átlagos képernyőmérete egyre növekvő tendenciát mutat, így lehetséges, hogy a kisebb felbontásra optimalizált megjelenítések hamar elavulttá válnak. A kis képméret okozta problémák kiküszöbölésével kapcsolatban ld. jelen jelmagyarázat 1.a és b pontját.
13. A bélyegképeket illetve az oldalak közötti navigációt tartalmazó szekció legyen hosszában tetszőleges méretű, hogy  korlát nélkül tudja tükrözni a kiadvány teljes fizikai szerkezetét. Ezt a görgetősáv engedélyezésével érhetjük el.
    1. Fontos, hogy ez a szakasz ne legyen fizikailag külön fájlban az oldalkeret többi részétől, tehát ne használjunk a FRAME elemet. A HTML-jellegű keret fő indoka éppen az, hogy minden információ és navigációs lehetőség fizikailag egy állományban tárolódjon. A FRAME kiküszöbölése a DIV HTML-elemekkel és a CSS2 szabványban meghatározott float, position, display és overflow tulajdonságok ötvözésével lehetséges.
14. Az oldalképet tartalmazó szekció kapjon saját görgetősávot, hogy a kép mozgatása egyszerűbb legyen kisebb monitoroknál is. A 13. a pont itt is követendő.
15. Bár grafikus alkalmazások és számos szolgáltatás a szürke hátteret ajánlja a képek megjelenítéséhez kellően semleges és ergonomikus háttérként, az ajánlott modellben mi a fekete mellett döntöttünk. Ezt azonban kifejezetten a szöveges információt tartalmazó képekhez ajánljuk, mivel a fekete háttér (hasonlóan pl. az e-book olvasó szoftverek által használt színhez) jobban megőrzi a könyvoldal illúzióját, és alkalmazkodik a nyomdai tükröt követő szemmozgáshoz. Világos háttér esetén a folyamatos olvasás nehezebb lehet. mivel a színkontraszt híján megerőltetőbb a tekintet oldalkeretre való koncentrálása. Képi információ esetén ellenben a hagyományos színválasztás ajánlott.

↑3.3.3.1 Képi megjelenítés tartalomjegyzékkel

3.3.2 ábra: Képi formátum megjelenítésére ajánlott szerkezet tartalomjegyzékkel

Hosszabb közleményeket tartalmazó, terjedelmesebb kiadványok esetén alkalmazandó megoldás. Ebben az esetben a navigáció nagy része az egy adott közleményen belüli oldalterjedelemben történik, a teljes számon belül pedig a tartalomjegyzék segítségével mozoghatunk.

A modell 1024x768-as képernyőfelbontás figyelembevételével készült.

Jelmagyarázat:

1. Maga az oldalt tartalmazó képfájl, a szolgáltatott teljes változat. A kép elem szöveges helyettesítőjének tartalma: "Kiadvány cím, számozás keltezés (lehet rövidített), oldalszám." Kivételes esetben, illetve ha még kisebb felbontásra optimalizáljuk a szerkezetet, megoldható, hogy a képre helyezett hivatkozás mögé egy még nagyobb változatot helyezünk el, mely önálló képként, HTML-jellegű keret nélkül nyílik meg. Itt két megoldás lehetséges:
   1. Nagy méretű, de 3000x2000 pixel felbontást meg nem haladó képfájl. Ez akkor ajánlott, ha igazán részletgazdag képre van szükség, melynek megjelenítéséhez hasznosnak bizonyulhat a legtöbb böngészőben elérhető automatikus zoom-funkció. (Ennek figyelembevételével nem ajánlunk itt újabb HTML-jellegű keretet a nagyobb képhez.)
   2. Ennél nagyobb, extrém méretű képeknél a hivatkozás mögött elhelyezhetünk FLASH-alapú képzoom animációt. Ez esetben azonban a képi változat keretében a formátumra vonatkozó figyelmeztetést kell elhelyeznünk.
2. Az adott közleményt alkotó oldalak sorszámai. A hivatkozás minden oldalszámnál a vonatkozó oldal keretfájljára mutat. A link title tulajdonságában a következő információkat tüntessük fel: "Kiadvány cím, számozás keltezés (lehet rövidített), oldalszám." Az aktuális oldal sorszámát emeljük ki, és ne helyezzünk rá hivatkozást.
3. Ikonok, melyeken a hivatkozás az előző, illetve következő oldal keretfájljára mutatnak. A kép szöveges helyettesítőjébe a navigáció irányát írjuk (pl. "előre", "vissza"). Itt azért nem tüntettük fel az oldalszámot, mert a 2. számú részlet mellett zavaró lehet. Természetesen a Grafikus ikonok helyett szövegesen is kiírhatjuk a lapozási irányt, ha elég a hely. Az ábrán egy, a 7-iktől a 35-ik oldalig tartó cikket ábrázolunk.
4. Az adott közlemény (amelyen belül navigálunk) szerzője és címe. A hivatkozás a cikk kezdőoldalát tartalmazó HTML-jellegű keretre mutat. A title tulajdonságba írjuk:"A cikk elejére".
5. Ebben a blokkban tudunk ténylegesen a részegységen (pl. szám) belül navigálni. Hivatkozás az egyes cikkek adatain (szerző, cím, oldalszám) található, mindig az adott cikk kezdőlapjának keretfájljára mutat. A hivatkozás title tulajdonságába írjuk: "A cikk megnyitása"
6. Amennyiben a kiadványt gyűjtemény részeként szolgáltatjuk, feltehető, hogy az rendelkezik valamiféle grafikus azonosítóval (pl. logo). Ennek elhelyezése azonnali tájékozató értékkel bírhat arra nézve, hogy kinek a kezelésében van a digitális kiadvány. A piktogramra (illetve grafikus elem híján a gyűjtemény ill. kiadó nevére) elhelyezett hivatkozás mutasson a szolgáltató gyűjtemény nyitóoldalára vagy a kiadó honlapjára, ennek híján a kiadvány nyitóoldalára. A kép szöveges helyettesítőjébe, vagy a title tulajdonságába írjuk be a következő információkat "szolgáltatás ill. kiadó neve – nyitólap".
7. A kiadvány címére tegyünk hivatkozást a teljes kiadvány nyitólapjára, title tulajdonságba írjuk be a következő információkat: "Kiadvány címe – nyitólap". Ezt az adatot megismételhetjük az oldal alján is, ha kényelmi szempontok indokolják.
8. A számozás és keltezés feltüntetett adatára tegyünk hivatkozást a szám képként böngészhető tartalmának kezdőoldalára. A title tulajdonságba írjuk be a következő információkat: "Kiadvány címe, számozás, keltezés (rövidítve) – nyitólap". Ezt az adatot megismételhetjük az oldal alján is, ha kényelmi szempontok indokolják.
9. A „Kiadvány leírása” elem megnevezése attól függ, hogy mit helyezünk el mögötte hivatkozásként: lehet az szabványos bibliográfiai leírás, önállóan, vagy adatbázis részeként, különböző leíró adatokat (pl. bibliográfiai leírás és szöveges ismertető) ötvöző oldal. A title tulajdonságot töltsük ki ennek megfelelően. Ezt az adatot megismételhetjük az oldal alján is, ha kényelmi szempontok indokolják.
10. A szerzői jogi tudnivalókat akkor tüntessük fel, ha a „Kiadvány leírása” elem nem tartalmazza azokat. A hivatkozás a digitális kiadvány használatát érintő jogi tudnivalókat tartalmazó fájlra mutasson.
11. Az ábrán a piros vonal jelzi, hogy normál méretű megjelenítés körülbelül hol található a képernyő alja. Ez láthatólag azzal járhat, hogy a kép teljes egészében nem fér el a kimeneten. Bizonyos kiadványok esetében természetesen ennél kisebb képméret is elegendő a tartalom részleteinek megőrzés érdekében. Figyelembe kell venni azt is azonban, hogy a személyi számítógépek átlagos képernyőmérete egyre növekvő tendenciát mutat, így lehetséges, hogy a kisebb felbontásra optimalizált megjelenítések hamar elavulttá válnak. A kis képméret okozta problémák kiküszöbölésével kapcsolatban ld. jelen jelmagyarázat 1.a és b pontját.
12. A cikkek közötti navigációt tartalmazó szekció legyen hosszában tetszőleges méretű. Ezt a görgetősáv engedélyezésével érhetjük el. Szélességét az oldalkép (1 pont) méretigényének függvényében a lehető legnagyobbra állítsuk be, hogy a szövegméret skálázható maradjon.
    1. Fontos, hogy ez a szakasz ne legyen fizikailag külön fájlban az oldalkeret többi részétől, tehát ne használjunk a FRAME elemet. A HTML-jellegű keret fő indoka éppen az, hogy minden információ és navigációs lehetőség fizikailag egy állományban tárolódjon. A FRAME kiküszöbölése a DIV HTML-elemekkel és a CSS2 szabványban meghatározott float, position, display és overflow tulajdonságok ötvözésével lehetséges.
13. Az oldalképet tartalmazó szekció kapjon saját görgetősávot, hogy a kép mozgatása egyszerűbb legyen kisebb monitoroknál is. A 12. a pont itt is követendő.
14. Bár grafikus alkalmazások és számos szolgáltatás a szürke hátteret ajánlja a képek megjelenítéséhez kellően semleges és ergonomikus háttérként, az ajánlott modellben mi a fekete mellett döntöttünk. Ezt azonban kifejezetten a szöveges információt tartalmazó képekhez ajánljuk, mivel a fekete háttér (hasonlóan pl. az e-book olvasó szoftverek által használt színhez) jobban megőrzi a könyvoldal illúzióját, és alkalmazkodik a nyomdai tükröt követő szemmozgáshoz. Világos háttér esetén a folyamatos olvasás nehezebb lehet. mivel a színkontraszt híján a megerőltetőbb a tekintet oldalkeretre való koncentrálása. Képi információ esetén ellenben a hagyományos színválasztás ajánlott.

Természetesen a fenti modellek rugalmasan alkalmazhatók, annak fényében, hogy milyen tartalommal van dolgunk, illetve mennyi tervezési munkát tudunk a képi változat készítésébe fektetni. A megadott navigációs és azonosítási pontok megtartása azonban indokolt, ha mindenképpen megbízható szolgáltatást akarunk építeni.

↑4. Megőrzés

A kulturális szempontból értékes tartalmat közlő honlapok esetében – ilyeneknek tekinthetők a digitális időszaki kiadványok – az emberi közösség fokozott érdeke azok tartalmának rövid és hosszú távú megőrzése.

↑4.1 Hosszú távú megőrzés

Hosszú távú megőrzésen azt a tevékenységet értjük, amely lehetővé teszi az egymás után következő generációk számára a tudás átadását. A megőrzés jelentheti az eredeti dokumentum konzerválását ideális tárolási és biztonsági körülmények biztosításával, illetve jelentheti a tartalom és forma más hordozón történő reprodukálását. A 20. század utolsó évtizedeiig a könyvtári szakma főleg a mikroforma (mikrofilm, mikrofiche) segítségével készített állományvédelmi célú másolatot. Ezek jól bevált és időtálló megoldások voltak, ugyanakkor költségesek, és helyhez kötötték az olvasót, mivel mikrofilmolvasók nem széles körben elterjedt eszközök.

A múlt század végén nyilvánvalóvá vált, hogy a kulturális örökség – különösen a könyvtári anyag – reprodukálása sokkal egyszerűbb, gyorsabb és költségkímélőbb digitális eszközökkel. Nagy előnye továbbá ennek a megoldásnak, hogy ezek a másolatok szinte bárhol használhatók számítógépen. A megoldás egyszerűsége azonban magában rejti saját csapdáit is. Viszonylag könnyű ugyanis elkészíteni egy kiadvány digitális másolatát, de nagyon nehéz garantálni annak hosszú távú használhatóságát, azaz a tartalom digitális megőrzését. A számítástechnika fejlődése annyira gyors és nehezen prognosztizálható folyamat, hogy sosem tudhatjuk, hogy az általunk választott hardveres és szoftveres megoldás még egy évtized múlva is használható lesz-e. Nem egy példát sorolhatnánk arra, mikor nagy erőfeszítéssel előállított digitális gyűjtemények vesztek kárba, mivel a használt formátum már nem nyitható meg a használatban lévő számítógépek és szoftverkörnyezetek segítségével.

A szakma reakciója alapján született meg a digitális megőrzés fogalma, mely az így előállt problémákból keresi a kiutat, melynek fő stratégiai tényezői az előre tervezés és a szabványosítás.

Ami mindenképp látható előre – mivel már most is létező probléma – az az, hogy különböző rendszerkörnyezetek (platformok) léteznek egymás mellett. Ez valószínűleg a jövőben is így lesz, de már jelenleg is vannak olyan technikai eszközök, melyek készítői a fejlesztésnél már tekintettel voltak arra, hogy eszközeik és az azokkal előállított kimenet minél több környezetben használható legyen.

↑04.1 Ajánlás: Törekedjünk a platformfüggetlen megoldásokra. Szolgáltatásaink kialakításánál, és a formátumok megválasztásánál vegyük tekintetbe a megőrzés szempontjait, tegyünk lépéseket a tekintetben, hogy az általunk közölt tartalmak elérhetők maradjanak a következő generációk számára is.

Linkajánló:
A kulturális honlap minőségi követelményei
https://mek.oszk.hu/minerva/html/dok/kulthonlapminkov.htm
Kézikönyv a minőségi elvekről
https://mek.oszk.hu/minerva/html/dok/minoseg-10elv.htm
https://mek.oszk.hu/minerva/html/dok/minoseg-10elv.htm#60

↑4.2 A Digitális megőrzés kérdései

A digitális megőrzés kérdéskörének három dimenziója van. Az egyik a hordozó, a másik a nyilvántartás, a harmadik a formátum. Ezekből mi ajánlás szintjén csak a formátumokat érintjük, de röviden kitérünk a többi problémára is.

↑4.2.1 Hordozók és nyilvántartás

A hordozók tekintetében számolhatunk optikai tárolókkal, merevlemezekkel, szalagos egységekkel és egyéb elterjedt archiválási eszközökkel. Míg minden megoldás esetében rendelkezünk hozzávetőleges becslésekkel az adott hordozó várható élettartalmát és megbízhatóságát illetően, addig ezeket nem tudjuk tapasztalatokkal igazolni, lévén viszonylag kevés idő telt el e technológiák megjelenése óta. A hordozók másik problémája, hogy egyre nagyobb mennyiségű anyag tárolására kell készen állniuk. Az általában elterjedt fájlformátumok mérete tendenciózusan nő, párhuzamosan az előállított digitális anyag mennyiségével.

Ez az ajánlás nem tér ki a hordozók kérdésére, mivel hardverspecifikációkkal nem fogalakozunk, s emellett a választott megoldás a digitalizálók esetében financiális tényezők függvénye.

Ugyanez áll a tárolás virtuális struktúrájára és a nyilvántartásra. A közintézmények nagy része ma már alkalmaz valamiféle tartalomkezelő rendszereket, melyek segítségével nyomon tudja követni digitális állományának állapotát, státuszát, a változatok egymáshoz való viszonyát és a szolgáltatás állapotát.

Az ideális megoldást erre a célra az OAIS (Open Archival Information System Model) Referenciamodell szolgáltatja, mely az összes, digitális archiválással kapcsolatos folyamat figyelembevételével épült ki, már a hosszú távú megőrzés kérdéseit és szolgáltatást is szem előtt tartva. Ilyen alkalmazások beszerzésénél illetve fejlesztésénél mindenképpen ehhez a mintához érdemes alkalmazkodni.

Ezekre a rendszerekre is igaz az, ami például a dinamikus tartalomszolgáltató megoldásra: fenntartásuk speciális környezetet és kompetenciát igényel.

Bár az ilyen eszközök elősegítik a digitális megőrzés céljait azzal, hogy kezelik a tárolandó tartalommal kapcsolatos információt és lehetővé teszik a szervezett tárolást, magának a digitális gyűjteménynek a kezelő rendszertől függetlenül is fenn kell maradnia.

↑4.2.2 Formátum

A formátum kérdése érinti legérzékenyebben a digitalizálási folyamatot. Az azt meghatározó döntések sorában két nagyon alapvető kérdést kell még a munka elején megválaszolni:

• milyen formátumban szeretnénk megőrizni a digitalizált anyagot?
• milyen formátumban szeretnénk használni a digitalizált anyagot?

Az első kérdésben döntünk a megőrzési formátumról, a másodikban a szolgáltatási formátumról. Ebben a fejezetben a megőrzési formátumról van szó, a digitális nyersanyag előállításának különböző típusaira nézve.

↑04.2 Ajánlás: Közvetlenül a digitalizálás eredményeként készült formátum tartalmazza a lehető legnagyobb részletességgel az eredeti tartalom összes jellemzőjét a beviteli módnak megfelelően. Ez a megőrzési formátum, ami mindig szabványos és platformfüggetlen szoftveres megoldásra kell épüljön.

A beviteli módnak megfelelő részletesség alatt azt értjük, hogy szkennelt, illetve fotózott anyag estében igyekezzünk a képi eredeti lehető legpontosabb reprodukcióját elkészíteni. Azaz a képet nagy felbontásban, tömörítésmentes formátumban, automatikus képkorrekció nélkül mentük el az első fázisban. Szöveges reprodukciónál (pl. ha begépeljük az adott szöveget) mindig határozzunk meg a munka kezdetén részletes szövegkritikai elveket (pl. betűhibák, hiányok kezelése, stb.), és azokhoz mindenképp ragaszkodjunk. Mindenképp végezzünk korrektúrát. Ezt a változatot őrizzük meg módosítások nélkül, biztosított tárolóeszközökön. Készítsünk másolatot, amelyet a további feldolgozás során módosíthatunk.

Megjegyzés: A megőrzési formátumnak az eredeti dokumentum elérhetetlenné válása esetén is vissza kell adni annak lehető legtöbb formai és tartalmi jegyét. Ez a megőrzés lényege. Továbbá lehet, hogy évek múltán a jelenlegieknél sokkal hatékonyabb módon állíthatjuk elő a használati verziókat (a OCR szoftverek, szövegbányászati eszközök fejlődésével). Ezekhez a lehető legrészletesebb és időtállóbb digitális eredetire van szükség.

A szakmai szóhasználat a megőrzési formátumot gyakran nevezi bementi formátumnak, illetve „master”-nek.

A megőrzési formátum mindig kövesse a szakmai konvenciókat, melyek például meghatározzák, hogy milyen fájlformátumok jöhetnek szóba ebben az esetben.

A hagyományos hordozó jellege, formátuma és állaga alapján kell kiválasztanunk az ideális beviteli módot. Mikrofilmről például mikrofilm- (negatív-) szkennerrel dolgozzunk, modern anyagot elkészíthetünk lapszkenneren, sérülékeny, illetve rossz állapotú, régi anyagot pedig fotózhatunk. Itt főként állományvédelmi szempontok jöhetnek szóba, ezek meghatározásával itt nem foglalkozunk.

↑4.2.2.1 Szkennelt képek

A szkennelés módját befolyásolhatja az anyag mérete, minősége és kora. Számos tényező lehet ezek szerint, amelyekhez képest be kell konfigurálnunk az általunk használt berendezéseket. Fontos azonban, hogy beállításaink eredményeképp az eredetivel a lehető legjobban egyező digitális másolat jöjjön létre. Minden korrekciót csak a mentési változat másolatain végezzünk el.

↑04.3 Ajánlás: Állókép jellegű szkennelt beviteli formátum esetén a megőrzési változatot mentsük tömörítésmentes TIFF (Tagged Image File Format) 6.0 fájlként. Az eredeti alapegységei (oldal, tábla, kép) külön-külön fájlba kerüljenek.

A TIFF 6.0 címkézhető, bitmap alapú, tömöríthető képformátum. Specifikációja 1992 óta elfogadott, a legtöbb digitalizáló berendezés ismeri. Egyes eszközök esetében a formátum "Aldus TIFF" néven érhető el. Bár lehetséges, nem ajánlott egy dokumentum több képét egy TIFF-fájlba menteni, mert a legtöbb képfeldolgozó szoftver nem tudja kötegesen kezelni a többoldalas képfájlokat.

A képformátumok specifikációit a készülő képfeldolgozással kapcsolatos ajánlás tárgyalja majd. [Digitális Könyvtári Füzetek 2.]

Linkajánló

TIFF 6.0 Revízió

http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

http://www.digitalpreservation.gov/formats/fdd/fdd000022.shtml

↑4.2.2.2 Fotó

A fotózásra is igaz, hogy a felvételek készítésénél ne alkalmazzunk semmiféle korrekciós mechanizmust, igyekezzünk az eredeti tulajdonságokat visszaadni. Dolgozzunk a fényképezőgép saját nyers (RAW) formátumával, ne felhasználói jellegű (pl. JPG) fájlokban mentsük kis a végeredményt. A használt eszköz natív formátumát ezek után konvertáljuk a nyersképek egységes tárolására készített DNG-formátumban.

↑04.4 Ajánlás: Fotó útján készült állókép jellegű beviteli formátum esetén a fényképezőgép belső archiválási formátumát mentsük el DNG (digitális negatív) állományként. Az eredeti alapegységei (oldal, tábla, kép) külön-külön fájlba kerüljenek.

A DNG (Digitális Negatív) az Adobe Systems fejlesztésében jött létre a RAW kameraformátumok adatcseréjének megkönnyítésére. A jelentősebb fényképezőgép-gyártók formátumai már képesek együttműködni ezzel a formátummal. 

A képformátumok specifikációit a készülő képfeldolgozással kapcsolatos ajánlás tárgyalja majd. [Digitális Könyvtári Füzetek 2.]

Linkajánló

DNG Specifikáció
http://www.adobe.com/products/dng/pdfs/dng_spec.pdf

↑4.2.2.3 Karakteresen bevitt szöveg

Ha tisztán szöveges formátumú beviteli anyagról van szó, úgy a megőrzési állomány formára nézve szöveg. Az eredeti tartalom strukturális jellemzőit (Címek, kiemelt szövegrészek, szakaszok stb.) szintén rögzítenünk kell. Ha szövegszerkesztőt használunk, fennáll a veszélye, hogy az így létrehozott adatállomány évek elteltével nem lesz teljes mértékben használható, mert a létrehozó szoftver elavul, újabb változatai pedig esetleg nem kezelik ugyanúgy a tartalmat.

Ezért fontos, hogy a szöveges tartalmat mindig egységesen kódolt karakteres állomány és strukturális jelölőelemek kombinációjából állítsuk össze.

Például:

<főcím>Cím</főcím>

<alcím>Alcím</alcím>

<bekezdés>Cikk szövege… </bekezdés>

az ilyen jellegű tárolásra a legmegfelelőbb az XML (Extensible Markup Language), mert

• a dokumentumtípus-definícióban (DTD) mi határozhatjuk meg a szükséges strukturális elemeket
• biztonsággal kezeli a karakter-kódolási szabványokat
• platform- és szoftverfüggetlen
• egyszerűen átalakítható
• könnyen készíthető belőle HTML-kimenet
• adatfeltárásra is használható (Ha például adott folyóirat cikkeinek címadatait szeretnénk kinyerni).

↑04.5 Ajánlás: Szöveges jellegű beviteli formátum esetén a megőrzési változatot mentsük UTF-8 kódolású, DTD (Document Type Definition) által meghatározott XML-formátumban.

Linkajánló

XML 10 pontban
http://www.w3c.hu/forditasok/XML_10_pontban.html
XML A Wikipédiából, a szabad lexikonból
http://hu.wikipedia.org/wiki/XML
DTD-k és metaadatkezelés a MEK-ben
https://mek.oszk.hu/html/irattar/dtd.htm
XML DTD folyóirat-rovathoz és folyóiratcikkhez
https://mek.oszk.hu/mekdtd/article/TEI-MEK-article.dtd
Text Encoding Initiative
http://www.tei-c.org/P4X/

Digitális időszaki kiadványok nem csupán digitalizálás útján keletkezhetnek, hanem előfordulhat, hogy eleve erre a formátumra tervezett dokumentumokról van szó. Ezek a kiadványok többnyire szöveg- illetve kiadványszerkesztő szoftverek segítségével készülnek (melyekkel kapcsolatban fennállnak a már említett problémák).

↑4.2.2.4 Digitálisan született anyag

Egyre több időszaki kiadvány keletkezik csak számítógépes eszközök (szövegszerkesztők, kiadványszerkesztők) igénybevételével, kifejezetten digitális felhasználásra. Ezek az úgynevezett digitálisan született anyagok. Az eredendően elektronikus formátum azonban önmagában nem jelenti a hosszú távú használhatóság zálogát, ugyanis ezek a szoftver- illetve formátumtípusok nagymértékben ki vannak téve a változás és avulás veszélyének a folyamatosan változó felhasználói igények és a gyártók közötti piaci verseny miatt. Az ilyen állományok esetében tehát különösen fontos egy olyan megőrzési formátum, mely a legtöbb funkció fenntartása mellett képes garantálni a hosszú távú használhatóságot.

↑04.6 Ajánlás: Digitálisan született kiadványainkat a megőrzés céljaira mentsük el PDF-A formátumban.

A PDF-A szintén az Adobe Systems fejlesztése. A specifikáció elkészült 1-a fejezete ma már a ISO-19005-1 számon jegyzett nemzetközi szabvány. A PDF-A lényege, hogy a fájlt alkotó tartalmi, formai és metainformáció teljes mértékben eltárolódik magában az állományban, és az rendszerkörnyezetektől függetlenül ugyanazt a tartalmat fogja eredményezni használatkor. A fájlformátum technikai támogatottsága 2006-tól fogva létezik, várható a legtöbb PDF készítésére is képes szoftver újabb változataiba már beépül a lehetőség a PDF-A kimenet készítésére is.

Linkajánló

PDF-A Competence Center
http://www.pdfa.org/

PDF-A-képes szoftverek
http://www.pdfa.org/doku.php?id=pdfa:en:products

↑4.2.3 Dinamikus kimenetben készült kiadvány-archívumok

Amennyiben úgy döntünk, adatbázis-alapú rendszerekben is publikálhatunk  elektronikus időszaki kiadványokat. Minden programozott alapú alkalmazásnál fontos azonban szem előtt taratani a fenntarthatóság tényezőjét: az így létrehozott szolgáltatásaink csak addig fognak élni, amíg a létrehozáskor fennálló rendszerkörnyezet elérhető, illetve tudjuk követni annak változásait. Célszerű tehát az így szolgáltatott tartalmat ettől a környezettől független változatban is megőrizni. Mindenképp legyen tehát a tartalmunknak egy adatbázistól független, ugyanakkor tartalmilag tagolt verziója, archiválási célokra. 

↑04.7 Ajánlás: A kiadványunknak legyen legalább egy, rendszerkörnyezettől függetlenül használható, statikus könyvtárrendszerben elhelyezett változata. A statikus könyvtárstruktúra tükrözze a kiadvány tartalmi felépítését.

↑4.2.4 Metaadatok hosszú távú megőrzése

Mint említettük, az archiválandó digitális állományok kezelésére rendelkezésre állnak az összes funkciót lefedő rendszerek, melyek, ugyanúgy mint a kiadvány szolgáltatására használt HTML- illetve dinamikus keret, tárolják és közlik a metaadatokat. Nem elégséges azonban, ha a leíró adatok például csak a szolgáltatási változatban, illetve az azt kezelő rendszerben érhetők el. A digitális megőrzés maximális biztonsága érdekében a leíró adatokat célszerű magukban az archivális (master) állományokban is elhelyezni. A 4.2.2 pontban ajánlott megőrzési formátumokban az mind lehetséges.

Az Adobe Systems fejlesztésében készült az Extensible Metadata Platform (XMP) szabvány, mellyel az általunk választott adatséma szerint készült leíró adatokat közvetlenül az állományok fejlécében helyezhetjük el, szoftveresen kinyerhető, további adatcserére is alkalmas formában, az XMP tehát egyszerre beépülő adatmodul és lehetséges adatcsere-formátum. Segítségével elvégezhető az alábbi formátumok címkézése: JPEG, JPEG 2000, GIF, PNG, HTML, TIFF, AI (Adobe Illustrator), PSD, PostScript, Encapsulated PostScript (EPS). Alapértelmezésben támogatja a Dublin Core szabvány egyszerű adatmezőit, de más adatsémák bevitelére is használható.

Linkajánló

Extensible Metadata Platform
http://www.adobe.com/products/xmp/overview.html

↑4.2.5 Megőrzés az EPA segítségével

Az Elektronikus Periodika Archívum és Adatbázis (EPA) szolgáltatás az Országos Széchényi Könyvtárban indult 2004-ben. A szolgáltatás célja, hogy könyvtári kezelésbe vonja a digitális formában online és offline nyilvánosan elérhető, magyar és magyar vonatkozású időszaki kiadványokat és integrálódó kiadványokat. Az EPA egyrészt nyilvántartásba veszi őket, másrészt a saját szerverén válogatva archiválja, és online szolgáltatja is. Az EPA nyilvános szolgáltatása bárki számára szabadon hozzáférhető, és a gyűjtőköri elvek mentén bárki hozzájárulhat annak gyarapításához.

Az archívum bővítése a jogtulajdonos (általában kiadó) írásos engedélyéhez kötött. Az EPA legújabb szolgáltatása a muzeális jellegű és értékű időszaki kiadványok digitalizált változatainak figyelése a Sajtómúzeum nevű szolgáltatás keretében. A Sajtómúzeum a magyar sajtó történetének kezdeteitől a XX. század első feléig bezárólag képezi az EPA archívum metszetét, gyűjti a hazai sajtótörténeti digitalizálási munkák adatait, és gyűjti (részben archiválja, szolgáltatja) a muzeális kiadványokra vonatkozó szakirodalmat.

Az EPA archívum gyűjtőkörébe tartoznak a: nyilvánosan és ingyenesen online szolgáltatható, magyar nyelvű vagy magyar kiadású, heti vagy annál hosszabb periodicitású (a határon túli kiadványok esetében a napilapok is), oktatási, tudományos vagy kulturális szempontból hasznos időszaki kiadványok. A gyűjtőkörbe tartozó kiadványok kiadóinak ill. jogtulajdonosainak hozzájárulása mellett az EPA vállalja, hogy a meglévő elektronikus változatból public domain változatot készít, azt szolgáltatja és megőrzi.

A folyóiratok esetében az EPA XML-ben rögzíti a tartalomjegyzékeket. Ennek eredményeként tartalomjegyzék adatbázist épít és a tartalomjegyzékek adatait automatikusan betölti a MATARKA (Magyar Folyóiratok Tartalomjegyzékeinek Kereshető Adatbázisa – Miskolci Egyetem Könyvtár, Levéltár, Múzeum) szolgáltatás adatbázisába. A tartalomjegyzék XML online szabadon elérhető.

Az EPA szolgáltatás működését és fejlesztését, ill. a hosszú távú megőrzés infrastrukturális hátterét az Országos Széchényi Könyvtár biztosítja.

Az EPA, az archív állományba bekerülő kiadványokat folyamatosan szolgáltatja, tehát adott esetben párhuzamos szolgáltatásként segíti a kiadvány tartalmának folyamatos elérhetőségét. Az EPA maga is rendelkezik tükörszerverrel, hogy saját szolgáltatásának folyamatosságát biztosítsa. Emellett a teljes állományról rendszeres biztonsági mentés készül. Jelenleg minden EPÁ-ban archivált kiadvány teljes anyaga három különböző gépen tárolódik ezek közül kettő földrajzilag is különböző helyen található.

A gyűjtőkörébe tartozó kiadványok számára az EPA nemcsak mint digitális raktár ill. párhuzamos szolgáltatás, hanem mint ingyenes tárhelyszolgáltatás és publikációs rendszer is elérhető. A kiadvány tartalmához tartozó fájlok tekintetében korlátlan tárhely áll rendelkezésre. Az EPA biztosítja a stabil elérhetőséget, hivatkozhatóságot, interoperabilitást és teljes szövegű kereshetőséget. A kiadvány oldaláról mindössze arra van szükség, hogy a megjelentetni kívánt tartalmat, előre egyeztetett formátumban és módon eljuttassa az EPA munkatársaihoz.

A public domain közegben nem szolgáltatható elektronikus állományok elhelyezhetők továbbá az Országos Széchényi Könyvtár digitális objektumkezelő rendszerében, az OSZK Digitális Könyvtárban (OSzKDK), melybe archiválás illetve zártláncú szolgáltatás céljából bárki beszolgáltathatja a kezelésében álló anyagokat. Az OSzK DK periodikumokat kezelő modulja még fejlesztés alatt áll, de archiválandó tételeket már tud fogadni.

↑04.8 Ajánlás: A nyomtatott kiadványok esetében ismert kötelespéldány rendszer mintájára, juttassuk el elektronikus folyóiratunkat az Országos Széchényi Könyvtárba. Ezt jelenleg az EPA rendszeren és az OSzK Digitális Könyvtáron keresztül tehetjük meg.

Linkajánló:
Elektronikus Periodika Archívum és Adatbázis
https://epa.oszk.hu
https://efolyoirat.oszk.hu
Információk az EPA-ról
https://epa.oszk.hu/html/irattar/epa_str.htm
EPA együttműködési megállapodás
https://epa.oszk.hu/html/irattar/egyuttmukodesi.pdf
Sajtómúzeum
https://sajtomuzeum.oszk.hu
Országos Széchényi Könyvtár Digitális Könyvtár (OSzKDK)
http://www.oszkdk.hu
Magyar Folyóiratok Tartalomjegyzékeinek Kereshető Adatbázisa
http://matarka.hu