Sisteme Informatice Pentru Managementul Continutului PDF

Sisteme informatice pentru managementul conţinutului 1
CAPITOLUL I
INTRODUCERE ÎN MANAGEMENTUL CONŢINUTULUI
În secolul XX, cel mai mare eveniment tehnologic şi social în acelaşi timp a fost
apariţia Internetului. Web-ul a devenit un mediu de publicare a informaţiei. Site-urile
web sunt folosite pentru a promova companiile şi produsele sale, pentru a presta
servicii şi informaţii, pentru a facilita comunicarea. Pentru site-uri medii şi mari, se
pune problema managementului conţinutului lor. De aceea, s-au implementat sisteme
de management al conţinutului.
Publicarea electronică a accelerat exponenţial crearea conţinutului. Astfel, la
sfârşitul anilor ’80 apăruse fenomenul de “supraîncărcare informaţională”, situaţie
agravată de apariţia calculatoarelor personale, care nu permiteau un control
centralizat.
La începutul anilor ’90, calculatoarele personale au început să fie unite în reţea,
lucru care a favorizat apariţia aplicaţiilor centralizate construite în baza principiilor
client-server. Aceasta a dat posibilitatea restabilirii controlului asupra conţinutului
electronic, dînd naştere epocii managementului documentelor.
Situaţia a început să se schimbe pe la mijlocul anilor ’90 odată cu creşterea
popularităţii Internetului. Către anul ’89, Internetul conţinea deja milioane de pagini
web, şi a devenit o afacere serioasă. Managementul documentelor a ieşit din modă,
oferind locul managementului de conţinut web (web content).
Dar euforia din domeniul Tehnologiei Informaţiei (TI) a trecut odată cu
prăbuşirea NASDAQ şi dot.com-urilor în 2000. S-a revenit la soluţii mixte ce conţineau
documente obişnuite (pe hârtie) şi electronice (conţinut web), cu accent pe dispozitive
fără fir (wireless), fluxuri audio/video (streaming) şi alte forme de conţinut electronic.
Ritmul implementării de soluţii de comerţ electronic B2C (afacere către consumator)
(B2C – business to customer) a scăzut, în schimb a crescut interesul faţă de
comunicarea automatizată a conţinutului electronic în afaceri prin intermediul
reţelelor comerciale XML B2B (XML - eXtensible Markup Language, B2B -Business to
Business).
La început, sistemele de management al conţinutului (CMS) erau baze de date
gigantice care puteau căuta rapid şi puteau salva fişiere bazate pe text. FileNet şi
Documentum, o parte a RCM Corp, au fost primele care au realizat un sistem de
căutare şi scanare text şi de documente microfilm.
Odată cu apariţia web-ului, realizatorii acestor sisteme au decis să realizeze şi
produse care puteau să arhiveze şi să caute şi alte feluri de fişiere, în special coduri
executabile şi grafice. Pe această piaţă au intrat, însă, şi Vignette şi Interwoven.
Evenimentele care au marcat dezvoltarea CMS sunt următoarele:
 1970 – CM pe mainframe-uri: publicare electronică
 1977 – apariţia calculatoarelor personale şi a interfeţelor text
 1982 – apariţia interfeţelor grafice
 1984 – CM pe calculatoare personale: publicare desktop
 1985 – FileNet introduce Visual Workflo
 1986 – Quark Xpress
 1990 – utilizarea tehnologiei Client-Server
 1992 – Lotus Nutes
 1993 – Mosaic Graphical Browser
 1995 – Vermeer Technulogies Front Page
 1995 – Apache Web Server
 1995 – CM pe web : publicare web
 1995 – CNET PRISM (un sistem de management al conţinutului autorizat
şi sistem de generare a paginii)
 1996 - Iulie – Vignette dobândeşte CNET PRISM
 1996 - Septembrie – Soft Quad anunţă apariţia Intranetului Hot Meta
L(IBM RS/6000)
 1996 - Octombrie – Documentum anunţă apariţia Right Site – Web
Content Management
 1996 - Noiembrie – Texture Web Publishing System (necesită utilizarea
unui browser compatibil cu Java)
 1996 - Decembrie – Apariţia sistemului de publicare electronică Inso
(dobândirea de Dyna Base, Dyna Text, DynaWeb)
 1997 – Apare Macromedia Dreamweaver, Adobe Go Live
 1998 – Future Tense Content Server
 1998 – Apare TYPO3, un CMS open – source
 2000 – Microsoft şi IBM introduc UDDI.
 2001 - Decembrie - Documentum achiziţionează Bulldog (DAM)
 2001 – Broadvision cumpără Interleaf Bladerunner
 2001 – Open Market cumpără Future Tense Content Server
 2002 – Documentum achiziţionează Boxcar (syndication)
 2002 - Aprilie – File Net achiziţionează sistemul eGrail WCM
 2002 – Stellent achiziţionează Ancept (DAM) şi Kinecta (syndication)
 2002 - Octombrie – Apare Tiki Wiki - un CMS open source
 2002 - Octombrie – Documentum achiziţionează eRoom (colaborare)
 2002 - Decembrie – Vignette achiziţionează Epicentric (portal)
 2002 – Divine achiziţionează Open Market şi Content Server.
 2003 – Red Hat achiziţionează Ars Digita ACS
 2003 - Iunie – Interwoven achiziţionează Media Bin(RM)
 2003 - August – Open Text achiziţionează Gauss (WCM)
 2003 - August – Interwoven achiziţionează iManage (DM)
 2003 - Septembrie – Vignette achizi Intraspect (colaborare, KM)
 2003 – Fat Wire achiziţionează Content Server cel mai căutat
 2004 - Februarie – Vignette achiziţionează Tower (DM)
 2004 - August – Interwoven achiziţionează Software Intelligence (RM)
 2004 - August – Open Text achiziţionează Artesia (DAM)
 2005 – Hummingbird achiziţionează Red Dot (WCM)
Sistemele de management al conţinutului au evoluat într-o piaţă mare şi

schimbătoare cu produse clasificate după preţ şi capacităţi. În acelaşi timp, CMS a
evoluat într-un sistem matur, standard.
La început, sistemele de management al conţinutului au fost o activitate in-
house ce a ajutat editarea pe site-uri web şi sistemele de management. Organizaţiile
care erau implicate în activităţi de editare, cum ar fi revistele online, ziarele etc. au
realizat primele versiuni de sisteme de management al conţinutului pentru a lucra mai
uşor.
Vignette, o filială a CNET Networks, o companie de internet bazată pe media
întemeiată în San Francisco, este considerată a fi prima firmă care a promovat
sistemele de management al conţinutului. Înfiinţată în 1993 de Haslez Minur şi Shelby
Bonnie, companie publică ale cărei acţiuni sunt tranzacţionate la NASDAQ, deţinea un
WDM şi un sistem de editare. În aceea perioadă, Vignette căuta sponsorizare pentru
tehnologia de editare pe web pe care o crease şi astfel a apărut CNET. CNET a investit
o sumă considerabilă în Vignette şi aceasta a primit licenţă pentru produs şi putea,
astfel, să vândă sistemul de management al conţinutului. Acest lucru s-a întâmplat în
anul 1995 şi majoritatea au considerat că acela a fost momentul care a marcat
începutul sistemelor de management al conţinutului.
Deşi sistemele de management al conţinutului funcţionează, fără îndoială, cu
ajutorul biţi-lor şi bytes-lor de pe calculatoare, trebuie menţionat faptul că apariţia
conţinutului datează încă de la apariţia editării şi a comunicării pe pământ. Aşa că, în
această privinţă, managementul conţinutului este la fel de vechi ca şi civilizaţia
noastră.
Vignette, care avea o reputaţie din ce în ce mai bună ca şi dezvoltator de
unelte pentru gestiunea conţinutului site-urilor web, obţine, oficial, un Web Content
Management autentic şi un sistem de generare a paginii numit Presentation of Real-
Time Interactive Material (PRISM) de la CNET, în iulie 1996. Vignette integrează noul
sistem în propriul produs software de management al conţinutului şi realizează PRISM
ca şi produs propriu.
Compania FileNet a IBM-ului a fost şi ea una din primele companii care au
realizat în anii 1980 sisteme care gestionau documentaţie şi, mai apoi, imagini şi
workflow. Documentum este şi ea o altă companie care lucra în acest domeniu şi a
fost achiziţionată de EMC în anul 2003.
Vignette, dar şi alte companii au realizat sisteme care să poată gestiona şi să
caute atît texte, cît şi alte tipuri de fişiere, cum ar fi cele multimedia.
Următorul pas în acest proces a fost includerea comunicaţiilor şi a fluxului de
documente care permiteau colaborarea. Open Text a achiziţionat o organizaţie
intitulată Odesta şi, odată cu ea, LiveLink, o tehnologie pentru managementul
colaborativ. Prin această achiziţie, munca în colaborare a devenit o componentă a
sistemelor de management al conţinutului. În această perioadă îşi face apariţia şi Lotus
Notes, sporind comunicarea programată şi colaborarea din managementul
conţinutului.
Astăzi sistemele de management al conţinutului au devenit un mix complet de
caracteristici care sunt orientate pentru a crea şi menţine conţinutul de bază al web-
ului efectiv şi colaborativ. Aceste sisteme suportă fişiere de diferite formate şi pot
gestiona orice tip de conţinut, cum ar fi text, imagini, grafice, video, sunete,
documente şi înregistrări.
La data de 22 ianuarie 2006 existau 587 de companii producătoare de CMS. Cererea
pentru software de sistem de management al conţinutului (CMS) este în continuă
creştere. IDC previzionează că, până în 2009, vânzările globale de astfel de produse
software vor depăşi 6 miliarde USD
Pagini Web şi componente de conţinut
Cei mai mulţi experţi cad de acord asupra noţiunii de conţinut: conţinutul este
reprezentat de „obiecte” din site-urile Web, care pot fi clasificate în două categorii:
 Informaţii – text şi imagini care se pot vedea pe un site web în momentul
vizitării acestuia;
 Aplicaţiile şi software-ul care rulează pe serverele site-ului Web şi afişează
informaţia către vizitatori.
Unii experţi în domeniu cred că domeniul unui CMS constă doar din informaţiile
gestionate şi utilizate, în timp ce alţi experţi menţionează că acesta constă atât din
informaţii, cât şi în aplicaţii. La prima vedere, definiţia atotcuprinzătoare pare să fie cea
corectă, dar se pune întrebarea: este necesară gestiunea aplicaţiilor în acelaşi fel ca şi a
conţinutului? Cei mai mulţi oameni ar răspunde negativ, invocând faptul că
producătorii de software ar trebui să dezvolte două sisteme diferite – unul care să
gestioneze informaţiile (adică sistemul de gestiune a conţinutului – CMS), iar altul care
să gestioneze aplicaţiile (informaţiile sunt cele afişate în timp ce aplicaţiile determină
modalitatea de afişare a acestora).
Cea mai mare diferenţă între cele două abordări pare să fie faptul că fluxul de
lucru al informaţiei şi al aplicaţiilor variază în mod considerabil şi sunt diferite.
Diferitele abordări, scopuri, utilizatori şi fluxuri de lucru presupun deci, construirea a
două sisteme diferite. Forţarea existenţei informaţiilor şi a aplicaţiilor în acelaşi model
vor cauza complexităţi care nu sunt de dorit nici pentru programatori, nici pentru
utilizatorii sistemului.
Dezvoltarea unui CMS care va funcţiona indiferent de tipul de conţinut
(informaţie afişată sau gestiune de aplicaţii) necesită capacitatea de a menţine şi de a
urmări două fluxuri de lucru în acelaşi timp. Este adevărat că fluxurile de informaţii şi
ale dezvoltării de aplicaţii sunt similare până la un punct: ambele creează, modifică,
aprobă, testează şi lansează conţinut. Totuşi, sunt necesare expertize diferite în
crearea informaţiei în comparaţie cu crearea aplicaţiilor, iar aceste diferenţe se măresc
pe măsură ce se continuă stagiul către lansarea conţinutului.
De asemenea, fluxurile de lucru ale informaţiei şi aplicaţiilor nu sunt la fel. De
exemplu, pentru fluxul de lucru al unei aplicaţii sunt necesari paşi şi instrumente
diferite: analiza şi design-ul sunt mult mai detaliate, existând şi compilarea, testarea de
sistem şi de produs final.
Aplicaţiile sunt mult mai complex imbricate cu site-urile Web ca întreg decât
este informaţia cu site-urile. Pentru multe sisteme CM, legătura dintre aplicaţii şi un
site Web este atât de strânsă încât este necesară închiderea unui site Web înaintea
instalării, lansării sau actualizării aplicaţiei. În schimb, informaţia presupune entităţi
distincte. Este posibil să se adauge, actualizeze sau să se şteargă informaţia dintr-un
site web fără a ne face griji cu privire la închiderea site-ului pentru acest lucru.
În practică se observă că cele mai multe sisteme de CM nu sunt utilizate în

întregime pentru gestiunea conţinutului aplicaţiilor sau a combinaţiilor cu informaţiile.
În cele mai multe cazuri, producătorii de sisteme CM se concentrează numai pe
gestiunea informaţiei, existând, în schimb, soluţii specializate în gestiunea codului
sursă pentru a gestiona conţinutul aplicaţiei. Exemple de sisteme de gestiune a
conţinutului pot fi Vignette şi Interwoven, ambele suportând gestiunea oricărui tip de
informaţie/conţinut. Totuşi, ambele oferă add-on-uri pentru gestiunea codului sursă,
producătorii făcând astfel distincţia între informaţie/conţinut gestionabil şi cod sursă
gestionabil.
După cum se poate observa pe Web, orice site este alcătuit din mai multe tipuri
diferite de conţinut: text, imagini, obiecte audio, obiecte video etc., abordarea
separată a acestora fiind mult mai uşoară. Motivul principal este acela că se permite
specializarea instrumentelor (utilizarea unui instrument specializat pentru fiecare tip
de conţinut) şi a muncii (un expert în desen nu trebuie să se preocupe, de exemplu, de
scrierea unui articol). Sistemele de gestiune a conţinutului se bazează în întregime pe
conceptul de „bucăţi de conţinut”, termenul utilizat fiind de componente de conţinut.
Granularitatea unei componente de conţinut este determinată de sistemul CM
utilizat. Componentele de conţinut sunt stocate, de obicei, în depozite care utilizează
acelaşi format. De exemplu, imaginile ar putea fi stocate sub formă de fişier formatat
GIF cu înălţimea şi lăţimea predeterminate. De asemenea, componentele de conţinut
ar trebui să aibă înţeles de sine-stătător. Un exemplu de componente de conţinut
poate fi observat în figura următoare.
Figura 1.1 – Pagini web şi componente de conţinut.
Un document este alcătuit din component de conţinut. Sistemele de gestiune a

documentelor oferă aceleaşi facilităţi ca ale unui CMS, dar la nivel de document
(gestiunea întregului document web şi nu a părţilor din interiorul acestuia).
Elementele unui sistem de gestiune a conţinutului
In mod normal, un CMS constă din cel puţin trei elemente:

 Aplicaţia de gestiune a conţinutului (CMA – content management
application) – gestionează componentele de conţinut;
 Aplicaţia de gestiune a metaconţinutului (MMA - metacontent
management application) – gestionează informaţia despre
componentele de conţinut;
 Aplicaţia de livrare a conţinutului (CDA – content delivery application) –
oferă modalitatea de afişare a componentelor de conţinut pe Web.
Aplicaţia de gestiune a conţinutului
Gestionează întreg ciclul de viaţă al componentelor de conţinut, de la crearea

acestora până la eliminarea lor din sistem, pe baza unui depozit. Un depozit poate lua
forma unei baze de date, a sistemului de fişiere sau a combinaţiei între cele două.
Procesul de gestiune este unul secvenţial după natură şi este îndeplinit pe baza unui
workflow. Aplicaţia de gestiune a conţinutului din cadrul unui CMS poate fi considerată
partea de administrare a acestuia.
CMA permite autorilor de conţinut să creeze componente de conţinut fără
cunoaşterea HTML, de exemplu, sau fără cunoştinţe de arhitecturi Web. Toate aceste
aplicaţii CMA sunt multi-utilizator prin construcţie, fiecare utilizator putînd îndeplini
unul sau mai multe roluri în ciclul de viaţă al componentei. Multe CMA au o securitate
bazată pe roluri, în care utilizatorii au permisiunea de a executa sarcinile alocate lor în
momentul adăugării lor în sistem. Pentru un site Web mai mic, de exemplu, unde
lucrează un număr mic de oameni, securitatea poate consta într-un număr mic de
roluri, fiecare rol îndeplinind un număr diferit de sarcini. Pentru un site Web mare,
poate exista un număr mare de roluri, fiecare cu responsabilităţi limitate.
Scopul unui CMA este de a trece componentele de conţinut prin ciclul lor de
viaţă, cât de rapid şi de eficient posibil. La finalul ciclului de viaţă, componentele de
conţinut ar trebui să se găsească într-o stare matură şi stabilă. Figura următoare
ilustrează stagiile comune unui ciclu de viaţă.
Aprobarea: înaintea finalizării oricărui stagiu din ciclul de viaţă şi de începerea

următorului, este nevoie ca o persoană cu autoritatea necesară să aprobe modificările
aduse componentei de conţinut. Procesul de aprobare poate varia între site-urile Web,
chiar şi între cele care au acelaşi sistem de gestiune a conţinutului. În organizaţiile mari
este necesară o persoană, rol sau comitet diferit pentru aprobarea componentei de
conţinut, înainte ca aceasta să progreseze către următorul stagiu. La cealaltă extremă,
un site web mic, de exemplu, o singură persoană ar putea aproba întregul ciclul de
viaţă al componentei.
Figura 1.2 – Arhitectură generică pentru Aplicaţie de Management a Conţinutului

(CMA).
Design-ul: este locul în care sunt identificate şi descrise toate componentele de

conţinut care vor fi publicate. În unele sisteme de CM, componentele de conţinut intră
în sistem în acest stagiu, sub formă de comentarii, descrieri sau locuri, pe care autorii
le vor completa mai târziu.
Crearea: este procesul de achiziţionare al componentelor de conţinut, cuprinzând atât
scrierea componentei de la început, cât şi achiziţionarea conţinutului din alte surse şi
încărcarea acestuia în sistem.
Editarea: după ce a avut loc crearea componentei, aceasta poate participa, în runde
multiple, la editare şi rescriere, până când persoanele cu autoritatea potrivită cred că
respectiva componentă este completă, corectă şi gata pentru a începe stagiul în
următorul ciclu de viaţă.
Aşezarea în document: după finalizarea componentelor, acestea sunt aranjate şi
integrate într-un document pentru vizualizare.
Testarea: după finalizarea documentelor (web), acestea ar trebui testate pentru
funcţionalitate în browser-e, pentru link-uri greşite, imagini prea mari pentru a se
potrivi cu restul conţinutului etc.
Staging: după testare, componentele sunt mutate pe un server temporar pentru a
aştepta replicarea către serverele de producţie. Scopul acestui pas este de a face
transferul către serverele finale fără a interfera cu activitatea utilizatorilor.
Livrarea: conţinutul trebuie mutat periodic în site-ul live, altfel site-ul va stagna în mod
rapid. Această procedură poate fi foarte complexă, în funcţie de numărul de servere
deţinute în fermă sau în funcţie de posbilitatea accesării conţinutului 24/7.
Întreţinerea: procesul de gestiune al componentelor nu se finalizează odată cu livrarea
conţinutului în site, acesta trebuind actualizat cu informaţii adiţionale.
Arhivarea: după ce un conţinut este depăşit şi nu mai este întrebuinţat, ar trebui
arhivat. Arhivarea nu semnifică faptul că utilizatorii nu-l mai pot accesa, ci este
accesibil prin căutarea în arhiva de documente a site-ului.
Eliminarea: în cazul în care conţinutul devine învechit şi nu mai poate fi actualizat,
componenta de conţinut ar trebui eliminată. Deşi această facilitate există, cele mai
multe procese din cadrul unui CMS doar arhivează conţinutul, neeliminându-l complet.
Aplicaţia de gestiune a metaconţinutului
Într-un CMS, în mod ideal, conţinutul şi livrarea acestuia ar trebui separate complet, de
aici apărînd separarea părţii administrative a CMS în aplicaţia de gestiunea a
conţinutului şi în aplicaţia de gestiune a metaconţinului; fiecare este specializată în
lucruri diferite: conţinut şi livrarea conţinutului.
Motivul principal pentru această separare este faptul că CMA şi MMA au
workflow-uri şi grupuri de utilizatori diferite. Astfel, aplicaţia de gestiune a
metaconţinutului este utilizată de personalul creativ sau de design al site-ului şi
conţine un ciclu de viaţă specific creării interfeţei grafice a site-ului.
Între tipurile de metaconţinut gestionate de aplicaţie putem găsi:
 Şabloane
 Script-uri client şi server
 Aplicaţii compilate server-side
Aplicaţia de livrare a conţinutului
Scopul acestei aplicaţii este de a afişa componentele de conţinut din depozit

folosind elementele de metaconţinut. O aplicaţie bună de livrare a conţinutului este
gestionată direct prin intermediul metaconţinutului, acesta din urmă determinând
ceea ce este afişat şi cum este afişat. Există, practic, un număr nelimitat de modalităţi
prin care metaconţinutul determină ce componente vor fi afişate, precum şi
modalitatea lor de afişare, totul depinzând de cît de creativă este echipa care creează
şabloanele, script-urile şi/sau programele.
1.1. SISTEME DE MANAGEMENT AL CONŢINUTULUI (CMS)
Noţiunea de CMS este greu de definit, multe produse pretinzând a fi soluţii

CMS complete: jurnale personale (personal weblogs), wiki-uri (wiki este un site web
care permite redactarea sa de către vizitatori şi este destinată editării colective),
portaluri de noutăţi. Un sistem de management al conţinutului (CMS) este un sistem
software utilizat la asistarea utilizatorilor săi în procesul de management al
conţinutului. CMS-ul facilitează organizarea, controlul şi publicarea de documente sau
alt tip de conţinut, cum ar fi imagini şi resurse multimedia. Un CMS facilitează adesea
crearea în comun de documente. CMS este un sistem folosit pentru a administra
conţinutul unui site. Se pot utiliza şabloane standard cu care este livrat un CMS sau se
pot crea altele după preferinţele fiecăruia. Un CMS indexează toate datele dintr-un
sistem iar utilizatorii pot căuta informaţii în baza de date folosind cuvintele cheie.
CMS-ul ar trebui să permită chiar unui utilizator fără experienţă IT să creeze, să
editeze, să administreze, să publice orice tip de conţinut respectând anumite reguli
care să asigure o afişare corectă a informaţiei dorite. Este uşor de instalat de către
oricine, chiar şi de cei care nu au prea mare experienţă. Cu ajutorul lui se poate crea
un site în câteva minute, după care urmează modelarea după preferinţele şi
necesităţile fiecăruia.
Sistemele de management al conţinutului sunt folosite adesea pentru stocarea,
controlarea documentelor cum ar fi articole, manuale de operare, manuale tehnice,
ghiduri de vânzări şi broşuri de marketing. Astfel, informaţiile prezentate de aceste
sisteme sunt actualizate permanent, iar căutarea unor date mai vechi se realizează
relativ uşor.
Un CMS poate avea următoarele funcţii:

 Importarea şi crearea de documente şi material multimedia;
 Identificarea utilizatorilor cheie şi a rolului lor în managementul
conţinutului;
 Abilitatea de a atribui roluri şi responsabilităţi diferitelor categorii de
conţinut;
 Definirea de sarcini de lucru adesea cuplate cu trimiterea de mesaje în
funcţie de eveniment, astfel încât managerii de conţinut sunt alertaţi când
intervin schimbări;
 Abilitatea de a urmări şi organiza mai multe versiuni ale unei singure
instanţe a conţinutului;
 Abilitatea de a publica conţinutul într-o biblioteca, pentru a susţine accesul
la conţinut.
Un sistem de management al conţinutului oferă următoarele facilităţi cheie:

 Şabloane automate - creează şabloane vizuale standard care pot fi aplicate
automat atît conţinutului nou cît şi celui existent, creând un punct central
pentru schimbarea interfeţei unui site;
 Conţinut uşor editabil - odată ce conţinutul e separat de reprezentarea
vizuală a sitului, editatul şi manipulatul devin, de obicei, mult mai uşoare şi
mai rapide. Cele mai multe sisteme CM includ unelte de editat WYSIWYG
ce permit personalului ne-tehnic să creeze şi să editeze conţinut;
 Set scalabil de facilităţi - cele mai multe sisteme CM au plugin-uri sau
module care pot fi instalate uşor pentru a extinde funcţionalitatea;
 Upgrade-uri după standardele web - soluţiile active de management al
conţinutului primesc, de obicei, update-uri regulate care includ noi facilităţi
şi menţin sistemul la standardele web;
 Managementul workflow-ului – workflow-ul este procesul creării de sarcini
secvenţiale şi paralele care trebuiesc îndeplinite de către CMS. De exemplu,
un autor de conţinut scrie un articol care nu este publicat pe site până când
nu este verificat de editor şi aprobat de editorul şef;
 Managementul documentelor – sistemele CM pot include mijloace de
gestionare a ciclului de viaţă al unui document, de la creare, revizii,
publicare, arhivare pînă la distrugere.
După Stephen R.G. Fraser 1, un system de gestiune al conţinutului ar trebui să

cuprindă:
 Interfaţă standard pentru creare, editare, aprobare şi livrare de conţinut;
 Depozit comun;
 Controlul versiunilor, urmărire şi rollback;
 Workflow;
 Generarea dinamică a paginilor;
 Personalizare;
 Managementul cache-ului de performanţă;
 Conversia conţinutului;
 Integrare cu motor de căutare;
 Monitorizarea, analiza şi raportarea accesului la conţinut.
Conform Documentum2, un CMS:

 Permite personalului netehnic să creeze sau să publice conţinut fără
asistenţa membrilor echipei IT;
 Separă conţinutul de structură, permițând crearea de şabloane şi de reguli
de prezentare;
 Asigură aderarea autorilor de conţinut la standardele web ale organizaţiei;
menţine securitatea şi elementele de navigare;
 Asigură un mecanism de publicare, astfel încât site-ul să fie mereu
actualizat;
 Consolidează datele din afacere şi conţinutul într-un sigur depozit pentru
acces mai rapid, reducând şi costurile de întreţinere a versiunilor tipărite;
 Permite crearea de conţinut prin browser-e web standard, reducând
costurile de instruire;
 Crează rapoarte de audit al activităţilor, pentru motive de securitate;
 Restricţionează editarea conţinutului pe baza apartenenţei utilizatorilor în
rol/grup/divizie;
 Oferă mecanisme de control al reviziei şi de publicare automată prin
workflow-uri;
 Oferă mecanisme de control al versiunilor/istoric al documentelor pentru a
permite rollback la conţinut/pagini dorite din versiunile dorite;
 Permite controlul documentelor prin interfeţe de tip check-in/check-out;
 Permite programarea publicării/eliminării conţinutului la anumite date;
 Suport pentru indexare/căutare pe baza metadatelor din conţinut;
 Raportare detaliată pentru utilizatorii finali şi pentru administratori.
1
Real World ASP.NET: Building a Content Management System, Apress, 2002
2
EMC, http://www.emc.com/
Tipuri de CMS
Dacă orice informaţie care este stocată digital fără nici un fel de organizare
poate fi descrisă ca şi conţinut, atunci un software care se ocupă de gestiunea acestor
informaţii poate fi numit sistem de management al conţinutului. La fel, un sistem de
management al documentelor este cel care se ocupă cu gestionarea documentelor sau
un sistem de management al conţinutului web este cel care se ocupă cu gestionarea
paginilor web. Astfel, putem spune că orice vânzător vede sistemul de management al
conţinutului din perspectiva propriului produs şi ne putem da seama că nu există doar
o formă a sistemelor de management al conţinutului, ci mai multe.
În funcţie de sursa de documentare, există mai multe clasificări ale tipurilor de
sisteme de management al conţinutului. Astfel, conform Wikipedia, avem următoarele
forme:
 Un sistem de management al conţinutului web este un software pentru
managementul site-urilor web;
 Un sistem de gestionare a muncii pentru publicarea unui articol;
 Un sistem de management al documentelor;
 Un sistem de management al conţinutului dintr-o singură sursă – unde
conţinutul este stocat într-o bază de date relaţională.
Tipuri de sisteme CM:
 CMS bazate pe module – majoritatea sarcinilor din ciclul de viaţă al unui

document sunt rezolvate de modulele CMS-ului. Modulele cele mai
întâlnite sunt crearea/editarea, modificarea şi editarea de conţinut;
 CMS bazate pe transformare în funcţie de limbajul documentului – un alt
mod de abordare a CMS-ului realizat prin utilizarea standardelor deschise.
CMS-urile bazate pe XSLT compilează documente pregătite din XML şi
template-uri XSLT. CMS-urile bazate pe XML. Sapiens compilează un
document dintr-un şir de informaţii "pure", template-uri de design si
funcţionalitate;
 CMS bazate pe web – un alt tip de CMS care utilizează baze de date, cum
ar fi PostgreSql, MySql sau MsSql şi limbaje de scripting sau unelte, cum ar
fi coldfusion, php, jsp sau asp care interacţionează cu informaţia pentru a o
transforma in conţinut vizual. Informaţia stocată într-o bază de date este
interogată şi compilată într-o pagină HTML sau într-un alt document şi
transformată cu ajutorul CSS/XSLT. Acest sistem poate include şi alte
funcţii, cum ar fi discuţii, board-uri, blog-uri sau scrisori prin email.
Sisteme open source de gestiune a conţinutului
Spre deosebire de soluţiile comerciale, CMS-urile open source nu încearcă să

încorporeze funcţionalităţi “la modă” pentru a deveni mai populare, ci se
concentrează pe comunitatea de utilizatori care au necesităţi bine definite faţă de
managementul conţinutului. Exemple de sisteme open source:
Baze de date Ultima
Nume Platformă Licență
suportate variantă
MySQL, Oracle, SQL Server,
Alfresco Java 2.1 GPL
PostgreSQL, Informix
Java, XML,
Apache Lenya Apache 2.0 Apache License
Cocoon
1.10.2
b2evolution PHP MySQL GPL
"Florida"
BLOG:CMS PHP MySQL GPL
blosxom Perl Flat-file database 2.0 MIT
Bricolage Perl PostgreSQL 1.10.3 BSD
CMSimple PHP Flat-file database 2.9 Affero
Perl, XUL,
MySQL şi orice tip de Perl
Cyclone3 JavaScript, 3.0 GPL
DBI
C, Java
Java, XML,
Daisy Apache MySQL 2.0.1 Apache License
Cocoon
Dokuwiki PHP Flat-file database 2006-11-06 GPL
MySQL Beta versiunea 2.0
DotClear PHP 1.2.5 GPL
supports PostGreSQL
Microsoft SQL Server sau
DotNetNuke ASP.NET orice alt sistem de stocare a 4.8.0 BSD
informaţiei
Drupal PHP MySQL or PostgreSQL 5.5 GPL
e107 PHP MySQL 0.7.10 GPL
MySQL/Postgresql/Oracle/
eZ Publish PHP 4.0.0 GPL
Microsoft SQL Server
Educational
Fedora Java MySQL sau Oracle 2.2
Community License
Java, XML on
jAPS - java Agile HyperSonic SQL,
Windows or GPL
Portal System PostgreSQL
Linux
Joomla! PHP MySQL 1.0.13 GPL
KnuwledgeTree
Document
PHP MySQL 3.5 GPL
Management
System
Lyceum PHP MySQL GPL
Magnulia Java JCR 3.0.3 LGPL
Mambo PHP MySQL 4.6.2 GPL
MediaWiki PHP MySQL, PostgreSQL 1.11.0 GPL
PHP
Midgard CMS (Midgard MySQL LGPL
framework)
MODx PHP MySQL 0.9.6.1 GPL
Baze de date Ultima

suportate variantă
MoinMoin Python Flat-file database 1.5.8 GPL
Perl, MySQL sau MS SQL server
Movable Type mod_perl, sau Oracle sau PostgreSQL 4.01 GPL
FastCGI sau SQLite
Nucleus CMS PHP MySQL 3.23 GPL
PostgreSQL, MySQL, Oracle,
Nuxeo EP Java 5.1.1 LGPL
SQL Server, Ingres
TCL
OpenACS PostgreSQL/Oracle 5.1.5 GPL
AOLserver
MySQL, Oracle, PostgreSQL,
OpenCms Java 7.0.3 LGPL
SQL Server, DB2, HSQL
phpCMS PHP Flat-file database 1.2.2 GPL
PHP-Fusion PHP MySQL 6.01.13 GPL
PHP-Nuke PHP MySQL 8.0 GPL
phpWCMS PHP MySQL 1.3.3 GPL
phpWebSite PHP MySQL sau PostgreSQL 1.1.0 LGPL
Flat-file
PhpWiki PHP database/MySQL/PostgreS GPL
QL etc.
ZODB, SQLite, PostgreSQL,
Plone Python 3.0.5 GPL
MySQL, Oracle via Zope
PmWiki PHP Flat-file database 2.1.27 GPL
PostNuke PHP MySQL .764 GPL
Radiant Ruby MySQL, PostgreSQL, SQLite 0.6.4 MIT
Perl on
Scoop MySQL 1.1.8 GPL
mod_perl
PHP + SQLite, PostgreSQL, MySQL,
Serendipity 1.2 BSD
Smarty MySQLi
SilverStripe PHP MySQL 2.2.1 BSD
PHP +
SiteFrame MySQL 5.0.2 Creative Commons
Smarty
Perl on
Slash MySQL GPL
mod_perl
SPIP PHP MySQL 1.9.2 GPL
TangoCMS PHP MySQL 106-Osprey GNU/GPL 2
TandemServer ASP.NET XML GPL
Textpattern PHP MySQL 4.0.5 GPL
TGS Content
PHP MySQL 0.2.5r3 GPL
Management
TikiWiki PHP ADOdb 1.9.7 LGPL
TWiki Perl Perl DBI compatibile 4.1.2 GPL
Ruby on
Typo MySQL, PostgreSQL, SQLite MIT
Rails
TYPO3 PHP MySQL, PostgreSQL, Oracle 4.1.4 GPL
Baze de date Ultima
suportate variantă
Quick.Cms.Lite PHP Flat-file database 2.0 GPL
Perl on
WebGUI MySQL GPL
mod_perl
WordPress PHP MySQL 2.3.2 GPL
MySQL, PostgreSQL, SQLite
PHP with
utilizând ADOdb şi
Xaraya XHTML/XML 1.1.3 GPL
Microsoft SQL Server cu
/XSLT
Creole
XOOPS PHP MySQL 2.2 GPL
XOOPS Cube PHP MySQL 2.1.2 GPL
Impactul Open Source în evoluţia CMS1
 Componentele modulare ce apar în rezultatul proiectelor comune vor

determina organizarea funcţională a arhitecturii sistemelor şi nu drepturile
de proprietate sau durata licenţei;
 Dovezi clare de aplicabilitate şi compatibilitate cu anumite aplicaţii datorită
distribuţiei de extensii şi adaptări speciale ale aplicaţiei, asociate cu fiecare
implementare;
 Cu toate că proiectele CMS-urilor cu cod deschis sunt mai bine organizate şi
distribuite, lor le vor lipsi funcţionalităţi de nivel înalt, cum ar fi: algoritmi
moderni de căutare, suport multimedia, criptografie de ultimă oră,
managementul valorilor digitale. Organizaţiile care mizează pe avantajul în
afaceri adus de CMS spre deosebire de concurenţii săi, vor prefera soluţiile
comerciale şi garanţiile oferite prin procurarea acestora.
Studiu de caz: alegerea unui CMS open source:
Următoarele hotărâri ar putea ajuta la alegerea unui CMS:

 Conţinutul sau scopul : definirea scopului conţinutului este la fel de
importantă ca şi conţinutul propiu-zis. Este conţinutul realizat pentru
forumuri, interacţiuni sau este construit pentru exprimarea sentimentelor,
cum sunt blogurile şi articolele;
 Formatul: conţinutul va include texte, imagini, video, audio, XML, PDF,
HTML etc.
 Cum ar trebui stocat conţinutul: în fişiere/foldere sau în baze de date;
 Suportul: pentru CMS open source suportul este foarte important. Cât de
mult te ajută? Cât este de activ?
 Add–on-urile: este foarte puţin posibil ca un CMS să se potrivească de la
început cu ceea ce utilizatorii aşteaptă, de aceea este foarte important ca
acesta să aibă cât mai multe opţiuni de add-on-uri valabile pentru CMS
ales.
1
Oleg Bularca, Sistem de management al conţinutului pentru Web, Teza de Doctorat, Chişinău, 2006
După ce au fost stabilite aceste hotărâri, se pot încerca mai multe sisteme de
CM pentru a vedea care se apropie mai mult de dorinţele utilizatorului. Singurul site
care te lasă să te joci cu mai multe CMS-uri open source cu privilegii de administrator
înainte de a-l instala pe site-ul tău este www.opensourceCMS.com. Aici pot fi găsite
mai multe categorii de CMS din care să alegi : Portaluri, Bloguri, e-Commerce,
Groupware, Forumuri, e-Learning, Galerii cu imagini, Wiki, Lite şi Miscellaneous.
Singura problemă este că permite doar aplicaţii bazate pe PHP.
După ce sunt încercate mai multe CMS-uri, se observă că fiecare CMS are
propriile puncte tari şi puncte slabe. Cel mai important este să alegi un CMS care să se
potrivească cu felul în care vrei tu să-ţi organizezi conţinutul. S-ar putea să îţi ia ceva
timp şi efort să înveţi singur cum funcţionează un CMS.
Apoi ar trebui verificată popularitatea CMS-ului. Trebuie făcută o listă cu
popularitatea CMS-urilor, pornind de la numărul celor care vizitează sau votează
aplicaţia. Ar putea fi întocmită o listă bazată pe categorii şi voturi în ordine
descrescătoare. O listă de popularitate care este sortată după categorii şi după cel mai
mare succes. Popularitatea este calculată după următoarea metodă: media aritmetică
a punctajelor tuturor voturilor. Numărătoarea este numărul total de voturi. Hit-ul
indică de câte ori a fost vizitată pagina.
Oferă CMS-ul ales de tine siguranţă, sau nu? Este una din întrebările care ar
trebui puse, deoarece nimeni nu doreşte să aleagă un CMS care să nu ofere siguranţă.
De asemenea, ar trebui hotărîte caracteristicile şi funcţiile dorit în site-ul final.
Următoarele întrebări ar trebui să ajute la fundamentarea deciziei:
 introducerea un calendar pentru a ţine evidenţa evenimentelor;
 nevoia de un spaţiu pentru upload sau download;
 introducerea o galerie de imagini;
 posibilitatea ca pe acel site să se şi voteze;
 suport pentru mai multe limbi sau suport pentru traducere;
 importanţa securităţii şi a permisiilor intrărilor.
După determinarea sistemului de bază şi a caracteristicilor addon-ului, este

timpul deciziei referitoare la aspectul site-ul. Majoritatea sistemelor utilizează
template-uri/şabloane sau skin-uri şi CSS (cascading style sheets) care permit
modificarea felului în care arată site-ul final. Totul depinde de imaginaţia
administratorului. Chiar dacă acesta nu este un expert în grafice sau template-uri,
există câteva templat-uri gratuite, care se pot modifica în aşa fel încît să se potrivească
cu site-ul dorit.
În urma premierilor CMS 2007, au fost premiate în funcţie de categorie
următoarele CMS-uri:
Primele 3 CMS-uri open source din 2007 au fost:

1. Drupal
2. Joomla!
3. CSM Made Simple
Cele mai promiţătoare CMS-uri open source:
1. MODx
2. Tzpolight dotCMS
Cele mai bune CMS-uri open source bazate pe PHP:
1. Joomla!
2. Drupal
3. e107
Cele mai bune CMS-uri open source bazate pe altceva decât PHP:
1. mojoPortal
2. Plone
3. Silva
Cele mai bune CMS-uri open source din reţele sociale:
1. WordPress
2. Drupal & Elgg
1.2. METADATE
Setul de nume şi relaţii din sistemul metatorial conţine baza conţinutului. Fără
baza fundamentală, conţinutul ar fi fără formă şi “slăbit” din toate punctele de vedere.
Metadata reprezintă părţi mici de informaţii sau date ataşate la conţinut şi care permit
facilitarea unor operaţii cum ar fi stocare, catalogare şi repararea (unor erori) ale
conţinutului. Un sistem metadata corect deţine diverse clase de conţinut într-o schemă
bine pusă la punct şi în care componentele conţinutului sunt legate între ele, la fel ca şi
colecţiile, managementul şi publicarea sistemelor testate.
“Meta” în sine (Oxford English Dictionary) semnifică o coloană care marchează

limita unei piețe circulare. Dar, într-un mod mai general, “meta” este un prefix. El
modifică înţelesul cuvintelor care îl preced. Dupa Merriam-Webster OnLine (www.m-
w.com), ca prefix, meta are următoarele înţelesuri:
 situat în spate sau dincolo;
 schimbare sau transformare;
 domeniu vast şi transcendent;
 element foarte bine organizat cu o formă specifică.
Cuvântul meta poate fi familiar din limbajul HTML unde există acele <meta>
tag-uri. Acest tag era folosit pentru a specifica informaţii despre un fişier HTML. După
părerea unor experţi, cuvântul “meta” s-ar putea traduce cu succes prin “despre”.
Prin urmare, metadata ar însemna o dată despre mai multe date. Termenul
reprezintă un domeniu mult mai vast, așa cum se poate vedea şi pe pagina principală
de web Metadata Coalition1. Aici, înţelesul cuvântului are mai multe caracteristici.
Astfel, metadata:
 oferă posibilitatea de a partaja date între aplicaţii. În contextul content
managementului, metadatele permit existenţa de publicaţii care au nevoie
de diferite forme ale aceleiaşi date pe care să le extragă dintr-un depozit
comun;
1
http://www.omg.org/
 standarde - metadatele reprezintă un set de elemente standard pe care

toate grupurile le cunosc în vederea definirii informaţiilor. În contextul
content managementului, aceste standarde pot fi mai mult interne în zilele
noastre, dar au acelaşi rol. Aceste standarde asigură că, în mod automat,
eforturile unei persoane sau ale unui grup pot fi ulterior refolosite, dacă toţi
utilizează aceleași reguli;
 focus pe bazele de date: interesul major pentru metadate în ziua de astăzi
este reprezentat de partajarea şi standardele care stau în spatele aplicaţiilor
de baze de date standard. Depozitele de date şi schimbul de date între
aplicaţii reprezintă o problemă care afectează organizaţiile cu volume
enorme de date stocate în baze de date şi în alte fişiere care nu pot fi
interpretate decît cu ajutorul aplicaţiei care le-a creat;
 conştientizare a întregii lumi: deşi metadata este un termen folosit în
sistemele de date, ea mai poate fi înţeleasă ca parte integrantă a aplicaţiilor
unei organizaţii. CMS este o aplicaţie de mare amploare a unei organizaţii.
Metadatele fac posibil faptul ca aceste aplicaţii să poată interacţiona cu alte
surse de date din respectiva organizaţie; de asemenea, prin metadate,
sistemul de gestiune a conţinutului poate unifica şi utiliza el singur
informaţii în mod automat şi eficient.
Conform1 metadatele reprezintă date care descriu structura şi funcţionarea

utilizării informaţiei în organizaţie, în acelaşi timp descriind sistemele pe care le
utilizează pentru a gestiona informaţia. Crearea unui model de metadate este acelaşi
lucru cu crearea unui model organizaţional al chiar industriei IT.
Ciclul de viaţă al metadatelor
Chiar începând din fazele de planificare şi design al unei aplicaţii trebuie să se

urmărească toate metadatele create, nefiind fezabil procesul de ataşare a metadatelor
numai după începerea procesului de producţie. De exemplu, dacă metadatele create
de o cameră digitală la înregistrare nu sunt înregistrate imediat, acestea ar putea să
trebuiască să fie restaurate mai târziu cu un mare efort. În consecinţă este o necesitate
ca grupuri diferite de producători/autori de resurse să coopereze folosind metode şi
standarde compatibile.
Ciclul de viaţă al metadatelor, la fel ca al tuturor obiectelor electronice cuprinde:
 manipulare: metadatele trebuie să se adapteze dacă resursa pe care o
descriu se modifică. Operaţiunea este executată de aplicaţiile de astăzi.
De exemplu, programele de editare de imagini nu urmăresc, de obicei,
metadatele de tip Exif create de camerele digitale;
 distrugere: uneori poate fi utilă reţinerea metadatelor chiar şi după
distrugerea resurselor la care erau ataşate. De exemplu se poate reţine
istoricul modificărilor dintr-un text.
1
William R. Durrell, Data Administration: A Practical Guide to Data Administration, McGraw-Hill,
1985
Stocarea
Metadatele pot fi stocate intern, în acelaşi fişier cu datele brute sau extern,
într-un fişier separat. Ambele modalităţi au avantaje şi dezavantaje:
 stocarea internă permite transferarea metadatelor împreună cu datele
pe care le descriu, metadatele fiind astfel manipulate cu uşurinţă şi
întotdeauna disponibile. Această metodă creează mari redundanţe şi nu
permite păstrarea împreună a mai multor metadate;
 stocarea externă permite introducerea medatelor într-o bază de date,
de exemplu, pentru o căutare mai eficientă. Nu există redundanţă iar
metadatelor pot fi transferate simultan prin utilizarea streaming-ului. Cu
toate acestea cele mai multe formate utilizează URI-uri pentru
specificarea modalităţii în care metadatele sunt legate de datele brute.
În plus, există o întrebare legată de formatul metadatelor: stocarea acestora

într-un format care poate fi citit de oameni, precum într-un fişier XML care poate fi
înţeles şi editat fără instrumente specializate. Pe de altă parte, aceste formate nu sunt
optimizate pentru volume mari, fiind mult mai utilă stocarea metadatelor în format
binar, neinterpretabil direct de către oameni pentru a îmbunătăţii performanţa şi a
scădea consumul de memorie.
Aplicaţii care utilizează metadate
Bazele de date relaţionale utilizează metadate sub forma cataloagelor (tabele

care conţin date despre tabelele bazei de date, numele mărimea, numărul de
înregistrări precum şi tabele despre câmpurile tabelelor, din ce tabele fac parte,
denumirea acestora etc.).
Metadatele depozitelor de date pot fi clasificate, de obicei în două categorii:
 metadate back room utilizate pentru funcţiile de extragere,
transformare şi încărcare de date din sistemele tranzacţionale;
 metadate front room, utilizate pentru etichetarea ecranelor şi crearea
rapoartelor.
Aplicaţiile de Business Intelligence utilizează metadate pentru a descrie modalitatea de
interogare a datelor, de filtrare, analizare şi afişare în aplicaţiile de BI (instrumente de
raportare, instrumente OLAP, instrumente Data Mining). Ca exemple putem enumera:
 metadate OLAP: descrierea şi structura Dimensiunii, Cuburilor,
Măsurilor, Ierarhiilor, Nivelurilor etc.;
 metadate de raportare: descrierea şi structurile Rapoartelor, graficelor,
interogărilor, filtrelor, seturilor de date etc.;
 metadate în Data Mining: descrierea şi structura DataSet, a algoritmilor,
a interogărilor etc.
Metadata în aplicaţiile de Content Management
Dacă “managementul conţinutului” ar fi o artă de a denumi informaţiile,

metadata ar fi setul de nume corespunzător. Content Management este strâns legat de
conceptul de metadate. Metadatele au grijă ca întreg sistemul să nu se autodistrugă
sau să iasă de sub control extinzându-se. Acest control este principala caracteristică a
metadatelor într-un CMS. Dacă toţi paşii primesc un nume şi un număr, se va putea
organiza şi exercita întregul control asupra conţinutului.
Figura 1.3 – Utilizarea Metadatelor în sisteme de gestiune a conţinutului.
Tipuri de metadata
În continuare vor fi prezentate câteva tipuri de metadate care ar putea fi

întâlnite frecvent în domeniul content management-ului:
 metadate de structură – sunt cele care mai des întâlnite; preced multe alte
tipuri de metadata, prin crearea de diviziuni structurale în conţinut;
 metadate de format - se aplica la orice nivel de structură definită şi
marchează modul în care se intenţionează afişarea structurii respective;
 metadate de acces - organizează structurile create într-o ierarhie şi alte
structuri de acces;
 Metadate de gestiune - reprezintă datele ataşate structurilor pentru a le
administra şi urmări în evoluţia lor;
 metadate de includere - se folosesc la partea externă a conţinutului,
marcând locul în care va fi introdus conţinutul extern.
Limbajele de marcare (de tipul XML) reprezintă modalitatea principală în care
se pot aplica metadate asupra conţinutului. Cealaltă modalitate este reprezentată de
aplicarea metadatelor prin intermediul bazelor de date.
Conform1 metadatele pot fi clasificate astfel:

 conţinut. Metadatele pot descrie fi însăşi resursa (de exemplu numele şi
mărimea unui fişier) sau conţinutul resursei (de exemplu „Acest fişier este
unul video care arată un meci de fotbal”);
 variabilitate. În funcţie de întreaga resursă metadatele pot fi fie imutabile
(nu se modifică – „Titlul” filmului nu se modifică în timpul rulării acestuia),
fie variabil („descrierea scenei” se modifică);
 funcţie logică. Există trei niveluri de funcţie logică:
o nivelul sub-simbolic – care conţine datele brute;
o nivelul simbolic – cu metadate care descriu datele brute;
o nivelul logic – care conţine metadate care permit interpretarea,
analiza logică a nivelului simbolic.
In următoarea secţiune vor fi prezentate pe rând aceste tipuri de metadate,

dând detalii şi exemple în XML sau HTML, pentru a vizualiza aplicarea metadatelor.
Metadatele de structură
Metadatele de structură furnizează informaţii de tipul: “poţi numi acest obiect

ca....”. Este tipul de metadată de bază, în sensul că, înainte de a zice ceva despre un
lucru, trebuie mai întâi ca acel lucru să fie denumit. Acest tip de metadată creează
obiecte separându-le de restul obiectelor din jurul lor. In CMS, metadatele de structură
împart întregul text, de la definirea limitelor caracterelor şi până la divizarea colecţiilor
vaste de publicaţii, respectând lista de mai jos:
 caractere: cea mai mică unitate structurală. Datorită faptului că definirea
metadatelor se poate aplica la caractere individuale, nu se poate ignora
aceasta unitate. Pentru că un caracter este cea mai mică unitate pe care un
PC o poate stoca (nu se poate tipări jumătate de caracter!) nu este nevoie
de un marcaj special pentru a arata unde începe un caracter şi unde se
termina acesta.
 cuvinte: colecţii de caractere care se intenționează a fi citite ca o unitate:
spaţiile şi punctuaţia separă cuvintele. Se poate spune cu exagerare ca
spaţiile şi punctuaţia sunt elemente metadata care spun că, cuvântul este
cuvânt.
 paragrafe: colecţii de cuvinte care se intenţionează a fi citite ca unitate. Se
marchează paragrafele folosind un element metadata pentru a vedea
limitele acestuia. (In HTML se poate folosi tag-ul <p>), iar intr-un text
normal uniform se folosește “Enter”. Paragrafele sunt importante de
1
http://en.wikipedia.org/wiki/Metadata, preluat 26 ianuarie 2008
marcat deoarece se pot aplica metadatele de formatare la nivelul

paragrafului.
 elemente: colecţii de caractere, cuvinte, sau paragrafe care se
intenționează a fi citite ca o unitate (de ex.: titlurile). Elementele se
suprapun cu paragrafele şi cuvintele în ceea ce priveşte nivelul de aplicare.
Se poate întâmpla să existe un paragraf format din mai multe elemente dar
şi un element format din mai multe paragrafe. Ceea ce diferă la un element
este faptul că este cea mai mică structură care se doreşte să se acceseze
separat în sistemul respectiv. Se marchează elementele cu metadate
specifice pentru a arăta unde încep şi unde se termină (de ex.: Coloanele
bazelor de date în bazele de date relaţionale şi tag-uri în XML).
 componente: colecţii de elemente pe care cititorul trebuie să le ia ca pe un
întreg din sistem (ca o foaie albă, de ex.). În CMS, componentele sunt
structurile la nivelul cărora se lucrează. Astfel, ele reprezintă structurile pe
care se aplică managementul şi metadatele de acces. Se marchează limitele
componentelor prin folosirea metadatelor specifice (spre ex. rândurile în
bazele de date relaţionale şi tag-uri elemente în XML);
 noduri: colecţii de componente care, după publicare, se intenţionează a fi
citite ca o unitate. Intr-o pagina de web nodurile sunt paginile; într-un
material printat, nodurile sunt secţiunile (titluri, capitole, părţi ş.a.m.d).
Nodurile impun un set standard de limite în jurul componentelor conţinute
de ele. In acest sens, nodul reprezintă o metadată pentru componente. Pe
paginile web, limitele fişierului înconjoară nodul (fiecare nod e un fişier
HTML). La imprimare, se vor marca limitele nodului prin metadate de forma
(stiluri de titluri etc.) .
 publicaţii: colecţii de noduri care se intenţionează a fi luate ca unitate la
citire (un singur site intranet pt. departamente de ex). Pe paginile web
publicaţiile se diferenţiază între ele folosind convenţiile grafice şi de
navigare internă din site (un site poate avea una sau mai multe publicaţii în
el). Publicaţia este o metadată pentru noduri şi nodurile reprezintă o
metadată pentru componentele conţinute. Publicaţia poate spune: ”citeşte
aceste noduri în contextul publicaţiei de arie largă”.
 grupuri de publicaţii: colecţii de publicaţii care se intenţionează a fi luate ca
o unitate (de ex: volumele dintr-o enciclopedie). Grupurile de publicaţii sunt
transmise atât pe web cât şi la printat, de convenţiile de formatare şi
structurile de navigare care sunt oferite de utilizatori prin mutarea
publicaţiilor în acel grup. Încă o dată, un grup reprezintă o metadată pentru
publicaţia particulară oferind un context vast în care se poate interpreta
înțelesul publicaţiei.
Caracteristicile comune ale tuturor acestor diviziuni structurale sunt că fiecare

defineşte un întreg care se poate separa de ceea ce îl înconjoară; fiecare impune un
context larg şi un alt nivel de cunoaştere din jurul celor care-l conțin; de asemenea,
trebuie oarecum sa se marcheze fiecare diviziune (chiar dacă numai cu metadate de
formatare sau cu convenţii grafice). Urmează un exemplu simplu, scris în XML, care
arată multe dintre tipurile de structură descrise anterior:
<COLLECTION>
<PUB>
<SECTION>
<NODE>
<HEADER>...</HEADER>
<COMPONENTS>
<COMPONENT>
<ELEMENT>
<PARA>
<COMPONENT>...</COMPONENT>
<PARA>
</ELEMENT>
</COMPONENT>
</COMPONENTS>
<FOOTER>...</FOOTER>
</NODE>
</SECTION>
</PUB>
</COLLECTION>
Chiar un exemplu simplu ca cel de mai sus este sugestiv privind metadatele de
structură. In primul rând se observa că nu apare nici o dată, ci doar metadate.
Descrierea este făcută, dar se lasă în afară lucrul care o descrie (pentru simplitate).
In al doilea rând, se observă imbricarea colecţie. Fiecare colecţie de metadata
conţine metadatele din cadrul ei. Interpretarea fiecărei componente se adâncește pe
măsura apropierii de nod, de secţiune, de publicaţie şi chiar de nivelul colecţiei. Astfel,
toate nivele superioare sunt metadate ale componentei (ori meta-metadate, meta-
meta-metadate s.a.m.d).
In final, se observă stratificarea dintre componente, elemente şi paragrafe. In
acest exemplu, un element conţine un paragraf care la rândul lui are altă componentă.
A se urmări acest exemplu mult mai realist:
<ELEMENT>
<PARA>
Acesta este corpul de text şi in el inserez o imagine.
<MEDIA ID="m1" URL="img.jpg">
<SIZE>100,200</Size>
<CAPTION>Aceasta e o componenta separata.</CAPTION>
</MEDIA>
</PARA>
Lucrurile normale par ciudate atunci cand cu adevarat te gandesti
la ele!
</ELEMENT>
Componenta <MEDIA> (in acest caz, o imagine) este plasata înăuntrul

paragrafului,care este conţinut înăuntrul unui element, care la rândul lui este într-o
componentă. Dacă se transformă componenta <MEDIA> în HTML, aceasta devine un
conţinut şi o parte din metadata de includere așa cum arata următoarele rânduri:
<IMG SRC="img.jpg" WIDTH="100" HEIGHT="200" />

<H6>Aceasta e o componenta separata</H6>
Metadate de format
Acestea se pot interpreta astfel: ”Iată cum afişez obiectele pe care le înconjor”.
Metadatele de format se pot aplica la orice nivel de structură din sistem. In multe
cazuri, tagurile structurale sunt cele interpretate şi devin metadate de formă specifice
platformei, după cum se poate observa în acest exemplu,in XML:
<SECTION LEVEL="1"> O sectiune </SECTION>
Se poate transforma acest exemplu în metadată de format pentru a prezenta o

pagină web, aşa cum se vede mai jos:
<H1> O sectiune </H1>
Destul de frecvent , metadatele de format se află sub controlul Content

Management System prin faptul că fac parte dintr-un anume element. Spre exemplu,
se permite ca autorii să includă coduri HTML pentru îngroșat, înclinat sau subliniat în
formele lor de web pe care le folosesc la introducerea unei componente. Codurile
sursă sunt depozitate neparsate din punct de vedere al sintaxei în câmpurile bazelor de
date dar reuşesc să ajungă spre pagina web fără ca cineva să le observe. Bineînţeles că,
dacă „destinul” componentele este de a fi afişate într-un alt format decât HTML, este
nevoie de o analizare mai aprofundată a acestora.
În exemplul următor în XML, se poate vizualiza mai bine varietatea de
metadate de formă.
<COLLECTION>
<PUB DISPLAY="child">
<SECTION>
<NODE>
<COMPONENTS LAYOUT="table">
<COMPONENT>
<ELEMENT TYPEFACE="Arial">
<PARA STYLE="body">
Un <FORMATTAG>text</FORMATTAG>
<PARA>
</ELEMENT>
</COMPONENT>
</COMPONENTS>
</NODE>
</SECTION>
</PUB>
</COLLECTION>
Deşi se trişează oarecum aici, prin punerea unor elemente de formatare în

conţinut, acest lucru făcând parte din şabloane, totuşi exemplul este bun pentru acest
tip de metadate.
Mai jos se găsesc câteva dintre conceptele de format prezente în exemplul anterior:
 tagul <PUB> are ca atribut <DISPLAY> ca un lucru adiţional la el. Acest
atribut controlează afişarea publicaţiei din cadrul colecţiei. Aceasta are rolul
următor: ”Afişarea publicaţiei într-un cadru copil al colecţiei”. Valoarea
metadatei de afişare controlează, deci, afişarea/formatarea publicaţiei.
Această metadată de obicei se află într-un şablon, nu într-o structură de
conţinut.
 tagul <COMPONENT> are ca atribut STYLE. Dacă se afişează paragraful,
formatarea asociată stilului corpului (body) înconjoară conţinuturile
elementului PARA. Pentru fiecare tip de publicaţie care va fi realizată, se pot
asocia diferite coduri de formatare cu acelaşi nume de stil.
 tagul <PARA> are ca atribut STYLE. Dacă se afişează paragraful, forma
asociată stilului corpului (body) înconjoară conţinuturile elementului PARA.
Pentru fiecare tip de publicaţie care va fi produsă, se pot asocia diferite
coduri de formatare cu acelaşi nume de stil.
 textul text - are ca metadată <FORMATTAG> care îl înconjoară. Daca se
afişează cuvântul, elementele de formatare asociate tagului înconjoară
cuvântul. Pentru fiecare tip de publicaţie care va fi realizată, se pot asocia
diferite coduri de formatare cu acelaşi tag.
 orice tag poate avea o formatare asociată chiar dacă nu e special făcut
pentru a fi o metadată de formă. Se poate decide, spre exemplu, ca titlurile
de pe web să fie de mărime 12 şi îngroşate. Pentru a face acest lucru,
trebuie tratat tagul <HEADER> la fel ca şi tagul <FORMATTAG>. În cazul
transmiterii header-ului, trebuie asigurat că aplicaţia din jurul lui are
mărimea 10 ingroşat.
Metadata de acces
Metadatele de acces pot fi interpretate astfel: „Iată cum această structură se

potriveşte cu restul elementelor”. Sunt numite metadate de acces deoarece, de cele
mai multe ori, sunt folosite pentru a dobândi acces la conţinut. Se pot clasifica şi ca
metadate de structură deoarece descriu structura logică a conţinutului. De fapt,
numindu-le meta-metadate de structură este mult mai corect, deoarece ele prezintă o
structură de structuri. Dar, de obicei, se preferă această diferenţiere de metadatele de
structură fiindcă se folosesc diferite tehnici pentru a le stoca şi controla. Metadatele de
acces se pot stoca în interiorul unei componente sau în afara ei într-un loc separat.
Tipurile metadatelor de acces corespund cu tipurile de structuri de acces: ierarhii,
index, asociaţii şi secvenţe.
Urmărind exemplul următorul în XML, se observă includerea unor metadate de acces:
<COLLECTION>
<PUB>
<SECTION>
<NODE KEYWORDS="rollup">
<COMPONENTS>
<COMPONENT INDEX="term1,term2,term3">
<ELEMENT>
<PARA>
<LINK TARGET="C123"> Pentru mai
multe informatii
</LINK>
</PARA>
</ELEMENT>
</COMPONENT>
</COMPONENTS>
</NODE>
</SECTION>
</PUB>
</COLLECTION>
Ierarhia sau secvenţa sunt prezente în acest exemplu. Prin natura sa, limbajul
XML oferă o ierarhie şi o secvenţă predefinită. Pentru a specifica modalitatea de
indexare, se adaugă aceste două atribute:
 elementul <COMPONENT> are un atribut de index unde înşiruie
termenii de index pentru componentă.
 elementul <NODE> are atribute ale cuvintelor cheie(<KEYWORDS>) care
specifică modul în care nodul tratează termenii de index. In acest caz,
atributul “spune”: ”Înșiruie toţi termenii de index de la toate
componentele ce aparțin nodului”. Intr-o pagina HTML, această
comandă poate rezulta din crearea unui tag <META> la începutul
fişierului HTML care listează toţi termenii de index necesari motoarelor
de căutare.
Pentru a specifica asocierile se adaugă un tag <LINK>. Acest tag include un

atribut TARGET care numeşte structura cu care se uneşte şi un text care îl foloseşte
pentru a transmite link-ul. Intr-o pagină web, rezultatul poate arăta astfel:
Pentru mai multe informatii, <A HREF="C123.htm">click aici</A>.
La imprimare, link-ul poate arăta în acest fel după transmitere:
Pentru mai multe informatii, vedeti "Links" in 5.
Metadatele de acces se pot găsi la fel de des în afara structurii conţinutului ca şi

în interiorul lui.
Modul în care au fost prezentaţi termenii de index din exemplul de mai sus nu
este cel mai bun mod de a-i aborda. Poate se preferă ca, în loc de a introduce termenii
într-o componentă, să fie introdusă componenta în termeni, ca exemplul următor:
<INDEX>
<TERM>
<NAME>NOAA</NAME>
<COMPONENTS>C123,C456,C789</COMPONENTS>
</TERM>
</INDEX>
Această abordare este o metodă mai bună de a controla un index mare. In sens
mai realistic, ea plasează metadatele indexului în afara structurii conţinutului dar in
schimb face referire la structură.
Metadatele de management
Noţiunea metadatelor de tip management este foarte apropiată de noţiunea

normale, standard de metadate. Acest tip de metadate este definit pentru a ajuta
utilizatorii să fie la curent cu diferite modificări şi să administreze conţinutul.
Următoarele metadate sunt printre cele mai comune metadate de tip
management:
 ID
 Titlu
 Autor
 Creează data
 Modifică data
 Status
 Mărime
 Proprietar
 Data publicării
 Data de pierdere a valabilităţii
Se observă că aceste tipuri de metadate nu sunt specifice doar

managementului. Oricare dintre aceste tipuri pot fi considerate ca şi conţinut pentru a
fi publicat, cât şi ca o dată pentru a ajuta utilizatorii în controlarea conţinutului ce
urmează să fie publicat. Necunoscând limitele unor sisteme CMS, cu sau fără a arăta
valorile acestor elemente metadata, folosul lor este acelaşi: de a ajuta la urmărirea şi
administrarea conţinutului.
Urmărind acest exemplu, se observă tipul de metadate descrise:
<COLLECTION>
<PUB ID="p1">
<SECTION ID="s1">
<NODE ID="n1">
<COMPONENTS>
<COMPONENT ID="C123">
<TITLE></TITLE>
<ADMIN>
<OWNER>O234</OWNER>
<CREATE>9/23/01</CREATE>
<MODIFY>9/30/01</MODIFY>
<STATUS>Status1</STATUS>
</ADMIN>
<ELEMENT NAME="intro">
<PARA ID="p1">...</PARA>
</ELEMENT>
</COMPONENT>
</COMPONENTS>
<FOOTER...</FOOTER>
</NODE>
</SECTION>
</PUB>
</COLLECTION>
Metadatele de tip management din acest exemplu sunt uşor de înţeles. In

primul rând, fiecărei entităţi semnificative i se atribuie un identificator unic pentru a fi
localizată precis. Componentele primesc un set de elemente noi care specifică
metadatele de management care se doresc să fie incluse în componenta respectivă.
Pentru claritate, se introduc aceste elemente noi (toate fiind taguri XML). In realitate,
aproximativ toate pot fi atribute XML.
Metadatele de includere
Metadatele de includere port fi interpretate astfel: ”Se pune aici entitatea

externă”. Acestea permit referirea conţinutului care nu e in mod fizic in structura
conţinutului. Amintim exemplul de la metadatele de structură în care a fost inserată o
componenta într-o alta:
<ELEMENT>
<PARA>
<MEDIA ID="m1" URL="dabw.jpg">
<SIZE>100,300</SIZE>
<CAPTION>Aceasta este o componenta separata. </CAPTION>
</MEDIA>
</PARA>
la ele!
</ELEMENT>
Dacă se doreşte transformarea unui element <MEDIA> într-o componentă

separată, ar fi bine dacă nu s-ar insera într-o altă componentă prin specificarea unui
URL ci, în schimb să aibă o referinţă bazată pe ID, după cum urmează:
<ELEMENT>
<PARA>
<INCLUDE REFID="m1">
</PARA>
Lucrurile normale par ciudate atunci cand cu adevarat te
gandesti la ele!
</ELEMENT>
Tagul <INCLUDE>, la evaluarea de către codul care transmite pagina HTML, se

găseşte componenta “m1” şi se plasează în acel punct. Intre timp, componenta “m1”
nu este blocată într-un loc particular în structura conţinutului; este stocată cu celelalte
componente “m” care se pot găsi mai uşor, se pot controla şi se pot include in alte
locuri in conţinut.
Metadatele de includere se utilizează frecvent în publicaţiile care fac referinţă

la obiecte media, după cum este arătat în secţiunea metadatelor de structură.
Următorul exemplu explică cum se referă o imagine in HTML:
<IMG SRC="dabw.jpg" WIDTH="100" HEIGHT="300">

<H6>Aceasta este o componenta separată.<H6>
Se poate utiliza următoarea abordare în loc de aceasta:
<ELEMENT>
<PARA>
<IMG SRC="dabw.jpg" WIDTH="100" HEIGHT="300">
<H6>Aceasta este o componentă separată<H6>
</PARA>
la ele!
</ELEMENT>
Apar şi aici unele probleme: imaginea şi descrierea acestei sunt blocate în acest
loc. dacă imaginea trebuie reutilizată, trebuie recopiate tag-urile de includere a
imaginii şi a descrierii acesteia. Prin utilizarea unei referinţe, de exemplu, se evită
recopierea în mai multe locuri şi, în plus, se pot schimba toate instanţele unei
componente prin schimbarea într-un singur loc.
Tagurile <INCLUDE> din aplicaţiile web dinamice sunt esenţiale, permiţînd
scrierea o singură dată a unei componente şi „includerea” ei în mai multe pagini. În
aplicaţiile de gestiune a conţinutului acest proces de scriere o singură dată şi de
reutilizare înlocuiesc procesul de includere din aplicaţiile web dinamice.
Categoriile câmpurilor de metadate
Pana acum s-a vorbit despre limbajul XML. In XML, toate metadatele se reduc
la elemente şi atribute. O abordare mai generală ar fi să se clasifice metadatele nu
după înţelesul lor, ci prin valorile pe care le pot lua. Trebuie menţionat modul în care
structura unei baze de date relaţionale reprezintă metadatele. Se considera următorul
tabel al unei baze de date:
Figura 1.4. Liniile sunt limitele componentei iar coloanele sunt limitele elementului.
Conţinutul este în micile căsuţe ale reţelei. Restul reprezintă metadata, aşa cum
descrie lista de mai jos:
 Numele coloanelor reprezintă metadata de structură şi delimitează
limitele elementului;
 Liniile sunt metadata de structură care delimitează limitele
componentei;
 Metadatele de tip management sunt prezente în ID, Nume, Tip, Autor şi
coloanele tipului angajatului;
 Metadatele de includere sunt în coloana ImagePath.
Continuând cu informaţii despre metadate din perspectiva bazelor de date, se

poate spune că metadatele devin nişte categorii bazate pe valorile pe care elementul
metadata îl poate avea. Valorea elementului Autor, de exemplu, poate fi "Karl
Weyrauch”. Valoarea elementului “Create Date” poate fi 3 ianuarie 2002. Pentru a face
tranziţia de la XML la baza de date completă, în locul elementelor metadata, ele devin
câmpuri metadata.
Câmpurile metadata care pot fi găsite într-un sistem CMS pot fi clasificate în
următoarele categorii:
 Text liber - unde valoarea câmpului poate fi numai un text string. Titlurile,
spre exemplu, sunt de atâtea feluri fiindcă fiecare titlu e diferit;
 Textul constrâns - unde valoarea câmpului este text, dar textul trebuie să
respecte nişte reguli. Un câmp metadata “Body Text”, poate, de exemplu,
permite orice caracter ASCII împreună cu codurile HTML pentru bold, italic
şi underline. Sau se pot impune câmpului reguli privind limite de lungime,
limite la numărul de caractere care se pot pune în acel câmp;
 Şablon de text - unde fiecare valoare a câmpului trebuie să urmeze nişte
reguli particulare de formatare. Datele şi timpul se încadrează în această
categorie pentru că se pot forma numai într-un număr limitat de moduri;
 BLOB (Binary Large Objects) - unde valoarea câmpului este orice dată
binară care poate fi interpretată de unele aplicaţii. Imaginile şi alte câmpuri
media sunt exemple de câmpuri BLOB;
 Boolean - unde valoarea câmpului poate fi “adevărat” sau “fals”. E posibilă,
de exemplu, crearea unui câmp numit “Public”. Dacă această valoare e
adevărată utilizatorii pot vedea componentele într-un web site public.
 Liste închise - unde utilizatorii pot alege valoarea dintr-un set predefinit de
valori. Se poate crea, de exemplu, un câmp “Stare revizuire”, unde acesta
este una dintre 10 posibile valori.
 Liste deschise - unde utilizatorul poate alege valoarea dintr-o listă sau
poate adăuga noi intrări la lista, pentru ca apoi să le aleagă. Se poate crea,
de asemenea, un câmp “Cuvinte cheie”, unde utilizatorul poate ori selecta
una dintre cuvintele cheie din lista existentă sau poate adăuga alta nouă.
Dacă se utilizează liste deschise, trebuie asigurat faptul că ceilalţi utilizatori
adaugă obiecte noi într-o manieră controlată şi responsabilă;
 Identificator unic - unde valoarea trebuie să difere de valorile celorlalte
câmpuri. Toate componentele ar trebui sa aibă un câmp ID care să poată fi
localizat uşor în orice bază de date;
 Liste ierarhice - unde utilizatorii pot alege valori dintr-o listă ierarhică. Se
poate crea, de exemplu, un câmp numit “Produs” de unde utilizatorul poate
selecta un produs dintr-o listă schiţată de categorii de produse şi produse;
 Câmpuri combinate - care sunt alcătuite din una sau mai multe dintre
tipurile precedente. Se poate, de exemplu, să se creeze un câmp “Legătură”
care să fie o combinaţie dintre o listă rezumat şi un câmp referinţă. Pentru a
completa în câmp, utilizatorul alege dintr-o listă rezumat toate
componentele disponibile. Ce ea ce este stocat în acel câmp reprezintă o
referinţă la o componentă.
Se observă că aceste categorii se întind de-a lungul a două domenii: cum se
completează informaţia în acel câmp şi ce rămâne stocat în câmp. Câmpurile
combinate ilustrează conceptul foarte bine: un tip de câmp specifică interfaţa
utilizatorului (rezumat, spre exemplu), şi unul e responsabil cu stocarea. In acest sens,
este “foarte CMS” - vedere centrala a tipurilor câmpurilor care se axează pe ceea ce
este mai important la sistemul managerial şi utilizatorii lui. O abordare mai generală (şi
mai puţin utilă) este o vedere centrală a datelor şi axarea pe tipul datei din câmp (este
text, întreg, număr real, BLOB etc.)
1.3. TAXONOMIA CONŢINUTULUI ŞI A UNUI PORTAL
Conform cu dicționarul American Heritage Stedman's Medical dictionary,

taxonomia reprezintă clasificarea organismelor într-un sistem ordonat care indică
relațiile naturale. Definiția merge foarte bine pentru o taxonomie a conţinutului sau a
conținutului unui portal. Trebuie să deosebim taxonomia unui portal de cea a
conținutului, care sunt foarte strâns legate dar nu sunt același lucru.
Taxonomia (din grecește taxix, care înseamnă aranjament sau diviziune și
nomon care înseamnă lege) este știința clasificării folosită pentru a oferi o coordonată
pentru discuții și analize, sau găsire de informații. În teorie, dezvoltarea unei taxonomii
bune ia în seamă importanța separării elementelor unui grup (taxoni) în subgrupuri
(taxe) care sunt mutual exclusive, neambigue și care, luate împreună, includ toate
posibilitățile. În practică o taxononie bună ar trebui să fie simplă ușor de ținut minte și
ușor de folosit.
Una dintre cele mai bune taxonomii este cea divizată de omul de știință suedez
Carl Linnaeus1, a cărui clasificări în biologie este viabilă și azi (cu modificări).
Un exemplu de taxonomie poate fi observat şi în figura următoare:
Figura 1.5. Exemplu de taxonomie.
Aplicaţii ale taxonomiilor
Structurile de taxonomii pot fi utilizate într-o varietate de feluri, ca de exemplu

în a-i ajuta pe cercetători să găsească materiale sursă, pe cititori să găsească informaţii
1
http://en.wikipedia.org/wiki/Carolus_Linnaeus, http://www.ucmp.berkeley.edu/history/linnaeus.html
într-o carte sau pe vizitatorii unui site web să găsească informaţii într-un jurnal
electronic. Taxonomiile sunt utilizate de cumpărători pentru a localiza produse şi
servicii, de manageri să găsească sursele de expertiză şi să construiască comunităţi de
practică ce includ experţi care lucrează în probleme de cercetare înrudite.
Structurile de taxonomii pot eficientiza procesele automatizate. De exemplu,
termenii taxonomici pot fi utilizaţi într-o interogare a unui motor de căutare pentru a
ajuta utilizatorii să găsească informaţiile mai uşor sau pot fi utilizaţi într-un program de
filtrare pentru a personaliza alertele de email sau site-urile web. Aplicaţiile
taxonomiilor au trei elemente cheie: oamenii, sarcinile şi sursele (conţinutului).
Trebuie să notăm că aceiaşi structură taxonomică poate servi în mai multe aplicaţii şi
poate fi aplicată diferitelor tipuri de conţinut (articole, cărţi, video, vorbire etc).
Un număr de companii, printre care Inxight Software, Mohomine şi Metacode
susţin că pot interpreta contextual semantic al oricărui document text şi să clasifice în
mod automat textul, din zbor. Acestea utilizează:
 Liste de termeni standard („maritim” în loc de „ocean”);
 Relaţii ierarhice („transport” este un termen subordonat „industrie”);
 Referinţe încrucişate (transportul pe barcă poate fi interpretat ca
„transport pe mare” sau „transport maritim”).
În ciuda acestor instrumente automatizate, cei mai mulţi analişti dezvoltă
taxonomii pa baza inteligenţei lor.
Într-o organizaţie o parte particulare de informaţie poate avea un număr diferit
de utilizări iar diferiţi angajaţi pot avea perspective diferite asupra părţii respective de
informaţie. De exemplu, presupunem încheierea unui contract cu un client. Unde ar
trebui să rezide această informaţie în taxonomia organizaţiei? Răspunsul depinde de
cine caută informaţia respectivă. Departamentul juridic va spune ca acel contract ar
trebui să rezide în categoria contracte ale acelui client. Din cauză ca acel contract
reprezintă şi un activ contabil, departamentul de contabilitate ar sugera înregistrarea
în categoria active. În cele din urmă, departamentul de vânzări ar vedea documentul
înregistrat ca parte a relaţiei cu clientul.
Mai mult, multe portaluri din ziua de astăzi suportă facilitatea de a crea
taxonomii personalizate pentru un utilizator. Ne reamintim faptul că, deşi pot exista
vederi diferite asupra aceluiaşi document, numai un document fizic poate exista. În
general, portalul stochează numai documente care stochează metadate în
infrastructura organizaţiei, fiind astfel stocată locaţia fizică a documentului astfel încât
portalul să poată obţine documentul în momentul în care este cerut de utilizator.
Documentul real poate să rezide oriunde în infrastructura organizaţiei (server de
fişiere, bază de date, site-ul web al companiei sau într-o bază de date Lotus Notes, de
exemplu). Atât timp cât taxonomia urmăreşte documentul virtual într-un depozit de
documente, utilizatorii nu trebuie să aibă probleme în găsirea acelui document.
Documentele sunt partiţionate în grupări logice care sunt uşor de navigat.
Acestea permit utilizatorilor să găsească informaţia chiar dacă încep căutarea cu un
singur cuvânt. Categoriile dintr-o taxonomie se mută de la general către specific,
facilitând căutările iterative şi de adâncime prin care atât utilizatorii începători cât şi
cei avansaţi pot naviga rapid.
O categorie dintr-o taxonomie poate fi utilizată pentru a limita scopul căutării,
reducând astfel numărul de documente irelevante returnate. De asemenea, categoria
facilitează navigarea în conţinut, permițând utilizatorilor să traverseze un număr mare
de documente înrudite.
Informaţia este filtrată pe baza atributelor din fiecare categorie. Taxonomia
dintr-un portal este creată pentru a prinde toată informaţia din acel porta şi de a o
plasa în locurile potrivite în taxonomia organizaţiei.
Taxonomiile oferă flexibilitate în regăsirea conţinutului. Una din problemele
centrale legate de găsirea informaţiei este faptul că un cuvânt poate avea mai multe
înţelesuri. Ambiguitatea unei limbi face căutarea mai dificilă deoarece sunt omise
obiecte care sunt marcate cu cuvinte diferite dar înrudite, sau sunt aduse pe ecranul
utilizatorului rezultate eronate un cuvânt cu sens prea larg a fost asignat unor obiecte.
Implementarea unei taxonomii
Există, în general, trei modalităţi de creare a taxonomiilor:

 Crearea automată a taxonomiilor şi clasificarea automată a documentelor;
 Crearea manuală a taxonomiilor de către oameni;
 Creare asistată a taxonomiilor şi clasificarea asistată a documentelor.
În cazul unui proiect două sau chiar toate trei modalităţile de abordare pot
aduce beneficii. Trebuie ţinut cont de faptul că, taxonomia nu este completă atît timp
cît se adaugă conţinut nou, acestea evoluând în timp ca răspuns la cererile de
schimbare venite din partea utilizatorilor.
Crearea automată a taxonomiilor
În ultimul timp au fost dezvoltaţi un număr de algoritmi care să permită

clasificarea depozitelor de date. Într-un studiu efectuat de Delphi Group1 au fost
identificaţi mai mulţi algoritmi de bază, printre care:
 Analiză lingvistică – identifică subiect, verbe şi obiectele unei fraze şi le
analizează pentru a le extrage înţelesul;
 Analiza statistică a textului – măsoară frecvenţa apariţiei cuvintelor,
plasarea lor, gruparea şi distanţa dintre cuvintele unui document;
 Taxonomii bazate pe reguli – clasifică documentele pe baza regulilor create
şi întreţinute de experţi; utilizează expresii de tip „dacă – atunci” care
măsoară cât de bine se încadrează un document într-o categorie.
Chiar şi furnizorii de instrumente de clasificare automată au conchis faptul că

judecata umană este esenţială pentru finalizarea unei taxonomii. Instrumentele
acestora reduc timpii şi costurile, permiţând şi găsirea de şabloane în date care nu sunt
evidente pentru analişti.
1
Taxonomy and Content Classification: Market Milestone Report," April 11, 2002
Produs Furnizor Observaţii

BrainEKP (Enterprise Knowledge The Brain Technologies Prezintă vizualizări inovative de
Platform) taxonomii
IDOL Server Autonomy Corp
Inxight Categorizer Inxight Utilizează analiză statistică şi
lingvistică
SemioTaxonomy Entrieva Colecţie de 27 de taxonomii
preconstruite
Stratify Classification Server Stratify Inc Utilizează analiză statistică şi
lingvistică, tehnici de clustering
statistic
Crearea manuală a taxonomiilor
A doua modalitate de abordare este de a permite unui specialist în taxonomii să

formuleze şi să dezvolte taxonomia portalului. Această abordare poate fi scumpă şi
consumatoare de timp, dar organizaţia ar beneficia de expertiza şi experienţa unui
analist. Unul din riscuri este acela că taxonomia s-ar putea dezvolta şi absorbi prea
multe resurse ale proiectului unui portal şi ar face-o prea dificil de continuat până la
capăt astfel încât să se încadreze în planificare.
Crearea asistată a taxonomiei
Această abordare este un hibrid între primele două, presupunând analiza

umană în concordanţă cu instrumente de căutare şi clasificare automată. Există multe
surse de date care pot ajuta în dezvoltarea unei taxonomii: jurnale ale interogărilor de
căutare, analiza cererilor din depozit, rezultate ale unui focus grup, rezultate ale
interviurilor, chestionare. Toate acestea reprezintă indicatori ale tipului de conţinut
dorit de fiecare segment de angajaţi împreună cu planificarea acestuia. Aceste surse
pot specifica şi comportamentul de căutare al angajaţilor, metodele de acces (căutare
sau navigare), puncte de acces (elementele de metadate) care ar trebuie utilizate în
taxonomiile descriptive şi de navigare.
Valoarea unei taxonomii
Cunoştinţele reprezintă valoare iar organizaţia care deţine cunoştinţele

potrivite obţine avantaj competitive. Problema existent astăzi nu este aceea că
informaţia nu există, ci aceea că nu poate localiza informaţia rapid şi eficient. Analiştii
estimează că peste 80% din informaţia unei organizaţii există într-un format
nestructurat, sub formă de notiţe ale întâlnirilor, de exemplu. Această informaţie se
acumulează într-un ritm accelerat, pe măsură ce, din ce în ce mai multe organizaţii îşi
transferă înregistrările în calculatoare şi în documentele electronice gestionate de
aplicaţii de DM. Datele şi informaţiile adaugă doar o mică valoare unei organizaţii
deoarece doar cunoştinţele îi dau acesteia putere şi avantaj competitiv. Dar informaţia
necesită un context pentru a deveni cunoştinţe, iar aceste cunoştinţe trebuie să ajungă
în mâinile celor care pot să o utilizeze.
Exemplu1
Termenul „taxonomie” a fost utilizat extrem de mult, astfel încât, atunci când
ceva este numit ca şi taxonomie, acel lucru poate fi, de fapt, orice, deşi în realitate
înseamnă un fel de structură abstractă.
Figura 1.6 – Taxonomie.
Imaginea de mai sus arată plasarea „topic map” într-o structură taxonomică
ipotetică. După cum se poate observa, structura poate ajuta pe cineva care caută
informaţii despre „topic map” sau clasificarea documentelor legate de „topic map” să
utilizeze termenii potriviţi.
Observăm faptul că taxonomia ajută utilizatorii să descrie subiectele; din
punctul de vedere metadatelor nu există diferenţă între un vocabular simplu şi
controlat şi o taxonomie. Metadatele leagă obiectele de subiecte în timp ce aici
subiectele au fost aranjate într-o ierarhie. Deci, o taxonomie descrie subiectele
utilizate pentru clasificare dar nu însăşi metadatele; totuşi, poate fi utilizată în
metadate. Acest lucru este ilustrat în figura următoare:
Figura 1.7 – Taxonomie şi metadate.
1
http://www.ontopia.net/topicmaps/materials/tm-vs-thesauri.html
În această diagramă, liniile albastre reprezintă metadate în timp ce liniile negre,

care creează taxonomia, sunt parte a schemei de clasificare bazată pe subiect.
Distincţia derivă din liniile albastre care sunt aserţiuni despre lucrare dar linia neagră
dintre “topic map” şi “knowledge representation” nu reprezintă o aserţiune despre
lucrare, fiind una despre “topic map”. O consecinţă este faptul că, dacă avem o altă
lucrare despre “topic map”, nu trebuie să repetăm faptul că “topic map” aparţine
ierarhic de “knowledge representation”.
După cum am menţionat, taxonomia oferă mai multe informaţii despre
concepte, ajutând astfel utilizatorii. Totuşi, chiar dacă o taxonomie ajută utilizatorul,
există un număr de informaţii despre concepte care nu sunt capturate aici, după cum
urmează:
 Faptul că „XML Topic Maps” este sinonim cu “XTM”;
 Diferenţa între XTM şi „topic map”;
 Relaţia dintre „topic maps” şi clasificarea bazată pe subiect, şi „topic
map” şi web-ul semantic;
 Relaţia dintre XTM, XML, TMCL, şi HyTM;
Toate acestea au consecinţe asupra utilizatorilor, deoarece înseamnă că aceştia
trebuie să caute folosind termenul exact, să caute în locurile precise pentru a găsi
termenul etc. O taxonomie precum cea definită în exemplul de mai sus nu poate
gestiona problemele de mai sus, deşi trebuie să notăm că multe sisteme la care ne
referim ca taxonomii pot să extindă modelul de bază definit aici.
1.4. ŞABLOANE
Şablonul este un termen folositor pe care multe persoane îl asociază cu

modelul de prezentare decât cu ceea ce reprezintă el, un tip structural. Mulţi
producători folosesc acest termen pentru a se referi la şabloane logice, lucru foarte
adevărat, în dezvoltarea softului tradiţional, dar devine foarte confuz dacă se face
referire la lumea web, unde şabloanele sunt asociate cu un layout.
Se folosesc mai ales în HTML, unde acestea înlocuiesc componentele
conţinutului. Depinzând de implementare, şabloanele pot avea înlocuitori pentru alte
şabloane, permiţând într-o abordare modulară, dezvoltarea aspectul unui site web.
Tipuri diferite de componente ale conţinutului pot cere şabloane specifice pentru a fi
plasate într-o pagina web.
Motoare de şabloane
Figura 1.8 – Motor de şabloane.
Conţinutul (dintr-o bază de date) şi “specificaţiile prezentării”( într-un şablon de

web) sunt combinate (printr-un motor şablon) pentru producerea în masă de
documente web.
Un motor şablon de web reprezintă un software care este menit să proceseze
şabloanele web şi informaţiile legate de conţinut pentru a produce documente web. El
rulează în contextul unui sistem de şabloane. Conform 1, un sistem de şabloane descrie
aplicaţiile şi metodologiile utilizate pentru producerea de pagini web, pentru lansarea
(publicarea) acestora în site-uri web şi transmiterea lor prin Internet. Asemenea sistem
procesează şabloanele web folosind motoare de şabloane. În sistemele de gestiune a
conţinutului, a cadrelor de lucru sau a editoarelor HTML, sistemul de şabloane web
este reprezentat de instrumentul de publicare pe web.
1
http://en.wikipedia.org/wiki/Web_template_system, preluat 26 ianuarie 2008
Tipuri de motoare şablon
De obicei, un motor şablon face parte dintr-un sistem şablon de web sau un
cadru de lucru şi poate fi utilizat ca şi un pre-processor, filtru sau procesor de şabloane.
In mod curent, software-ul de procesare a şabloanelor este în mod frecvent utilizat în
contextul dezvoltării web-ului.
XSTL este un model de procesare a şabloanelor realizat de către W3C 1, fiind
realizat în primul rând pentru transformările din datele XML în documente web sau
alte output-uri.
Limbajele de programare ca PERL, RUBY, C şi JAVA susţin procesarea
şabloanelor fie nativ, fie prin bibliotecile add-on şi diverse module. JavaServer Pages
(JSP), PHP şi Active Server Pages (ASP cu VBScript, Jscript sau alte limbaje) sunt
considerate motoare de şabloane web.
Caracteristici
Motoarele şablon tipice au caracteristici comune la un nivel superior de

programare a limbajului, cu accent asupra facilităţilor de procesare a textului simplu.
Aceste caracteristici includ:
 Variabile şi funcţii;
 Înlocuiri de text;
 Includeri de fişiere (şi includeri prin referinţă);
 Evaluări condiţionale şi bucle.
Exemplu de şablon web
Exemplul următor ilustrează un proces simplificat pentru un model tipic de

motor şablon web. Motorul şablon produce o pagina web prin procesarea sursei
şablonului web împreună cu datele dintr-o bază de date relaţională. Motorul de
şabloane înlocuieşte variabilele cu valori specifice; în ilustraţie, substituirea lui $x de
către conţinutul bazei de date (în pagina 01 “Mother”, în pagina 02 “World”).
Un exemplu de şablon web poate arata astfel:
<html>
<h1>Hello {$X}</h1>
</html>
Cu un conţinut adiţional de cod sursa şablon.
templateAssign ('X', 'World');
... sau când se specifică contextul bazei de date relaţionale:
1
http://www.w3.org/TR/xslt, XSL Transformation
$data[01]='Mother'; $data[02]='World';
templateAssign('X', $data[$i]);
Beneficii de utilizare a motoarelor şablon
 Încurajarea organizării codului sursă în niveluri operaţionale distincte;

 Sporesc productivitatea prin reducerea reproducerilor şi eforturilor
inutile;
 Dezvoltă lucrul în echipă prin separarea muncii după setul de aptitudini
(artistic faţă de tehnic, de exemplu);
Procesorul şablon
Figura 1.9 – Procesor de şabloane.
O diagrama ilustrativă a tuturor elementelor de baza şi a fluxului de procesare a unui

motor şablon
Un procesor de şabloane (cunoscut ca şi motor de şablon sau parser) este un

software sau o componentă software menită pentru a combina unul sau mai multe
şabloane cu un model de date, pentru a produce unul sau mai multe documente
rezultate. Un document rezultat este orice fel de output formatat, incluzând
documente, pagini web sau cod sursă, toate acestea fie luate ca un întreg, fie
fragmentat.
Elementele sistemului
Toate sistemele de procese şablon cuprind cel puţin următoarele elemente

primare:
 Un model de date asociat;
 Unul sau mai multe şabloane sursă;
 Un procesor sau un motor de şabloane;
 O ieşire generată în formă de documente rezultate.
Modelul de date
Aceasta poate fi o bază de date relaţională, un fişier precum XML, un alt

format de bază de date, un tabel sau orice altă sursă de date preformatată. Unele
sisteme de procesare a şabloanelor pot utiliza un număr limitat de tipuri de date.
Altele sunt proiectate pentru o mai mare flexibilitate, acceptând astfel mai multe tipuri
de date.
Şablonul sursă
Şabloanele sursă sunt specificate în mod tradiţional:

 Conform unui limbaj de programare pre-existent;
 Conform unui limbaj şablon special definit;
 Conform trăsăturilor aplicaţiei gazdă;
 Conform unei combinaţii hibride a tuturor celor de mai sus.
Motorul şablon
Motorul şablon este responsabil pentru:

 Conectarea la un model de date;
 Procesarea codului din sursa şablonului;
 Direcţionarea informaţiilor de ieşire către un fişier text, stream-uri sau pipeline.
Documente Rezultate pot fi sub forma unui document întreg sau a unui fragment de
document.
Utilizare
Procesarea şabloanelor este folosită în contexte variate, pentru diferite scopuri.

Scopul de bază face referire la o aplicaţie software sau la motorul şablon în curs de
folosire. Deseori flexibilitatea sistemelor de procesare a şabloanelor oferă foloase
neconvenţionale pe care designer-ii nu le-au anticipat iniţial.
Documentele generate
Cadrul de generare a documentelor se foloseşte de procesarea şabloanelor ca

un model central de producere a documentelor.
Coduri sursă generate
Instrumentele utilizate în generarea codului sursă susţin generarea de cod

sursă (ca documentele rezultate) din modele abstracte de date (de exemplu din UML,
date relaţionale, date stocate în diverse aplicaţii de întreprindere) pentru domenii de
aplicaţii particulare, organizaţii particulare, sau în simplificarea procesului de producţie
pentru programatori.
Funcţionalitatea aplicaţiei
Un motor şablon de web procesează şabloanele web şi datele sursă (dintr-o

bază de date relaţională) în scopul de a produce una sau mai multe pagini web de
ieşire sau fragmente de pagini web de ieşire. El apare ca parte integrantă într-un
sistem de şabloane web sau cadru de lucru pentru aplicaţii. Astăzi, software-ul de
procesare a şabloanelor este mult mai utilizat în contextul dezvoltării web.
Comparaţie
XSTL este un model de procesare a şabloanelor realizat de către W3C. Este

realizat în primul rând pentru transformările din datele XML (în documente web sau
alte ieşiri).
Limbajele de programare ca PERL, RUBY, C şi JAVA susțin procesele şablon fie
nativ, fie prin biblioteci add-on (pentru adăugare) şi diverse module. JavaServer Pages
(JSP) şi Active Server Pages, sunt exemple de motoare şablon făcute special pentru
dezvoltarea aplicaţiilor web. În plus, procesarea şabloanelor este inclusă câteodată ca
şi subcaracteristică în pachete software de tipul editoarelor de text, medii de
dezvoltare IDE şi sisteme manageriale de baze de date relaţionale.
Sistemul de şabloane web
Figura 1.10 – Sistemul de şabloane Web.
Fluxul de date ilustrează elementele de baza ale unui sistem şablon.
Sistemele şablon reprezintă o îmbinare între şablon, motoare şablon şi o echipă

de utilizatori finali ai sistemului, la producerea documentelor de ieşire. Ele sunt
sisteme pentru dezvoltarea software dar şi pentru publicarea proceselor. In general,
ele conţin mai multe subsisteme care le ajută în utilizarea altor sisteme.
Un sistem de şabloane web cuprinde următoarele:
 Un motor şablon: software, când se procesează o intrare anume,
transformându-se într-o ieşire anume, care are două ieşiri furnizoare de:
o resursă şablon: furnizează şablonul şi biblioteca şablon specifică;
o resursă de date: un furnizor de intrare, de exemplu o baza de
date în SQL sau un fişier XML, locale sau mutate.
 Un limbaj de şablon, un model de date de intrare şi un model de date de
ieşire standard.
Folosire şi tipuri de sisteme
Sistemele de şabloane sunt utilizate în contexte variate, pentru diferite scopuri.

Scopul de bază face referire la o aplicaţie software sau la motorul şablon în curs de
folosire. Deseori, flexibilitatea sistemelor de procesare a şabloanelor oferă foloase
neconvenţionale pentru care, iniţial, designerii nu le-au anticipat.
Documentele generate
Cadrele de documente generate folosesc, in mod obişnuit, procese şablon ca

model central de generare a documentelor. Şablonul şi ieşirile motorului sunt privite ca
documente. Există multe tipuri de sisteme de şabloane de “documente-centrale” şi pot
fi grupate în următorul mod:
 Sisteme şablon de web care sunt folosite în contexte web, pentru pagini
web sau pentru producerea documentelor web.
 Subsisteme de procesare a cuvintelor;
 Subsisteme de expediere a listelor;
 Subsisteme de generări automate de documentaţii software;
 Subsisteme de publicaţii desktop folosind pagini master şi style sheets.
Exemplu: sisteme bazate pe limbaj macro TeX.
 Tehnologii de publicare a paginilor dinamice care utilizează şabloane de
editare care generează colateral, adăugiri, trimitere directă şi alte
documente.
 Subsisteme de publicare (raportare) a bazelor de date şi intrări automate
ale conţinutului în documente publicate desktop.
 “Documente-centrale XML” ale şablonului sistem. Au loc unele suprapuneri
cu web-ul deoarece XML era la început un standard web; exista şi alte
suprapuneri, deoarece XML poate fi/este formatul standard pentru toate
acestea.
Generarea codului sursă
Instrumente pentru generarea codului sursă suportă generări de cod sursă (ca
şi documente rezultate) de la modele abstracte de date (ex: UML, date relaţionale,
stocări de date specifice unui domeniu dintr-o organizaţie) pentru domenii de aplicații
particulare, organizaţii particulare, sau in simplificarea procesului de producere pentru
programatori.
Sisteme de generare a codului sursă
Acestea sunt centrate asupra aplicaţiilor (de obicei un compilator) şi partea de

motor din sistem: preprocesorul şi codul sursă al motorului şablon sunt exemplele de
baza. Se pot avea în vedere şi: şablon (programare), şablon (software) şi şablon
(metaprogramare).
1.5. PUBLICAŢII
Scopul unui sistem de gestiune a conţinutului este acela de a crea publicaţiile

dorite de audienţă. Deşi în trecut cele mai multe sisteme putea crea un sigur site web,
astăzi cele mai multe pot gestiona site-uri web multiple, mai multe materiale pentru
imprimare precum şi un număr mare de tipuri de publicaţii, precum cele pentru
sindicalizare sau pentru diverse dispozitive.
Definiţia din Merriam-Webster OnLine (at www.m-w.com) precizează faptul că

“publicare” înseamnă:
1.a) a face general cunoscut;b) a face anunţuri publice; 2.a) a împărtăşi

publicului; b) a produce sau a lansa pentru distribuţie.
Dacă s-ar putea extinde aceste definiţii, s-ar putea spune că publicare poate
însemna şi audienţă. Dar, în mod cert, anumite publicaţii nu sunt publice. Multe din
publicaţiile din cadrul unei afaceri se restricţionează la un anumit grup de oameni (de
obicei la personal, parteneri sau cei care plătesc).
„A publica” înseamnă a lansa informații. Pe baza definiţiei de mai sus, orice
conţinut disponibil unor persoane reprezintă o publicaţie. Definiţia se poate închide
sau restrînge prin specificarea faptului că o publicaţie reprezintă informaţia făcută
disponibilă, care este unificată şi care are următoarele caracteristici:
 Are un scop: în plus faţă de scopul pentru care se creează fiecare publicaţie,
trebuie determinat modul în care fiecare scop al publicaţiei se leagă de
obiectivele întregului sistem şi de a celorlalte publicaţii produse de sistem;
 Editorii: trebuie creată o echipă responsabilă cu continuarea compoziţiei,
testarea şi lansarea publicaţiilor şi să se decidă cum să interacţioneze cu echipa
sistemului CMS;
 O audientă: în plus faţă de decizia cu privire la persoanele pe care le deserveşte
fiecare publicaţie,trebuie relaţionată audienţa acesteia cu alte entităţi din CMS;
 Un set de mesaje: pentru asigurarea ca fiecare publicaţie a atins precis
audienţa dedicată ei, trebuiesc definite modurile prin care publicaţia este
transmisă, cu o bună înfățișare şi cu mesaj convingător;
 Calitatea de autor: pentru fiecare publicaţie (presupunând că are mai mulţi
autori, ca în cazul sistemului CMS), trebuie decis care dintre aceştia să fie citat
ca autor al întregii publicaţii şi care au atribuţii în cadrul publicaţiei;
 Conţinut: trebuie să se decidă care clase de componente să fie incluse în
publicaţie. Dacă nu se intenţionează publicarea fiecărei instanţe a unei clase,
atunci trebuie găsită metadata care separă instanţele, pentru a separa
instanţele care să se includă de cele care să nu fie;
 Structură: în plus faţă de deciderea principiilor generale, indexul, încrucişarea
de referinţe şi structura de navigare a publicaţiei, trebuie decis modul în care
fiecare dintre aceste structuri sunt relaţionate cu structurile CMS de acelaşi tip.
Se pot obţine principiile generale ale publicaţiei din schiţa conţinutului care
deţine toate componentele, de exemplu, sau trebuie găsită o altă modalitate
de a genera cuprinsul publicaţiei?
 Cicluri: Ca şi intrare a modulului de workflow, trebuie stabilit cât de des trebuie
publicaţia să fie reîmprospătată, marcată ca o nouă versiune şi revăzută ca
proiect de bază şi de construcţie.
Figura 1.11 – Ciclul de viaţă al unei publicaţii.
Aceste calităţi care sunt date informaţiilor lansate, se unesc şi ajung într-o
comunicare inteligibilă care are greutate şi autoritate. Deşi aceste calităţi sunt
importante, utilizatorii de obicei le neglijează (le cunosc dar le uită).
Scopul publicaţiei
De obicei, nimeni nu se deranjează să întrebe “De ce se doreste un intranet?” şi

nimeni nu observă că nu se întreabă acest lucru. Bineînţeles că fiecare publicaţie are
un rost. De ce oare oamenii uită adesea scopul publicaţiilor electronice? Aici sunt
descrise două dintre motivele pentru care ar uita:
o nevoile proiectului sunt slabe şi vagi - nimeni nu se gândește la scopul
proiectului - tehnologia este câteodată prea sofisticată şi oamenii care
creează aceste publicaţii sunt confuzi încă înaintea primei întâlniri;
o viaţa la frontiera electronică se desfăşoară rapid - tehnologia avansată
care se mişcă rapid încât oamenii uită să înceapă cu începutul şi uită ce
au stabilit săptămâna trecută. Se întâmplă ca oamenii să înceapă cu
mijlocul procesului şi să intre direct în detalii.
Fiecare autor ştie care este scopul publicaţiei lui – de exemplu pentru scriitori
(editori) este acela de a obţine profit de pe urma vânzării cărţilor. Pentru reviste, este
acela să obţină profit din promovarea conţinutului către un grup de oameni ţintă.
Indiferent de obiectivele lor, editorii clasici ştiu să adune, să controleze şi să publice
conţinutul pentru a-şi atinge scopurile.
Scopul adevărat se poate comunica în câteva fraze. Dacă cineva le aude,
persoana respectivă poate să-şi imagineze imediat ce face part din conţinut şi ce nu,
sau dacă conţinutul este interesant sau nu pentru el precum şi ce întrebări şi interese
va satisface.
Editorii
Editorii sunt oamenii din spatele publicaţiilor care depun timp şi efort pentru a
asigura lansarea publicaţiilor. Grupul de publicare poate sau poate să nu includă autorii
conţinutului. Intr-o lume a sistemelor de informaţionale ale corporaţiilor, autorii sunt
rareori cei care le publică. Cei care le publică de obicei sunt un grup mic de experţi
tehnici şi de editare care preiau ce au creat autorii şi transformă acest conţinut într-un
site web sau alte tipuri de publicaţii.
Înainte ca sistemul să fie lansat, cei care publică reprezintă echipa care se
ocupă cu proiectul CMS. După ce sistemul este terminat şi rulează, echipa care se
ocupă cu proiectul trebuie să se transforme într-o echipă de publicare care asigură
faptul că fiecare publicaţie continuă să funcţioneze şi să fie disponibilă audienţei sale.
Cei care publică se asigură că publicaţiile îşi îndeplinesc scopul şi, în lumea electronică,
se asigură că publicaţia “merge” (nu clachează sau „se strică”). O singură publicaţie
poate avea are următorul “personal”:
 personalul managerial: managerii sunt responsabili cu afacerea

publicaţiei (costuri, personal, venituri);
 personalul editorial: editorii sunt responsabili cu crearea sau obţinerea
conţinutului şi pregătirea lui pentru publicaţie;
 personalul tehnic: aceştia sunt responsabili cu construirea sistemului
care adună, controlează şi publică conţinutul;
 personalul creativ: aceştia sunt responsabili cu înfățișarea şi aspectul
publicaţiei, la fel şi cu farmecul şi capacitatea de a impresiona publicul
ţintă;
 personalul arhitectural: aceştia se plasează cumva între cei editoriali,
tehnici şi creativi, fiind responsabili cu alcătuirea structurală a sistemului
conţinutului şi a conţinutului însuşi.
Într-un CMS aceste resurse se vor partaja între publicaţii, creând eficienţă de-a
lungul acestora dar şi poate însemna faptul că oamenii pot să-şi piardă concentrarea
asupra publicaţiilor deoarece grija principală este sistemul. Acest ultim lucru se poate
evita prin crearea unei imagini asupra sistemului specificându-i doar rolul de obiect de
bază în crearea publicaţiilor interesante.
Audienţa
O publicaţie reprezintă o conversaţie asincronă. Nu are loc în timp real. In timp

ce scriu, autorii îşi imaginează ce vor gândi cititorii şi le răspund în frazele următoarele.
Apoi, după ce au citit lucrarea, cititorii răspund în mintea lor la cuvintele autorului.
In realitate, o calitate a unei munci interesante este aceea ca se realizează o
interacţiune “pe viu” între autor şi cititor. Dacă fiecare publicaţie are un autor, atunci şi
fiecare autor are audienţa lui. In plus, dacă la publicaţiile electronice se uită aprecierea
autorului, atunci se uită şi aprecierea audienţei.
Intr-o lume a publicaţiilor electronice, nu este uşoară doar înţelegerea unei
singure audienţe, în primul rând pentru că publicaţiile electronice pot atinge o masă
vastă de oameni. Să se determine care sunt persoanele vizate pentru aceste publicaţii
nu este uşor. In al doilea rând, se deține o capacitate tehnica de a detecta şi a
înregistra profilul personal al fiecărui utilizator. Prin utilizarea acestei informaţii se
poate adapta o publicaţie, din punct de vedere teoretic, fiecărei persoane, creînd astfel
la fel de multe audienţe ca şi număr de utilizatori.
Mulţi editori de publicaţii electronice sunt de părere că audienţa e greu de
definit. Aceştia uită des că adevărata audienţă nu este compusă din cei care îi
contactează ci din cei pe care doresc să-i aibă ca ţintă. Tot timpul trebuie să se aibă în
vedere un grup de oameni pentru care se arată interesul major şi alte grupuri pentru
care se arată mai puţin interesul.
Faptul că fiecare utilizator poate face parte din target şi faptul că o publicaţie
nu se adresează oricui poate apărea ca şi o contradicţie, dar nu este aşa. In realitate,
ultimul depinde de primul lucru. Dacă nu se limitează această audienţă îndeajuns,
atunci nu se va şti ce doresc utilizatorii, nu se pot aduna informaţii despre fiecare în
parte şi nu se va putea segmenta conţinutul oferit.
Un studiu de caz pentru Mesaje
Dacă o publicaţie este o conversaţie, atunci se pot lua aceste mesaje date de
publicaţii. Se consideră următoarea conversaţie ipotetica între Laura şi o serie de site-
uri pe care acesta le vizitează:
Laura: (Vizitează site-ul 1) Pot sa cumpăr un cartuş de pe acest site?

Site 1: Click aici pentru a cîştiga o vacanţă pentru doi! Apropo, acest site este despre
imprimante.
Laura: Următorul site. (Click-uri către site-ul 2.)

Laura: Pot sa cumpăr un cartuş de pe acest site ?
Site 2: Bine aţi venit în Lumea Imprimantelor. Cunoaştem totul despre imprimante şi
dorim să vă împărtăşim şi vouă aceste informaţii. Experţii noştri caută informaţii
despre imprimante pe glob şi o prezintă aici. Click aici pentru mai multe...
Laura: Acest lucru înseamnă că vindeţi cartuşe de imprimantă? (Click pe link-ul
prezentat de site.)
Site 2: Cu mai multe de 200 de experţi contributori, noi ştim despre ce vorbim. Ce
doriţi? Intrebări frecvente despre imprimante? Specificaţii de imprimante? Părţi din
imprimante?
Laura: Poate e pe unde în Părţi din imprimante? Las-o baltă! Următorul site. (Click la
site-ul 3.)
Laura: Pot să cumpăr un cartuş de pe acest site?

Site 3: Suntem Oraşul Imprimantelor. Ce doriţi pentru imprimanta Dvs? Driver-e?
Consumabile? O imprimantă nouă?
Laura: Consumabile, cred. (Click pe link-ul Consumabile.)
Site 3: Alegeţi numele imprimantei şi al consumabilului pe care-l doriţi şi noi o să-l
căutăm pentru Dvs.
Laura: Hei, ce fel de imprimantă am? Ceva HP….
Site 3: Nu vă reamintiţi ce model? Click aici…
Laura: (Click pe ecranul următor) Da, asta e. E modelul ABC.
Site 3: Avem cartuşe din modelul dorit.
Laura: Voi cumpăra 2.
Laura încearcă să aibă o conversaţie cu fiecare site vizitat. Site-ul nr. 1 o ignoră
complet, aşa că trece peste el. Site-ul nr. 2 răspunde la întrebarea ei, dar nu într-un
mod care poate fi înţeles. Totuşi, are un răspuns, deci ea continuă conversaţia. Ea face
click şi se pune întrebarea iar. La acest site, Laura este dezamăgită pentru că nu i se
răspunde în conformitate cu problemele ei şi trece la următorul. Site-ul nr. 3 răspunde
la prima întrebare destul de bine ca să o facă pe aceasta să-şi mărească interesul şi să
continue conversaţia. Acest site o ajută să-şi dea seama ce fel de imprimantă are şi
astfel să facă rost de cele 2 cartuşuri, şi să plece satisfăcută.
Primele doua site-uri sunt rele? Pentru Laura au fost. Site-urile nu au putut
răspunde la întrebările Laurei, şi atunci aceasta a încetat conversaţia. Pentru cineva
care vroia să câștige o vacanţă, primul site avea dialogul cel mai bine pregătit. Pentru
cineva care avea probleme la imprimante site-ul 2 era cel mai potrivit. Pentru persoane
care caută cartuşe, site-ul 3 era cel mai potrivit.
Un site sau alte publicaţii oferă mesaje indiferent dacă se doreşte acest lucru
sau nu. Aici se găsesc câteva întrebări pe care audienţa le poate pune publicaţiei
respective:
 Ce eşti? – întrebarea fundamentală, prin care oamenii doresc să afle de cel

de publicaţie este, dacă se găsesc în locul potrivit (tipul publicaţiei
prezentate – comercială, de informaţii, politică etc)
 Ce ai în conţinut?
 Eşti dedicat oamenilor din clasa mea?
 Această publicaţie îmi merită timpul, efortul şi banii?
 Mesajele instant - formează o impresie din prima clipă, fiind una neverbală
(culori, densitatea informaţiei, aşezarea în pagină, stil);
 Mesajul scurt şi concis - se stabileşte dacă se merită efortul de a continua
într-un timp de 5 pînă la 30 de secunde;
 Mesajul pe termen mediu - dacă se tot pun întrebări şi conţinutul nu
răspunde la ele, atunci utilizatorul părăseşte publicaţia;
 Mesajul pe termen lung - dacă se pun întrebări şi se răspunde atât cât să
menţină curiozitatea şi interesul audienţei, atunci conversaţia continuă;
O publicaţie care doreşte să-şi menţină audienţa trebuie să anticipeze

întrebările acesteia şi răspunsurile pe care se aşteaptă să le audă.
Calitatea de autor
Fiecare lucrare publicată provine de undeva. Niciodată nu se vor citi, privi sau
asculta fără a avea consideraţie faţă de cel care a creat-o. Ce se întâmplă dacă o
publicaţie nu e “semnată” de nici o persoană? Atunci se va găsi calitatea de autor la
motorul de căutare al site-ului Google? La prima privire, răspunsul este “nu”. Google
nu creează conţinutul, ci doar îl expune. Google reprezintă un punct de agregare unde
toată lumea îşi expune publicaţia. Google este autorul site-ului lui. Dacă nu se găseşte
ce se caută, se pune vina pe cineva? Google, de exemplu este un nume răspândit.
Calitatea de autor este o parte flexibilă a contextului la care oamenii pun în jurul lui
orice conţinut pentru a-i determina credibilitatea şi înţelesul.
Putem considera următoarele propoziţii:
Lumea este plată. - Joe Nimeni (un tip de care te loveşti pe stradă)
Lumea este plată. - Alan Greenspan (Preşedintele U.S. Federal Reserve)
In primul caz, se va crede că acest comentariu este despre geografie dar nu se

va crede conţinutul. In al doilea caz, (dacă se ştie ca Alan Greenspan este un faimos
economist) se va crede că acest comentariu este despre o performanţă financiara şi
conţinutul poate este mai credibil ca primul comentariu. Cum poate face editorul să se
lămurească aceste lucruri?
 Să nu omită problema calităţii de autor a publicaţiei sale; (să o rezolve
înainte ca utilizatorii să o rezolve pentru el);
 Să se asigure că citează şi spune despre profilurile autorilor cât mai mult
posibil. (bibliografia bine pusă la punct, pentru ca audienta să creadă ce se
scrie în publicaţie).
Forma publicaţiei
Forma publicaţiei poate avea doua înţelesuri: modul în care este codată
informaţia şi codurile care sunt folosite în vizualizarea informaţiei transmise. O
publicaţie are nevoie de ambele forme.
In general, un site web foloseşte un sistem de tip ASCII pentru a stoca limbajul
HTML. Aproape fiecare procesor de cuvinte sau instrumente de aşezare în pagină
poate decodifica şi manipula ASCII. Codurile de formatare pe care HTML le utilizează
prin folosirea codului ASCII se codifică, dar trebuie să aibă loc şi un proces prin care să
se facă vizualizarea/transformarea acestora în informaţii. Browsere-le web şi variantele
recente de procesoare de cuvinte pot decodifica şi manipula codul HTML de formatare.
Structura publicaţiei
Până şi cea mai mică publicaţie are o structură. Chiar şi fluturaşii care anunţă
ceva anume au un scop şi o structură bine definită. Se pot vedea şi anumite detalii care
apar subordonate titlului şi care au o anumită mărime şi poziție. In final, se pot observa
şi indicaţii ale unui autor sau ofertantul flyer-lui. Totuși, daca ne referim la publicaţii,
cu cât sunt mai complexe, cu atât au o structura mai avansată.
Publicaţiile pot avea toate structurile de acces: ierarhii, indecşi, referinţe
încrucişate şi secvenţe. De asemenea, pot deţine şi toate metadatele de structură de la
caractere la grupuri de publicare. Intr-o perspectivă CMS, poate cea mai importantă
structură este “nodul”. Deşi structura cheie a unui sistem CMS este “componenta”,
cheia unitate a publicaţiei este “nodul”. Nodul este mărimea unităţii de bază a unei
publicaţii. In cadrul publicaţiilor web, această unitate este reprezentată de o pagină.
Deci, o publicaţie web este formată din mai multe pagini.
În majoritatea publicaţiilor electronice (aplicaţii CD-ROM, sisteme de asistenţă),
nodul reprezintă tot un fel de pagină. Este conţinutul care apare pe ecran ca o unitate.
îl poţi stoca într-un fişier sau bază de date, dar întotdeauna apare în faţa cititorului
publicaţiei ca o unitate.
In publicaţiile printate, nodul nu este uşor de identificat. De obicei, publicaţiile
printate depăşesc limitele dintre unităţi în favoarea abordării narative continue. Totuşi,
şi cele mai complexe romane au capitole. Fiecare pagină albă este un nod al paginii
albe în general. Cărţile mai bine structurate au conţinutul pe nivele variate de titluri,
care reprezintă o unitate mai mică a întregului conţinut. Revistele folosesc articolele ca
unitate de bază. Fiecare articol este un întreg mai mic al publicaţiei mari. Singurul
cuvânt care se aplică la publicaţiile imprimate în acelaşi mod în care cuvântul pagină se
aplică la publicaţiile electronice, este secţiunea.
Cel mai important la un sistem CMS este faptul că nodul este unitatea
publicaţiei pe care şablonul publicaţiei o creează. Dacă se rulează un şablon, rezultă un
nod al publicaţiei. Acest lucru se observă cel mai clar pe web, unde un şablon aproape
întotdeauna produce o pagină HTML. Este mult mai greu de observat la cele printate,
unde un şablon poate produce o bucată mare din publicaţie cu mai multe secţiuni.
Totuşi, în publicaţiile printate create de un sistem CMS, se observă nişte noduri
dimensionate produse de un singur şablon.
Dacă există mai mult de o publicaţie, trebuie avute în vedere trei structuri: câte
una pentru fiecare publicaţie şi încă una pentru conţinut, atunci când acesta nu se află
în nici o publicaţie. Ca să se producă mai mult de o publicaţie cu acelaşi conţinut bazat
pe un sistem CMS, conţinutul de bază trebuie să fie bine structurat, pentru a putea
deriva structura din publicaţia mai mică de la structura conţinutului de bază. Sau,
trebuie stocate structurile publicaţiei undeva în afara publicaţiei propriu-zise, unde
personalul sistemului CMS le poate actualiza şi edita.
Publicaţiile bune sau mai puţin
O bună publicaţie, folositoare, are următoarele caracteristici:

 Satisface o anumită nevoie: îşi stabileşte scopul şi tot conţinutul este în
conformitate cu acesta;
 Deserveşte o anumită audienţa: dacă utilizatorul înţelege conţinutul şi
comunicarea este familiară, atunci publicaţia este dedicată acestuia.
 Trebuie să fie uşor de folosit: este foarte bine structurată şi utilizatorul
îşi dă seama încă de la început dacă publicaţia conţine elementele
căutate de acesta;
O publicaţie mai puţin bună poate avea următoarele defecte:

 Nu este aplicabilă domeniului de interes;
 Nu este inteligibilă - utilizatorul găsește informaţia dar nu o poate
înţelege;
 Nu este accesibilă - utilizatorul ştie că informaţia pe care o caută este
acolo dar nu o poate găsi.
Primele două probleme privesc scopul şi audienţa. Dacă o publicaţie este utilă,
utilizatorul poate spune imediat dacă aceasta conţine arii de interes pentru el, iar dacă
face parte din audienţă, conţinutul poate fi înţelese de utilizator. Totuşi, pe web poate
apărea problema legăturilor între site-uri, care pot conduce utilizatorul direct în
mijlocul unei lucrări, ceea ce nu poate informa utilizatorul despre scopul şi audienţa
acesteia.
Cea de-a treia problemă este legată de navigarea către o publicaţie, care poate
apărea în cuprinsul site-ului dar nu există link-uri către publicaţia efectivă.
Publicaţiile şi şabloanele
Intr-un sistem CMS, şabloanele creează publicaţii. Un şablon scuteşte de munca

manuală de aşezare continuă a conţinutului în structuri particulare şi forme. Ar fi
împovărător să se ia înregistrările din baza de date sau elemente XML din depozitul
sistemului CMS şi să se transforme în pagini web sau pagini printate. Prin folosirea unui
şablon, se decide o singură dată care este modul în care se aşează în pagină şi se
formatează conţinutul, iar apoi se lasă computerul să facă el singur paginile sau
secţiunile de publicaţie.
Şabloanele uşurează procesul de creare a publicaţiilor din conţinutul nedefinit
al sistemului CMS.
In particular, un şablon are următoarele atribuţiuni:
 Leaga sistemul CMS de publicaţii – un şablon face legătura între CMS şi
structura şi formatul publicaţiilor care sunt create pe baza lui;
 Îmbină constituenţi statici cu cei dinamici: separă părțile din pagină sau
din secţiune care se schimbă de cele care nu se schimbă;
 Construiesc o pagină sau o secţiune dintr-o publicaţie: creează automat
părţi de publicaţie;
 Atrage publicaţia într-un sistem de publicaţii: împart cod şi conţinut

pentru a crea prezentări multiple ale aceleiaşi baze de informaţii şi
funcţionalităţi.
 Foloseşte logica: permit selectarea conţinutului dintr-un sistem CMS,
procesarea acestuia şi formatarea pentru vizualizare;
 Găzduiesc alte şabloane: fiecare pagină, secţiune sau zonă de navigare
poate avea propriul şablon.
Şabloanele mai trebuie să îndeplinească următoarele sarcini:
 Să creeze contextul publicaţiei – aspectul publicaţiei cade în sarcina şablonului

utilizat. Acesta cuprinde culori, aşezarea în pagină, imaginile care pot
„înconjura” conţinutul, branding-ul şi titulatura din publicaţie, fonturi şi alte
stiluri etc;
 Să producă formatarea publicaţiei – pe web acest lucru semnifică producerea
de HTML. Pentru imprimare pot exista, în schimb, mai multe limbaje
proprietare de marcare. Şablonul trebuie să translateze conţinutul neutru din
punct de vedere al formatului într-un conţinut rezultat corespunzător cu
publicaţia;
 Să producă structurile publicaţiei – şablonul trebuie să producă convenţiile de
structură pentru publicaţie, depozitul putînd, de exemplu, să stocheze doar o
structură încrucişată;
 Să stabilească publicul ţintă pentru care este dedicată publicaţia – în cazul
personalizării, şablonul trebuie să detecteze audienţa şi să producă pagini de
publicaţii şi de secţiuni pentru aceştia. Un şablon pentru o pagină web poate să
conţină, de exemplu, cod care să detecteze dacă un copil accesează pagina
respectivă schimbînd, în consecinţă, aspectul site-ului.
In final, pentru a lega publicaţia de sisteme externe, şabloanele trebuie:

 Să se conecteze - trebuie să reuşească să acceseze sistemul extern folosind
codul de programare corespunzător;
 Să interogheze - trebuie să ştie cum să ia datele din sistemele externe; de
exemplu, sistemul de card de credit poate folosi o structura SQL pentru
accesarea datelor, după ce şablonul s-a conectat la el;
 Să trimită date înapoi - trebuie să urmeze toate convenţiile pe care sistemul
extern le cere pentru primirea datelor din publicaţie; de exemplu, sistemul de
card de credit poate cere de la şablon un set de date de tranzacţie într-un şir de
caractere delimitat de virgule.
Publicarea fişierelor XML
Sistemul de publicare al CMS este responsabil pentru aducerea conţinutului

dintr-un loc de depozitare şi pentru formatarea lui în fişiere terminate. Un sistem de
publicare poate folosi limbajul XML pentru şablonare. Şabloanele sunt programe care
selectează conţinutul, îl formatează pentru prezentare şi integrează pagina publicată
cu alte programe (cu sisteme de comerţ electronic, de exemplu). Unele sisteme
întrebuinţează limbaje de programare open, de tipul: ASP.NET (standard Microsoft)
sau JSP/J2EE (standard Java) cât şi platforma de programare pentru şabloane. Aceste
sisteme open sunt “XML-agnostic” în care se poate alege să se relaţioneze cu XML, dar
nu sunt concepute să facă asta. Dacă se dorește întrebuinţarea uneltelor de tip XML,
de exemplu, DOM sau XSLT în sistemele open, trebuie adăugat “cod” care este în afara
domeniului normal al unui sistem de gestiune a conţinutului.
Alte sisteme întrebuinţează un limbaj de programare brevetat, pentru a duce la
bun sfârşit task-urile cerute de şabloane. Având în vedere acest domeniu brevetat,
unele sisteme folosesc XML pentru a reprezenta construcţiile lor de programare.
Parte din codul şablon al unui sistem particular poate arăta in acest mod:
<FIND type="PressRelease">
<WHERE>
Author=Jon Doe
</WHERE>
</FIND>
Sisteme care folosesc aceasta abordare pot cere pe drept ca sistemul lor de
şabloane să folosească standarde open ale XML-ului. Ele folosesc aceste standarde
pentru a crea un limbaj de programare al lor, care oricum trebuie învăţat. Se poate să
nu fie posibilă integrarea instrumentelor XML, DOM, XSLT în acest tip de sistem.
In final, unele produse CMS folosesc standarde de şabloane XML, XSLT. Pentru
că XSLT are XML ca un loc de plecare, sistemele care utilizează XSLT trebuie să stocheze
conţinutul doar în XML. In plus faţă de folosirea limbajului XML pentru a crea şabloane,
sistemul poate să nu fie capabil să publice limbajul XML transformat. Orice sistem CMS
care permite stocarea XML poate avea ca ieşire tot XML. Unele sisteme CMS de
publicare şi sindicalizare pot transforma codul XML care îl stochează (sub un DTD în
XML) sub un DTD diferit pentru sindicalizare sau publicare, la dispozitive care înțeleg
un DTD particular (unele pentru telefoane care au protocoale pentru aplicaţii wireless
sau e-books, de exemplu).
Crearea unui sistem de publicaţii
Şabloanele permit partajarea conţinutului şi codului într-o familie de publicaţii.

Pentru a realiza această partajare, trebuie lucrat în următoarele zone:
 Suprapunerea conţinutului: trebuie să se decidă felul în care conţinutul

fiecărei publicaţii se suprapune. De exemplu, cele mai bune practici pot să
apară şi în părţile laterale ale documentaţiei de training. Se poate, de
asemenea, stabili ca studiile de caz să apară intr-o formă mai scurtă;
 Suprapunerea design-ului: trebuie să se decidă modul în care forma fiecărei
publicaţii se suprapune. Se poate decide ca toate publicaţiile să aibă logo-ul
organizaţiei în colţul din dreapta-sus. Se poate crea o paletă de culori pe
care toate publicaţiile să o folosească.
 Modificarea proceselor: trebuie decis modul în care personalul şi echipa
care se ocupă cu procesele publicaţiei curente trebuie să se schimbe.
Folosind un sistem CMS se transformă aproape toate lucrările curente. Cei

responsabili cu conţinutul editorial al publicaţiei trebuie să lucreze în
contextul întregii colecţii de procese. Cei responsabili cu layoutul şi
producţia de publicaţii îşi desfăşoară activitatea nu în crearea publicaţiilor
terminate, ci în crearea de şabloane care încorporează standardele de
design ale organizaţiei şi care aduc conţinutul într-o formă modernă.
1.6. INDEXAREA ŞI CĂUTAREA CONŢINUTULUI
Indecşii
Un index reprezintă o lista ordonata de cuvinte şi expresii care clasifică un conţinut.

Termenul index înglobează următorii termeni:
 Cuvinte cheie: Oamenii folosesc des acest cuvânt, in special pe web, pentru a
face referire la o lista de termeni sau expresii dintre care se poate alege şi, prin
intermediul cărora, se poate sări la conţinutul care îl descriu. Această
operaţiune este cunoscuta ca o “căutare cu cuvinte cheie“ dar, de fapt, ea
reprezintă un index al cuvintelor cheie;
 Tezaur: acest termen se refera la utilizarea unui ghid al unor cuvinte alternative
sau sinonime în locul celor care sunt ştiute. Dacă se caută, de exemplu,
cuvântul “pantof”,computerul poate folosi o colecţie (tezaur) pentru a extinde
căutarea la expresia “încălţăminte” sau tipuri de încălţăminte (sanda, adidas,
tocuri etc.). Tezaurul poate fi văzut tot ca un fel de index care face legătura,
mapează între un set de cuvinte şi un alt set.
Pentru mulți experţi, cuvântul “index” şi tema care rulează între cuvinte cheie şi
tezaure este “harta”. Un index oferă o harta între cuvintele şi conceptele celui care
caută şi cele din sistem. Indexul de cuvinte cheie, de exemplu, este o harta între
cuvântul căutat in lista de căutare şi pagina web corespunzătoare. Tezaurul este o
harta între cuvântul ales şi toate celelalte cuvinte care ar fi putut fi alese daca s-ar
cunoaşte modul in care sistemul descrie conţinutul.
Scopul indexului este de a ghida utilizatorul de la cuvintele pe care le ştie către
cele pe care le caută.
Intr-un sistem CMS şi publicaţiile sale, indecşii au următoarele caracteristici:
 prezintă tot vocabularul: orice cuvânt sau expresie importanta din sistem
sau din publicaţie ar trebui sa apăra intr-un asemenea index;
 prezintă concepte: indecșii prezintă conceptele pe care sistemul sau
publicaţia le folosește. De exemplu, PLAN îşi poate indexa aparițiile de presă
sub termenul “programe de actiune împotriva sărăciei” chiar daca acea
expresie nu apare in aparitie;
 includ sinonime. Un index bun include de asemenea, şi vocabularul şi
conceptele audientei respective. Conceptele de “a se vedea si..” (see also)
conduc utilizatorul poate nu la aceiaşi expresie ci la expresiile sinonime din
sistem.
 ordonează vocabularul şi conceptele. Bineînțeles,cea mai populara ordine in
index este cea alfabetica. Dar sunt posibile şi multe altele. Indexări după
date, autor, locație, tipuri media, sau orice alta parte de metadata posibila
şi comuna.
Indexul de tipărire (așa cum apare in cele mai multe cărţi) este un dispozitiv de
indexare elegant şi folositor, pe care mulţi l-ar adopta, la fel ca pe un cuprins. O parte
din motivul pentru care nu este adoptat, este acela ca puţini pot scuti efortul extra
necesar pentru a pune laolaltă un index bun. Dar chiar şi acelea care includ o funcție
extinsa de cuvinte cheie in site-urile lor, de obicei omit câteva lucruri intr-un index de
tipărire:
 Ierarhia. Un index de carte foloseşte doua nivele de expresii pentru a face
mai uşoară listarea termenilor şi subtermenilor;
 Numărul paginii. Un index de carte listează numerele de pagini la care s-a
găsit termenul. Se poate ştii care este termenul important deaoarece acesta
este îngroşat sau cumva marcat altfel;
 Capacitatea de a scana conţinutul. Se pot avea mai mult de 100 de termeni
pe o pagina a unui index. Se pot scana porţiuni mari din index foarte repede
şi eficient pentru căutarea cuvântului respectiv;
 Asocieri. Liniile “vedeti si..” dintr-un index permit găsirea unei referinţe
apropiate a termenului sau mişcarea in index.
Acest lucru este ignorat din cauza ignorantei, a costului,a rezoluţiei ecranului şi
„tirania” interfeţei standard cu utilizatorul. Nu toţi designerii de web știu cum
funcționează indexurile tiparite. Trăsăturile extinse ale unui index sunt costisitoare
pentru crearea în web iar monitorul nu oferă aceiaşi densitate de informaţie ca şi o
pagina imprimată.
La încheierea discuţiei despre indecşi, trebuie să arătăm ca aceştia sunt un caz
special de ierarhie. Un exemplu de ierarhie pe două nivele poate fi observată în
exemplul următor:
Content Management
Vezi si „Digital Asset Management”
Enterprise Content Management
Lista de Sisteme de Gestiune a Continutului
Portal
Portaluri Organizaţionale
Portaluri web
Portaluri in jocuri video
Portaluri in Fictiune
Tipul indexului din ierarhie nu poate substitui cuprinsul (deşi se poate încerca şi
acest lucru) ci constituie totuşi, o ierarhie.
Consideraţii asupra indecşilor
Urmează în continuare câteva consideraţii care pot fi luate în calcul la creare de

indecşi:
 Trebuiesc luaţi in serios: trebuie încercat sa nu se presupună că se fac doar
cuvinte cheie. Trebuie luptat împotriva conceptului prin care toţi indecşii stau
intr-o caseta care are maxim 25 caractere şi 10 linii;
 Trebuie sa se profite de tehnicile de printare: cu constrângerile date de timp şi
interfața utilizatorului, trebuie încercat să se extindă tehnicile prin care se
asigura navigarea într-un index imprimat;
 Trebuie folosit un vacabular de interior şi unul de exterior: Un index este locul
principal pentru a-i învăţa pe utilizatori cuvintele potrivite care trebuiesc
folosite. Este nevoie de includerea de sinonime pentru vocabularul interior din
index care da celor de afara o cale de a intra.
Indexarea in bazele de date relationate
Indexul reprezintă un rezumat in 30-50 cuvinte care descriu conţinutul

publicaţiei. Un index face legătura între fraze şi conţinut (sau alte fraze). In cărţi,
intrările din indecşi se refera la pagini. Intr-un sistem CMS, intrările din indecşi se pot
referi la pagini, componente, elemente sau poziţii de text. Indecşii care se referă la
componente se pot reprezintă uşor într-o bază de date relaţională. Un foarte simplu
dar adecvat tabel de indecşi este arătat in figura următoare.
Figura 1.12 - Un tabel simplu de indexare a bazei de date
Prima coloana listează termenii din index, în timp ce a doua coloana listează ID-
urile componentelor la care indecşii se aplică. In aplicaţii reale se pot face modificări la
acest format simplu pentru a-i îmbunătăţii calitatea. In primul rînd, se pot dori două
nivele de indecşi. Pentru a realiza acest lucru,trebuie sa se prezinte cumva un rezumat
in tabel: un set de cîmpuri sau se poate face ceva mai simplu dat fiind ca sunt doar
două nivele şi că sunt in ordine alfabetică. Toţi programatorii ar prefera sa nu listeze
toate ID-urile componentelor intr-o coloană. Mai bine ele se pun într-o tabelă separata
sub forma de tabel care are doar un ID pe coloana. Partea dificilă a indecşilor nu este
partea de creare a tabelelor bazei de date, ci efortul depus in indexarea conţinutului.
Daca sistemul este creat pentru a produce pagini web, mulţi ar fi tentaţi sa asocieze
cuvintele cheie din indecşi cu paginile web. Cei mai multi indecsi din paginile web
actuale folosesc tag-uri <META> pentru a crea cuvinte cheie pe care site-ul lor le poate
utiliza, la fel ca şi orice motor de căutare web, după cum urmează:
<META NAME="keywords" CONTENT="cuvin cheie 1, portal, studenti">
Aceasta este o abordare destul de realista in cele mai multe cazuri si singura in
cazul indexării paginilor web. Nu este nevoie de crearea unui index in sistemul CMS
care refera componentele (si nu paginile). In timpul creării unei pagini este destul de
uşor să se introducă valori în tag-ul <META> din termenii de index ale fiecărei
componente din pagină. In acest mod, pe măsură ce componentele sunt adăugate sau
şterse din pagina ,cuvintele lor cheie vor avea grija de ele însele.
Indecşi in XML
Indecşii din XML urmăresc acelaşi tip de logica, ca şi in cazul bazelor de date
relaţionale. În exemplul următor in XML se poate observa acest lucru:
<INDEX>
<TERM Name="Beneficii" ID="I1">
<COMPONENTID>RU3</COMPONENTID>
</TERM>
<TERM Name="Pensie" ID="I2">
</Term>
</Index>
Explicaţii:
1. elementul <INDEX> separă indexul de celelalte structuri din depozitul XML;

2. elementul <TERM> cuprinde o singura intrare de index. Are un atribut nume
care are termenul indexat şi atributul ID care identifica in mod unic termenul;
3. elementul <COMPONENTID> marchează o singura componentă care este
indexată de termen. Doar ID-ul componentei este dat. Numele componentei
(sau numărul paginii, daca se produce o publicaţie tipărita) este obţinut prin
folosirea ID-ului in timp ce indexul este publicat. Se puteau „împacheta” ID-
urile componentelor intr-un singur atribut dar ar fi fost mai greu de înţeles.
Referinţe încrucişate
O referinţă încrucişată leagă în mod direct o parte de conţinut de altă parte. O

referinţă încrucişată conţine termenul, mai mult folosit de hyperlink sau link. Un link
este o modalitate de a „sări” de la o pagină Web (sau alt nod al unei publicaţii) la alta,
indiferent de locul în care se găseşte în site. Referinţa încrucişată este mai descriptivă
şi se poate aplica tuturor tipurilor de publicaţii.
Referinţele încrucişate s-au transformat, odată cu apariţia publicaţiilor
electronice, din informaţiile adiţionale din pagini în modalităţi centrale de a parcurge o
publicaţie electronică. De fapt, World Wide Web-ul a fost numit pe baza
interconexiunilor care sunt posibile prin utilizarea referinţelor încrucişate care pot
traversa nu numai două părţi de conţinut din acelaşi domeniu ci şi din orice spaţiu care
este accesibil într-un site Web.
Pe lângă faptul că o referinţă încrucişată poate conţine referinţe şi referenţi,
acestea formează căi printr-un domeniu de conţinut. O secvenţă este o cale liniară prin
care editorul consideră logice părţile/bucăţile anterioare şi următoare. Prin urmarea
referinţelor încrucişate, utilizatorii pot crea o cale alternativă, bazată pe următoarea
noţiune la care urmează să ajungă (sau să se uite).
Figura 1.13 - Referinţe încrucişate între termeni din Wikipedia
Căutarea full-text
Reprezintă procesul foarte familiar de a introduce un cuvînt sau frază intr-o

căsuţa de text, de a apăsa pe butonul de Căutare şi de a obţine o listă de titluri. În
timpul apăsării pe butonul de căutare si afişarea rezultatelor, programul scanează
fiecare bucăţică de text disponibil după cuvintele căutate şi le afişează sub forma unor
link-uri.
Acest tip de căutare este una dintre cele mai fascinante facilităţi ale informaţiei
în format digital. La acest moment sunt disponibil algoritmi foarte eficienţi care pot
indexa şi căuta prin volume enorme de text şi pot returna mii sau milioane de titluri în
cîteva secunde. Iar acest lucru este si mai interesant deoarece se face fără intervenţia
umană, programele fiind automatizate complet, în acelaşi timp scanînd textul şi
actualizîndu-şi indecşii pe măsura modificării textului căutat.
Cel mai convingător exemplu ale unui astfel de program de căutare în text este
reprezentate de motoarele de căutare de pe Web. Google, Live, Alta Vista şi alte cîteva
mii permit utilizatorilor să caute cuvinte cheie într-un procent semnificativ din întregul
World Wide Web. Utilizatorul scrie cîteva cuvinte şi poate obţine sute de mii de titluri
de pagini care conţin cuvintele respective.
O asemenea putere şi uşurinţă de utilizare au făcut multe persoane să creadă
că obţinerea de rezultate în acest fel este cea mai puternică metodă de acces la
informaţie. Totuşi, există şi o parte negativă: căutarea în tot textul funcţionează prea
bine. După ce utilizatorii au fost uimiţi de puterea lui Google, aceştia devin repede
frustraţi: cine doreşte 100.000 sau mai multe rezultate ?
Figura 1.14 – Viitorul Google.
Deoarece este automatizat, căutarea automată în întregul text este un

instrument uşor şi la îndemână pentru editor, deşi este, de obicei, mai greu de utilizat
de către utilizatori.
Căutarea în text seamănă cel mai bine cu un index al bazelor de date, în care
indexul este o tabelă enormă de cuvinte şi poziţiile lor în text. Cea de-a doua parte a
programului procesează cuvintele. După apăsarea butonului de căutare, aplicaţia caută
în index locaţia şi titlurile care sunt asociate cu cuvintele introduse de utilizator. Ca şi
un index dintr-o bază de date, indexul de text nu adaugă nimic în text dacă nu există ci
face doar căutarea şi accesul la informaţii mai rapide.
Componentele unui sistem de căutare
Sistemele de căutare sunt orientate în doua direcţii: spre conţinut şi spre cel
care caută. In general,acest lucru înseamnă ca un motor de căutare trebuie sa indexeze
conţinutul şi solicitările de procese. Pentru a îndeplini aceste funcţii, multe dintre
sistemele de căutare au patru componente majore interdependente, de complexităţi
variate:
1. Identificarea conţinutului (crawling)

2. Indexarea
3. Procesarea cerinţelor
 analiza
 armonizare
 post-procesare
4. Rezultatele de formatare
Daca unul dintre aceste elemente lipseşte, eficienţa şi performanta sistemului

de căutare scad. Dacă prima funcţie nu poate face identificarea unui conţinut nou,
atunci lista de indexare nu va conţine acel conţinut şi devine perimat (învechit).
Similar, dacă folosirea excesivă a sistemului supraîncarcă subsistemul de
procesare al solicitărilor, resursa de care este nevoie pentru a realiza actualizarea
indexului de incrementare poate sa nu fie disponibila, sau timpul de răspuns pentru
listarea rezultatelor să fie îndelungat.
Căutarea şi regăsirea conţinutului
Valoarea conţinutului stă în exploatarea lui (prezentarea şi folosirea acestuia).

In acest caz căutarea şi regăsirea conţinutului trebuie să se facă intr-un mod simplu, în
contextul unui CMS. Tradiţional, această sarcină aparţine arhivării, care oferă servicii
asemănătoare, ca de exemplu căutarea mediatizată. Aceasta este datoria
instrumentelor specifice (de exemplu a bazelor de date), şi a procedurilor şi limbajelor
speciale ale documentarilor, având nevoie de cunoştinţele unor experţi în domeniu.
Cu o volum de conţinut şi un număr de utilizatori in continuă creştere care îl
accesează, procedura de căutare trebuie sa devina mai intuitiva şi uşor de manevrat.
Cei care vor sa caute conţinutul dintr-un sistem CMS sunt jurnaliştii, editorii,
cercetătorii, experţii în marketing şi, în sistemele deschise, chiar întregul public.
Prin urmare, cele mai importante aspecte ale catarii şi extragerii conţinutului
sunt interfețele simple, cu aplicații prietenoase, prezentări bine structurate ale
rezultatelor căutării şi consideraţiile drepturilor de acces ale utilizatorilor. Unealta de
căutare trebuie să permită căutarea nestructurată şi căutarea avansată în baze de
date. Continuând, odată cu dezvoltarea uneltelor pentru procesare media s-a făcut
posibila şi folosirea căutării prin exemple (de exemplu, o regăsire a unei imagini
similare sau o întrebare prin ezitare). Sistemul trebuie să ofere şi interfeţe pentru
aceste operaţii noi de căutare. Reprezentarea conţinutului in lista cu rezultate este
îndeosebi textuală.
Oricum, din ce în ce mai mult, această informaţie este îmbogăţită cu copii de o
rezoluţie mică a originalului sau, în special în cazul elementelor video, cadre cheie,
teme sau alte elemente audiovizuale abstracte. Ideal, interfaţa de căutare şi
prezentare a rezultatelor trebuie să fie configurabilă pentru a putea sa se adapteze
cerinţelor specifice ale grupului de utilizatori sau utilizatorilor individuali.
Procesele de selectare pot include tăieturi neprelucrate, care permit
utilizatorilor să marcheze părţi ale conţinutului pentru procesarea mai departe.
Utilizatorii care caută în conţinut pot avea diferite drepturi pentru vizualizarea şi
extragerea lui. Intr-un mediu complex, aceasta poate include transferul automat a unei
copii a originalului (sau părţi selectate) pentru producerea sau broadcastul
echipamentului. Altor utilizatori li se pot permite numai vizualizarea copiilor de calitate
scăzuta, de exemplu. Intr-un mediu web aceste copii pot fi desfăşurate, pentru a
preveni utilizatorii care recepţionează sa stocheze o copie a conţinutului.
Bazata pe volumul in creştere de date stocate in numărul in creştere de locuri,

căutarea şi regăsirea sunt mai importante ca niciodată pentru timp, acurateţe şi
regăsirea contextului de informaţii şi date cruciale pentru a realiza funcţiile unei
afaceri. Această cale va pune accent pe tehnicile, instrumente şi tehnologiile care
includ:
 taxonomii/folksonomii
 metadate
 motoare de căutare
 clasificare automata
 clasificarea documentelor
 categorisirea
Căutarea şi regăsirea conţinutului este definită de unirea unor solicitări ale

utilizatorilor împotriva unor părţi utile sau înregistrări de text liber sau reproducerea
unor înregistrări. Aceste înregistrări pot fi de orice tip de text nestructurat (înregistrări
bibliografice, articole de ziar, înregistrări reale de avere, sau paragrafele dintr-un
manual).
Motoare de căutare Web
Pe Internet şi pe componenta sa vizibilă, World Wide Web-ul există miliarde de

pagini disponibile, care aşteaptă să fie vizitate pentru a oferi informaţii despre o
miriadă de subiecte. De asemenea, există milioane de pagini disponibile, cele mai
multe dintre ele denumite în funcţie de dorinţa autorului, toate pe servere cu nume
criptice sau protejate. Totuşi, în momentul în care un utilizator doreşte să acceseze un
anumit subiect, acesta utilizează un motor de căutare pe Internet.
Motoarele de căutare pe Internet sunt site-uri web specializate, create pentru a
ajuta oamenii să găsească informaţii stocate în alte site-uri. Există multe diferenţe în
modul în care lucrează diferitele motoare de căutare, dar acestea execută în general
aceleaşi trei sarcini de bază:
1. caută pe Internet sau „selectează” părţi din Internet, pe baza cuvintelor
importante;
2. reţin un index al cuvintelor pe care le găsesc şi a locului acestora;

3. permit utilizatorilor să caute cuvinte sau combinaţii de cuvinte găsite în
acest index.
Motoarele de căutare iniţiale deţineau un index cu câteva sute de mii de pagini
şi documente, şi recepţionau şi serveau cam două mii de cereri pe zi. Astăzi, un motor
de căutare de vârf indexează sute de milioane sau chiar miliarde de pagini şi răspunde
la zeci de milioane de interogări pe zi. În continuare vom vedea modalitatea în care
sunt executate aceste sarcini şi cum motoarele de căutare de pe Internet alătură date
separate pentru ca utilizatorul să găsească ceea ce are nevoie.
Când se vorbeşte despre motoare de căutare pe Internet, se vorbeşte în
general despre motoare de căutare pe World Wide Web. Totuşi, înainte ca web-ul să
devină partea proeminentă a Internetului, existau şi alt fel de motoare de căutare, care
permiteau utilizatorilor să găsească informaţii în Internet. Astfel, există şi astăzi, dar se
utilizează foarte puţin, programe precum „gopher” sau „Archie”, care ţineau indexuri
de fişiere stocate pe serverele conectate le Internet, reducând în mod semnificativ
timpul necesar găsirii programelor sau documentelor. La sfârşitul anilor 1980,
utilizarea la maximum a Internetului însemna utilizarea programelor „gopher”,
„Archie”, „Veronica” etc. Astăzi cei mai mulţi utilizatori îşi limitează căutările la
serverele web, ftp sau de grupuri de dialog.
Înainte ca un motor de căutare să poate spună utilizatorilor unde se găsesc
anumite documente, acestea trebuie să fie mai întâi găsite. Pentru a găsi informaţii din
miliardele de pagini web, un motor de căutare foloseşte o aplicaţie specială, numită
„robot de căutare” sau „spider”, pentru a construi o listă de cuvinte găsite în paginile
web. Procesul prin care un spider îşi construieşte lista se numeşte „web crawling”, iar
pentru ca un motor de căutare/spider să construiască o listă eficientă de cuvinte,
acesta trebuie să caute printr-o mulţime de pagini.
Figura 1.15 - Un "Spider" obţine conţinutul unei pagini web şi creează o listă de
cuvinte cheie care permit utilizatorilor să găsească informaţiile pe care le doresc.
Un spider îşi începe căutarea prin web pornind de obicei de la o listă cu servere
intens utilizate şi cu pagini web foarte populare. Spider-ul va începe cu un site popular,
indexând cuvintele din pagini şi urmând toate legăturile găsite în site-ul respectiv,
ajungând în acest fel să traverseze şi să indexeze partea cea mai utilizată a web-ului.
Google.com a început ca un motor de căutare academic. În lucrarea care
descrie modalitatea de construire a acestuia, Sergey Brin şi Lawrence Page au
exemplificat cât de repede poate să lucreze un spider. Astfel, sistemul a fost construit
pentru a utiliza mai mulţi spider-i, trei de obicei, fiecare spider putând să ţină deschise
300 de conexiuni către pagini web la un moment dat. La cea mai ridicată performanţă,
folosind patru spider-i, sistemul putea căuta în peste 100 pagini pe secundă, generând
600 kilobytes de date în fiecare secundă.
Menţinerea unui sistem rapid însemna de asemenea construirea unui sistem
care să alimenteze spider-ii cu informaţii. Astfel, Google.com iniţial avea un server
dedicat pentru a oferi URL-uri spider-ilor. Google avea de asemenea şi propriul server
DNS, translatarea numelor în adrese fiind semnificativ mai rapidă, micşorând în acelaşi
timp şi întârzierile datorate reţelelor.
În momentul în care un spider Google vizita o pagină HTML, acesta ţinea cont
de două lucruri:
 cuvintele găsite în pagină;
 poziţia acestor cuvinte în pagină.
Cuvintele găsite în titlu, subtitlu, metatag-uri şi alte poziţii de importanţă
relativă erau notate cu o semnificaţie specială în timpul căutărilor iniţiate de utilizatori.
De asemenea, spider-ul a fost construit pentru a indexa toate cuvintele semnificative
din pagină, lăsând la o parte cuvintele de legătură.
Alţi spider-i folosesc alte procedee pentru indexare, permiţând, spre exemplu,
spider-ilor să opereze mai rapid sau să permită utilizatorilor să caute mai eficient sau
ambele. De exemplu, unii spider-i menţin o listă de cuvinte din titlu, subtitlu şi legături,
împreună cu cele mai utilizate 100 de cuvinte din pagină şi fiecare cuvânt din primele
20 de linii de text. Se pare că Lycos utilizează această modalitate de indexare a
conţinutului paginilor web.
Alte sisteme, precum AltaVista.com, merg în altă direcţie, indexând toate
cuvintele din pagină, inclusiv toate cuvintele de legătură sau „nesemnificative”.
Această împingere către completitudine are şi alte modalităţi de funcţionare, mai ales
prin utilizarea meta-tag-urilor.
Meta-tag-urile permit proprietarului unei pagini să specifice cuvintele cheie şi
conceptele sub care va fi indexată pagina respectivă. Acest lucru poate fi folositor în
cazul în care cuvintele din pagină pot avea două sau mai multe semnificaţii, meta-tag-
urile ghidând motorul de căutare în alegerea celei mai corecte semnificaţii pentru
cuvintele respective. Există de asemenea şi anumite pericole în utilizarea acestor tag-
uri, deoarece un proprietar neatent sau fără scrupule ar putea adăuga meta-tag-uri
care să se potrivească celor mai populare subiecte, fără ca acestea să aibă nimic cu
conţinutul în sine al paginii. Pentru o protecţie împotriva acestei practici, spider-ii
corelează de obicei conţinutul paginii cu meta-tag-urile, respingând tag-urile care nu se
potrivesc cu cuvintele din pagină.
Toate cele de mai sus presupun faptul că proprietarul paginii sau site-ului
doreşte ca pagina/site-ul să fie inclus în rezultatele activităţii motoarelor de căutare.
De multe ori proprietarii nu doresc includerea într-un motor de căutare major sau nu
doresc indexarea anumitor pagini dintr-un site. Pentru acest lucru a fost dezvoltat
protocolul de excludere al roboţilor (robot exclusion protocol). Acest protocol,
implementat în secţiunea de meta-tag-uri de la începutul unei pagini web, comunică
robotului de căutare să nu indexeze pagina şi/sau să nu urmărească nici unul din link-
urile din pagina respectivă.
După ce spider-ii au terminat sarcina de găsire a informaţiilor în paginile web
(trebuie să notăm faptul că această sarcină nu se termină niciodată - din cauza naturii
mereu schimbătoare a web-ului, spider-ii indexează pagini în permanenţă), motorul de
căutare trebuie să stocheze informaţiile adunate într-o modalitate utilizabilă. Există
astfel două componente care fac datele adunate accesibile utilizatorilor:
 informaţia stocată cu datele;
 metoda în care este indexată informaţia.
În cel mai simplu caz, un motor de căutare doar va stoca cuvintele şi URL-ul
unde au fost găsite. În realitate, acest lucru ar face dintr-un motor de căutare unul cu
utilizări limitate, deoarece nu ar exista nici o modalitate de a spune dacă acel cuvânt a
fost utilizat într-un context important sau unul trivial în pagina respectivă, nici dacă
acel cuvânt a fost utilizat o singură dată sau de mai multe ori, sau dacă pagina conţine
legături către alte pagini cu acel cuvânt. Cu alte cuvinte, nu ar fi nici o posibilitate de a
construi un clasament care ar încerca să prezinte cele mai utile pagini la începutul listei
de rezultate.
Pentru a crea şi afişa cele mai utile rezulte, cele mai multe motoare de căutare
stochează mult mai multe date decât cuvântul şi URL-ul în care a fost găsit. Un motor
ar putea stoca numărul de apariţii al cuvântului în pagină, putând de asemenea să
asigneze câte o „greutate” fiecărei intrări, cu valori mai mari ataşate cuvintelor care
apar către începutul documentului, în subtitluri, legături, meta-tag-uri sau titlul paginii.
Fiecare motor de căutare comercial are diferite formule sau modalităţi pentru
asignarea greutăţii pentru cuvintele din index. Acesta este unul din motivele pentru
care o căutare după acelaşi cuvânt în motoare de căutare diferite va produce liste de
rezultate diferite, cu paginile prezentate în ordini diferite, chiar dacă sunt indexate
aceleaşi pagini.
Fără a ţine cont de combinaţia precisă de informaţii adiţionale stocate de un
motor de căutare, datele vor fi stocate în mod codat, pentru a economisi spaţiul de
stocare. De exemplu, documentul original de prezentare al Google.com utiliza 2 bytes,
fiecare din 8 biţi, pentru a stoca informaţii referitoare la greutate: cuvântul era scris cu
litere mari, mărimea fontului, poziţia sau alte informaţii necesare clasificării. Fiecare
factor putea lua 2 sau 3 biţi în cei 2 bytes, având ca rezultat stocarea unui volum mare
de informaţii într-un spaţiu foarte compact.
După ce informaţia este compactată/codată, aceasta este gata de indexare. Un
index are un singur scop: permite găsirea foarte rapidă a informaţiei. Există mai multe
modalităţi de a construi un index, dar una din cele mai eficiente modalităţi este
utilizarea unui tabel hash (hash table). Prin hashing, se aplică o formulă matematică
pentru ataşarea unei valori numerice fiecărui cuvânt, formula fiind construită pentru a
distribui în mod egal intrările de-a lungul unui număr predeteminat de diviziuni.
Distribuţia numerică este diferită de distribuţia cuvintelor din alfabet, aceasta fiind
cheia eficienţei unui tabel hash.
În limba engleză, de exemplu, există unele litere cu care încep cele mai multe
cuvinte, în timp ce alte litere sunt la începutul a mai puţine cuvinte (comparaţi litera
„M” din dicţionar cu litera „X”). Această inegalitate înseamnă că găsirea unui cuvânt
care începe cu o literă mai „populară” ar putea lua mai mult timp decât găsirea unui
cuvânt care începe cu o literă mai puţin utilizată la începutul cuvintelor. Prin hashing se
elimină această diferenţă şi se reduce timpul mediu pentru a găsi o intrare. Tot prin
hashing se separă cuvintele de indecşii în sine. Tabela hash conţine numărul hash
împreună cu un pointer către datele efective, date care pot fi sortate în orice direcţie.
Combinaţia de indexare şi stocare eficientă face posibilă obţinerea rapidă a
rezultatelor, chiar dacă utilizatorul creează o interogare complexă.
Căutarea printr-un index presupune construirea unei interogări de către
utilizator şi transmiterea ei către motorul de căutare. Interogarea poate fi simplă,
alcătuită din minim un cuvânt sau mai complexă, necesitând operator booleeni, care
permit rafinarea şi extinderea căutării.
Operatorii booleeni cei mai des utilizaţi sunt următorii:
 AND – toţi termenii separaţi prin „AND” trebuie să apară în pagină
sau în document. Unele motoare de căutare pot folosi „+” în loc de
„AND”;
 OR – cel puţin unul din termenii separaţi prin „OR” trebuie să apară
în pagină sau document;
 NOT – termenul sau termenii care urmează după „NOT” nu trebuie
să apară în document. Unele motoare de căutare pot folosi „-” în
locul cuvîntului „NOT”;
 FOLLOWED BY – unul din termeni trebuie să fie urmat în mod direct
de către altul;
 NEAR – unul din termeni trebuie să fie la o distanţă specificată în
cuvinte de celălalt termen;
 Ghilimele – cuvintele dintre ghilimele sunt tratate sub formă de
frază, iar acea frază trebuie să fie găsită în interiorul documentului
sau paginii;
Căutările definite prin operatorii booleeni sunt căutări „literale”, în care
motorul caută cuvintele sau frazele exact cum sunt introduse. Acest lucru poate fi o
problemă în cazul cuvintelor cu mai multe înţelesuri. În cazul în care utilizatorul este
interesat doar în găsirea paginilor care conţin doar unul din sensuri, se pot astfel de
interogări, dar ar fi mai util ca motorul de căutare să realizeze acest lucru în mod
automat.
Astfel, una din ariile de cercetare în domeniul motoarelor de căutare este cel al
„căutării bazate pe concepte”. Unele din aceste cercetări presupun utilizarea analizei
statistice în pagini care conţin cuvintele sau frazele care sunt căutate, pentru a găsi alte
pagini în care utilizatorul ar putea fi interesat.
Alte domenii de cercetare privesc interogările bazate pe limbaj natural, putând
astfel fi introduse interogări la fel ca întrebările puse oamenilor, fără a mai fi nevoie de
operatori booleeni sau structuri de interogări complexe. Cel mai important motor de
căutare care foloseşte limbajul natural este AskJeeves.com, care parsează interogările
pentru a găsi cuvintele cheie, pe care le aplică mai apoi indexului de site-uri construit.
AskJeeves.com lucrează cel mai bine cu interogări simple, dar există o competiţie
deosebită în acest sens.
1.7. DEPOZITUL BAZAT PE XML
Obiectele din bazele de date au fost inventate ca un mijloc convenabil de

depozitare sau serializare de date de care programele au nevoie pentru a manevra
programarea orientată pe obiecte. Programatorii care în mod tradiţional au o strânsă
legătură cu bazele de datele, pentru a stoca date, duc o muncă foarte grea pentru a
încerca să introducă date ierarhice în rânduri şi coloane, aşa că au inventat un sistem
de stocare ierarhic.
Date orientate pe obiecte reflectă structura de programare a obiectelor care
sunt prelucrate. Ca un simplu exemplu, se presupune că este scris un program care
trebuie să se ocupe de curriculum unei universităţi. Se creează un obiect cu numele
Curs care procesează cursurile particulare, un obiect numit Departament care
procesează nivelele departamentelor şi un alt obiect numit Facultate care conţine
toate funcţiile necesare şcolii. Intre aceste trei obiecte se stabilesc următoarele relaţii:
 Modul în care se procesează un Curs depinde de departamentul în care se
află clasa. Toate cursurile din departamentul de Calculatoare, de exemplu,
obligă studentul să aibă specializare în Calculatoare. Pentru accesarea
obiectului Departament trebuie întâi apelată funcţia Inscriere din Curs.
 Modul în care se procesează un Departament depinde de şcoala în care se
află. Toate schimbările de curs în departamentul de Calculatoare, de
exemplu, trebuie aprobate de decanul facultăţii. Pentru accesarea
obiectului Facultate, trebuie apelată întâi funcţia schimb Curriculum din
Departament.
Se poate reprezenta relaţia dinre acestea şi astfel:
Şcoala (are numele aprobat)
Departament (necesita cursul)
Curs (are date despre curs)
Undeva trebuie stocat numele aprobat, ceea ce necesită cursul şi date despre
curs, la fel ca şi o mulţime variată de date despre cursuri, departamente şi şcoli. Un
programator poate (şi deseori face) crea relaţii între tabelele bazelor de date pentru a
putea ţine evidenţa datelor.
Nu există o potrivire naturală între aceste date ierarhice şi rândurile şi
coloanele bazei de date; o modalitate mult mai potrivită pentru stocarea datelor
pentru acest obiect model poate fi ceva de genul exemplului următor:
<Facultate>
<APPROVER></APPROVE>
<DEPARTAMENT>
<Necesar></ Necesar>
<CURS>
<CURSDATA></CURSDATA>
</CURS>
</DEPARTAMENT>
</Facultate>
Pentru a stoca date în această structură, trebuie doar parcursă ierarhia

numelor obiectelor stocate şi datele lor. Pentru a reintroduce un set de date, se citeşte
ierarhia datelor, se creează un obiect de instanţă în timp ce se dă de numele acestuia şi
se încarcă datele care sunt listate.
Bineînţeles că în practică este puţin mai complicat decât explicaţia dată acum,
dar aceasta ajuta la formarea unei perspective a cum trebuie parcurse şi făcute
acestea. Structura precedentă de XML se potriveşte structurii programării orientate pe
obiecte ca o mănuşă. Legătura bazelor de date cu cea a lumii obiectelor se potriveşte
ca figurina unui cub introdusă într-o gaură rotundă.
Așadar, bazele de date orientate obiect au fost inventate pentru a furniza
programatorilor o metodă mult mai accesibilă şi rapidă pentru stocarea şi extragerea
de date pentru ierarhii de obiecte. Acest lucru este important deoarece conţinutul
componentelor este asemănător cu programarea pe obiecte; la fel cu obiectele,
componentele vin într-o anumită ierarhie. Iar ierarhiile componentelor sunt la fel de
incomod de stocat în baze de date cum sunt şi ierarhiile de obiecte. Programatorii de
conţinut s-au îndreptat spre baze de date orientate-obiect pentru multe din motivele
pentru care au făcut-o şi programatorii de obiecte.
Modul ierarhic de stocare a informaţiei în bazele de date ale obiectelor este un
motiv silit de luare în considerare a CMS-ului. Şi mai important este faptul că sintaxa
care este folosită pentru crearea ierarhiei de informaţie este XML-ul. Pentru un CMS
care foloseşte XML ca format de bază a conţinutului, alegerea unei baze de date
orientate-obiect este naturală.
Baze de date orientate obiect versus XML
Nu este nevoie de o bază de date pe obiecte pentru a programa în XML. In

realitate, puţini programatori de XML cunosc baze de date pe obiecte. Ei lucrează cu
fişiere XML. Un fişier XML are aceeaşi structură şi sintaxă ca o bază de date pe obiecte.
Pe de altă parte, sunt câteva motive pentru care e mai bine să alegem (la fel cum
folosesc şi unele companii care produc CMS ) o bază de date pe obiecte:
 Fişiere multiple: va trebui să se lucreze cu multe fişiere XML şi se va dori ca
acestea să fie unite printr-o ierarhie; şi capacitatea de a se căuta prin toate
fişierele în acelaşi timp, cum oferă o bază de date pe obiecte.
 Livrarea: va trebui un mediu mai sofisticat de livrare decât cel oferit de
sistem. Multe baze de date pe obiecte, de exemplu, vin cu web caching, şi
funcţionalitatea de răspuns de care este nevoie pentru a rula consumul site-
ului.
 Mediu de dezvoltare: se poate prefera mediul de programare şi
administrare pe care îl oferă o bază de date pe obiecte. Multe baze de date
pe obiecte vin, de exemplu, cu propriile extensii standard ale XML-ului cum
ar fi XPath şi XSLT care sunt preferabil de folosit în locul altor standarde mai
puţin dezvoltate.
 Performanţe: Bazele de date pe obiecte oferă câteva realizări în plus faţă de
fişierele XML. Multe furnizează indecşi care, de exemplu, permit găsirea
unor informaţii mult mai rapid decât în fişiere de tip XML.
Stocarea claselor de componenţă şi a instanţelor
Cea mai simplă metodă de stocare a componentelor în XML este înăuntrul unui singur
element care poartă numele clasei conţinut:
<BENEFICII_R_U>
<ID>1</ID>
<NAME> Pensie </NAME>
<TYPE>Standard</TYPE>
<AUTHOR>Derek Andrews</AUTHOR>
<EMPLOYEETYPE>FT</EMPLOYEETYPE>
<IMAGEPATH>images/ru/zimbet.jpg</IMAGEPATH>
<TEXT>Planul nostru...</TEXT>
</BENEFICII_R_U>
Componenta este un element XML, şi toate componentele elementelor sunt

elemente XML. Se pot face mult mai multe lucruri cu codul de componentă XML
transformând anumite componente în atribute, după cum arată şi exemplul următor:
<BENEFICII_R_U ID="HR1" Type="Standard" AuthorID="A21"

EmployeeType="FT">
<NAME>Pensie</NAME>
<TEXT> Planul nostru...</TEXT>
</BENEFICII_R_U>
S-a ales să se facă atribute ID, Type, Author şi EmployeeType pentru motive
particulare, bazate pe câmpurile elementelor în care se află, după cum urmează:
 Elementul ID este un identificator unic. Este generat automat de către CMS
(şi posibil să nu fie văzut vreodată de către utilizator). Făcându-l atribut, se
poate specifica (într-un DTD sau schemă) că este un ID şi trebuie să fie unic
de-a lungul tuturor componentelor HRBenefit. O mică schimbare este
necesară pentru crearea atributului ID. In XML ID-urile trebuie sa înceapă cu
un caracter, aşadar se schimbă valoarea 1 în HR1.
 Componenta elementelor Type şi EmployeeType sunt liste închise.
Utilizatorul alege o variantă dintr-un set obigatoriu. Făcându-le atribute, se
pot defini ca liste închise (intr-un DTD sau schemă) şi specificând alegerile
valabile. Din nefericire nu există o metodă uşoară echivalentă cu crearea
unei liste deschise într-o schemă XML.
 Componenta element Author este mai complexă. Presupunând că sunt
componente Author şi în altă parte a sistemului care au numele autorului,
denumirea job-ului, adresa de e-mail, etc., în aceasta componenta, în loc să
dublăm informaţia care se află în componenta Author, e mult mai
inteligentă metoda de referire corectă la componenta autor. Cu alte
cuvinte, elementul componentă Author este o listă deschisă ale cărei valori
sunt o referinţă la alta componentă. Făcând-o atribut, se specifică faptul că
este referinţă (numita IDREF în limbajul DTD) şi impune ca întodeauna să
indice componenta existentă Author. Pentru că este un atribut IDREF, i-am
schimbat numele cu AuthorID şi i-am schimbat valoarea de la numele
autorului la componenta ID.
Pentru stocarea tuturor componenetelor HRBenefits, trebuie doar învelite intr-
un element superior:
<BENEFICII_R_U>
< BENEFICIU ID="HR1" Type="Standard" AuthorID="A21"
EmployeeType="FT">
<NAME>Pensie</NAME>
<TEXT>Our great Pensie plan...</TEXT>
</ BENEFICIU >
EmployeeType="FT">
<NAME>Medical</NAME>
<IMAGEPATH>images/hr/zimbet.jpg</IMAGEPATH>
<TEXT>Wait till you see the...</TEXT>
</ BENEFICIU >
EmployeeType="FT+">
<NAME>Stomatologic</NAME>
<IMAGEPATH>images/hr/ zimbet.jpg</IMAGEPATH>
<TEXT>We now do teeth!...</TEXT>
</ BENEFICIU >
</BENEFICII_R_U>
Se observă singularul şi plurarul tag-urilor din convenţie. Componentele de

instanţă sunt numite la singular (HRBENEFIT). Tipul conţinutului este numit la forma de
plural a instanţei (HERBENEFITS). Aceasta este o convenienţă de numire comună atât
pentru XML cât şi pentru programarea orientată pe obiecte.
Dacă se creează impresia că XML este uşor de creat, atunci pe de o parte este
adevărat, dar este şi greşit. Este foarte uşor de scris blocuri de text ca cel anterior; este
extrem de greu de creat un sistem complex şi interconectat de elemente şi controlate
riguros după cum şi trebuie. Cu alte cuvinte, urmărind regulile de sintaxă ale XML-ului
este uşor (concept al formarii XML). Creând şi apoi urmând un set complex de reguli de
construcţie specificate de DTD este greu (conceptul unui XML valid). Cu toate acestea,
se poate vedea că XML-ul este chiar capabil să infăţişeze componente.
Intr-un depozit XML, problemele sunt mult mai uşoare. Presupunând că se dă
următoarea structură în elementul Text a componentui HRBenefit:
<TEXT>
<TITLE>We now do Teeth!</TITLE>
<PULLQUOTE>
<B>My gums and molars never felt so good.</B>
<IMAGE>laurasmile.jpg</IMAGE>
</PULLQUOTE>
<H1>
a paragraph of text here
<H2>a paragraph of text here</H2>
</H1>
<H1>a paragraph of text here</H1>
<CONCLUSION>
Put your mouth where our money is-<B>use the
plan!</B>
</CONCLUSION>
</TEXT>
Pentru a stoca aceasta structura într-un fişier XML sau o bază de date, cel mai
simplu se include în componentele mai mari XML. Nu este nevoie de nici o tehnică
specială de obţinere a structurii sau ridicare a unei părţi din ea. Elementele care sunt
incluse în tag-urile <TEXT> sunt la fel de accesibile utilizatorului depozitului în care sunt
stocate precum sunt şi oricare alte elemente ale componentelor. In plus, nu contează
dacă unele componente au multe diferenţe de structură în elementele <TEXT> şi altele
foarte puţine. Orice ar fi acolo este stocat şi accesibil la cel mai de jos tag <B>. Totuşi,
cea mai grea parte este de a ajunge la punctul în care trebuie doar copiat textul între
elementele <TEXT>.
In particular, trebuie urmatoarele:
 Textul trebuie bine format în XML. Deşi nu este în totalitate adevărat (se
poate pune orice fel de text dacă este folosită o caracteristică a XML-ului
numită CDATA), este adevărată dacă se doreşte folosirea textului. Este
relativ mai uşor pentru aducerea textului în XML (spre exemplu din HTML)
sau chiar dificil (de exemplu dintr-un vechi procesor de cuvinte).
 Textul trebuie să fie valabil XML. Deşi nu este în totalitate adevărat, este
destul de adevărat dacă se doreşte folosirea tuturor avantajelor pe care le
oferă regulile XML-ului care sunt listate într-un DTD sau într-o schemă.
Intr-o bază de date relaţională nu contează ce fel de text este în rânduri sau
coloane, principala problemă este de recunoaştere a structurii într-un text structurat.
In baza de date de obiecte şi fişiere XML, contează foarte mult ce fel de text este stocat
în fiecare element. Deşi bazele de date relaţionale au probleme cu textele structurate,
XML şi bazele de date au probleme cu textele care nu sunt structurate.
Stocarea structurilor de acces
Majoritatea structurilor de acces sunt foarte uşor de reprezentat şi lucrat cu ele într-o
structura XML.
Ierarhii în XML
XML-ul este desigur excelent în stocarea ierarhiilor. Luăm ca exemplu, următoarea

structura a unui site intranet:
Beneficii RU
Pensie
Medical
Stomatologic
Evenimente
Eveniment 1
Eveniment 2
Eveniment 3
Site-uri utile
Site 1
Site 2
Site 3
Stiri
Industrie
Stire 1
Stire 2
Organizatie
Stire 1
Stire 2
Acest site este stocat intuitiv şi repede, la fel ca următorul set de elemente:
<OUTLINE>
<FOLDER Name="Beneficii RU">
<ITEM ID="RUPensie">
<ITEM ID="RUMedical">
<ITEM ID="RUStomatologic">
</FOLDER>
<FOLDER Name="Evenimente">
<ITEM ID="Eveniment1">
</FOLDER>
<FOLDER Name="Site-uri utile">
<ITEM ID="Site1">
<ITEM ID="Site2">
<ITEM ID="Site3">
</FOLDER>
<FOLDER Name="Stiri">
<FOLDER Name="Industrie">
<ITEM ID="IStire1">
<ITEM ID="IStire2">
</FOLDER>
<FOLDER Name="Organizatie">
<ITEM ID="OStire1">
<ITEM ID="OStire2">
</FOLDER>
</FOLDER>
</OUTLINE>
Versiunea XML a schiţei este chiar similară cu versiunea textului simplu a

schiţei, deşi are importanţe diferenţe. Este clar că versiunea XML este mai lungă. De
fapt, XML este „otrava” multor programatori spartani care preferă un număr minim de
caractere de marcare şi cred că folosirea unui banal cuvânt în marcare este pentru
începători. Cu toate acestea, fiecare caracteristică a schiţei trebuie să fie în mod clar
codată, incluzând şi următoarele:
 Nesting: XML reprezintă imbricarea în outline prin închiderea elementelor
Folder în alte elemente Folder;
 Referinţa ID: XML face referinţă la componente prin ID astfel încît, dacă
numele se schimbă, nu trebuie să se rescrie nimic. ID-ul este o informaţie
suficientă pentru ca sistemul, mai târziu, să returneze numele obiectelor şi
să creeze un set de linkuri către paginile componentelor.
Se observă că în această schiţă se presupune că există elemente undeva în

codul XML care conţin de asemenea referiri la ID. In limbajul managementului
conţinutului, se poate spune că schiţa se referă la un set de componente HR, Site-uri,
IStory şi componente OStory.
Indecşi in XML
Reprezentarea unui index în XML este pe simplă şi urmează aceeaşi logică ca a

unei baze de date. Indexul unor componente HR care sunt descrise mai sus pot fi
reprezentate astfel în XML:
<INDEX>
<TERM Name="Beneficii" ID="I1">
</TERM>
<TERM Name="Pensie" ID="I2">
</TERM>
</INDEX>
Următoarele lucruri se observă în exemplul precedent:

 Elementul <INDEX> setează indexul independent de alte structuri din depozitul
XML;
 Elementul <TERM> permite închiderea unei singure intrări de index. Are un
nume de atribut care conţine termenul folosit de index şi un atribut ID cu care
se identifică cu termenul;
 Elementul <COMPONENT> marchează o singură componentă care este
indexată de către termen. Doar componenta ID este dată. Numele
componentei este regăsit folosind ID-ul ca index în timpul publicării.
Încrucișarea referinţelor in XML
Cea mai simplă formă de încrucişare prin referinţă arată în felul următor într-o
structură XML:
<LINK>
Pentru mai multe informaţii, accesati
<REFERENTID>HR3</REFERENTID>
</LINK>
Referinţa este închisă în elementul <LINK>, şi referirea la ID este închisă în

elementul <REFERENTID>. Pentru a adăuga mai mult control asupra link-ului, se pot
adăuga mai multe atribute, după cum arată şi exemplul următor:
<LINK Type="formore" Autotext = "yes" Position="inline">

<REFERENTID>HR3</REFERENTID>
</LINK>
Secvente in XML
Deoarece componentele sunt în general încrustate în ierarhii, într-o structura

XML secvenţa primară este de obicei disponibilă şi independentă faţă de structura în
sine.
Adiţional faţă de oricare structură care poate fi creată automat din sortarea
componentelor unor elemente, alte secvenţe pot fi reprezentate mult mai uşor ca cele
din exemplul următor:
<SEQUENCE Type = "Topics">

</SEQUENCE>
Se poate folosi atributul Type al elementului <SEQUENCE> pentru a declanşa

orice management particular sau funcţie de publicare care sunt particulare acestui tip
de secvenţă.
Subiectele “tip de secvenţă”, spre exemplu, pot avea o icoană specifica folosita
în link-urile de secvenţă.
Stocarea modelului de conţinut
După cum este cazul cu bazele de date relaţionale, cea mai mare parte a
modelului de conţinut se află în codul XML care stochează componentele. In general,
XML se comportă mai mult ca un model de bază de date relaţională abstractă, în care
numele şi valorile permise ale claselor de componente şi elementele sunt stocate într-
un loc, iar valorile sunt stocate într-o locaţie diferită.
In bazele de date relaţionale, programatorii au trebuit să inventeze o
modalitate de separare a structurilor componentelor de componente. In lumea XML-
ului, structura este întotdeauna separată de date. XML foloseşte DTD (“Document
Template Definition”) sau schema XML pentru definirea structurii după care se
ghidează data.
Aici se poate observa un segment de XML care a fost folosit şi pentru
evidenţierea componentei HR:
<BENEFICIU_R_U>
<ID>1</ID>
<NAME>Pensie</NAME>
<TYPE>Standard</TYPE>
<AUTHOR>Derek Andrews</AUTHOR>
<EMPLOYEETYPE>FT</Employeetype>
<TEXT>Planul nostru de Pensii...</TEXT>
</BENEFICIU_R_U>
Pentru a simplifica, toate elementele componente au fost transformate în elemente

XML.
<BENEFICIU_R_U ID="1" Type="Standard" AuthorId="A1" EmployeeType="FT">

<NAME>Pensie</NAME>
<TEXT>Planul nostru de Pensii...</TEXT>
</BENEFICIU_R_U>
Cu o singură excepţie, aceste două versiuni ale componentei HRBenefit sunt din
punct de vedere informaţional echivalente. In al doilea exemplu, în loc de tipărirea
numelui autorului, s-a folosit ID-ul autorului care indică structura unui autor ce se află
în altă parte. Cu toate că cele două versiuni pot fi informaţional echivalente, cea de a
doua este mult mai uşor de administrat. Făcând unele elemente atribute XML, se pot
folosi unele caracteristici ale unui XML DTD pentru a le controla. In exemplul următor
se poate observa un DTD care poate fi folosit pentru a specifica structura permisă a
unei componente HR:
<!ELEMENT BENEFICII_R_U (BENEFICIURU)+>

<!ELEMENT BENEFICIURU (NAME, IMAGEPATH, TEXT)>
<!ATTLIST BENEFICIURU
ID ID #REQUIRED
Type (Standard | Extended) #REQUIRED
AuthorId IDREF #REQUIRED
EmployeeType (FT | PT | ALL) #REQUIRED
>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT IMAGEPATH (#PCDATA)>
<!ELEMENT TEXT (#PCDATA)>
1.8. CANALE DE CONȚINUT
Termenul „portal” este deseori supra-utilizat şi poate fi dificil să definim exact

ceea ce este un portal. Totuşi, punctul de vedere general este acela că un portal este
un agregator de conţinut care poate obţine date din diverse surse şi le poate prezenta
într-o manieră uniformă, consistentă şi configurabilă, obţinând acest lucru prin
utilizarea unei arhitecturi multi-tier constând în portlet-uri şi canale. Din nou, nu există
o definiţie precisă pentru „portlet” şi pentru „canal”, diferite aplicaţii portal utilizând
aceste noţiuni într-o manieră interschimbabilă.
Totuşi, pentru a clarifica, un „canal” este considerat ca obiectul care oferă
informaţie unui portal, în timp ce un „portlet” va fi obiectul prin care utilizatorii vor
vedea conţinutul respectiv. Diagrama următoare ilustrează relaţiile dintre portaluri,
portlete şi canale.
Figura 1.16 – Canale de conţinut în cadrul unui Portal.
Un portal oferă oportunitatea de a dezvolta „canale” de conţinut – colecţii de

articole care sunt importante şi/sau interesante pentru diverşi membri. Aceste canale
pot fi apoi abstractizate şi sumarizate la diferite niveluri pentru a oferi conţinut pentru
alţi membri/utilizatori ai aplicaţiei respective.
Canalele pot conţine ştiri de interesa particular pentru diferite departamente
din organizaţie. Evenimentele, zilele de naştere, recunoaşterile, conferinţele viitoare şi
alte obiecte adiţionale pot fi plasate în canalele unui portal. Abonaţii acestor canale
vor vedea aceste obiecte sub forma unor articole, care pot fi deschide după dorinţă.
Canalele pot fi făcute disponibile ca şi opţiuni selectabile de către utilizatorii
portalului. Editorii de conţinut, de exemplu, pot să creeze canale în prin selectarea
diverselor obiecte din alte canale, iar abonaţii unui astfel de canal vor putea sa vadă
doar articolele selectate de editori. La nivelul organizaţiei, editorii pot selecta diverse
articole din mai multe materiale disponibile pentru a crea canale la acest nivel.
Canalele pot fi accesate pe baza drepturilor de securitate şi a rolurilor.
Tipuri de canale
Conform uPortal 1 , o aplicaţie open-source de tip portal dezvoltată de

organizaţia non-profit JA-SIG2, utilizată în multe3 universităţi mari ale lumii, defineşte şi
utilizează următoarele tipuri de canale:
1
http://www.uportal.org
2
http://www.ja-sig.org/
3
http://uportal.org/who-prod.html
 Canale proxy: sunt cele mai simple canale de implementat deoarece obţin
conţinut dintr-un site web pe care-l reproduce într-un portlet. Acestea sunt
cele mai uşor de implementat dar şi cel mai greu de controlat deoarece
portalul nu are control asupra aspectului portletului. Canalele de acest tip
cuprinde:
o Canale Inline Frame
o Canale WebProxy
 Canale de date XML: aceste canale produc date în format XML pe care
portalul le va afişa ulterior în portleturi folosind XSLT. Utilizarea unui format
cunoscut în portal, de tipul RSS, de exemplu, presupune faptul că se vor
utilize tehnologiile de transformare implicite de tipul XSLT, fiind, totuşi,
uneori şi nevoie de personalizarea acestor şabloane. În cazul utilizării unui
format XML adaptat pentru nevoi personalizate, va fi necesară crearea de
noi transformări XSLT pentru afişare. Printre tipurile de canale de date
bazate pe XML enumerăm:
o Canalele RSS;
o Canalele ATOM;
o Canalele generice XML/XSLT.
Aceste canale sunt ideale pentru publicarea informaţiilor. RSS şi ATOM sunt
ideale pentru publicarea informaţiilor găsite în liste, sub forma de
evenimente, servicii, cursuri, anunţuri, în timp ce canalele XML/XSLT
generice pot fi utilizate pentru alte tipuri de informaţii structurate.
 Canale interactive locale: reprezintă o aplicaţie creată să se execute într-un
portlet. Acestea pot fi locale (adică se execută pe acelaşi server ca şi
portalul) sau “la distanţă” (rulează pe alte servere). Canalele locale
presupun instalarea de cod pe serverul local, printre diferitele mecanisme
de scriere a acestor tipuri de canale putând găsi:
o uPortal Java Channel - specific acestui tip de portal;
o JSR 168/268 Java Channel – portlet generic, care, teoretic, poate fi
lansat şi executat în orice aplicaţie portal care suportă aceste
implemenare Java.
 Canale interactive la distanţă: au avantajul că nu necesită instalarea de cod
pe serverul portal, printre diferitele mecanisme de scriere a acestor tipuri
de canale putând găsi:
o Canale XFORM1: necesită cunoştinţe de XFORM şi Web CGI;
o Canale WSRP2: necesită cunoştinţe de SOAP şi servicii web.
Canale Inline Frame
Acest canal este cel mai uşor de implementat, o pagină web externă fiind
afişată în propriul cadru HTML în interiorul portalului (folosind tag-ul HTML iframe).
Avantajul acestui tag este că un site extern poate fi uşor adăugat în portal fără nici o
modificare.
1
http://www.w3.org/MarkUp/Forms/
2
Web Services for Remote Portlets: http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wsrp
Cu toate acestea, există şi dezavantaje. Astfel, portalul nu are control asupra
aspectului paginii web externe în momentul afişării acesteia, pagina respectivă părând
că nu este din locul respectiv (nu va respecta culorile alese de utilizatori, preferinţele
etc.). Cele mai multe pagini sunt create pentru a fi afişate pe întreg ecranul şi nu într-
un mic portlet din cadrul unei pagini, apărând astfel nevoia ca utilizatorul să utilizeze în
exces barele de navigare orizontală şi verticală. De asemenea, există browser-e care
nu suportă tag-ul iframe sau îl dezactivează ca măsură de securitate.
Canalul de tip WebProxy este o altă cale rapidă de a aduce conţinut în cadrul
portalului. În momentul în care este afişat un canal de acest tip, el va încerca să obţină
date dintr-un URL configurabil, să facă nişte transformări simple asupra conţinutului şi
apoi să-l afişeze în portal.
Printre problemele care pot apărea la utilizarea canalelor de tip Web Proxy
enumerăm:
 Aspect: acest canal va fi afişat la fel ca pagina originală şi nu va fi
transformat să respecte aspectul portalului;
 Transmiterea de date: aceste canale pot avea probleme legate de
transmiterea/POST-area de date înapoi către aplicaţia/pagina originală
din care s-a obţinut conţinutul, fiind necesare, uneori, modificări ale
codului sursă pentru a suporta acest canal;
 Probleme JavaScript: pot apărea probleme de afişare şi logică client-side
în cazul în care pagina sursă originară a canalului foloseşte (în mod
excesiv) JavaScript.
 Nu există suport pentru cadre (frame-uri).
Canalele RSS şi ATOM
RSS (Really Simple Syndication sau RDF Site Summary) reprezintă o listă XML de noi
obiecte, fiind o modalitate uşoară de publicare a ştirilor, evenimentelor sau a altor
obiecte bazate pe liste prin simpla publicare a informaţiilor sub forma unui document
XML.
RSS nu este dificil de creat, existând un număr de editoare care ajută utilizatorii.
Versiunile importante de RSS sunt:
 RSS 0.9x: versiunea iniţială bazată pe XML şi părintele celor două facţiuni
divergente;
 RSS 1.0: una din versiunile curente deviate din RSS 0.9; este bazat pe
tehnologii de tip Semantic Web precum RDF şi nu pe scheme XML. RSS 1.0
suportă module adiţionale pentru evenimente din calendar, cursuri,
anunţuri, stări ale serviciilor etc. Transformările XSLT trebuie modificate în
concordanţă cu modulele extensibile;
 RSS 2.0: altă versiune “curentă”. Este derivat direct din RSS 0.9, dar este
bazat pe XML, fără supportul adiţional de module din RSS 1.0.
Exemplu de canal RSS
1. <?xml version="1.0"?>
2.
3. <rdf:RDF
4. xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5. xmlns="http://purl.org/rss/1.0/">
6.
7. <channel rdf:about="http://myserver.ox.ac.uk/myfeed.rss">
8. <title>Stirile mele</title>
9. <link>http://portal.unitbv.ro</link>
10. <description>
11. Acesta este site-ul meu
12. </description>
13.
14. <image
rdf:resource="http://xml.com/universal/images/xml_tiny.gif" />
15.
16. <items>
17. <rdf:Seq>
18. <rdf:li resource="http://portal.unitbv.ro/anunt1.html"
/>
19. <rdf:li resource="http://portal.unitbv.ro/anunt2.html"
/>
20. </rdf:Seq>
21. </items>
22.
23. </channel>
24.
25. <item rdf:about="http://portal.unitbv.ro/anunt1.html">
26. <title>Interesting stuff</title>
27. <link>http://myserver.ox.ac.uk/myannouncement1.htmll</link>
28. <description>
29. O descriere a unui anunt interesant!
30. </description>
31. </item>
32.
33. <item
rdf:about="http://myserver.ox.ac.uk/myannouncement1.html">
34. <title>Alt anunt interesant </title>
35. <link> http://portal.unitbv.ro/anunt2.html</link>
36. <description>
37. O alta descriere a unui anunt interesant!
38. </description>
39. </item>
40. </rdf:RDF>
Ca rezultat al divergenţelor dintre standardele RSS, ca şi pentru adaptarea la

instrumentele de “blog” (utilizarea RSS pentru jurnale bazate pe web şi, uneori, pentru
chat), a apărut ATOM (Atom Syndication Format1 şi Atom Publishing Protocol2), un nou
standard bazat pe XML pentru anunţuri.
1
http://tools.ietf.org/html/rfc4287
2
http://tools.ietf.org/html/rfc5023
Un exemplu de ştiri ATOM:
<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom">
<title>Stiri folosind ATOM</title>

<subtitle>Un subtitlu.</subtitle>
<link href="http://example.org/feed/" rel="self"/>
<link href="http://example.org/"/>
<updated>2007-12-13T18:30:02Z</updated>
<author>
<name>Catalin Maican</name>
<email>maican@unitbv.ro</email>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>
<entry>
<title>Lansare Portal Universitar</title>
<link href="http://portal.unitbv.ro/2007/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2007-12-13T18:30:02Z</updated>
<summary>Text de sumar.</summary>
</entry>
</feed>
Canale XFORM
XFORM1 reprezintă o modalitate de construire a interfeţelor cu utilizatorii, prin

utilizarea XML independent de platformă. Există, totuşi, posibilitatea de a specifica
diverse constrângeri, de tipul validării datelor introduse, permițând clientului să decidă
asupra aspectului.
Canalul XForm se va executa în portal iar când va fi instruit să se afişeze, îşi va
obţine date de tipul XForm dintr-un URL preconfigurat, va afişa formularul în canal şi
va reacţiona la interacţiunea cu utilizatorul. În momentul în care formularul este corect
completat, datele vor fi POST-ate către un URL dat în XForm sub forma unei structuri
XML. Procesul se va repeta în mod continuu.
Acest lucru înseamnă că, dacă se doreşte schimbarea framework-ului portal,
munca ce a fost depusă nu este pierdută, ci poate fi refolosită cît timp există un
processor XForm pentru portalul respectiv.
Canale de distribuţie prin Web
Web-ul nu este un canal de informaţii, ci un mediu de comunicare şi

interacţionare într-o manieră bidirecţională. Multe organizaţii au descoperit puterea
de a oferi servicii on-line clienţilor şi partenerilo de afaceri. Acest aspect a câştigat
relevaţă în zona serviciului CRM. Cu ajutorului servicului de web, organizaţiile scutesc
mâna de lucru pentru a susţine interacţiunile, iar clienţii beneficiază de servicii rapide
oricând. In plus, canalul de web deschide o gamă de posibilităţi pentru vânzarea
1
http://en.wikipedia.org/wiki/Xform
efectivă şi moduri inovatoare de creare a valorii adăugate pentru clienţi. Astăzi,

canalele web sunt considerate un aspect semnificativ, dacă nu crucial, pentru
managementul relaţiilor cu clienţii.
Figura 1.17 – Canale de conţinut şi servicii.
Integrarea canalelor web, dintr-un aspect tehnic, poate fi văzută ca o

combinaţie între conţinut şi servicii agregate şi canalizate de un cadru portal.
Un cadru portal implementează prezentarea (foaie de stiluri etc), autentificarea
şi autorizarea, personalizarea, navigarea şi alte lucruri independente legate strict de
funcţionalitatea conţinutului. Aplicaţia care oferă conţinutul şi serviciile utilizatorului
prin intermediul unui portal poate fi complexă, dar în contextul CRM, aceasta poate fi
împărțită în următoarele domenii:
 eServices - permit utilizatorilor un self-service al informaţiei, să realizeze

comenzi sau cereri on-line, să descarce broşuri sau formulare etc. Şi, în
acelaşi timp, să ofere organizaţiei mediul pentru schimbul de informaţii
orientative (de exemplu: informaţii despre bursa de valori);
 eCommerce - permite organizaţiilor să activeze Internetul ca un alt canal de
vânzări. E-commerce oferă stocări on-line cu funcţionalităţi ca: catalogul de
produse, plăţi on-line, promoţii speciale, coşuri de cumpărături, serviciu de
marketing 1 la 1, etc. .
 Content management - oferă infrastructura pentru publicarea informaţiilor
despre produse, informaţii legate de marketing şi cele mai noi veşti în
domeniu. Această abordare a canalelor web permite găsirea celei mai
potrivite tehnologii pentru fiecare componentă aflată in canal.
eServices
Implementarea acestui serviciu poate fi făcută în mai multe moduri şi depinde

de existenţa sau nonexistenţa, în cadrul organizaţiei, a unui front-office bazat pe CRM,
de cât de uşor poate fi integrat într-un asemenea sistem şi, bineînţeles, de nevoia de
cerere şi integrare care poate fi generală sau specifică.
Beneficiile existenţei unui software CRM care să implementeze canalul web
sunt aparente, în acest caz, aplicaţiile self-services au nevoie să fie plasate în cadrul
procesului CRM. Exemple ale acestei funcționalități sunt actualizarea informaţiilor
clienților (modificarea adresei), vizualizarea facturilor şi plasarea comenzilor on-line.
Schimbul de informaţii între aplicaţia CRM şi canalul de servicii aferent este facilitat de
un model comun de date, aceeaşi gama de tehnici, aceleaşi servicii web şi fluxuri de
lucru compatibile.
eCommerce
Portalurile dedicate clienţilor care au o politică complexă de marketing sau un

domeniu bazat pe vânzări vor avea mai mult profit din produse specializate care oferă
cataloage de produse, promoţii şi campanii, magazine on-line, coşuri de cumpărături,
plăţi on-line şi multe alte funcţii specificate. Comunitatea open-source oferă produse
în acest sens, cu platforme eCommerce cum sunt: OFBiz, OSCommerce sau aplicații
bazate mai mult pe managementul conţinutului, cum ar fi eZ publish.
CAPITOLUL II
SOFTWARE DE COLABORARE ȘI DE MANAGEMENT AL
DOCUMENTELOR
Collaborative software (sinonim cu groupware) este un software construit

pentru a ajuta persoanele implicate în diferite proiecte să-şi atinge scopurile.
Collaborative software este baza pentru computer supported cooperative work (cum
pot fi executate activităţile şi colaborarea prin intermediul sistemelor de calcul).
Astfel de sisteme software (figura următoare), cum ar fi e-mail-ul, calendarul,
chat-ul sau wiki aparţin acestei categorii. S-a sugerat că legea lui Metcalfe (cu cît
numărul persoanelor care folosesc acest software este mai mare, cu atît el devine mai
valoros) - se aplică acestui tip de software.
Termenul general “software social” (aplicaţii bazate pe web care permit
utilizatorilor să interacţioneze şi să partajeze date unii cu alţii. Exemple: MySpace,
Facebook – ca site-uri sociale, Flickr, YouTube – ca site-uri media, Amazon, E-bay ca
site-uri comerciale) se aplică sistemelor care sunt folosite în afara locurilor de muncă,
de exemplu serviciile de întâlniri on-line şi de reţele sociale, cum ar fi Friendster sau
Facebox. Studiul colaborării prin intermediul calculatoarelor cuprinde studiul acestui
software şi fenomenele sociale asociate cu el.
Figura 2.1 - Software de groupware şi de knowledge management ajută grupuri

separate să colaboreze pentru schimb rapid de informaţii.
Colaborarea, în sensul utilizat de tehnologia informaţiei, pare să aibă câteva
definiții. Unele sunt uşor de susţinut, dar altele sunt atât de largi, încât îşi pierd orice
înțeles aplicativ. Înțelegerea diferenţelor din interacţiunile umane este necesară
pentru a asigura utilizarea unor tehnologii corespunzătoare în scopul de a îndeplini
acţiuni.
Există trei căi primare prin care omul interacţionează: conversaţia, tranzacţia şi
colaborarea.
 Interacţiunea conversaţională este un schimb de informaţii între doi sau
mai mulţi participanţi, scopul primar fiind descoperirea sau formarea unei
relaţii. Nu există o entitate centrală în jurul căreia se învârte interacţiunea,
aceasta fiind în realitate un schimb gratuit de informaţii fără o constrângeri
definite. Tehnologiile de comunicaţie, cum ar fi telefonul, e-mail-ul sau
mesageria instantanee sunt suficiente pentru astfel de interacţiuni;
 Interacţiunile tranzacţionale implică schimbul unor entităţi tranzacţionale
unde o funcție majoră a entităţii tranzacționale este să modifice relaţiile
dintre participanți. Entitatea tranzacțională este într-o stare relativ stabilă şi
constrânge sau definește noi relații. Unul dintre participanți schimbă bani
pentru bunuri şi devine client, de exemplu. Acțiunile tranzacționale sunt
manevrate de sisteme tranzacționale care gestionează stările intermediare
şi creează înregistrări pentru depozite persistente.
 In interacţiunile de colaborare, funcția principală a relației participanților
este de a modifica entitatea unei colaborări (opusul tranzacției). Entitatea
colaborării este într-o formă relativ instabilă. Exemplele cuprind
dezvoltarea unei idei, crearea unui design, atingerea unui scop comun. De
aceea, tehnologiile de colaborare reală livrează funcţionalitate mai multor
participanţi. Managementul înregistrărilor şi al documentelor, discuţiile în
mai multe fire, auditul istoricului şi alte mecanisme concepute pentru a
captura eforturile multora într-un mediu gestionabil, sunt tehnologii tipice
de colaborare.
Ca şi o categorie emergentă a software-ului, o platformă de colaborare este o

platformă electronică unificată care suportă comunicare sincronă sau asincronă printr-
o varietate de dispozitive şi canale.
O extensie a groupware reprezintă „collaborative media”, software care
permite mai multor utilizatori concurenţi să creeze şi să gestioneze informaţia intr-un
site web. Modelele de colaborare media cuprind modelele wiki şi modelele Sladshot
(weblog colaborativ - Slashdot-Like Automated Storytelling Homepage).
Printre site-urile cu conţinut disponibil în mod public şi bazate pe software
colaborativ putem găsi: WikiWikiWeb, Wikipedia si Everything2.
În funcţie de metoda utilizată putem clasifica aceste aplicaţii în:
 Unelte de colaborare bazate pe web;
 Unelte de colaboratoare software.
După domeniul serviciului putem clasifica aplicaţiile de colaborare în:

 Unelte de tip knowledge management;
 Unelte pentru crearea cunoştinţelor;
 Unelte pentru partajarea informaţiei;

 Instrumente pentru managementul colaborativ al proiectelor.
Conform WhatIs1, aplicaţiile groupware pot fi clasificate în două categorii,

specificînd dacă membri grupului colaborează în timp real sau nu. Avem, astfel,
groupware sincron (colaborare în timp real între membri unui grup distribuiţi din punct
de vedere geografic) şi groupware asincron.
Cele trei nivele de colaborare
Groupware poate fi clasificat în trei categorii: unelte de colaborare şi de

comunicare, instrumente de conferinţă şi instrumente de management colaborativ.
Comunicarea poate fi asemănată unui schimb nestructurat de informaţie. Un
telefon dat sau o discuţie prin mesagerie instantanee sunt exemple de astfel de
comunicare. Conferinţa (sau nivelul de colaborare) se referă la munca interactivă cu un
scop comun, exemple fiind brainstorming-ul şi votul. Coordonarea se referă la munca
complexă şi interdependentă, orientată spre un anumit scop comun. O bună metaforă
pentru înţelegerea acestui lucru este reprezentată de echipa de sport, în care toţi
trebuie să contribuie la joc la timpul potrivit, ajustându-și, în acelaşi timp, jocul la
situaţia în desfăşurare; toată lumea face ceva diferit, pentru ca echipa să câștige.
Instrumente de comunicare electronică
Uneltele de comunicare electronică trimit mesaje, fişiere, date sau documente,

facilitând astfel partajarea informaţiei. Printre exemple putem cuprinde:
 conferinţa sincronă
 e-mail
 faxul
 mesajele voce
 wiki-urile
 publicarea web
 controlul revizuirilor
Instrumentele de conferinţă electronică
Uneltele electronice de conferinţă facilitează schimbul de informaţii dar intr-un

mod mai interactiv. Printre exemple putem cuprinde:
 forumurile pe Internet - o platformă virtuală de conversaţie utilizată pentru
a facilita şi gestiona mesajele text online;
 chat online - o platforma virtuală de discuţie utilizată pentru a facilita şi
pentru a gestiona mesajele în timp real de tip text;
 telefonia - permit utilizatorilor să interacţioneze;
1
http://searchdomino.techtarget.com/sDefinition/0,,sid4_gci212217,00.html
 conferinţele video - PC-urile în reţea schimbă semnale audio şi video;
 data conferencing - PC-urile în reţea partajează o tablă de date comună
(whiteboard) care poate fi modificată de fiecare utilizator;
 application sharing - utilizatorii pot accesa un document sau o aplicaţie
partajată din computerele lor în mod simultan;
 sisteme electronice de întâlniri (EMS – Electronic Meeting Systems)- un
sistem de conferinţă construit într-o camera; camera are un scop special şi
va conţine un videoproiector mare conectat cu numeroase PC-uri.
Instrumente de management colaborativ
Uneltele de management colaborativ facilitează şi gestionează activităţile de

grup. Printre exemple putem enumera:
 calendare electronice (numite şi software pentru gestiunea timpului) –
programează evenimente, aduc automat la cunoştinţă şi amintesc
membrilor grupului de evenimentele de care sunt interesaţi;
 sisteme de management a proiectelor – programează, urmăresc şi schiţează
paşii într-un proiect, pe măsura ce aceştia sunt finalizaţi;
 sisteme workflow - gestiunea colaborativă a sarcinilor şi a documentelor în
cadrul unui proces de afaceri;
 sisteme de gestiune a cunoaşterii - colectează, organizează, gestionează şi
partajează variate forme de informaţie;
 sistem extranet - colectează, organizează, gestionează si partajează
informaţia asociata cu finalizarea unui proiect (construcţia unei clădiri, de
exemplu) între mai multe organizaţii;
 sistem intranet – colectează, organizează, gestionează si partajează
informaţia asociata cu finalizarea unui proiect (construcţia unei clădiri, de
exemplu) între departamentele unei singure organizaţii;
 sistem de software social – organizează relaţiile sociale ale unui grup;
 foi de calcul online – colaborează şi partajează date si informaţii
structurate.
Aplicaţiile de Colaborare pot fi bazate pe web (de exemplu: UseModWiki sau

Scoop), sau pe sisteme desktop (CVS – Concurent Verions System, sau Revision Control
Systems - RCS).
Implementarea
Cel mai mare obstacol in implementare unui groupware este de a convinge

oamenii să-l folosească. Instruirea este necesară pentru a face oamenii confortabili în
a-l folosi, iar dacă oamenii nu se vor simţi confortabili cu folosirea unui astfel de
software, nu-l vor folosi. Angajaţilor trebuie să li se dea încurajări pentru utilizarea
acestor aplicaţii: răsplăţile pot fi financiare sau psihologice.
In multe cazuri colaborarea este invers proporţională cu cultura organizaţională
a companiei deci implementarea va fi disruptivă. Deplasarea culturii unei companii de
la a fi competitivă la a fi cooperativă nu este o sarcină uşoară. Se vor cere schimbări la

toate nivelele organizației, incluzând în departamentele de conducere.
Unul dintre cele mai mari obstacole este dorinţa tipica a organizaţiei de a
standardiza cunoştinţele practicate precum şi acela de a implementa instrumente şi
procese care susţin scopul organizaţiei respective. O valoare mai mare şi o
implementare mai rapidă pot fi realizate prin evitarea zicalei “un software care se
potriveşte peste tot”. Îndemnând oamenii să adopte acelaşi rol activ (de exemplu
contribuţia produsă şi măsurată de numărul de încărcări/upload-uri) produce doar un
comportament condus de expresia “jocul există după regulile după care este jucat”.
Cultivarea practicii de colaborare în locul în care aceasta înfloreşte din propria voinţa
aduce cele mai rapide beneficii.
CMS şi integrarea cu sistemele de comerţ electronic
Un sistem de management a conţinutului web bine organizat ar trebui să

faciliteze vânzarea de conţinut electronic. Atât sistemul WCM, cât şi front-end-ul de
comerţ electronic trebuie să fie integrate pentru a oferi servicii de comerţ electronic ce
exploatează în mod optim caracteristicile conţinutului ca şi bun electronic.
In contrast cu celelalte sisteme cu care un CMS se integrează, web-ul şi sistemul
de comerţ electronic oferă serviciile lor unui public mai larg şi, din această cauză, sunt
mai accesibile din exterior. Aceasta implică automat şi luarea în considerare a
securităţii sistemului.
Componentele aplicaţiilor care se bazează pe tehnologia Active-X sau Java pot fi
mult mai uşor integrate într-o pagina web sau aplicaţii de tipul comerţ electronic.
Totuşi, sistemul poate fi sensibil la separarea părţilor publice din sistem de cele care
stochează şi administrează bunurile. De aici, în contrast cu sistemul de management al
conţinutului web, care face parte din aplicaţia de prezentare (a imaginii organizaţiei pe
Internet), un CMS la nivel de organizaţie ar trebui să furnizeze conţinutul şi informaţiile
relevante într-o formă securizată. O posibilitate este, de exemplu, folosirea schimbului
de mesaje între aplicaţiile web şi CMS-ul. O dată ce conţinutul relevant a fost pregătit
şi aprobat pentru publicarea lui pe web, acesta poate fi ori trimis în mod activ către
aplicaţia de web sau stocat într-o zonă de unde să poată să fie accesat de către
serverul web public. Depinde de workflow dacă conţinutul din acest context este deja
codat pentru publicare pe web sau este doar un material neprelucrat care să fie inclus
în paginile de web. In acest context, formatul mesajelor şi a fişierelor în care se află
conţinutul este crucial. Integrarea poate fi facilitată dacă conţinutul este deja codat
într-un format care poate fi utilizat direct de către aplicaţia web.
In cazul sistemelor de comerţ electronic care integrează conţinut dinamic dintr-
un sistem de gestiune a conţinutului, sistemul de CMS trebuie, de asemenea, să fie
protejat faţă de accesul public. In plus, selecţia conţinutului oferit spre vânzare este un
proces activ şi nu toate obiectele din CMS pot fi oferite/vândute în acelaşi timp. Deşi o
integrare directă prin componentele aplicaţiei şi API poate fi uşor de realizat, este mai
sigur dacă sunt separate cele două sisteme şi se foloseşte schimbul de mesaje şi fişiere
ca tip de integrare.
Conform cu procesul de workflow în comerţ electronic alăturat, există trei mari
interacţiuni între un CMS şi un sistem de comerţ electronic:
Figura 2.2 – Integrarea dintre un CMS şi un sistem de comerţ electronic
1. Livrarea conţinutului informaţional: CMS-ul furnizează metadate şi o

reprezentare proxy a obiectelor conţinut care au fost selectate de
utilizatori. Această informaţie ar trebui furnizată într-un format de schimb,
care să poată fi uşor interpretat, procesat şi inclus în sistemul front-end de
comerţ electronic;
2. Cerere de realizare: este un mesaj de la sistemul de comerţ electronic către
CMS care include identificatorii (ID-urile) obiectelor de conţinut (care
trebuie să fie unice în contextul ambelor sisteme); de asemenea,
informaţiile referitoare la ce va fi folosit şi adresa de livrare a clientului sunt
incluse de asemenea în cadrul informaţiei. Informaţiile despre intenţiile de
utilizare sunt necesare pentru a clarifica drepturile de securitate. Intr-o
organizaţie orientată pe vânzare, acestea fac parte din comerţul electronic.
In acest caz, folosirea informaţiei nu va fi schimbată între cele doua
sisteme;
3. Drepturile de utilizare: CMS-ul trimite un mesaj înapoi specificând situaţia
drepturilor. Acesta reprezintă intrările (input) pentru viitoarele procesări ale
cererilor de vânzare.
O altă interfaţă relevantă în context este interfaţa sistemului ERP, în care este
trimis un mesaj referitor la folosirea obiectelor de conţinut. In plus, sistemul necesită şi
o interfaţă pentru sistemul de livrare. In cazul livrării electronice, conţinutul necesar
este livrat prin reţele cu viteze foarte mari, sateliţi, etc. Aceasta este echivalent cu
schimbul de conţinut între două organizaţii, cum ar fi informaţii în fişiere formatate
standard şi un subset de metadate care ar trebui livrate codat în formatul specificat.
2.1. CAPTURĂ DE DATE ȘI DE DOCUMENTE
Este inevitabil ca fiecare companie să genereze și să proceseze informații

stocate pe suport de hârtie. Aproximativ 95%1 dintre înregistrările unei companii
tipice sunt constituite din documente pe suport hârtie.
Pentru mai mult de o decadă, industria a oferit o varietate de soluții pentru
managementul electronic al informațiilor in locul celor pe suport hârtie. Soluțiile
tradiționale includ:
 Sisteme workflow: Prin acestea se rutează automat imagini ale
documentelor de afaceri, (scrisorile și diverse formulare) în cadrul
organizației;
 Sisteme de prelucrare a imaginii: Gestionează imaginile stocate, ceea ce
oferă o clasificare mai sofisticată și o recuperare mai bună decât
tradiționalul sistem de stocare și recuperare a documentelor;
 Sisteme de management al documentelor: Salvează fiecare document, dând
posibilitatea unei organizații să urmărească datele și textul concomitent cu
modificările apărute (făcute mai multe persoane) la nivelul documentelor;
 Sisteme de stocare și recuperare: Stochează documentele cu un index de
etichete (numele clienţilor, ID, și numărul de telefon, de exemplu), dând
posibilitatea operatorului să găsească repede informații din baza de date
utilizând una sau mai multe etichete din index;
 Aplicații verticale: Acestea îndeplinesc cerinţele specifice de procesare
datelor în piețele verticale (organizațiile de asigurări și de sănătate, de
exemplu), oferind aplicații customizabile cuplate cu hardware de selectare a
imaginilor.
Aceste tehnologii sunt frecvent tratate ca sisteme de management a

documentelor, document imaging, management al conținutului , managementul
electronic al conținutului, soluții de workflow sau sisteme de management a
cunoștințelor. Indiferent de numele ales, acestea oferă un mecanism de a controla
mari colecții de documente cu scopul de a:
 Salva documentele într-un spațiu fizic mai mic, conservând o copie a
originalului în formă electronică.
 Accesarea informațiilor stocate în documente rapid , ușor și simultan.
 Accesarea informațiilor de la mai multe rețele de calculatoare interne sau
externe.
1
Captiva Software Corp, 1999
Este clar că soluțiile de scanare a documentelor oferă beneficii excelente
afacerii. Din păcate totuși, aceste soluții adesea au o funcționalitate limitată în ceea ce
priveşte volumul de captură; ele se concentrează pe managementul, stocarea și
livrarea documentelor din controlul lor, dar nu oferă cea mai bună configurație
scalabilă sau întreprinzătoare croită pentru nevoile unice ale unei companii. Acesta
este motivul pentru care captura documentelor a evoluat într-o afacere de sine
stătătoare.
Procesul de captură
Captura informațiilor reprezintă procesul de convertire a informațiilor stocate

pe suport de hârtie, directoare de fax sau în alte formate electronice, în date digitale
astfel încât ele sa poată fi procesate și stocate printr-o varietate de tehnologii pentru a
fi consultate ulterior.
Înainte ca informațiile dintr-un document să devină date utilizabile trebuie să
fie efectuate mai multe operaţii diferite. Operaţiile aplicate fiecărui document și
ordinea în care acestea trebuie efectuate constituie fluxul unui proces de captură sau
Capture flow. Fluxul de captură este un concept critic pentru că nu fiecare document
se supune aceluiași set de sarcini, nici fiecare proces de afaceri nu necesită aceleași
informații dintr-un document.
Aceasta nu trebuie confundat cu fluxul de lucru (workflow); datele trec prin
mai multe stagii în timpul vieții lor utile din principala linie a unei aplicații de afaceri.
Un sistem electronic tipic care execută captură de informații este compus din
elemente software și hardware care execută următoarele funcții:
1. Pregătirea documentelor
2. Captura imaginii
3. Extragerea și validarea datelor
4. Exportarea datelor
5. Managementul sistemului și raportarea
Figura 2.3 - Procesul de ansamblu de captură a documentelor.
Pregătirea documentelor
Birourile de scanare profesională dedică în mod frecvent mai multe ore-om

pregătirii documentelor decât scanării efective. Această fază inițială necesită personal
disponibil care să examineze și să pregătească documentele pentru procesul de
captură. Acesta include eliminarea agrafelor/capselor sau a altor elemente fizice care
sunt inacceptabile, în timp ce se asigură că paginile individuale nu conțin mâzgălituri
sau colțuri îndoite.
În majoritatea cazurilor este vital să se pre-sorteze sau să se creeze grupuri
logice de prioritate pentru procesul de scanare. Aproape toate aplicațiile de captură
procesează serii distincte de lucru decât sa accepte paginile într-o manieră ad hoc.
Spre exemplu, separarea cererilor de revendicare de formularele de garanție dă
posibilitatea unei linii de procesare și, în final, a unui mediu de lucru mai eficient. Acest
lucru de asemenea oferă o un prim pas pentru contabilizare și audit, vital în multe
modele de afaceri.
Captura imaginilor
Scanarea unui document produce o imagine grafică ce poate fi apoi stocată

într-un calculator ca o reprezentare digitală a originalului. Când se alege un scanner,
există o serie de criterii ce trebuie respectate. Dimensiunile, volumul și calitatea hârtiei
și, bineînțeles, costurile de funcționare, trebuiesc luate în calcul înainte de a selecta un
scanner. Abilitatea de a folosi o gamă largă de scanere este una care definește
caracteristicile unui sistem bun de captură de imagini; există un exces de 250 de
scanere create pentru un volum mare de scanări care sunt folosite în mod normal1.
Merită luat în considerare avantajul unui Automatic Document Feeder (AFD).
Acest dispozitiv dă posibilitatea utilizării unui teanc de hârtie și automat să se tragă
câte o pagină în scaner, mărind viteza procesului de scanare semnificativ. Majoritatea
scanerelor fără AFD sunt create pentru a scana elemente grafice și nu sunt potrivite
pentru captura de documente. Totuși, unele documente care au fost deteriorate sau
răsucite, cărți și pagini cu note adiționale atașate fizic, etc. au nevoie de o scanare pe
un scaner tradițional.
Scanerele pot gestiona o varietate de dimensiuni de hârtie, de la cărți de vizită,
la schițe tehnice. Majoritatea birourilor au nevoie doar de scanare de documente pană
la A3 dar, pentru organizațiile care au departamente care utilizează planuri sau schițe
arhitecturale, există scanere cu formate mari care suportă până la documente A0.
Viteza sau trecerea prin scaner a documentului este demnă de luat în seamă.
Tipic, scanerele de captură de documente suportă intre 6 și 200 de pagini pe minut în
mod simplex sau duplex. Scanarea duplex dă posibilitatea scanării ambelor părţi a
paginii dintr-o singură trecere. Evident, viteza mare și scanarea duplex măresc costul
scanerului. În unele cazuri, două scanere de 20 pagini pe minut oferă avantaj
semnificativ decât unul de 40 de pagini pe minut, din motive software sau de operare.
De reţinut că nu toate sistemele de captură a documentelor suportă mai multe
scanere, în timp ce la altele pot exista restricţii licență sau de performanță.
Tehnologiile avansate au permis producătorilor de scanere să creeze dispozitive
care sunt capabile să scaneze paginile color, în plus față de tradiționalul alb și negru.
Aceasta oferă un avantaj semnificativ pentru privitori, o pagină color adesea conține
informații utile care se pierd în alb/negru, deși ar trebui luat în seamă și creșterea în
mărime a fișierului și a timpului de scanare. Din nou, unele softuri de captură sunt
capabile să accepte atât rândurile color cât și cele alb negru, rutându-le pe amândouă
prin procesul de extragere a datelor și livrând diferite imagini, fiecare optimizată
pentru Internet sau folosire tradițională într-un software client.
Majoritatea distribuitorilor pot oferi un indicator al sarcinii recomandate pentru
produsul lor și asta ar trebui luat în considerare; o mașină cu sarcină de lucru mare
utilizează materiale mai robuste și necesită o testare mai bună în faza de design și, de
obicei, acest lucru se reflectă în prețul de cumpărare. Totuși, rezultatul constă într-un
număr mult mai mic de întreruperi neplanificate, fapt adesea mult mai valoros pentru
multe operații.
Este important să existe posibilitatea de a prelucra şi îmbunătăţii calitatea
imaginilor aplicând diferite tehnologii cum ar fi creșterea contrastului, tăierea
marginilor, reconstruirea caracterelor pierdute și eliminarea neclarităților. A devenit
foarte comun ca aceste tehnologii să fie găsite într-un scanner iar variantele automate
îl scutesc pe utilizator de diverse reglaje, fapt care, de asemenea, ar trebui luat în
considerare. Trebuie menţionat de asemenea ca modificările duse unor imagini o pot
face pe aceasta inutilă în justiție dacă un audit de securitate nu poate dovedii ce s-a
întâmplat, de cine și când relevant în cazul ştergerilor unor pagini goale (când softul
șterge automat paginile pe care le consideră goale). Pentru a evita acest lucru, unele
sisteme de captură permit exportarea imaginii originale și/sau a unor variante
modificate în diverse stagii.
1
Pixel Translations, 2004
Asigurarea calităţii este de asemenea considerată parte intrinsecă a capturii de

imagine. Implementarea unor opțiuni pentru rotirea imaginilor, ordonarea lor sau
pentru o calitate optică suficient de bună pentru o captură cât mai acurată ar trebui
luate în considerare.
Este imperativ ca softul de captură să ofere o posibilitate de rescanare.
Imaginile cu o calitate slabă, rotație incorectă sau alte probleme, ar trebui reprocesate
fără a întrerupe orice sarcină sau adăugând întârzieri evitabile întregului proces.
Prepararea bună a documentelor are un impact semnificativ asupra ratei de greșeală,
rotirea incorectă a paginilor, documentelor deteriorate sau îndoite, care pot fi evitate
în majoritatea cazurilor cu o bună pregătire.
Există două metode de rescanare detaliată: la cerere și off-line. Cea la cerere
corectează imaginea folosind un soft în timpul scanării. Deoarece întrerupe scanerul,
este mai des folosită la un volum mai mic de date unde trecerea prin scaner nu este
principalul motiv de îngrijorare.
Rescanarea off-line este aproape tot timpul de preferat din mai multe motive:
1. Investiția făcută în scanere performante este eficientă deoarece mașinile
lucrează majoritatea timpului;
2. Un scaner diferit poate fi optimizat pentru această sarcină (folosirea unui de
tip flatbed decât unul cu tragere automată, de exemplu);
3. Scanerele au o gamă largă de setări ce pot fi ajustate care afectează
imaginea rezultată și un operator dedicat de rescanare va învăța care
opțiuni sunt mai bune pentru fiecare imagine, minimizând timpul folosit
pentru această operație.
Figura 2.4 - Diagrama fluxului de rescanare.

Captura de imagini poate include un element al importării unui document
electronic (spre exemplu faxuri, emailuri, documente word și altele) și, deși necesitatea
unui scaner nu este obligatorie, mulți dintre distribuitorii aplicaţii de captură de
documente o integrează în faza de scanare a procesului lor pentru a beneficia de
avantaje la extragerea datelor și regulile de validare din stagiile următoare.
Extragerea datelor
Când documentele de hârtie sunt primite la un birou ele trebuiesc organizate

pentru a fi utile, fiind sortate, etichetate, ștampilate puse în fișiere și arhivate într-un
dulap. Fără acești pași nimic nu poate fi găsit într-un loc de muncă foarte ocupat, iar în
cazul documentelor electronice, procesul este similar. Un sistem de scanare a
documentelor trebuie să conțină un sistem comprehensiv de indexare, care să
organizeze documentele pentru folosirea lor viitoare și accesarea lor rapidă, iar
extragerea precisă a datelor folositoare reprezintă temelia oricărei soluții bune de
captură; nu există nici un motiv pentru extragerea de informaţii eronate, indiferent cât
de repede se poate face, pentru că pierderea unei cantități mari de timp pentru a
verifica dacă aceste date sunt precise, va compromite întreaga investiție iniţială în
tehnologie.
Există mai multe căi de a asocia informații cu o imagine:
- Introducerea manuală a informațiilor care identifică imaginea și fișierele
capturate;
- Aplicarea recunoașterii optice sau inteligente a caracterelor (OCR/ICR) și
tehnologii de recunoaștere a codului de bare dintr-o imagine în vederea
extragerii datelor alfanumerice. Acest lucru poate include, de asemenea,
recunoașterea căsuțelor bifate sau a opțiunilor cu alegere multiplă;
- Aplicând tehnologii de procesare a formularelor (indentificarea
formulalelor, de exemplu) pentru a diferenția diferite tipuri de documente.
Introducerea manuală a datelor
Introducerea tradiționala a datelor sau „Key from Image” poate fi laborioasă și

scumpă dar are avantajul că este foarte precisă. Numărul de câmpuri și lungimea lor
medie formează baza pentru calcularea întregului cost de introducere a datelor, iar
cercetările indică faptul că operatorii sunt capabili să introducă date între 8000 și
11000 caractere pe oră pentru input alfanumeric. Operatorii de tip „Key from Image”
sunt subiecții unei rate naturale de eroare, fapt care trebuie luat în considerare.
O medie a industriei pentru greșelile unui singur operator este de 2,2%1, deși
intrările pe două canale (unde un al doilea operator introduce de asemenea date în
sistem, compară cele două valori) o scade semnificativ. Evident, pentru câmpurile
semnificative din sistem, se impune introducerea pe două canale. Adițional, ar trebui
folosit ghidajul documentarului BSI BIP0008. Parafrazând: operatorul care scanează
documentul nu ar trebui să fie același cu cel care verifică indexul datelor pentru ca
1
Census 2000 Testing, Experimentation and Evaluation Program, iulie 2003
sistemul să se alinieze la standarde1. Totuși, ca regulă generală, trebuie să existe trei

câmpuri pe document pentru a minimiza erorile (probabilitatea ca toate cele trei
câmpuri dintr-un document să fie greșite este statistic foarte scăzută).
Tehnologia „Key from Image” este ideală pentru documente disipate. Prin
natura lor, acestea sunt dificil de automatizat și necesită inteligență umană și
operatori care cunosc terminologia documentului. Prin urmare, acest fapt presupune
frecvent folosirea unei persoane mai pregătite în domeniu decât a unui funcționar, mai
eficient din punct de vedere al costului.
Figura 2.5 – Procesare de tip „Key from Image”.
Unele instrumente măresc viteza procesului de tastare, un foarte bun exemplu

fiind asistentul de index OCR. În acest exemplu, aplicaţia transformă documentul în
OCR și prezintă imaginea și textul aferent operatorului care folosește mouse-ul pentru
a selecta textul pe care doreşte să-l indexeze. Folosind această tehnologie ratele de
tastare pot depășii de 10 ori media din industrie minimizând costul de instruire și astfel
reducând costul total al sistemelor de captură.
Oricare ar fi baza tehnologiei, un avantaj semnificativ al „Key from Image” este
interfața interactivă, unde date din unul sau mai multe câmpuri pot fi folosite pentru a
interoga o sursă îndepărtată (fișiere, baze de date, sistem LoB) deci împrospătând
datele de referință și alte informații. Permițând interacțiunile cu un operator instruit,
interfețele pot simplifica captura de date și crește precizia.
OCR OMR ICR și codul de bare
Recunoașterea optică a caracterelor tipărite (OCR) și citirea codurilor de bare

sunt forme prestabilite ale automatizării. Ratele de precizie sunt variabile care țin de
scaner sau de calitatea documentului, dar testele indică că 0,04% din OCR-uri și
1
A Code of Practice for Legal Admissibility and Evidential Weight of Information Stored Electronically,
2004
0,00002% din codurile de bare au fost greșite chiar în condiții ideale. Experiența
practică din Marea Britanie sugerează că OCR-urile brute și necorectate oferă
aproximativ 10-30% rebuturi în timp ce codurile de bare sunt citite corect, dat fiind
faptul că imaginea are o calitate suficient de bună.
Este important de notat diferența dintre greșelile de substituire și rebut. Rata
de rebut a unei erori este cea mai citată și reflectă numărul de caractere citite greșit
sau recunoscute de program ca citite greșit; o eroare de substituție este clasificată ca
citită greșit și interpretată incorect dar care nu este marcată corespunzător. Un
exemplu este ca programul ar trebui să citească un ”c” și îl recunoaște ca un ”e” iar
greșeala nu este identificată.
În plus este o diferență substanțială între rata de ratare dintre caractere și
câmpuri. Considerând un document care are 10 câmpuri fiecare cu câte 10 caractere și
motorul OCR susține că rata de a da greș este de 20% rezultă că fiecare caracter are o
șansă de 1 la 50 de a fi greșit și atunci potențialul de eroare a întregului câmp este de 1
din 5 adică 20% pentru exemplu următor.
100 de caractere cu 2 greșeli. Un câmp cu un nivel de 20%
Figura 2.6 – Identificarea greşită a caracterelor în OCR.
Acest lucru este inacceptabil în multe medii, fiind necesare verificări adiționale,
referințe încrucişate sau validări externe. Zonele OCR sunt frecvent asociate cu diferite
câmpuri de index cu zone unice din document. Spre exemplu: dacă un număr de
referință este adesea tipărit în partea de sus stânga a unui document, este foarte
posibil să se configureze multe sisteme astfel ca regiunea să fie procesată în OCR și
datele rezultate să fie aplicate câmpului relevant. Este important ca fiecare document
să satisfacă niște criterii de bază pentru ca tehnica să funcționeze, și anume: toate
documentele trebuie să aibă datele în același loc și să folosească un font care poate fi
recunoscut, imaginea trebuie să nu conțină îndoituri sau greșeli de poziționare și, ideal,
fiecare item de date, ar trebui verificat cu un câmp secundar în baza unei reguli
definite. Este foarte posibil ca introducerea manuală, cu toate greutățile, ei să fie mai
justificată.
O extensie logică la zona bazată pe OCR este să se citească întreaga pagină,
proces utilizat în mod normal pentru PDF-uri și pentru sistemul de recuperare care
oferă o opțiune de căutare în tot textul. Poate fi mult mai productiv să cauți un singur
cuvânt sau o frază într-un raport mai larg decât să te bazezi doar pe titlu.
Tehnologia OMR (Optical Mark Recognition – Recunoaşterea Optică a

Semnelor) detectează absența sau prezența unui semn și poate fi considerată 99%
precisă1 odată ce este configurată. Notele de mai sus privind acuratețea pozițională se
aplică la OMR mult mai stringent, în timp ce căsuțele tind să fie poziționate în
apropiere.
Fiecare ofertant de tehnologie de captură va furniza specificațiile proprii pentru
căsuța limită dar, în general, este considerată o practică bună ca pereții unei căsuțe să
fie de 2 pixeli lungime. Presupunând rezoluția de 200 dpi aceasta va indica o grosime a
peretelui de 0,25 mm pentru că acest lucru dă softului de recunoaștere o șansă
rezonabilă de a recunoaște marginile de pe toate părțile și astfel diferențiind datele
clienților de fundal. Altă soluție este folosirea cernelii de excludere pentru a face
informațiile statice să se piardă la scanare lăsând doar urmele de stilou. Aceasta poate
avea ramificații legale deoarece imaginea nu mai este o reprezentare rezonabilă a
copiei de pe hârtie și, în plus, poate necesita redesenarea ei.
Recunoașterea inteligentă a caracterelor (ICR) este o extensie logică a

tehnologiilor de recunoaștere citate, dezvoltată pentru a citi date scrise de mână. Deși
este foarte afectată de calitatea și claritatea textului și imaginii originale, rate mai bune
de recunoaștere sunt posibile folosind informațiile contextuale. Recunoașterea
cuvintelor întregi din dicționar este mai ușoară decât încercarea de analizare
individuală a caracterelor în timp ce citirea liniei de total a facturii (unde datele sunt
întotdeauna numerice) este un exemplu de un dicționar mai mic unde ratele de
acuratețe pot fi îmbunătățite mult.
Cunoașterea gramaticii limbii poate fi de asemenea foarte folositoare; este
posibil să fie folosite diferite grupuri de câte trei litere care au loc într-o limbă. Spre
exemplu în engleză ”ion” este folosit mai des decât ”dle” și variate deducții pot fi
făcute pentru a îmbunătății acuratețea.2
Bineînțeles că aceste tehnici au fost dovedite folosind tradiționalul OCR. Este
considerată o practică bună a constrânge scrisul cu căsuțe, așadar încurajând scriitorul
să spațieze scrisul și să tipărească la o mărime rezonabilă astfel maximizând rata de
succes a recunoașteri. Din nou, înregistrarea precisă a paginii este cerinţă pentru orice
aplicație ICR.
În prezent scrisul cursiv de mână este foarte dificil de recunoscut cu orice
precizie rezonabilă și deși diverse organizații examinează aceste sector de piață, nu
trebuie să ne așteptăm să vedem o dezvoltare semnificativă în următorii ani.
Formulare
Recunoașterea formularelor a crescut din zona OCR și primele produse

potriveau textul cu rezultatele așteptate și astfel diferențiau o pagină de alta.
1
Research in Optical Mark Recognition, aprilie 2004, US Census Bureau Acquisition Division
2
Recognition and keying methodologies technical white paper, 2002, Neurascript Ltd.
Tehnologia s-a dezvoltat semnificativ și multe aplicații execută recunoașterea unei
pagini prin mai multe mijloace.
Privire generală asupra paginii (ID dinamic). Tehnica implică de obicei construirea unei
histograme alb-negru a paginii și o compară cu o bibliotecă predefinită. Dacă întreaga
imagine nu corespunde, cele mai multe aplicații vor împărții pagina în cadrane și apoi
compară fiecare secțiune pentru o acuratețe mai bună. Deși abordarea este rapidă,
deoarece histogramele sunt fișiere foarte mici și ușor de creat, este posibil să se obțină
rezultate false, deci aplicațiile tind să ofere o formă de indicator de încredere. Paginile
care aflate sub un indicator prestabilit sunt trecute printr-un proces de identificare
secundar.
Potrivirea din context sau potrivirea cuvintelor cheie. O apropiere în forță care
transformă pagina în OCR și compară textul rezultat cu documentele master. Este
evident folosirea mai intensivă a procesorului dar succesul este ridicat. Este frecvent
singura cale de a diferenția paginile cu număr mare de similitudini. Din nou, aplicațiile
ar trebui să se utilizeze un indicator de încredere pentru a izola limita documentelor.
Figura 2.7 – Recunoaşterea caracterelor din formulare.
Indiferent de tehnologia folosită, este normal să se adapteze procesul cu o

interfață de identificare manuală, pentru a lăsa operatorul să facă o selecţie în fiecare
situaţie în care aplicaţia nu poate să facă o selecție automată. Unele aplicații învață de
la utilizatori. Asta înseamnă că o nouă pagină care încă nu a fost văzută va fi in final
prezentată unui operator și este posibil să se introducă pagina în bibliotecă; paginile
ulterioare cu același tipar vor fi automat recunoscute. Alte aplicații de captură au
nevoie ca biblioteca să fie reconstruită manual ocazional pentru a adăuga noi tipare.
O tehnologie care se dezvoltă rapid este cea a recunoașterii libere a
formularelor. Aceasta este foarte des întâlnită în procesarea facturilor, unde
documentele conțin aceleași câmpuri dar conţinutul este substanțial diferit. În multe
cazuri nu este viabil să se creeze o bibliotecă cu toate variantele posibile deci
recunoașterea liberă a formularelor câștigă teren. Aceasta utilizează OCR din nou,
combinând cu un set de reguli care indică că atunci când cuvântul ”total” apare în text,
următorul set de numere ar trebui citit și stocat în câmpul de Total din baza de date,
de exemplu. Există un număr de variații pe baza acestei idei: în timp ce unele produse
vor folosi numai arborele de reguli, altele le vor mixa parțial cu identificarea dinamică
și vor crea o bibliotecă de pagini comune, pentru a face mai rapidă recunoașterea
formelor văzute frecvent de sistem.
Indiferent de tehnică, orice sistem de recunoaștere automată a formelor va da

greș în identificarea unor forme, varianta manuală trebuind să existe tot timpul la
dispoziție. În plus, toate motoarele OCR vor rata citirea documentelor care au fost
scanate prost sau sunt foarte slabe calitativ; trebuie luate in calcul la modalităţile de
livrare și la deteriorarea fizică care este foarte posibil să se întâmple la aceste pagini
pentru a realiza că nu este posibil să se citească întregul document în toate cazurile.
Așadar validarea stringentă ar trebui considerată de rigoare în orice mediu unde
integritatea datelor este importantă.
Figura 2.8 - Ruta de scăpare.
Surse importate
Majoritatea sistemelor de captură de azi se confruntă cu documente de hârtie,

dar aproape toate sunt capabile să aducă documentele scanate anterior la un format
de standard industrial și să le proceseze ca și cum ar fi fost scanate. Monitorizând
creșterea în comunicațiile electronice, a devenit foarte important să se accepte
documente standard office iar ele să fie procesate în același fel.
Considerând o ordine de achiziționare: acesta poate veni prin fax, hârtie sau
email, totuși procesul care survine ar trebui să fie același. Astfel, industria se îndreaptă
spre o perspectivă a unui ”document global” unde orice fișier poate fi acceptat. Fiind
considerat un fel de „căsuță poştală digitală”, acest lucru conduce la un beneficiu
semnificativ pentru un departament mare. În practică, pentru a recunoaște și a
procesa documente, se folosesc toate tehnologiile menționate mai sus, pe lângă un set
complex de reguli de afaceri și de tratare a erorilor; designul și configurația acestor
reguli formează cea mai mare parte a costului de implementare, adesea depășind
costul componentelor software.
Merită să fie luat în considerare ce necesități va avea organizaţia utilizatoare în
domeniul sistemelor de captură; este de presupus că înregistrările de voce vor avea
nevoie de un management la un anumit punct, spre exemplu.
Exportarea datelor
În final, rolul tuturor soluțiilor de captură este de a oferi date în formate

folosibile. Într-un birou tipic, fișierele de hârtie sunt găsite într-un anume dosar, într-un
anume sertar, într-un anume dulap. Este foarte ușor de replicat această structură
folosind dosare și directoare într-un calculator iar aceasta are beneficiul unui cost
foarte scăzut de intrare și o simplă tranziție pentru personalul din birou. La fel,
stocarea documentelor într-un dosar de calculator este adesea o soluție foarte bună
dar, de asemenea, lipseşte complexitatea unor soluții mai puternice; nu există o cale
directă de a căuta în mai multe dosare pentru un document pus greșit, spre exemplu.
Formatul imaginii exportate ar trebui luat în considerare; un format TIFF este universal
acceptat și recunoscut ca un standard deschis, el reprezentând imaginea originală
punct cu punct, nu pierde detalii în timpul compresiei și poate fi citit de un număr
foarte mare de sisteme.
PDF-ul câștigă de asemenea teren ca un format acceptat, fiind în special folosit

pentru distribuție pe Internet, deoarece programul care recunoaşte formatul este
gratuit și se comportă ca un plug-in în toate browser-ele comune.
Figura 2.9 - Fluxul de export.
Considerând că, prin design, sistemele de captură creează un volum

semnificativ de informații, este de multe ori de dorit a avea ca avantaj utilizarea unui
sistem de management al datelor în locuri care să accepte, proceseze și stocheze acest
trafic. Este imperativ ca sistemele de captură să fie capabile să comunice efectiv cu
orice program care le foloseşte, imaginile și datele dintr-un document trebuie
transferate ideal fără intervenție umană, rapid și eficient.
În timp ce toate soluțiile de captură suportă un număr comun de formate de
schimb de date ca CSV, ODBC sau XML, ceea ce se câștigă în aparență prin utilizarea
acestor formate, se pierde prin lipsă de securitate, fiabilitate și posibilitate de
urmărire. Prin definiție, ele exportă date în dosare comune sau directoare și asta nu
este acceptabil din mai multe motive. Astfel majoritatea sistemelor au posibilitatea de
a interacționa direct cu un depozite populare sau soluții de fluxuri de lucru, împingând
documentele și datele în programul de management al documentului într-o locație mai
precisă și oferă un control mai bun al erorilor sau evenimentelor care pot apărea în
timpul acestei migrații.
Managementul sistemului și raportarea
Integrarea și managementul procesului de captură, asigurarea siguranței și

raportarea statistică și a rezultatelor sunt sarcini vitale secundare pentru orice flux de
captură.
Figura 2.10 – Integrarea procesului de captură a documentelor cu alte procese.
Siguranţă și scalabilitate
Programul de captură trebuie sa fie stabil în toate condițiile de operare. Va

avea un impact care nu poate fi contabilizat și permis în sistem o creștere a volumului
de scanare? O creștere în volum necesită mai multe stații de procesare și doar câteva
soluții oferă un produs cu adevărat scalabil; majoritatea pachetelor procesează
încărcături de documente pe rînd, iar adăugarea unui al doilea client de index, nu ar
înjumătăţii timpul necesar pentru indexare. Un produs mult mai scalabil sparge lucrul
în pagini individuale sau documente, doar la acest nivel va fi posibil ca mai multe stații
de indexare să folosească în comun aceeași încărcătură.
În funcţie de mediul de lucru, o soluţie ar fi utilizarea stații de scanare multiple
mici și să fie legate ca să exporte în aceiași bază de date centralizată. În aceste cazuri
merită investigat ce opțiuni permite programul de captură: este nevoie ca indexarea să
fie făcută într-o locație anume sau de un anume utilizator? Ce flexibilitate există în
configurație și va funcționa programul într-un fel suficient de acceptabil pentru
procesul de afacere și utilizatorii sistemului?
Este important de asemenea să se asigure cum soluția va reuși să se recupereze
din dezastru și să se înțeleagă ce impact va avea orice ratare (software sau hardware)
în proces ca ansamblu. Sistemele care merg singure vor opri procesarea imaginilor
atunci când apare o eroare de sistem dar acest lucru nu trebuie să reprezinte cazul
pentru mediu de producție cu mai multe stații de lucru. Soluția client/server
mecanizează o arhitectură care poate mai bine să gestioneze probleme de rețea și de
hardware și trebuie considerată mandatorie în implementări mai mari; recuperarea din
asemenea erori este o caracteristică standard ale acestor sisteme dar, de obicei, nu
este menționată în soluții ale grupului de lucru.
Licențierea programelor de captură este de obicei în funcție de mai multe

imagini care sunt scanate sau importate; o pagină cu 2 fețe este considerată ca 2
imagini. Doar dacă afacerea are un volum lunar foarte stabil și precis, este înțelept să
se considere o licență anuală pentru că acest lucru furnizează variații în încărcătura de
lucru fără a forța cumpărarea unei licențe suficient de mari pentru a funcționa în
vârfuri ocazionale pe lunare. Unele aplicații (tipice client server) vor folosi licențiere
concurentă mai repede decât o rută specificată de mașină. Asta va permite un mediu
mai flexibil de lucru în timp ce mai mulți utilizatori pot folosi aceiași licență dacă
modelele de lucru o permit. Această abordare are un alt avantaj distinct pentru un sit
mai mare: a devenit posibil să se creeze un computer standard și astfel se reduce
nivelul de cunoştinţe al specialiștilor MIS și astfel economisind bani și timp.
Auditul și raportarea
Pentru a ajunge la a pune în practică linii de ghidare curente, este imperativ ca

softul de captură să fie capabil să găsească documentele în timp ce ele sunt în mișcare
în sistem: cine a scanat documentele; cine le-a indexat și cât timp i-a luat; ce se
întâmplă dacă alte operații au avut loc și în final unde au fost trimise datele finale. Ar
trebui luat în considerare dacă este acceptabil să fie modificată o imagine; ca un
exemplu în unele medii vizualizarea documentului este considerată o modificare și
astfel și originalul este reținut. Acest lucru poate fi un rezultat al ștergerii paginilor
goale; în cele mai multe astfel de cazuri este esențial un audit de evenimente ca
acestea; în practică după compresarea imaginilor, o pagină goală ocupă atât de puțin
spațiu încât nu merită bătaia de cap care implică ștergerea ei.
Trebuie, de asemenea, să se asigurare faptul ca informațiile de audit care au
sens să poată fi extrase în diverse momente de timp în timpul acestui proces și nu doar
la sfârșitul zilei.
Figura 2.11 - Raport tipic de date de audit.

Concluzii
Într-un sistem de captură de informații trebuiesc îndeplinite mai multe

obiective înainte ca informațiile dintr-un document să devină date utilizabile, care pot
fi eliberate apoi spre folosire într-o aplicație finală.
Într-un flux de captură particular sunt realizate mai multe sarcini. După cum s-a
văzut, acestea pot cuprinde introducerea manuală de date, validarea datelor și
verificarea calității (strângerea automată de date cum ar fi recunoașterea de coduri de
bare și recunoașterea din câmpuri, mărirea imaginilor) și exportarea. Deoarece fiecare
document poate necesita setul său propriu de sarcini de captură, este important să se
aibă în vedere ca procesul de captură să fie în întregime customizabil pentru a îndeplini
necesitățile curente și de viitor. Este important să fie luate în considerare standarde ce
trebuiesc atinse și să fie aleasă platforma care este capabilă să atingă sau să
depășească aceste obligații.
În următorul tabel se prezintă sumarul celor mai frecvente probleme
întâmpinate de către o organizaţie care achiziționează sisteme de captură astăzi.
Necesități Considerații importante

Noi funcționalități Asigurați faptul că producătorul de sisteme de captură
incorporează frecvent noi tehnologii și produse pentru o
gamă de necesități
Funcționalitatea nu este momentan Asigurați faptul că sistemul de captură are instrumente de
disponibilă sau are nevoie de dezvoltare customizare cum ar fi kit de dezvoltare de module pentru
limba sau limbile pe care le folosiți
Procesarea unui număr mare de pagini Alegeți un sistem de captură de informații scalabil care are
un număr semnificativ și demonstrabil de site-uri de lucru
mari
Suportă noi scanere Asigurați-vă că sistemul de captură suportă drivere de
scanere de standard industrial
Procesează diferite tipuri de documente Concentrați-vă pe sisteme de captură care permit soluției
dumneavoastră sau a furnizorului dumneavoastră să
stabilească fluxul necesar de procesare decât să vă bazați
pe distribuitorul de aplicaţii.
Suportă un sistem de management al Asigurați faptul că sistemul de captură este de la un
documentelor particular distribuitor care poate să demonstreze practic
compatibilitatea programelor și nu are aranjamente de
parteneriat active.
Reguli de afaceri complexe Flux de captură flexibil care poate fi modificat de către
partenerii dumneavoastră IT
Compatibilitate cu alte sisteme, spre Platformă care este în statistici și în audit bogată și care să
exemplu Sarbanes-Oxley poată fi exportată cu ușurință
2.2. DOCUMENT MANAGEMENT SYSTEM
Sistemele de management al documentelor sunt pachete software realizate

pentru a ajuta organizațiile de orice tip în managementul documentelor stocate în
forma electronică precum şi de a realiza trecerea de la documente şi organizări de
documente (dosare, bibliorafturi) din forma tradiționala pe hârtie în formă electronică.
Ele sunt şi un mijloc prin care se gestionează foarte eficient proprietatea intelectuală a
organizației, menţinută în documentele organizației răspândite în diverse rețele, pe
diverse stații de lucru, servere, unele pe hârtie, altele în diferite conturi de mail, în
filiale ale organizației etc.
Aceste sisteme gestionează întregul ciclu de viață al unui document, de la
crearea sa, multiplele sale versiuni realizate în manieră multi-user, stocarea tuturor
versiunilor precum şi realizarea şi stocarea fluxului acestui document în cadrul
organizației, repartizarea către utilizatori, birouri, filiale sau entităţi externe
organizației. Un modul important al unui astfel de sistem este modulul de registratură
electronică, modul prin care se realizează înregistrarea electronica pe registrele
organizației a tuturor documentelor în curs de intrare sau de ieșire, precum şi a
documentelor interne supuse regulamentului de înregistrare pe registre.
Legea arhivării electronice
Intrarea în vigoare a Legii Arhivarii electronice (nr.135 din 2007), completată de

dispozițiile Legii privind Arhivele Naționale, a Legii semnăturii electronice, a Legii
comerțului electronic şi de reglementările în vigoare privind conservarea, accesul şi
protecția informației cu caracter public sau privat, este privită de către jucătorii de pe
piața locală de Document Management drept începutul unui adevărat boom în
domeniu. Mai precis, din momentul în care legea va deveni funcționala, piața va
înregistra o dublare a cifrei de afaceri pe o perioada de un an şi o creștere accelerata
încă 4-5 ani.
Articolul 5 (Capitolul III) din Legea arhivarii electronice, prevede că: „Orice
instituție publică şi orice companie, societate națională sau societate comerciala la
care statul este acționar majoritar are obligația sa arhiveze electronic în condiții
corespunzătoare, pe întreaga durată de păstrare, documentele create sau deținute,
asigurându-le împotriva distrugerii, degradării, sustragerii ori comercializării în alte
condiții decât cele prevăzute de lege“. Efectele colaterale ale acestui act normativ,
coroborate cu cele ale integrării, vor asigura o gamă largă de clienți şi din afara sferei
de acționariat a statului, pe primul loc situându-se instituțiile financiare, companiile de
retail, telecomunicații etc.
Cine are nevoie de o soluţie de Document Management?
Din perspectiva unui editor sau producător de asemenea soluții, răspunsul nu

este prea dificil1 – toate firmele care lucrează cu un volum mare şi aflat într-o creștere
continuă de documente, în care informația se modifică rapid, în care timpul pierdut cu
căutarea datelor trebuie redus drastic, companii cu filiale multiple, care au nevoie de
un grad sporit de securitate a accesului la informație, dar care au nevoie şi de date
actualizate permanent.
Enumerarea de mai sus schițează imaginea unei companii dinamice şi
competitive, care vrea sa rămână pe piață cat mai mult posibil. Iar oferta este
accesibila chiar şi companiilor din categoria întreprinderilor mici şi mijlocii, soluțiile de
gestiune electronica a documentelor nemaifiind apanajul „giganților“. Desigur, în acest
1
Piaţa de Document Management aşteaptă boom-ul, http://www.marketwatch.ro/articles.php?ai=1972
context, intervine problema rentabilizării rapide a investiției, un aspect delicat, greu de
realizat, indiferent de mărimea organizației.
Necesitatea unei aplicaţii pentru managementul documentelor
In multe organizații, informații esențiale sunt „închise“ în teancuri de hârtii sau

în „insule“ izolate de informații electronice. Companiile şi instituțiile sunt copleșite de
cerințele de gestionare a informațiilor, de conformitate cu cerințele legale, diverse
regulamente/reglementari specifice, având costuri de gestionare a informațiilor în
continua creștere. Organizațiile au în mod tipic nevoie de a arhiva volume
considerabile de date pentru perioade mari de timp, în condiții de siguranță, înaltă
disponibilitate şi refolosire facilă, toate acestea la un cost cat mai mic.
Organizațiile sunt preocupate mai mult ca niciodată de managementul
documentelor. Mai mult de 80% din informația dintr-o organizație1 este informație
nestructurată. Datorita exploziei acestei informații, organizațiile au nevoie de soluții şi
strategii pentru a le ajuta la controlul şi transformarea acesteia într-un atuu,
transformarea riscului într-o oportunitate şi reducerea costului utilizării informației.
Îmbunătățirea fluxului de circulație a documentelor vine mai mult din
experiența practica, de zi cu zi: costuri ridicate cu distribuția informației, pierderea
unor documente sau regăsirea greoaie a unor informații, imposibilitatea urmăririi
activității desfășurate, comunicare ineficienta în cadrul organizației, existenţa unor
întârzieri în procesul de aprobare a unor documente, creșterea costurilor necesare
depozitării documentelor etc.
Exista mai multe aspecte care impun utilizarea unui astfel de produs, însă cele
mai evidente ar fi:
 evitarea sincopelor în transmiterea fizică a documentelor;
 reutilizarea informațiilor existente;
 adaptarea la cerințele tehnologice ale partenerilor;
 promovarea unei imagini coerente şi consistente;
 necesitatea încadrării în anumite standarde.
Cerinţe minime ale unei aplicaţii de Document Management
Conform Siveco2, orice aplicație de document management trebuie să aibă în vedere:

 registratură electronică;
 managementul documentelor de uz curent – indexare, versionare,
procesare pe flux, control al accesului, mecanisme de regăsire;
 managementul documentelor din arhiva organizației – digitizare, indexare,
mecanisme de regăsire, control al accesului, interval de păstrare;
1
Document Management de la SOBIS Eficienta pentru success,
http://www.marketwatch.ro/mw/index.php?do=9&tl=0&ar=563&viz=true
2
SIVADOC – ordine în documente,
http://www.marketwatch.ro/mw/index.php?do=9&tl=0&ar=565&viz=true
Un astfel de sistem ar trebui sa includă şi:

 zona de stocare a documentelor în format electronic;
 metodă de adăugare/extragere a documentelor;
 metodă de identificare a documentelor;
 un mecanism de blocare a documentului, în așa fel încât un singur utilizator
să poată modifica documentul la un moment dat;
 control de versiune şi istoric al modificărilor;
 securitate, pentru a controla accesul utilizatorilor la documente;
 metoda de căutare, pentru a regăsi cu ușurință documentul necesar;
 flux de documente, pentru a transmite documentele intre utilizatori într-un
mod structurat.
Funcţionalităţi
DMS - Document Management Systems, sistem de gestiune a documentelor,

reprezintă un set de programe folosite pentru a urmări şi pentru a stoca documente
electronice şi/sau imagini. Sistemul face pare din clasa mai largă a gestiunii
conţinutului, făcând adesea1 parte din sisteme de tip Enterprise Content Management
şi este integrat cu alte sisteme informatice. Sistemele de Document management oferă
facilitați de stocare, versionare, metadate, securitate avansata, indexare, căutare şi
afișare documente etc., după cum urmează:
 Metadatele sunt stocate pentru fiecare document în parte. Metadatele nu
fac parte din documentul în sine, ci conțin informații referitoare la
document, ce sunt atașate documentului, informații suplimentare care sunt
în întregime căutabile, şi care, prin conținutul lor descriptiv, măresc
posibilitățile de regăsire a documentului la o căutare. De exemplu, acestea
pot fi, data la care documentul a fost introdus în sistem şi utilizatorul care a
realizat aceasta operațiune. Sistemul poate, de asemenea, să extragă date
din documente în diferite moduri: OCR, ICR, BCR, patch code (coduri de
separare), batch code (coduri de lot documente), legătură la baza de date
externa, extragere text din documente electronice. Extragerea de metadate
(a întregului text disponibil în documente) favorizează modalitatea de
căutare fulltext. Textul extras din document poate fi stocat ca şi metadata
sau stocat împreună cu imaginea sau separat, ca resursă utilizabilă în timpul
căutării într-o colecție de documente.
 integrabilitatea este capacitatea sistemelor de document management de a
face parte din alte aplicații şi de a funcționa în cadrul acestora ca un modul,
astfel încât utilizatorii sa aibă percepția unui sistem unitar. Aceștia pot
vizualiza documente direct din depozitul sistemului de document
management, pot face schimbări, pot salva noua versiune fără a părăsi
aplicația folosită şi a o deschide pe cea de DMS.
Integrarea sistemelor este disponibilă în general pentru suite de tip "office", "e-
mail" şi "colaborativ", făcându-se folosind standarde deschise de genul ODMA (Open
1
Enterprise Content Management Association, http://www.aiim.org/
Document Management API-standard, recunoscut pentru partajarea fișierelor), LDAP
(protocol folosit în gestionarea identităţilor dintr-o companie, accesului la aplicațiile
corporatiste, securitate şi gestionarea informațiilor de tip organizațional; faţă de
bazele de date relaţionale, un director LDAP prezintă câteva caracteristici importante:
este mai „orientat-obiect”, poate reflecta ierarhii şi prezintă o optimizare pentru
citirea informațiilor stocate), WebDAV (Distributed Authoring and Versioning - permite
manipularea uşoară a documentelor şi scripturilor de pe un server Web şi are funcţii
adiţionale pentru a simplifica controlul versiunilor pentru mai mulţi autori) şi SOAP
(Simple Object Access Protocol - este un protocol de apel al unor funcții de pe alte
servere folosind XML pentru codificarea numelor de funcție apelate, parametri şi
returnarea rezultatelor), pentru a permite integrarea ulterioară cu alte aplicații;
 capturarea de date este procesul prin care se obțin date electronice din
date existente în format fizic, prin scanarea documentelor, aplicarea de
metode automate sau semi-automate de extragere a datelor (OCR, ICR,
transformare de conţinut - procesul de a transforma în text editabil o parte
a unei imagini care conține un document scris de mana, indexare);
 indexarea este operația prin care documentelor le sunt atribuite un set de
date de identificare unice. Indexarea este procesul prin care o componenta
software specializată (numita şi „motor de indexare”) procesează
conținutul, descompunând ”masa de text” în componentele sale
elementare, stocându-le în structuri de liste, alături de alte informații
conexe, cum ar fi locațiile lor relative (unele fata de altele), apartenenta la
document etc. Este o operațiune realizată pentru a simplifica operațiunea
de căutare şi vizualizare a datelor. De aceea, o importanta critica o are
crearea unei topologii de indecșii;
 stocarea documentelor implică şi gestiunea lor şi a ciclului de viața al
acestora: cum sunt clasificate, unde sunt stocate, pentru cat timp, unde vor
fi mutate, dacă vor fi distruse (șterse) şi ce timp de viață au;
 vizualizarea documentelor într-un context electronic poate fi o problema.
Vizualizarea unui singur document după un criteriu unic este o operație
simplă, dar devine complicată dacă utilizatorul căuta documente folosind
mai multe criterii, criterii de căutare parțiale, fraze care pot apărea în
context şi expresii booleene. Aceste operații se realizează folosind o
structura de indecșii implementată intern pe baza de date şi utilizează, de
asemenea, cât mai mult resursele de optimizare existente în sistemul de
gestiune al bazei de date;
 securitatea este vitală în cele mai multe sisteme de document
management. Aceste sisteme corespund unor standarde înalte de
securitate, sunt integrabile cu soluții de semnătură digitală şi soluții de
criptare date. Unele sisteme au un modul de gestiune a drepturilor date
utilizatorilor, ce gestionează profile de utilizatori, roluri, drepturi de acces
pe categorii de documente, permisii individuale pentru orice nivel;
 mediul de lucru colaborativ: implementarea facilitații de "check in/intrare” -
"check aut/ieşire" (luare document în editare) aseamănă DMS cu mediul de
lucru colaborativ. Astfel, un document luat în editare de un utilizator, va fi
disponibil spre citire pentru ceilalți utilizatori până când utilizatorul activ va
debloca documentul;
 versionarea documentelor este un proces ce permite utilizatorilor sa

vizualizeze şi să restaureze versiuni anterioare ale documentelor (acest
lucru se face tot datorită procesului de "check in" - "check out"). Se asigură
astfel managementul modificărilor survenite asupra documentului,
incluzând facilitatea de check out (trimiterea unui document în dosarul de
lucru care urmează a fi procesat de către autorul documentului) şi „check
in” (salvarea modificărilor asupra documentului), în funcţie de modul de
configurare, astfel rezultând o nouă versiune a documentului, urmărirea
reviziilor, controlul versiunilor şi înregistrărilor;
 registratura - gestiunea informaţiilor despre documente: termene de
rezolvare sau de răspuns a documentelor cu posibilitatea de alertare a
persoanelor implicate, gestiunea persoanelor implicate în rezolvarea
documentelor, legătura sau relaţionarea documentelor, gestiunea soluţiilor
sau a rezoluţiilor date documentelor, gestiunea documentelor la a căror
rezolvare participă mai multe departamente/compartimente simultan, cu
evidenţierea rolului fiecăruia şi a stadiului în care se află, generare fişă
document ce conţine toate informaţiile specifice.
Avantaje şi dezavantaje ale implementării unei soluții de DMS
Avantaje
 canalizarea firmei spre activitatea de baza, eliminându-se astfel timpii morți
din punct de vedere al productivității, regăsire, distribuție, accesare,
procesare a informațiilor;
 crearea unui mediu standardizat pentru introducerea de conținut, ducând la
accelerarea proceselor interne în cadrul unei firme;
 disponibilitatea informației atunci când este nevoie de ea;
 eficienta mai mare în manipularea documentelor;
 accesul la informație pe baza unor reguli stricte pentru oferirea unui grad
ridicat de securitate a informației;
 reducerea spațiului necesar arhivarii, eliminând posibilitatea de pierdere a
informațiilor, reducând costurile de manipulare, a cheltuielilor
administrative – consumul hârtiei;
 îmbunătăţirea controlului asupra activității desfășurate, pentru o
comunicare eficientă, reducerea timpilor de rezolvare a sarcinilor;
 scurtarea proceselor de lucru cu documentele cu 50%;
 reducerea consumului de hârtie, costurilor pentru copiatoare, fax, telefonie
şi posta cu minim 30% şi a timpului de distribuție cu minim 80%;
 module interconectate central, ușor de administrat şi utilizat;
 mod standardizat şi unitar de procesare a documentelor;
 facilitarea implementării unui sistem de management al calităţii;
 regăsirea promptă a informațiilor, răspunzând la întrebări de genul
“cine/ce/când/cui?”
 constituirea arhivei electronice a instituției într-o maniera profesionistă,
conformă cu ultimele proceduri legislative;
 posibilități de replicare - cu ajutorul acestor soluţii, datele şi informaţiile,
vor fi disponibile în acelaşi timp în două sau mai multe locaţii;
 reducerea riscurilor - reglementările legale care guvernau odată
documentele fizice se aplică acum şi formatelor electronice. Dacă se
eşuează în menţinerea şi controlul înregistrărilor de orice tip sau nu pot fi
produse ca dovezi legale, atunci poziția organizației, din punct de vedere
legal poate fi afectată, fiind astfel pasibilă de penalităţi, pierderi financiare
şi publicitate negativă. O soluție de document management ajută şi la
prevenirea problemelor prin stocarea, controlul şi protejarea documentelor
business împotriva fraudelor. În plus, furnizează instrumente ce permit
stocarea formatelor de orice tip, incluzând aici fax-urile şi email-ul,
rezolvarea cazurilor legale fiind mult mai uşoară;
 îmbunătăţirea politicilor privind manipularea datelor organizaţiei. Multe
organizații sunt guvernate de politici care specifică cât timp pot fi stocate
datele. O soluție de administrare a documentelor sau a înregistrărilor
optimizează procesele legate de stocare şi dispozițiile implicite. Astfel,
informațiile sunt păstrate cât trebuie, fiind uşor de eliminat atunci când
intră sub incidenta reglementarilor legale sau a politicilor interne.
Dezavantaje
 vulnerabilitatea perifericelor de stocare. Chiar dacă datele sunt centralizate,

ele se află pe un suport fizic (server, hard-disk, CD-Rom, disc optic etc.) care
necesită anumite condiții de depozitare. În plus, ritmul frenetic al evoluției
tehnologice conduce la o învechire rapidă a suporturilor de stocare, ceea ce
impune un sistem mai sofisticat în cazul unei eventuale migrări;
 un sistem dependent de reţea. Fără o rețea locală, un sistem de gestionare
electronică a documentelor nu îşi are rostul, viabilitatea sa impunând
dezvoltarea unui Intranet sau, şi mai bine, a unui Extranet. Inconvenientul
este evident – dacă reţeaua cade, datele nu mai sunt disponibile;
 constrângeri de ordin tehnic şi financiar. Implementarea unei soluții de
Document Management poate fi dificilă în anumite cazuri, când
organizaţiile posedă arhive cantitative importante. În acest caz, aplicațiile
de Document Management necesita resurse hardware suplimentare
importante (servere, linii de comunicație, stații de lucru, scannere rapide,
imprimante etc.). Securitatea informațiilor poate, de asemenea, supralicita
nota de plată;
 Dincolo de toate aceste impedimente, trebuie subliniat verdictul
specialiștilor: în implementarea unei soluții de gestiune electronică a
documentelor dificultatea este mai mult organizațională decât tehnică.
Aceasta deoarece reușita unei implementări este adesea condiționată de
implicarea utilizatorilor, în particular a personalului de conducere.
Soluţii oferite de DMS
Soluții pentru manageri
 Reducerea semnificativă a timpului de lucru alocat pentru gestionarea

documentelor;
 Reducerea spațiului pentru depozitare;
 Reducerea costurilor legate de copiere şi tipărire (echipamente, hârtie,
cerneală)
 Reducerea costurilor legate de mișcarea documentelor;
 Răspuns prompt la cerințele partenerilor facilitat de accesul rapid la
informație;
 Acces securizat la informații (drepturi de acces, documentele stocate sunt
criptate)
 Scalabilitate (investiție etapizată);
 Beneficii imediate (implementare rapida şi etapizată).
Soluții pentru utilizatori
 Ușurința în utilizare;
 Structura de directoare/fișiere în care sunt organizate documentele este
familiară oricărui utilizator;
 Multiplele opțiuni de căutare duc la regăsirea imediată a informațiilor;
 Generarea automata a documentelor va ușura semnificativ efortul de
editare, verificare pentru documentele standardizate;
 Gestionarea centralizată a documentelor în formă criptată sporește gradul
de siguranță;
 Gestionarea oricărui tip de document în format electronic;
 Notificări: cerere pe flux, modificări în directoare de interes etc.
Soluții pentru responsabilii IT
 Instalare rapidă;
 Tehnologii standard în industrie;
 Securitate - acces la documente;
 Securitate - acces la funcționalități – prin interfața de configurare;
 Securitate - pachetele de informații din rețea sunt criptate dinamic;
 Scalabilitate - fiind construita pe o arhitectura n-tier, aplicația permite
extinderea, fără efort, de la nivel de departament, la nivel de companie;
 Deschiderea la solicitările de personalizare a aplicației;
 Client auto-up date - administrarea aplicației client se face de la distanţă;
 Aplicația este disponibilă şi prin intermediul unui browser internet;
 Reducerea traficul intre locații - file servere distribuite;
 Utilizare rațională a echipamentelor de stocare - prin gestionarea
centralizată a documentelor;
Avantaje calitative
Exista şi posibilitatea, teoretică, a calculării creșterilor de rentabilitate per

angajat. Studiile indică faptul că, în mod uzual, aproximativ 80% din informațiile care
circula în cadrul unei organizații sunt informații nestructurate, care nu se pot regăsi în
baze de date, formulare, rapoarte etc. Iar anual, 8% din documentele scrise se pierd
din cauza erorilor de arhivare. În atare condiții, un manager aloca 50% din timpul său
de lucru managementului documentelor. Un alt studiu indica faptul ca un angajat
consumă, în medie, între 3 şi 5 ore căutând diverse informații. Estimând costurile per
ora ale unui manager şi ale unui angajat dintr-o companie, se pot deduce economiile
teoretice pe care le poate aduce implementarea unei soluții de Document
Management.
Componente ale soluţiilor de DMS
Arhivarea electronică
Are mai multe scopuri, dar toate sunt legate de creşterea eficienţei în
manevrarea documentelor. Documentele originale sunt scanate, iar imaginea digitală
este stocată într-o bază de date. Acestei imagini i se asociază diferite câmpuri (de
exemplu: suma, data, număr, nume), după care poate fi localizată. În momentul în care
documentul a fost introdus în baza de date el poate fi detectat cu ajutorul unui
program care face asocierea între câmpurile indexate şi document.
Un prim argument în favoarea arhivării electronice este necesitatea regăsirii
rapide a documentelor. În cazul arhivelor clasice, regăsirea unor documente este un
mare consumator de timp. De foarte multe ori rapoartele pe baza cărora trebuie să se
ia o decizie sunt incomplete (din cauza imposibilităţii găsirii tuturor documentelor ce
concură la realizarea raportului în timp util), iar deciziile pot fi greşite, într-o măsură
mai mare sau mai mică. Şi asta dacă nu se pune problema unor sucursale. În acest caz,
lucrurile se complică şi mai mult: eforturile pentru a deplasa oameni în sucursale sau
pentru a trimite documentele fizice în sediul central atrag după sine costuri mari (şi
costurile cresc cu numărul sucursalelor şi cu gradul de împrăştiere geografică).
O altă problemă a arhivei fizice este spaţiul efectiv ocupat de aceasta. Pentru a
putea fi consultată (cel puţin proiectele care sunt în lucru) arhiva trebuie ţinută în
aceeaşi locaţie cu sediul care le utilizează. Aceasta atrage după sine costuri mari, mai
ales când birourile sunt în locaţii centrale, extrem de scumpe. Un alt factor ce nu
trebuie neglijat în privinţa arhivei fizice este degradarea rapidă a documentelor prin
manevrarea lor repetată. Dacă este vorba de documentaţie scrisă, formate mici A4
maxim A3, pe hârtie, lucrurile mai pot fi încă stăpânite.
Figura 2.12 – Fluxul documentelor într-un DMS.
Există şi riscul distrugerii arhivei fizice din cauze externe: incendii, cutremure,
inundaţii. Mai nou, documentele electronice pot fi admise ca probe în instanţă, dar
pentru aceasta ele trebuie să îndeplinească o serie de condiţii (în principal să respecte
condiţiile impuse de Legea 135 - Legea privind arhivarea documentelor în formă
electronică).
Odată trecută în formă electronică, arhiva poate fi exploatată utilizând un
program de managementul documentelor, program ce are ca scop accesul eficient la
documente, prin clasificarea şi indexarea acestora, scăpându-ne astfel de foarte multe
neajunsuri, dintre care gestionarea variantelor documentelor este doar un exemplu.
Arhiva în formă electronică se poate integra foarte bine în aplicaţiile ERP ale
companiei. Toţi aceşti factori presează asupra companiilor care doresc să-şi mărească
productivitatea şi să-şi transforme arhiva fizică în una electronică.
Cui îi este folositoare o astfel de acţiune de transformare a arhivei fizice în una
electronică? Practic, oricui care are de accesat un număr mare de documente (notarii,
de exemplu), care are nevoie să ia rapid decizii (managerii de companii), care are
nevoie de acces la acelaşi document din mai multe locaţii (companii cu multe
sucursale, sau cu birouri chiar în altă ţară, sau chiar companii unde acelaşi document ar
trebui multiplicat în zece sau cincisprezece exemplare pentru fiecare departament). Iar
dacă ne referim la formate mari (desene), spaţiul mare ocupat şi gradul mare de
degradare al originalelor (ca să nu mai vorbim de costurile cu multiplicarea) sunt
lucruri care vorbesc de la sine.
Pentru documentele ce apar ulterior creării arhivei electronice - contracte,
facturi, scrisori etc., introducerea lor în baza de date se poate face de către client, prin
resurse proprii sau, periodic, prin apelarea la aceleaşi servicii externe care au generat
şi arhiva iniţială. În final, o bună exploatare a arhivei electronice se face doar cu
ajutorul unui program de managementul documentelor. În caz contrar, consultarea
arhivei electronice poate să fie la fel de dificilă ca şi căutarea fizică a documentelor
necesare.
Generarea documentelor în formate standardizate
Fiecare dintre organizații utilizează diverse formate standard pentru realizarea

anumitor documente. Crearea documentelor bazate pe aceste formate standard
devine foarte simplă, prin utilizarea mecanismului de generare automată a
documentelor. Astfel, în sistem sunt încărcate șabloane de documente care corespund
anumitor tipuri de documente create în cadrul activităților desfășurate. În momentul în
care un utilizator va dori sa creeze un nou document care sa respecte un anumit
format standard, nu va trebui decât să selecteze din lista de tipuri de documente pe cel
potrivit, să completeze câteva informații, după care sistemul va genera automat noul
document respectând formatul stabilit anterior prin șablonul corespunzător. De
exemplu, pentru emiterea unei cereri de concediu, se va specifica faptul ca se dorește
crearea unui nou document de acest tip. Sistemul va solicita utilizatorului introducerea
numelui solicitantului, a perioadei dorite şi a numelui persoanei ce va prelua atribuțiile
pe perioada concediului. După furnizarea acestor informații, sistemul va genera un nou
document ce respectă șablonul de cerere de concediu, în care completează automat
informațiile specificate de către utilizator. Acest document va putea fi ulterior
transmis, prin apăsarea unui singur buton, pe fluxul de aprobare corespunzător.
Regăsirea facilă a documentelor
Mecanismele oferite de căutare simplă sau căutare avansată în depozitul de

documente se adaptează oricărui nivel de cunoștințe în utilizarea calculatorului ale
beneficiarilor, precum şi necesitaților de a realiza filtrări bazate pe criterii de
complexităţi diverse. Pentru o căutare simpla, utilizatorul poate specifica numai un
cuvânt sau poate introduce o expresie respectând un anumit format, sistemul
realizând căutări prin toate informațiile relevante asociate documentelor.
Daca se dorește o filtrare mai exactă, numai după anumite criterii, cum ar fi
numele şi asocierea la un anumit cuvânt cheie, acest lucru se poate realiza prin
intermediul mecanismului de căutare avansata. Utilizatorul poate opta pentru catari
atât în informațiile asociate documentului (cuvinte cheie, atribute şi valori ale
acestora, autor, număr de înregistrare) cat şi în interiorul documentului.
Pentru a putea reutiliza proceduri de căutare folosite în mod uzual, sistemul
permite salvarea unor șabloane de căutare. Aceste șabloane pot fi expuse de către
autor şi pentru alți colegi din cadrul organizației.
Securizarea accesului la informaţii
Mecanismul de securitate a accesului este unul complex şi asigură:

 accesul controlat la orice nivel al Depozitului de documente, fie ca acesta
este sertar, dosar sau document;
 accesul controlat la funcţionalităţile sistemului, în funcție de rolul
utilizatorului în cadrul organizației (de exemplu un utilizator simplu nu va
putea modifica fluxurile de prelucrare prestabilite);
 utilizarea mecanismelor de semnătură electronică;
 gestionarea utilizatorilor sistemului, gruparea acestora în funcție de rolul în
organizație şi stabilirea nivelurilor de acces corespunzătoare;
 transmiterea în mod securizat a informațiilor dacă se dorește accesarea
aplicației din afara companiei sau din locații distribuite;
 integrarea cu sistemul de utilizatori existent în organizație, prin utilizarea
standardului LDAP, de exemplu;
 datorită sistemului de securitate şi mecanismului de definire a
responsabilităților, fiecare dintre angajați poate lucra numai cu acele
documente care îi sunt necesare pentru îndeplinirea în bune condiții a
propriilor obligații.
Semnătura electronică beneficiază de recunoaștere legală, având aceeași

valoare cu semnătura olografă. Prin aceasta modalitate creşte şi securitatea, pentru că
orice modificare a documentului, ulterioara semnării, duce automat la invalidarea
semnăturii. Cheia privată, esențială în procesul de generare a semnăturii electronice,
se afla stocata pe un dispozitiv securizat, iar accesul se face în baza unui cod pin.
Semnătura reprezintă un eșantion de date care demonstrează ca o anumita persoana a
scris sau a fost de acord cu acel document căruia i s-a atașat semnătura. De fapt, o
semnătură digitala furnizează un grad mult mai mare de securizare decât semnătura
olografa. Semnăturile digitale permit autentificarea mesajelor digitale, asigurând
destinatarul de identitatea expeditorului şi de integritatea mesajului. Alt avantaj îl
reprezintă mobilitatea, pentru că documentele pot fi semnate şi transmise electronic
de oriunde în lume. O cheie expiră după o anumită perioada de timp, cum ar fi un an,
iar documentele semnate cu o cheie expirată nu mai pot fi acceptate. Totuși, în multe
cazuri, este necesar ca documentele semnate sa poată fi considerate valide din punct
de vedere legal pe o perioada mai lunga de doi ani, cum ar fi concesiunile şi
contractele. Prin înregistrarea unui contract cu o semnătură digitala time-stamping în
momentul semnării, semnătura poate fi validată chiar şi după expirarea cheilor. Dacă
toate părţile implicate în contract păstrează o copie a acestei semnături, oricare dintre
ele poate demonstra că acel contract a fost semnat cu chei valide. De fapt, aceasta
semnătură poate confirma valabilitatea contractului chiar în cazul în care cheia unui
semnatar a fost compromisa după ce acesta a semnat contractul. Orice document
semnat digital confirmă faptul că valabilitatea semnăturii poate fi verificata şi după
expirarea cheilor.
Captura de date din formulare
 reduce costurile şi timpul de procesare manuala a formularelor cu pana la
90%, iar timpul total de procesare cu până la 50%;
 creşte productivitatea prin eliminarea introducerii manuale a datelor;
 oferă posibilitatea dispunerii datelor în timp real;
 îmbunătățește eficienţa proceselor de afaceri;
 acuratețe maxima prin recunoașterea caracterelor (OCR/ICR/OMR/BCR);
 disponibilitatea crescută atât a formularelor cât şi a datelor conținute în
formulare;
 scalabilitate ridicată în integrarea cu aplicațiile şi bazele de date deja
existente pentru a-si extinde funcționalitatea şi performanţa;
 flexibilitate - captura de date atât din formulare şi documente electronice
cât şi din cele tipizate;
 gestionarea întregului proces de introducere a datelor, de la scanare şi
recunoaştere, până la verificarea şi exportul datelor şi imaginilor în soluţii
pentru managementul documentelor, baze de date sau alte aplicaţii;
 permite lansarea scanării şi indexarea documentelor în locaţii îndepărtate
utilizând Internetul sau Intranetul;
 oferă opţiunea programării documentelor atunci când acestea sunt
angajate în managementul de documente, sau în sistemul de fluxuri de
lucru propriu.
Figura 2.13 – Arhitectura generică a unui DMS.
Personalizare unele dintre soluții sunt concepute pentru a permite

organizaţiilor să dezvolte soluţii fără ajutorul unui programator şi de a se extinde în
funcţie de nevoile afacerii.
Soluții de backup şi recovery: unii furnizorii îşi ajută clienţii în conceperea şi

implementarea soluţiilor de backup şi continuare a afacerii în caz de dezastre pentru
înregistrările aflate pe suport de hârtie, în fişiere electronice, sisteme de email, aplicaţii
de afaceri şi servere.
Fluxuri de documente (workflow) - caracteristice sistemelor de gestiune a

documentelor (DMS), reprezintă o bună metodă de urmărire a proceselor
operaționale, a proceselor de business. Pe scurt, dacă avem un sistem de urmărire a
proceselor bazat pe documente interne, acesta poate fi înlocuit cu unul sau mai multe
fluxuri de documente electronice, implementate în sistem. În orice moment se poate
verifica starea unui flux de documente, etapa curentă, persoanele care au accesat
fluxul şi datele completate în cadrul acestuia. Pe baza acestor date se pot genera
diferite alerte şi rapoarte. Alertele şi acțiunile automate se generează pe baza unor
valori predefinite în sistem, în urma cărora se vor realiza niște instrucțiuni. Rapoartele
vor fi generate în funcție de datele completate, periodic sau la cerere. Exista 3 tipuri de
fluxuri de documente:
 fluxuri manuale în cadrul cărora utilizatorul decide în ce pas trimite
documentul mai departe;
 fluxuri bazate pe reguli, care permit unui administrator crearea de reguli
care sa direcționeze documentul mai departe pe flux;
 fluxuri dinamice, care permit schimbarea fluxului documentului în funcție
de datele completate sau de metadate.
Utilizarea unui asemenea modul determină ca procesele de business să fie mai

eficiente prin automatizarea transferului fluxurilor de informații pe traseele optime,
economisind timp şi bani pentru oricine le utilizează.
Intre componentele fluxului de documente putem regăsi:
 Procesele: descriu ce lucruri trebuie făcute, cum trebuie făcute şi cine
trebuie sa le facă. În ziua de azi, membri organizațiilor îşi petrec majoritatea
timpului în faţa calculatoarelor, care în marea lor majoritate sunt
interconectate, iar pentru a automatiza un flux de documente trebuie sa se
aleagă ce procese se aplică pentru fluxul respectiv;
 Informatia: după ce s-au luat în considerare procesele care intervin de-a
lungul unui flux trebuie avută în vedere informația asociată acestor procese.
Această informație este, în marea ei majoritate, introdusă deja în modulul
de arhivare, deci ea doar va trebui folosită;
 Utilizatorii: cea mai importantă componentă în cele mai multe fluxuri de
documente sunt utilizatorii. Ei sunt cei care creează conținutul, iau decizii,
deleagă activitățile şi supraveghează fluxul pentru a se termina cu succes.
Scopul automatizării proceselor nu este de a face munca utilizatorilor mai
complicată, ci de a-i ajuta să se concentreze pe părţile cele mai importante
ale proceselor. Utilizatorii nu ar trebui să lucreze la întreținerea fluxului de
documente deoarece aceasta ar trebui sa evolueze automat.
Caracteristici ale DMS
Integrare şi modularitate: este permisă integrarea cu diverse aplicaţii.
Accesul la documente prin intermediul portalurilor Web: Un portal Web este capabil
sa răspundă cerințelor de acces mobil la sursele informaționale. Disponibilitatea
soluției de management de documente prin intermediul Web-ului aduce o serie de
beneficii. Astfel, având în vedere că singura cerință pe parte de client este existenta
unui browser Web (aplicație prezentă pe orice calculator), nu va fi necesara instalarea
şi configurarea fiecărei stații care folosește respectiva aplicație. De asemenea,
sistemele informatice de acest tip vor putea fi utilizate fără probleme atât din rețeaua
intranet, cat şi din mediul Internet. Pentru disponibilitatea în cele doua medii nu sunt
necesare eforturi pentru adaptarea aplicațiilor. Utilizatorii pot distribui cu uşurinţă
informaţiile relevante către colaboratori, reducându-se şi mărimea mesajelor e-mail şi
a ataşamentelor prin transmiterea de link-uri.
Asigurarea interoperabilitatii solutiilor de management de document: Dezvoltarea

Internetului a afectat fundamental arhitectura aplicațiilor informatice, determinând
modificări substanțiale în modul de distribuție şi accesibilitate a soluțiilor din aceastaă
categorie. Având în vedere aceste considerente, se poate spune ca accesarea
aplicațiilor prin intermediul unui simplu browser Web a venit în întâmpinarea
necesităților unei lumi caracterizata, printre altele, prin dinamism.
Prin XML şi serviciile Web poate fi asigurat un nivel ridicat de interoperabilitate pentru
soluțiile de management de documente. Prin aceste tehnologii poate fi asigurată
integrarea aplicațiilor de management de documente în medii eterogene. Serviciile
Web sunt o modalitate standardizată de distribuire a aplicațiilor care folosește
Internetul şi tehnologii fundamentale ce stau la baza acestei rețele. De asemenea,
serviciile Web oferă posibilitatea de interconectare a unei palete vaste de aplicații
disponibile pe diferite platforme şi în diverse locații de pe glob.
DMS Open Source
O companie ce cumpără un produs de la un producător tradiţional de software

plăteşte pe de o parte licenţa per entitate (utilizator, CPU) şi asigurarea (suportul), pe
de altă parte; în timp ce utilizarea unui produs open source implică doar costurile
legate de suport.
1.KnowledgeTree este un Sistem de Management al Documentelor Open
Source, ce poate fi folosit fără costuri de licență.
Funcționalităţi:
 Intefata web compatibila cu Internet Explorer şi Mozilla Firefox
 Integrare cu Windows Desktop şi cu Microsoft Office
 Cautare în continutul documnetelor
 Drepturi de acces asupra directoarelor pe baza de utilizatori, grupuri şi
roluri
 Lista de utilizatori se poate sincroniza cu un serve de LDAP sau cu Active

Directory.
Noua versiune KnowledgeTree oferă o platforma open source avansata pentru

administrarea documentelor, pentru companii de dimensiuni mici şi medii sau
departamente organizaționale. Noile facilitați ale acestei versiuni a KnowledgeTree
includ printre altele, funcționalitate pentru căutarea de documente bazata pe Apache
Lucene, compatibilitate PHP 5 şi suport pentru Microsoft Windows Vista.
2.Nuxeo a lansat versiunea 5.1 a platformei open source ECM (Enterprise

Content Management), despre care afirmă că este potrivita pentru marile companii
care investesc în SOA. SOA (Service Oriented Architecture - Arhitectură software
bazată pe servicii) este un tip de arhitectură software care presupune distribuirea
funcționalității aplicaţiei în unităţi mai mici, distincte - numite servicii - care pot fi
distribuite într-o reţea şi pot fi utilizate împreună pentru a crea aplicaţii destinate
afacerilor. Capacitatea mare cu care pot fi reutilizate aceste servicii în aplicaţii diferite
este o caracteristică a arhitecturilor software bazate pe servicii. Aceste servicii
comunică între ele trimiţând informaţii de la un serviciu la altul.
ECM este tehnologia software care permite organizațiilor să-si gestioneze la
nivel global documentele şi procesele de afaceri. Nuxeo susține ca noua versiune a
platformei ECM se focuseaza pe SOA, precum şi pe scalabilitate şi suport, pentru a
răspunde nevoilor marilor companii. Mai exact, ea oferă acum un suport tehnic şi
funcțional de nivel enterprise, patch-uri şi update-uri, precum şi utilitare de
management disponibile în fiecare faza a ciclului de viață al aplicației.
3.eZ Systems dezvoltă un Open Source Enterprise Content Management

System numit eZ Publish, folosit de diferite firme şi instituţii, de la ONU sau US Navy
până la mici magazine on-line.
Furnizori şi utilizatori ai soluțiilor de DMS
Printre companiile ofertante de soluții pe piață din Romania se număra Easy

Software UK-lider pe piața soluțiilor de document management, Advanced Technology
Systems - ATS, Eurocom, Genesys Software, INDACO, Keysoft, Konika Minolta, Matrix,
MGT, Microsoft, Net Consulting, QCT Connect, S&T, Scop, Siveco, Sobis, SoftNet,
Softwin, Star Storage, TotalSoft, UTI Grup, Xerox, XOR, CYCO Software, KOFAX,
Nemesis IT, Albsys GmbtH, Cardiff, Data Management Solutions, Readsoft, Captaris,
FaberSoft Inc, IBM File Net, XOR IT SYSTEMS, ATC ROM, GENESYS SYSTEMS RO,
DIGITAL SYSTEMS, LSI Soft Exim, Autodesk, Spectra Computers, Skill Software, Blue
Project Software, Epicor Software Corporation.
Conform CmsWire1, există următorii producători mari de soluţii Enterprise
Content Management şi Document Management:
1
http://www.cmswire.com/cms/products/
Enterprise CMS
Alfresco Enterprise (J2EE) IXOS (OpenText)
Day Software Microsoft SharePoint ECM
EMC/Documentum Mobius
Content Conductor Nuxeo EP
FileNet (IBM) OpenText
Hummingbird (OpenText) Optika (Stellent/Oracle)
Hyland OnBase Stellent/Oracle ECM
IBM Vignette ECM
Identitech VYRE - Unify
Interwoven ECM
Document Management
Ademero Microsoft SharePoint Server
Astroia Software Microsoft SharePoint Services
ColumbiaSoft Document Vasont
Locator Xerox DocuShare
Group Drive Xythos On Demand
Utilizatori ai soluţiilor de DMS
Firmele de avocatură, băncile, serviciile de securitate, dar şi companiile din

industria aeronautică sunt, în prezent, cele mai interesate de implementarea soluţiilor
de document-management. "ţinând cont de faptul că se vând anual sub 1.000 de astfel
de unităţi hardware, înseamnă că nici măcar 10% din totalul companiilor ce au nevoie
de aşa ceva nu au implementat o astfel de soluţie". De la “clasica” Administrație
Publică, la Ministere şi firme mari, acum astfel de produse se utilizează şi în cabinete
medicale (fişe pacienţi, de exemplu), spitale, cabinete de avocatura, firme de
consultanta, firme din domeniul media …cam peste tot unde ne copleşesc hârtiile,
fisierele, email-urile.
Printre utilizatori se numără: clienti care au implementat soluții de Document
Management Systems de la Sobis: Apulum Alba Iulia, Diana Forest Bacau, Köber Piatra
Neamt, Marmosim Simeria, Pegas Targu Mures, Poliflex Sibiu, Primaria Sibiu, Primaria
sectorului 3 Bucuresti, Primaria Brasov, Primaria Iasi, Primaria Ramnicu-Valcea,
Primaria Satu Mare, Primaria Constanta, Primaria Sighisoara, Primaria Fagaras,
Primaria Cernavoda, Prefectura Braila.
Clienți care au implementat soluții de DMS de la Epicor Software Corporation:
ING Asigurari, Saatchi & Saatchi, Timken, Ericsson, Bosch, Gillette, Coty Cosmetics,
Scania, Macromex, Velux, Sicomed, Agrana Holding, Flamingo Computers, Oriflame,
Coca Cola, Interamerican, Orkla Foods, Romcar, Star Foods, Ductil Steel, Tetra Pack,
Electrolux, Bunge-Cereol, Mobifon, Scandia.
Clienți care au implementat soluții oferite de Microsoft: Uzinexport,
Televiziunea Română, Petrom, Serviciul de telecomunicații speciale.
2.3. DIGITAL ASSET MANAGEMENT
Digital Asset Management constă în sarcini şi decizii cu privire la utilizarea,

adnotarea, catalogarea, stocarea şi regăsirea de bunuri digitate (fotografii, animaţii,
video şi muzică). Sistemele de management a bunurilor digitale reprezintă sisteme
software şi/sau hardware care ajută în procesul de management al bunurilor digitale.
Termenul „DAM - Digital Asset Management” se referă şi la protocoalele pentru
descărcarea, redenumirea, salvarea, gruparea, arhivarea, optimizarea, menţinerea şi
exportarea fişierelor. Conform 1 , există două tipuri principal aplicaţii DAM:
navigatoare/browser-e şi aplicaţii de catalogare. Navigatoarele citesc informaţiile din
fişiere dar nu o stochează in mod separat, în timp ce aplicaţiile de catalogare fac acest
lucru (catalogul de documente este separat de fişierele de fotografii, de exemplu).
Conform 2, DAM reprezintă un lanţ de produse software care permit arhivarea
şi gestiunea conţinutului digital. DAM poate fi oferit prin produse instalate la client sau
ca produse găzduite de către companii specializate care conţin aplicaţii simple la un
capăt al lanţului, soluţii DAM de bază în mijloc şi sisteme şi soluţii de livrare digitală la
celălalt. Produsele care fac parte din spaţiul DAM sunt utilizate pentru gestiunea
statică sau bazată pe timp a conţinutului digital (audio, video, grafică, fişiere CAD,
imagini, imagistică medicală, layout-uri de imprimare, fişiere text, prezentări, foi de
calcul etc.).
Tipuri de sisteme DAM
Pot fi distinse următoarele categorii de sisteme de management a bunurilor

digitale:
 Brand Asset Management Systems – se concentrează asupra facilităţii re-
utilizării conţinutului în organizaţii mari;
 Library asset management systems - se concentrează asupra stocării şi
regăsirii de bunuri de volume mari care nu se modifică frecvent (arhive de
fotografii sau video);
 Production asset management systems – se concentrează asupra stocării,
organizării şi revizuirii conţinutului digital media care se schimbă frecvent
(medii digitale în producţie);
 Digital supply chain services – transmit conţinut digital către detailişti (de
exemplu, muzică, jocuri şi video).
1
en.wikipedia.org/wiki/Digital_asset_management
2
http://www.dpsmagazine.com/content/ContentCT.asp?P=244
Figura 2.14 - Diferenţe între Document Management şi Digital Asset Management
În domeniul gestiunii conţinutul există, de o perioadă de timp, diferite încercări

de clarificare a diferenţelor între soluţiile utilizate în industrie cu diverse acronime:
DM, DAM, WCM, KM, DRM etc. Există totuşi o mare confuzie în continuare, legată mai
ales de rolul sistemelor DAM. Nu sunt, în cele din urmă, bunurile digitale totuşi şi
fişiere? Nu am putea să utilizăm, simplu, un sistem de gestiune a documentelor pentru
gestiunea tuturor fişierelor din organizaţie? Răspunsul pieţei este clar: nu! S-a dovedit
că managementul bunurilor media digitale, întru-câtva asemănător cu gestiune
documentelor, reprezintă o problemă care necesită aplicaţii specializate.
În continuare vom încerca să face această diferenţă între sistemele DAM şi
sistemele DM, punînd în evidenţă şi ce cunoştinţe ar putea fi utilizate în transferul unui
proiect din DM către DAM ca şi facilităţile unice ale produselor de gestiune a fişierelor
media în comparaţie cu fişierele text sau scanate.
În continuare vom face diferenţa între sistemele de gestiune a documentelor şi
sistemele DAM pe baza următoarelor criterii:
 Instrumente şi procese;
 Fişiere şi tipuri de conţinut;
 Utilizări în organizaţii.
Utilizări şi procese
Ceea ce stă atît la baza sistemelor DAM cît şi a sistemelor DM este

reprezentatde funcţionalităţi de gestiune a conţinutului de bază:
 Depozitul: baza oricărui sistem este reprezentată de utilizarea şi stocarea

conţinutului în baze de date, în sistemul de fişiere sau într-o combinaţie
dintre acestea. Acest serviciu cuprinde servicii de depozitare de bază:
controlul versiunilor, clasificare, încărcare şi descărcare de fişiere;
 Metadate: cuprinde descriptori, date administrative şi versionare precum şi
alte relaţii ierarhice, liniare sau de alt tip între obiectele de conţinut;
 Motor de căutare: pentru căutarea de obiecte în depozit pe baza
metadatelor definite mai sus;
 Subsistemul de acces şi de drepturi: defineşte privilegiile şi permisiile care
specifică cine/ce poate vedea şi gestiona diferite obiecte;
 Motor de workflow sau de colaborare: definirea şi programarea sarcinilor
seriale sau paralele.
Metadate
Vocabular
Drepturi
si
Permisii
Multimi
Locatia
Obiectului
Bun digital
Legaturi
Figura 2.15 – Model de bun digital generic.
Aceste similarităţi pot să încurajeze utilizarea sistemelor DM pentru gestiunea

mediilor sau invers. Totuşi, ceea ce distinge un sistem DAM de un sistem DM este
reprezentat de instrumentele periferice şi procesele construite în jurul acestor
elemente de fundal. Tabelul următor face diferenţa între instrumentele şi procesele
utilizate de cele două sisteme:
Procese şi instrumente Document Procese şi instrumente DAM

Management
 Capturează sau scanează-şi-capturează  Integrarea cu aplicaţii de editare media pentru
conţinut prin utilizarea OCR; a oferi acestora acces la depozite (QuarkXPres,
 Integrarea cu procesoare de text (Word, suitele Adobe desktop şi server, instrumente
Acrobat etc) pentru obţinerea conţinutului; video, CAD, Flash, aplicaţii 3-D etc);
 Permit definirea componentelor de conţinut  Dezasamblarea, legarea şi accesul la bunurile
într-un document; media compuse;
 Asamblează documente şi segmente de  Asamblează medii pentru reutilizare (liste de
documente pentru reutilizare; rulare video, seturi de imagini, prezentări în
 Manipulează documente (de exemplu: PowrePoint etc);
elimină sau rearanjează documente sau  Manipularea/transformarea imaginilor (cereri
elemente şi editează/revizuiesc texte pentru live pentru redimensionare sau conversia
cititori); culorilor);
 Permit stocarea eficientă a textului, deseori  Transcodarea video şi cereri pentru micşorarea
într-o varietate de formate, inclusiv în rezoluţiei şi refacerea codării video (MPEG /
Procese şi instrumente Document Procese şi instrumente DAM
Management
formate native şi XML; Real / QuickTime / WMV /etc);
 Oferă facilităţi de căutare specifice textelor  Recunoaşterea şi parsarea datelor implantate
(logica fuzzy, căutare în limbaj natural şi de în fişiere media (IPTC/ XMP etc);
proximitate) şi în mai multe limbi;  Instrumente pentru recunoaşterea imaginilor
 Prezintă rezultate de căutare pe baza pentru căutări vizuale („caută o imagine ca
metadatelor şi a sumarelor; aceasta”);
 Aplică metadate la diferite niveluri în  Instrumente pentru gestiunea fişierelor foarte
documente; mari (multi-GB in producţia video);
 Facilităţi de Gestiune a înregistrărilor  Aplică metadate la diferite niveluri în cadrul
(Records Management) pentru stocarea şi unui bun media;
urmărire, asigurînd astfel păstrarea  Indexare pentru text (ca şi la DM) dar şi
controlată şi ştergerea conţinutului pe bază indexare video, identificarea vorbitorului,
de timp şi de atribute. identificarea feţei etc.);
 Prezintă rezultate grafice ale căutării;
 Watermarking pentru imagini fixe şi în mişcare;
 Gestiunea avansată a drepturilor digitale
(DRM) şi urmărirea utilizării.
Fişiere şi tipuri de conţinut
Setul de instrumente descris mai sus este construit pentru gestiunea diferitelor
tipuri de fişiere. În consecinţă, o altă modalitate de a face distincţia între DAM şi DM
este de a urmări tipurile de fişiere gestionate de cele două sisteme.
Tipuri de fişiere gestionate de sisteme DM Tipuri de fişiere gestionate de sisteme

DAM
În principal fişiere bazate pe Text: Fişiere media:
 Hârtie;  Imagini
 Documente rezultate din instrumente precum  Logo-uri
Word, Excel, PowerPoint etc.;  Documente create de instrumente de tipul
 PDF; QuarkXPres, Adobe InDesign, Illustrator etc.;
 Rezultate sau stream-uri de imprimare din  Audio
diverse sisteme (de exemplu COLD);  Video
 Documente scanate;  Animaţii în Flash;
 Documente şi fragmente XML;  CAD
 Alte tipuri de fişiere text, inclusiv HTML;’  Imagini 3-D;
 Alte imagini şi fişiere multimedia, utilizate ca  HTML;
fişiere binare generice.  PowerPoint.
Unele sisteme DAM pot să gestioneze fişiere bazate pe text de tipul Word sau
PDF în timp ce unele sisteme DM sunt capabile să stocheze şi să gestioneze imagini sau
chiar filme scurte. Cu toate acestea, trebuie înţeles faptul că simpla stocare a acestor
fişiere în depozit nu este suficientă pentru acoperirea tuturor cazurilor de utilizare
pentru gestiunea bunurilor media.
Utilizări în organizaţii
Sistemele DAM şi DM pot fi utilizate în organizaţii în diferite forme pentru

rezolvarea cazurilor şi problemelor specifice ale afacerilor. În mod tipic acest lucru
presupune procese de automatizare.
Soluţiile DM şi DAM sunt utilizate pentru atât colaborare în timpul creării,
revizuirii şi procesului de aprobare cât şi pentru distribuirea diferitelor tipuri de
conţinut. Tabelul următor prezintă câteva dintre cele mai frecvente exemple.
Utilizări ale sistemelor DM Utilizări ale sistemelor DAM

Colaborare şi management pentru: Colaborare şi management pentru:
 Contracte;  Materiale de marketing şi publicitate;

 Documentaţii/manuale;  Kit-uri multimedia pentru presă;
 Politici şi proceduri;  Kit-uri multimedia pentru vînzări;
 Formulare;  Materiale multimedia pentru marketing;
 Cercetare;  Materiale multimedia pentru trainig-uri;
 Declaraţii;  Prezentări ale organizaţiei;
 Articole;  Video on demand (VOD)
 Rapoarte;  Biblioteci media:
 Corespondenţă; o Biblioteci de imagini;
 Fişiere de caz; o Biblioteci video;
 Documente Office generice. o Biblioteci de fonturi;
o Biblioteci de logo-uri;
o Biblioteci pentru PowerPoint
Se poate face distincţie între produsele DAM şi cele DM prin combinaţia de

tipuri de fişiere, instrumente şi prin expertiza privitoare la procesul de creare,
colaborare şi distribuţie a acestor fişiere/ bunuri media. În multe cazuri are sens
existenţă/achiziţia atât a unui sistem DM cât şi a unui DAM.
Multe organizaţii de marketing au văzut în sistemele DAM instrumentele
potrivite pentru reducerea costurilor prin creşterea eficienţei. Combinaţia între
comerţul electronic şi DAM poate fi o sursă importantă de venit independentă de orice
alt sistem (iTunes de la Apple este exemplul cel mai proeminent). Totuşi, pe termen
lung, o strategie de gestiune a conţinutului trebuie să ia în considerare integrarea
sistemelor de gestiune a documentelor cu cele de gestiune a bunurilor media.
Integrarea DAM în cadrul sistemelor de gestiune a conţinutului
Sistemele de gestiune a conţinutului au servit multor scopuri, cu diverse

rezultate şi grade de succes. În acelaşi timp, organizaţiile au început să-şi dea seama că
conţinutul digital reprezintă un element din ce în ce mai important din cadrul afacerii.
Pentru multe companii, proprietatea intelectuală, care reprezintă cunoştinţele de bază
din organizaţie, este cel mai important bun. Proprietatea intelectuală este capturată în
fişiere digitale de diferite tipuri: procese de producţie a bunurilor, instrucţiuni, trening-
uri, cercetare etc. crearea unui plan de lucru total, care să gestioneze această valoare a
devenit un scop strategic pentru acele companii care sunt capabile să planifice pe
termen lung.
Gestiunea conţinutului bazat pe text şi a bunurilor media în mod eficient
necesită, deci, integrarea mai profundă a sistemelor de gestiune a conţinutului. Multe
pachete de gestiune a conţinutului web au început să conţină facilităţi DAM
simplificate pentru a asista departamentele de marketing în prelucrarea imaginilor dar,
uneori, sunt necesare instrumente mai bogate în facilităţi.
Termenul ECM este utilizat acum pentru a descrie diverse combinaţii de
sisteme de gestiune a conţinutului digital. Cu toate acestea, nu există sisteme de tipul
totul-în-unul care să livreze conţinut. Numai în ultimii trei ani sistemele DAM, DM şi
WCM au fost identificate ca baza unei strategii combinate de unificare a conţinutului.
Figura 2.16 – Arhitectura unui sistem DAM.
Gradul de separare a aplicaţiilor este important, totuşi, pentru interfaţă sau

nivelul de prezentare. Un exemplu ar putea fi: conţinutul text extras dintr-un (W)CMS
iar imaginile extrase dintr-un sistem DAM prin apeluri SOAP din interiorul şablonului.
Acest lucru se poate obţine rapid în cazul separării clare a interfeţei cu utilizatorul de
cea a logicii din DAM.
Beneficiile unui DAM
Beneficiile utilizării1 unei soluţii eficiente de gestiune a bunurilor digitale media

pot fi văzute dintr-o varietate de perspective. Lista următoare prezintă un sumar al
beneficiilor utilizării acestui sistem în organizaţii:
1
http://www.digitalassetmanagement.com/benefits.php
 Depozit central de bunuri media digitale, utilizat pentru căutare eficientă de

tip point-and-click sau pentru ordonarea obiectelor asigură acces rapid şi
uşor la obiectele necesare;
 Acces bazat pe web la bunuri digitale din orice loc, în orice moment;
 Reprezentare consistentă a produselor în toate pieţele globale, menţinînd
integritatea brand-ului;
 Acces self-service pentru parteneri interni sau externi pentru comenzi de
bunuri digitale de utilizat pe web sau pentru imprimare, fără ca aceştia să
fie nevoiţi să înţeleagă formatele de fişiere sau spaţii de culori;
 Bunurile media actualizate şi aprobat sunt disponibile imediat pe piaţă şi
promovează noi lansări de produse mai rapid;
 Personalul existent se poate concentra pe competenţe de bază în
comparaţie cu pregătirea bunurilor digitale media, pentru creşterea
eficienţei producţiei;
 Controlul drepturilor de utilizare şi a restricţiilor bazate pe roluri asignarea
de roluri, în vederea obţinerii unui DRM eficient;
 livrarea automată a bunurilor digitale prin Internet pentru acces imediat la
conţinutul digital fără intervenţie umană;
 generarea de rapoarte detailate pentru a determina activitatea utilizării
bunurilor digitate pentru planificări şi strategii de marketing;
 integrarea in sistemele organizaţiei pentru a asigura consistenţa
conţinutului şi a imaginilor utilizate în canale externe.
2.4. MANAGEMENTUL ÎNREGISTRĂRILOR
Managementul înregistrărilor sau Records Management reprezintă totalitatea

activităţilor de identificare, clasificare, arhivare, păstrare precum şi ştergere a
înregistrărilor. Standardul ISO 15489: 2001 defineşte managementul înregistrărilor ca
fiind responsabilitatea managementului de a fi eficient şi sistematic în controlul,
crearea, menţinerea şi utilizarea înregistrărilor, ele fiind principalele informaţii ce
servesc drept dovadă în activitatea economică. Cu toate că definiţia ne duce cu gândul
la un document, o înregistrare poate fi atât un obiect tangibil sau o informaţie digitală
ce are valoare pentru organizaţie, de exemplu certificate de naştere, baze de date, e-
mail, documente office etc. Managementul înregistrărilor poate fi definit ca fiind
controlul sistematic al tuturor înregistrărilor firmei sau organizaţiei în timpul diverselor
faze ale activităţii lor. Scopul managementului înregistrărilor este acela de a asigura
utilitatea înregistrărilor de a face ca acest proces să fie eficient asigurând astfel o
securitate maximă a informaţiilor utile companiei, asigurând accesul şi folosirea lor,
precum şi distrugerea informaţiilor inutile companiei.
Figura 2.17 – Fluxul înregistrărilor într-o aplicaţie de Management a înregistrărilor.
Un sistem de management al înregistrărilor este de fapt un program (un set de

programe) folosit pentru identificarea şi stocarea datelor, precum şi gestionarea
acestora. Aceste programe asigură, în primul rând, securizarea datelor, precum şi
selectarea informaţiilor utile în procesul decizional. Primele programe folosite în acest
scop au fost utilizate de FBI şi poliţie pentru identificarea cât mai rapidă a suspecţilor,
un acces controlat la baza de date bine securizată, astfel economisindu-se timp şi
respective bani. Pe de alta parte gestionarea înregistrărilor la companii, organizaţii nu
are un istoric bogat, însa tendinţa actuală de a informatiza sistemul economic este în
plină amploare, de aceea tot mai multe firme încep să utilizeze sisteme de gestiune a
înregistrărilor, atunci când volumul lor devine din ce în ce mai mare.
Standardul ISO 23081-1: 2006 este un ghid care ajută la înţelegerea şi aplicarea
metadatelor utilizate în cadrul ISO 15489, Informare şi documentare – Managementul
înregistrărilor. Documentul se referă la interesul pe care îl prezintă metadatele pentru
managementul înregistrărilor în cadrul operaţiilor, şi la diversele funcţii şi tipuri de
metadate ce sprijină managementul operaţiilor şi al înregistrărilor. Standardul
defineşte, de asemenea, un cadru pentru managementul metadatelor.
Metadatele pentru managementul înregistrărilor vor prezenta mai multe
avantaje şi vor permite:
 Protejarea înregistrărilor cu valoare de dovadă;
 Garantarea accesibilităţii şi exploatării lor în timp;
 Facilitarea înţelegerii lor;
 Garantarea valorii lor de dovezi;

 Asigurarea autenticităţii, fiabilităţii şi integrităţii lor;
 Susţinerea managementului accesului, al confidenţialităţii şi al drepturilor;
 Facilitarea unei reperări eficace a înregistrărilor.
Figura 2.18 – Sistem de management al înregistrărilor care suportă şi adaptează

utilizatorul final cu practicile obişnuite de lucru.
Cadrul legislativ românesc
Procesul de integrare europeană aduce elemente de noutate in domeniul

politic românesc, şi anume două noi legi, extrem de importante, definitorii alături de
alte acte normative pentru „noua economie“ în România (semnătura electronică,
comerţul electronic, plăţile electronice) au apărut în Monitorul Oficial. Pe 22 mai 2007
a fost publicată Legea nr. 135 din 15 mai 2007 privind arhivarea documentelor în
formă electronică. Legea arhivării documentelor în formă electronică, aşteptată cu
interes de către agenţii economici, dar mai ales de către industria IT, este considerată
un pas important pentru continuarea procesului de dematerializare a documentelor
din societăţile comerciale. Legea creează cadrul juridic general aplicabil creării,
conservării, consultării şi utilizării documentelor în formă electronică, arhivate sau care
urmează să fie arhivate.
Legea nr. 135/2007 defineşte următoarele noţiuni:
a) administrator al arhivei electronice - persoana fizică sau juridică acreditată
de autoritatea de reglementare şi supraveghere specializată în domeniu să
administreze sistemul electronic de arhivare şi documentele arhivate în
cadrul arhivei electronice;
b) arhiva electronică - sistemul electronic de arhivare, împreuna cu totalitatea
documentelor în forma electronică arhivată;
c) furnizor de servicii de arhivare electronică - orice persoană fizică sau
juridică acreditată să presteze servicii legate de arhivarea electronică;
d) mediu de stocare - orice mediu pe care se poate înregistra sau de pe care
se poate reda un document în formă electronică;
e) mesaj electronic - documentul în formă electronică ce conţine date de
identificare privind expeditorul, destinatarul, precum şi momentul de timp
la care acesta a fost expediat, realizat în scopul transmiterii la distanţa a
unei informaţii prin mijloace electronice;
f) regim de acces la document - gradul în care se acordă drept de acces la
document de către titularul dreptului de dispoziţie asupra documentului;
g) sistem electronic de arhivare - sistemul informatic destinat colectării,
stocării, organizării şi catalogării documentelor în formă electronică în
scopul conservării, consultării şi redării acestora;
h) titular al dreptului de dispoziţie asupra documentului - persoana fizică sau
juridică proprietară sau, după caz, emitentă a documentului, care are
dreptul de a stabili şi modifica regimul de acces la document, conform
legislaţiei în vigoare.
Legea înregistrării operaţiunilor comerciale prin mijloace electronice a fost

promulgată prin Decretul semnat pe 19 iulie 2007 de Preşedintele României. Această
lege stabileşte regimul juridic al documentelor în formă electronică ce conţin date
privind operaţiunile economice de schimb sau vânzare de bunuri sau servicii între
persoane care emit şi primesc facturi, bonuri fiscale sau chitanţe în formă electronică.
Legile erau importante şi prin faptul că aliniază România la reglementările europene
din domeniu. Cu alte cuvinte, la 1 ianuarie 2008, se poate naşte şi în România prima
factură digitală.
Promulgarea legii menţionate mai sus deschide oportunitatea implementării
unor soluţii care să asigure suportul proceselor operaţionale de către tehnologiile cele
mai performante. Aceste soluţii permit lărgirea integrării procesului de prelucrare a
facturii dincolo de frontierele departamentului de contabilitate furnizori, către
furnizori, logisticieni şi celelalte compartimente interne care joacă un rol în controlul şi
validarea facturilor. În domeniul facturilor există o serie de probleme generate în
prezent de manipularea acestora în format hârtie. După cum se ştie, duratele mari de
realizare a tranzacţiilor, facturile pierdute, plăţile duble, costurile administrative mari,
nemulţumirile furnizorilor, sunt doar câteva dintre problemele cu care se confruntă
chiar şi cele mai experimentate departamente specializate în operaţiuni legate de
contabilitatea furnizorilor.
Un studiu IOMA şi Gartner, publicat în 2007, arată că în medie 7,5% din facturi
sunt rutate greşit, una din 20 facturi este pierdută, necesitând timp îndelungat pentru
recuperare sau emiterea unui document nou. Extragerea datelor, validarea,
arhivarea/regăsirea înseamnă, conform aceluiaşi studiu, până la 72% din costul de
prelucrare a unei facturi hârtie. Toate conduc la o concluzie indicând reducerea
costurilor de personal cu 87% prin trecerea la prelucrarea electronică. Studiind
alocarea timpului unui departament financiar-contabilitate, rezultă că acesta consumă
66% din timp procesând tranzacţii, şi doar 19% pentru managementul riscului, 11%
pentru asistenţa suportului decizional, şi 4% pentru administrare internă. Facturile
reprezintă, în termeni de volumetrie şi cost, o parte importantă din rutina zilnică a
unui departament de contabilitate. Eliminarea hârtiei şi prelucrarea electronică a

facturilor se pot traduce ca o reducere a costurilor de prelucrare cu peste 50%.
Jacqueline Laye, expert contabil APEX Team, consideră că reducerea importantă
a timpului de prelucrare a unei facturi înseamnă o economie importantă de costuri.
Conform legii privind înregistrarea operaţiunilor comerciale prin mijloace electronice,
facturile vor putea fi emise/primite şi arhivate în mod electronic. Unul dintre iniţiatorii
acestei legi spunea că legea “va desfiinţa factura de hârtie” într-un număr de ani. De
altfel, unele ţări vest-europene, au atins un grad de prezenţă al facturilor electronice
semnificativ în cazul Finlandei şi cuantificat la 20% în cazul Franţei, după aproape patru
ani de existenţă a facturii electronice. Alte studii indică o economie de 1% din PIB-ul
României, obţinută prin reducerea costurilor birocratice ca efect al acestei legi. Aceste
economii ar putea fi realizate prin eficientizarea administraţiei, accesul uşor al
cetăţenilor la instrumente de guvernare electronice, şi prin politica de achiziţii publice
în sistem informatic, cerinţele UE fiind ca, până în 2010, acestea să se realizeze în
proporţie de 50%. Facturile furnizor pot ridica şi o serie de probleme la nivelul
formatului în care sunt recepţionate de către agenţii economici. De exemplu, este
foarte probabil ca firmele de dimensiuni mici să nu fie interesate să investească în
construirea infrastructurii necesare emiterii electronice a facturilor. Din acest motiv, o
companie care optat pentru automatizarea tratamentului, va primi facturi atât în mod
electronic, cât şi pe suport hârtie, în funcţie de furnizorii săi. Pentru a asigura coerenţa
şi unitatea procesului, ea va trebui să recurgă la un sistem de dematerializare a
facturilor sosite pe hârtie, prin scanarea acestora şi introducerea lor în sistemul
informatic.
Conform noii legi, emiterea facturilor se poate face exclusiv în una din
următoarele două modalităţi:
 în formă electronică – trebuie să respecte formatul şi conţinutul stabilite de
lege şi va conţine marca temporală care certifică momentul emiterii şi
semnătura electronică a emitentului facturii
 pe suport hârtie, forma nestandardizată. Baza de impozitare poate fi înscrisă în
valută, dar dacă operaţiunea nu este scutită de TVA, suma TVA trebuie înscrisă
şi în RON. Factura centralizatoare (electronic) se poate întocmi dacă se referă la
livrări de bunuri şi/sau prestări de servicii către acelaşi client într-o perioadă ce
nu depăşeşte o lună calendaristică.
Codul Fiscal şi normele de aplicare ale codului fiscal, precum şi Noul regim de
numerotare şi emitere a facturilor începând cu 1 ianuarie 2007 (conf. Ordinului 2226 –
2006) par a veni în sprijinul desprinderii facturii de suportul hârtie.
Astfel:
- Formularele de factură, chitanţă, avizul de însoţire a mărfii, nu mai au regim special
de numerotare şi tipărire
- Regimul intern de numerotare al facturii se face pe baza unei decizii interne a
administratorului societăţii. Seriile de numere se pot defini anual.
- Folosirea vechilor formulare cu regim special este posibilă cu condiţia menţionării lor
în decizia internă. Elementele componente obligatorii ale unei facturi sunt definite de
Art. 155 din Codul Fiscal. Astfel, nu mai sunt neapărat necesare conturile cu coduri
IBAN, dar şi trecerea unor date cum ar fi cele din Cartea de identitate a emiţătorului,
sau ştampilele şi semnătura furnizorului şi beneficiarului.
Figura 2.19 – Depozitul de înregistrări
Condiţiile pentru emiterea facturilor în formă electronică presupun:

 utilizarea unui sistem informatic omologat de ANRCTI
 garantarea securităţii, fiabilităţii şi continuităţii serviciilor de prelucrare a
datelor
 folosirea de sisteme omologate pentru arhivarea de facturi în formă electronică.
Emitentul trebuie să ţină evidenţa în “Registrul electronic de evidenţă a

facturilor emise în formă electronică”, constituit şi actualizat de MEF. Acest registru
este public, disponibil on-line, actualizat permanent.
Procesul de emitere a facturilor poate fi externalizat, cu îndeplinirea
următoarelor condiţii:
 Furnizorul trebuie să notifice organul fiscal cu toate datele că emiterea de
facturi va fi realizată de un terţ, cu cel puţin o lună calendaristică înainte de a
iniţia această procedură
 Factura să fie emisă de către terţ în numele şi în contul furnizorului
 Factura să cuprindă toate elementele prevăzute de Codul fiscal
 Facturile să fie puse la dispoziţia organelor fiscale competente fără nici o
întârziere, ori de câte ori se solicită acest lucru.
Legea prevede că transmiterea facturilor prin mijloace electronice, în cazul

livrărilor, se poate face cu respectarea condiţiilor:
 Acord încheiat între părţi privind procedura de facturare
 Existenţa unui document centralizator pe suport de hârtie, cu evidenţa tuturor
facturilor transmise într-o lună calendaristică.
 Notificarea organelor fiscale cu cel puţin o lună calendaristică înainte de
aplicarea procedurii
 Garantarea autenticităţii sursei şi integritatea conţinutului facturii
În cazul achiziţiilor, sunt necesare din condiţiile de mai sus doar primele două.
Stocarea facturilor implică numeroase probleme (spaţiu, condiţii speciale), dat

fiind faptul că acestea necesită să fie păstrate şi arhivate pentru un număr de ani.
Pentru facturi pe suport de hârtie, stocarea pe teritoriul României este obligatorie, cu
toate costurile ridicate de spaţiile de arhivă în creştere. Stocarea facturilor emise şi
primite prin mijloace electronice se poate face în orice loc dacă se garantează accesul
on-line, precum şi autenticitatea sursei şi integritatea conţinutului facturilor. Facturile
emise şi primite electronic trebuie puse la dispoziţia organelor fiscale competente,
fără întârziere, ori de câte ori se solicită acest lucru.
Experţii de la firma DocProcess, consideră că există cinci variante alternative de
modelare a procesului generic reprezentat de circuitul unei facturi într-o firmă:
(recepţie-extragere indecşi-control-validare-introducere în contabilitate-arhivare), în
funcţie de gradul de migrare spre factura electronică:
1) Prelucrare tradiţională
2) Dematerializare simplă
3) Dematerializare cu indexare
4) Factura electronică – imagine semnată electronic
5) Factura electronică – document electronic structurat
Exemple de software ce au ca activitate Records Management
Alliance PaperChase Records Management (EDRMS) este un program ce

permite utilizatorului:
 să gestioneze un număr mai mare de înregistrări
 arhivarea înregistrărilor
 securizarea lor
 setează accesul fiecărui utilizator la înregistrări
 urmărește funcţionalitatea şi eficienţa datelor
Figura 2.20 - Alliance PaperChase Records Management.
Docsvault Small Business v2.0 este un program de tip multi-utilizator de

management al documentelor, include instrumente pentru micile firme în vederea
gestionării înregistrărilor într-o reţea locală.
Figura 2.21 - Docsvault Small Business.

Document Organizer Deluxe v2.8 este un program flexibil de management al

documentelor, permite utilizatorilor să obţină şi să organizeze informaţiile în funcţie de
categorie, tip, instituţie, cuvinte cheie, subiect, loc de stocare, note şi altele.
Simply Contacts - Customers and Sales v2.8 este un program ce include

urmărirea vânzărilor, a facturilor pe fiecare client, a datelor de contact având funcţii
atât de management cât şi de marcheting în acelașii sistem, permite accesul instant la
facturi, calculează taxele, arată facturile neplătite, arată istoricul sau fişa fiecărui client,
poate gestiona foarte ușor mii de înregistrări folosind şi datele furnizate de programele
contabile.
Figura 2.22 - Simply Contacts - Customers and Sales.
Mipsis CRM Document Management Software Desciption este un program de

management al documentelor ce permite o fidelizare mai mare a clienţilor printr-un
control şi o securizare a informaţiei, transmiterea automată a documentelor, baze de
date etc.
Figura 2.23 - Mipsis CRM Document Management Software.
2.5. WEB CONTENT MANAGEMENT
Conţinutul web este conţinutul textual, vizual sau auricular care se găseşte ca
parte a experienţei utilizatorului pe site-urile web. Poate să includă printre altele: text,
sunet, imagini, video şi animaţii.
In timp ce Internetul a început cu proiectul de cercetare al guvernului Statelor
Unite în anii ‘50, web-ul, aşa cum este acum în zilele noastre, nu a apărut decât după
ce Tim Berners-Lee şi colegii lui de la Laboratoarele Europene (CERN) au propus
conceptul de a conecta documentele între ele prin hiperlegături. Dar acest lucru nu s-a
realizat decît atunci cînd Moisac, înaintaşul browser-elor de astăzi, a făcut ca Internetul
sa devină mult mai mult decât serviciul unui sistem de fişiere.
Folosirea textului cu legături (hypertextul), a hiperlegăturilor şi a paginilor
bazate pe partajarea de informaţii introduse de Moisac şi mai târziu de Netscape, a
contribuit la definirea conţinutului web şi la formarea site-urilor web. Astăzi există mai
multe categorii de site-uri web, clasificate în funcţie de conţinutul lor web.
Conceptul de Pagină
Conţinutul web este dominat de conceptul de pagină. La sfârşitul anilor 1980 şi

începutul anilor 1990 era posibil pentru orice persoană să scrie şi să deţină o pagină
“Mosaic”; conceptul de “Home page” face ca ideea de pagină să fie neclară, confuză.
Era posibil pentru oricine să deţină un “Home page” sau o pagină web, dar, în multe
cazuri, site-urile web conţineau fizic multe pagini, în ciuda faptului că era numită
“pagină web”.
Deşi reţeaua Internet este principala resursă care se foloseşte pentru accesarea
online a unor locaţii specifice, sunt invocate diferite protocoale pentru accesarea
informaţiilor încapsulate. Când se accesează o adresă cum ar fi “http://
www.youtube.com” este de aşteptat să vedem un domeniu de pagini web, dar fiecare
pagină are instrumente încapsulate pentru a putea reda videoclipurile.
Conţinutul web HTML
Deşi în interiorul paginilor web sunt încapsulate diferite protocoale, acestea

sunt compuse din cod HTML, conţinutul rămânând cea mai importantă componentă a
paginii. In timp ce multe pagini web au o structură particulară localizată (în general
site-urile de afaceri), multe milioane de pagini web sunt structurate conform unei idei
comune.
Blog-urile sunt un tip de site-uri web care conţin, în primul rând, pagini web
create în HTML (chiar daca deţinătorul blogului nu ştie că paginile web sunt create
folosind cod HTML datorită instrumentelor de blogare). Milioane de oameni folosesc
bloguri online; blogul este în momentul de faţă un fel de “home page”, este locul în
care o persoană poate să dezvăluie informaţii personale şi/sau să dezvolte idei pe
anumite subiecte de interes particular. Chiar dacă un blog este scris şi cu alte scopuri,
cum ar fi promovarea unor afaceri, esenţa blogului este faptul că este scris de o
persoană şi aceasta dezvăluie informaţii din perspectiva ei.
Motoarele de căutare sunt compuse în primul rând din cod HTML. Acestea au,
de asemenea, o structură tipică pentru a căuta anumite informaţii. Un motor de
căutare numit şi SERP (Search Engine Results Page) afişează un titlu, în general numele
motorului de căutare şi pe urmă o lista de site-uri web şi adresa lor. Ceea ce este listat
este rezultatul unui grup de cuvinte în care se regăsesc anumite cuvinte cheie. Pagina
rezultată listează pagini web care sunt conectate cu aceste cuvinte cheie.
Forum-urile sunt compuse din conţinut textual organizat de codul HTML sau alt
cod care poate fi văzut într-un browser web. Mecanismul care conduce forumul este
înregistrarea utilizatorilor, care pot posta diferite comentarii. Deseori forumul este
format din întrebările diferiților utilizatori şi răspunsurile altora la aceste întrebări.
Site-urile de comerţ electronic sunt compuse din text şi încapsulate cu afişaj
grafic, cu poza obiectului care trebuie vândut. Totuşi sunt foarte rare cazurile în care
site-urile sunt compuse pagină cu pagină din cod HTML. Utilizatorul vede textul
principal sub formatul unei pagini web, care este deschisă şi vizualizată într-un
browser. Site-urile e-Commerce sunt în general organizate pe baza unui soft care este
identificat sub numele de “coş de cumpărături“.
O viziune de ansamblu a conţinutului de web
In timp ce sunt multe milioane de pagini web predominant făcute cu ajutorul

codului HTML, în general aceste date, aplicaţii, e-servicii, imagini, sunete, şi fişiere
video, pagini personale de web, mesaje de e-mail arhivate şi multe alte forme de
fişiere şi sisteme de date sunt văzute ca fiind parte integrantă din site-uri şi pagini de
web.
Managementul conţinutului presupune că în interiorul unei afaceri există un
grup de oameni care au roluri diferite în managementul de conţinut, cum ar fi autorul
conţinutului, editorul şi administratorul. De asemenea, se presupune că există şi un
sistem de management al conţinutului în care diferitele funcţii sunt organizate pentru
a furniza asistenţă în operarea sistemului şi organizarea informaţiei pe site-urile web.
Sisteme de Gestiune a Conţinutului Web
Un sistem de gestiune a conţinutului web (WCMS – Web Content Management

System) este un software implementat, de obicei, ca o aplicaţie web, utilizat pentru
crearea şi gestionarea conţinutului HTML. Acesta este utilizat pentru a gestiona şi
controla o colecţie de dimensiuni mari şi dinamică de material sau documente web
(documente HTML împreună cu imaginile şi obiectele ataşate). Un CMS facilitează
creare conţinutului, controlul şi editarea acestuia împreună cu numeroase funcţii de
menţinere web.
De obicei, software-ul oferă, printre altele, unelte de definire (creare) a
conţinutului, dându-le utilizatorilor cu puţină experienţă în utilizarea limbajelor de
programare sau de marcare, sau fără nici un pic de experienţă, posibilitatea de crea şi
gestiona conţinut cu uşurinţă relativă.
Cele mai multe sisteme utilizează o bază de date pentru a stoca metadate,
conţinut şi/sau artefacte necesare sistemului. Conţinutul poate fi stocat frecvent şi ca
fişiere XML, pentru a facilita reutilizarea şi pentru a permite opţiuni flexibile de
prezentare1.
Un nivel de prezentare afişează conţinutul către vizitatorii obişnuiţi ai site-ului
pe baza unui set de şabloane, definite deseori sub formă de fişire XSLT.2
Administrarea este făcută de obicei prin intermediul interfeţelor bazate pe
browser-e, dar există şi sisteme care necesită existenţa de aplicaţii special instalate
pentru acest lucru.
Un sistem de gestiune a conţinutului diferă de aplicaţii de editare a site-urilor
web, precum Microsoft FrontPage sau Adobe Dreamweaver, permițând utilizatorilor
netehnici să schimbe site-ul web existent cu puţină pregătire, sau chiar în lipsa
acesteia. Sistemele de gestiune a conţinutului web necesită existenţa unui
programator care să adauge sau să implementeze facilităţi, acestea fiind, în primul
rând, un instrument de menţinere a site-ului pentru administratorii şi utilizatorii
netehnici.
Scopul WCMS
O soluţie de gestiune a conţinutului web simplifică procesul prin care

contributorii/autorii de conţinut creează, publică şi actualizează conţinutului unui site
web. Soluţiile de gestiune a conţinutului web permit nu numai echipei de dezvoltare
web să întreţină site-ul, ci extinde această facilitate în mâinile contributorilor/autorilor,
1
Ethier, Kay, Scott Abel: Introduction to Structured Content Management with XML. CMS Watch
2
Woric Faithfull. Using XSLT to Make Websites. woric.net.
care sunt, în cele din urmă, responsabili pentru conţinut. Simplificat, un sistem de
management al conţinutului web:
 Simplifică procesul de creare, publicare şi actualizare a conţinutului
site-urilor web ale unei organizaţii;
 Permite atât persoanelor ne-tehnice, cît şi experţilor să participe;
 Micşorează timpul şi costurile asociate cu întreţinerea conţinutului
web.
Este important de notat faptul că un sistem de gestiune a conţinutului web este

un cadru de lucru în care resursele umane stau la bază, iar uzabilitatea produsului este
cheia utilizării acestuia. Acceptarea şi adoptarea soluţiei sunt conduse în primul rînd de
uşurinţa utilizării produsului de către utilizatorii finali. Un sistem de gestiune a
conţinutului este o cheltuială în plus dacă nimeni nu-l utilizează sau îl acceptă.
Importanţa conţinutului web
Site-ul web al unei instituţii a devenit principalul instrument de comunicare şi

informare, iar conţinutul din interiorul acestuia este esenţial, de exemplu, pentru
studenţi, părinţi, cadre didactice etc., în cazul unei instituţii de învăţămînt superior. În
acest caz, site-ul web este, deseori, prima influenţă asupra viitorilor studenţi, a
părinţilor, a absolvenţilor. Site-urile web reprezintă suportul cheie pentru informaţii
importante, relaţii publice, recrutări ca şi pentru un număr din ce în ce mai mare de
servicii de bază pentru organizaţie. Amînarea afişării ultimelor informaţii poate avea ca
efect informaţii eronate, frustrarea vizitatorilor şi, în cele din urmă, scăderea încrederii
în organizaţie.
Vizitatorii unui site web trebuie să fie capabili să obţină informaţii actuale,
corecte, astfel încât site-ul să fie o resursă valoroasă. Dacă nu este de încredere, atât
site-ul web cât şi organizaţia îşi vor pierde credibilitatea.
Pentru a complica şi mai mult lucrurile, multe servicii, care odată erau
gestionate de tipografii, au migrat către site-ul web al instituţiei. Migrarea către noile
servicii online depăşeşte cu mult resursele disponibile care ar trebui să le întreţină.
Deseori, din necesitate, vehiculul de bază în comunicare al organizaţiei este lăsat la
urmă iar acest lucru nu este acceptabil pe termen lung.
Beneficiile unei soluţii de WCM
Enumerăm în continuare beneficiile potenţiale ale soluţiilor WCM:

 Creşterea eficienţei – producţie mai mare cu costuri mai mici: un sistem de
WCM ar trebui să diminueze costurile de întreţinere a unui site web prin
reducerea coordonării şi timpului de producţie la implementarea de conţinut
nou şi la actualizări. Acest lucru este obţinut prin eliminarea gâtuirilor din
procesul curent prin distribuirea actualizării conţinutului către mai mulţi
contribuitori/autori de conţinut din organizaţie. Acest fapt ar trebui, de
asemenea, să reducă necesitatea angajării de personal IT suplimentar,
permițând, în acelaşi timp, actualizări mai frecvente;
 Comunicare mai bună şi mai rapidă: actualizările mai dese şi mai rapide permit
îmbunătăţirea comunicării între angajaţi. Dacă este implementat în mod corect,
un sistem de WCM poate elimina informaţii incorecte şi depăşite,
îmbunătăţind, în cele din urmă, imaginea finală şi strategia web a organizaţiei
pe Internet;
 Rezultatul:
o creşterea vizitelor repetate în site-ul web;
o îmbunătăţirea relaţiei cu angajaţii;
o creşterea satisfacţiei vizitatorilor;
o utilizarea mai bună a resurselor tehnice;
o reducerea costurilor;
o creşterea veniturilor obţinute de pe urma site-ului web.
Facilităţile WCMS
Sistemul de management al conţinutului web este adesea folosit pentru

stocarea, controlarea, versionarea şi publicarea documentelor specifice cum ar fi:
articole noi, manuale tehnice, ghiduri pentru vânzări şi broşuri.
Sistemul de management al conţinutului web poate folosi următoarele
caracteristici:
 Importare şi creare de documente şi materiale multimedia;
 Identificarea utilizatorilor după parolă şi rolul lor în managementul
conţinutului;
 Capacitatea de a desemna roluri şi responsabilități la tipuri sau categorii
de conţinut diferit;
 Abilitatea de a urmări şi crea multiple versiuni ale unui singur exemplu
de conţinut;
 Abilitatea de a publica conţinuturi locale pentru a sprijini accesul la
acesta;
Unele CMS permit formatarea automata a aspectului texului. De exemplu,
CMS-ul poate, în mod automat, să seteze culoarea, dimensiunea şi stilul scrisului.
Făcând parte din categoria instrumentelor de gestiune a conţinutului, sistemele

WCM moştenesc de la acestea facilităţile de control al documentelor, de audit, de
editare şi de gestiune cronologică a acestora.
Conform Wikipedia,1 un WCMS oferă următoarele facilităţi cheie:
 Şabloane automate: permite crearea de şabloane de ieşire (afişare), de
obicei folosind HTML, XML şi/sau XSLT care pot fi aplicate în mod
automat conţinutului nou şi existent, creând un loc central din care se
poate schimba aspectul unui grup de conţinut dintr-un site;
 Conţinut uşor editabil: odată ce conţinutul este separat de prezentarea
vizuală a site-ului, acesta devine mai uşor şi mai rapid de editat şi
manipulat. Cele mai multe sisteme WCMS includ instrumente de editare
1
Wikipedia, http://en.wikipedia.org/wiki/Web_content_management_system, 25 ianuarie 2008.
WYSIWYG bazate pe browser, permițând persoanelor netehnice să

editeze şi să creeze conţinut;
 Set de facilităţi scalabile: cele mai multe WCMS au plug-in-uri sau
module care pot fi uşor instalate pentru a extinde funcţionalitatea unui
site existent;
 Actualizări la standarde web actuale: soluţiile WCMS active permit
actualizări frecvente care includ noi facilităţi şi menţin sistemul la curent
cu cele mai noi standarde web;
 Gestiunea fluxului de lucru: workflow-ul este procesul de creare de
cicluri de sarcini cu execuţie secvenţială şi în paralel, care trebuie, în
acest caz, să fie îndeplinite sau executate de către WCMS. De exemplu,
un autor de conţinut transmite un articol pentru publicare pe un site,
dar acesta nu este publicat imediat ci este revizuit şi/sau aprobat de
editori înainte;
 Gestiunea documentelor: soluţiile CMS pot oferi mijloace de gestiune a
ciclului de viaţă a documentelor, de la crearea iniţială, revizuiri,
publicare, arhivare până la distrugerea acestuia;
 Virtualizarea conţinutului: sistemele CMS pot oferi utilizatorilor
posibilitatea de a lucra cu copii virtuale ale întregului site web, set de
documente sau cod sursă. Acest lucru permite ca schimbările în resurse
interdependente să fie vizualizate şi/sau executate în context, înainte de
trimitere spre publicare/aprobare/etc.
Aspect
grafic A
Conţinut B
Business C
Logic
Figura 2.24 – Fluxul conţinutului într-un WCMS.
Cele mai multe pachete WCMS oferă facilităţi canonice de ECM cu un scop
particular: transmiterea conţinutului către Web în concordanţă cu regulile de afaceri
ale organizaţiei. Produsele mai noi tind să scoată in evidenţă interfeţele bazate pe web
şi să nu mai utilizeze instrumentele proprietare, bazate pe clienţi special instalaţi pe
calculatoarele editorilor. Mai mult decât în alte segmente ECM, WCMS au mai multă
grijă de transmiterea conţinutului către utilizatorii finali. Pe lîngă funcţionalităţile ECM,
pachetele WCMS aduc funcţionalităţi speciale, incluzând:
 Unelte de creare şi transformare a conţinutului: pentru a permite
utilizatorilor să introducă în sistem conţinut care nu a fost normalizat în
HTML sau XML;’
 Gestiunea agregărilor şi componentelor: pentru a combina şi publica
bucăţi distincte de conţinut care ar putea proveni din surse variate;
 Şabloane: pentru a asigura consistenţa şi afişarea predictibilă pentru
mediul web;
 Căi de desfăşurare a conţinutului: pentru publicarea conţinutului în
platforme Internet standard (dezvoltarea, testare, producţie);
 Asamblarea şi livrarea paginii: pentru producţia şi transmiterea de
conţinut dinamic către utilizatorii finali sau către consumatorii de
conţinut;
 Personalizare: pentru transmiterea de conţinut personalizat către
consumatorii individuali;
 Caching şi replicare: pentru asigurarea de performanţe înalte în medii
publice, caracterizate prin vârfuri de cereri;
 Micro-aplicaţii: asigurarea interactivităţii de bază cu un site web;
 Sindicalizare: pentru a adăuga valoare conţinutului prin distribuire
bazată pe web;
 Formatare pentru dispozitive speciale: conţinutul poate lua diverse
formate, inclusiv conţinut care să fie afişat de către dispozitivele mobile;
Abordate şi din alte puncte de vedere, facilităţile esenţiale ale unui sistem de
WCM ar putea fi:
 Flexibilitate: sistemul de gestiune a conţinutului web ar trebui să se
adapteze la site-ul web actual sau la noua arhitectură refăcută a
acestuia. Flexibilitatea în oferirea de unelte potrivite pentru
contributorii/autorii de conţinut pentru a-şi îndeplini sarcinile este de o
importanţă covârșitoare. În plus, flexibilitatea sistemului de gestiune a
conţinutului este importantă pentru a evita crearea de gâtuiri
suplimentare. În timp ce un sistem de WCM ar putea facilita
actualizările făcute astăzi, tipul şi dimensiunea actualizărilor s-ar putea
schimba pe viitor, iar dacă sistemul nu este flexibil, va apărea o gâtuire
suplimentară în actualizarea sistemului de management a conţinutului
web;
 Scalabilitate: dacă sistemul este instalat pentru un singur departament
acum, iar pe viitor se prevede o instalare pentru întreaga organizaţie,
trebuie să ne asigurăm de faptul că sistemul va fi scalabil, astfel încât să
acopere nevoile instituţionale în creştere. Poate, mai important, trebuie
asigurat faptul că sistemul este scalabil astfel încât să acopere o
diversitate largă de tipuri de conţinut şi de autori, de la cei mai tehnici
până la cei care se simt confortabil doar utilizând un procesor de text. În
cele din urmă, sistemul trebuie să fie scalabil pentru a putea utiliza noi
tehnologii pe măsură ce acestea sunt adoptate pe web şi Internet.
Sistemele create în jurul standardelor deschise şi nu cele proprietare vor

asigura acest lucru;
 Preţ pe măsură: cele mai multe sisteme de gestiune a conţinutului web
sunt de tipul „un singur sistem pentru gestiunea a tot”. Acest lucru
poate conduce la situaţii speciale, mai ales în programe pilot, în care
necesităţile pot fi redefinite ulterior. Costul iniţial şi costurile pe termen
lung trebuie să fie pe măsura necesităţilor reale. Acest lucru trebuie să
asigure şi scalabilitatea din punct de vedere al numărului de utilizatori;
 Implementare rapidă: fiecare zi de aşteptare a implementării reprezintă
un cost şi o posibilă oportunitate pierdută pentru organizaţie. De
asemenea, cu cât procesul de implementare durează mai mult, cu atât
mai sigur vor apărea depăşiri de buget;
 Bazat pe browser: acest lucru reduce necesitatea instalării şi întreţinerii
de aplicaţii suplimentare pe maşinile clienţilor, în acelaşi timp
permițând modificări din orice loc, în orice moment. Sistemul ar trebui
să permită autorilor de conţinut să navigheze direct în pagina pe care
doresc să o editeze şi să o actualizeze în contextul întregului site;
 Funcţionalitate multi-utilizator: sistemul trebuie să permită adăugarea
cu uşurinţă de utilizatori, de grupuri de utilizatori şi ataşarea de drepturi
de editare în secţiuni particulare din site pentru aceştia. Un sistem
ierarhic bazat pe roluri este o necesitate absolută;
 Uşor de utilizat: acest lucru este evident, dar fiecare sistem de gestiune
a conţinutului web este diferit. Unele pretind să fie de tip WYSIWYG iar
altele chiar sunt; altele sunt restricţionate de sistemul bazat pe
şabloane iar altele oferă ce e mai bun din ambele lumi. Cel mai bun
sistem de gestiune a conţinutului este cel care este îmbrăţişat şi utilizat
de către cei cărora li se adresează şi care se potriveşte unei diversităţi
de persoane, bunuri media şi situaţii.
Soluţiile WCMS au adoptat în ultima vreme şi alte facilităţi cheie din alte
segmente de tehnologie. De exemplu, producători de WCM au adoptat facilităţi de
DAM – Digital Asset Management pe măsură ce bunurile electronice grafice ale
clienţilor lor au devenit din ce în ce mai sofisticate.
În cele din urmă, conţinutul care va fi publicat pe Web are un anumit ciclu de
viaţă, iar înţelegerea acestuia reprezintă cheia spre construirea cererilor şi
tehnologiilor care se potrivesc cel mai bine cu necesităţile unei organizaţii.
Planificarea implementării unui WCMS
Ar trebui să fie evidentă elaborarea unui plan înainte de a se implementa un

nou sistem de management al conţinutului, însă acest lucru se întâmplă destul de rar.
Să evidenţiem mai în amănunt acest aspect: în ziua imediat următoare după ce
contractul de cumpărare a sistemului de management al conţinutului a fost semnat,
vânzătorul va pune câteva întrebări standard cum ar fi: Ce fel de implementare se va
face? Dacă la această întrebare nu există un răspuns clar şi simplu, proiectul nu va
merge bine, iar vânzătorul nu va putea şti exact care sunt necesităţile adevărate ale
proiectului şi, ca urmare, vor exista consecinţe. Acestea sunt câteva lucruri care ideal
ar trebui rezolvate de la bun început pentru a nu exista greşeli pe parcurs.
Figura 2.25 – Planificarea implementării unui WCMS.
Produs versus Proiect
In multe cazuri, selectarea unui nou sistem de management al conţinutului

poate fi văzută ca un proiect tehnologic care are ca scop obţinerea unui nou produs
sau o parte a “infrastructurii”. Când privim totul din această perspectivă, cel mai bine
este să implementăm CMS-ul şi pe urmă să se găsească modalităţile cele mai bune
pentru a-l folosi.
Cu şase săptămâni de implementare standard pentru o piaţă de mijloc a
vânzătorului, există doar scopuri limitate pentru planuri adiţionale şi design. Dacă
planurile nu sunt gata până la începerea proiectului, vor exista întârzieri semnificative
şi se vor înregistra cheltuieli suplimentare datorită unei “variaţii a proiectului”. De
asemenea, apar probleme din cauza confuziei dintre proiect şi produs. Fundamental,
proiectul este cel care livrează un site mai bun (un site web sau Internet), şi produsul
este cel care face legătura între începutul şi finalul proiectului.
Mai există un motiv cheie pentru a stabili planurile proiectului în avans: aceste
detalii influenţează ce fel de produs este obţinut. Produsele nu sunt nelimitate ca
flexibilitate şi fiecare produs are atuuri şi slăbiciuni. Acest lucru înseamnă că sunt
foarte eficiente în anumite cazuri şi complet nefolositoare în altele.
Există două mari elemente în re-dezvoltarea proiectelor web: redesenarea site-

ului existent şi selectarea unui nou sistem de management al conţinutului. Aceste două
elemente reflectă nişte probleme de dedesubt care practic fac să funcţioneze
proiectele web: problemele de structură şi conţinut ale site-ului publicat şi probleme
cu managementul si publicarea site-ului. Tentaţia este să se aleagă un singur furnizor
care să se ocupe atât de reproiectarea site-ului, cât şi de sistemul de management al
conţinutului. Acest lucru este însă o greşeală mare. Cel mai bine este ca reproiectarea
şi CMS-ul să fie repartizate la doi furnizori separaţi deoarece vor funcţiona mai bine.
Reproiectarea site-ului web
Principalul motiv pentru un proiect web nou este că site-ul iniţial este “stricat”.
Problemele tipice includ structura slabă a site-ului, design-ul şi conţinutul de date
învechit. Pentru acestea, organizațiile trebuie să ţină cont de procesul de design.
Acesta implică acţiuni cum ar fi sortarea şi testarea caracterului utilizatorului. In orice
regiune din lume sunt câteva firme care sunt specializate în acest tip de procese.
Acestea au o experienţă vastă în privinţa nevoilor utilizatorilor şi a procesului de
reproiectare, oferind încredere clienţilor că noul design este mai eficient şi nu doar
atractiv.
Dincolo de procesul de design centrat pe utilizator, trebuie avut în atenţie şi
designul la vedere. Acesta produce interfaţa finală a site-ului, incluzând grafică şi
culori; acest serviciu este furnizat de un alt specialist în interfeţe web, deseori de la o
firmă specializată.
Dar există şi firme care oferă un pachet întreg atât în privinţa uzabilităţii cât şi
al designului interfeţei. Când se caută un designer, organizaţiile trebuie să aibă în
vedere experienţa şi metodologia folosită de firmă. In timp ce agenţiile de design web
pot oferi un CMS, ele practic pot doar să furnizeze interfeţe grafice sau aspectul pentru
acel CMS. Acest lucru nu garantează faptul că tehnologia aleasă este cea optimă, chiar
dacă aptitudinile agenţiei de design sunt foarte bune.
Designul înainte de toate
Deşi la fel de important, designul ar trebui făcut înainte de alegerea unui CMS.
Toţi utilizatorii finali recunosc faptul că designul final este un criteriu important în
selectarea produsului CMS, iar facilităţile aplicaţiei pot fi ulterior evaluate în timp ce
vânzătorul face demonstraţie pentru abilitatea implementării designului dorit.
La un anumit moment, se va pune problema justificării proiectului sistemului de

management al conţinutului web (WCMS). Din fericire există un caz de afacere care
este folosit pentru WCMS atît în registrul pentru cost, cât şi în cel pentru venit.
Toate eforturile majore ale tehnologiei au început cu decizii importante, aşa că
este bine să existe un plan de afaceri iniţial pentru ca echipa să se poată concentra –
mai ales daca CFO va încasa cecuri foarte mari de la cumpărători. Ca orice investiţie, un
proiect de WCMS se justifică în termeni de “beneficii grele (mari)” care sunt foarte
uşor de cuantificat, şi “beneficii slabe (ușoare)” care pot fi calitative, dar cu siguranţă
nu mai puţin importante. Şi, ca orice proiect IT, aproape toate beneficiile firmei
producătoare fluctuează de la schimbările organizatorice, aşa că pentru fiecare avantaj
se va cita o importantă notificare sau chiar două.
Documente structurate
Documentele structurate sunt un alt tip de media care sunt foarte relevante
într-un CMS. Dezvoltarea lor s-a produs din două părţi distincte, anume industria de
printare media şi cea a domeniilor Web. Ca urmare, inițiativele hypertext-ului şi
hypermedia au contribuit la dezvoltarea limbajelor şi standardelor pentru
documentele structurate.
In contrast cu documentele obişnuite în format RTF, MS Word sau PDF,
documentele structurate sunt caracterizate de folosirea limbajului de marcare “mark-
up” şi link-urilor către alte documente externe şi informaţii. Pentru CMS, acestea
reprezintă provocări importante.
Standardele importante considerate în acest sens sunt SGML, HTML si XML.
SGML
Standard Generalized Mark-up Language sau SGML este dezvoltat în special de

editorii americani. Ideea de bază este că textul este scris fără nici un fel de formatări şi
se folosesc tag-urile pentru a marca anumite elemente de text cum ar fi titlurile sau
paragrafele. Cu SGML, aşezarea în pagină poate fi determinată flexibil la etapa de
procesare a textului. Tag-urile de structură facilitează, de asemenea, procesarea
automată a întregului text din document.
SGML defineşte un framework în care sintaxele tag-urilor sunt definite;
ocurenţa şi interpretarea semantică a textului este lăsată pentru aplicaţia care
procesează documentul SGML.
SGML este orientat pe obiecte cu clase, obiecte, ierarhii de clase şi obiecte
moștenite, etc. De asemenea, acesta permite instrucţiuni specifice de procesare în
cadrul documentului SGML.
Analiza şi formatarea documentului sunt procese separate. Tag-urile sunt cele
care determină structura documentului. Cu toate acestea, părţi din aşezarea în pagină
sunt adesea asociate cu structura ei. Contextul documentului în care a fost iniţial făcut
trebuie luat în considere în momentul formatării documentului.
In SGML, sunt patru mari categorii de tag-uri care se remarcă:
 Tag-urile mark-up descriptive, determină structura documentului: <start-
tag> document element </end-tag>;
 Referirile de entitate sunt referirile la alte elemente care înlocuiesc referirea
de entitate în timpul prezentării documentului
 Declaraţiile mark-up definesc elemente care pot fi referinţe a referirilor de
entitate.
 Procesarea instructiunilor: definesc instrucţiuni pentru alte programe, cum
ar fi instrucţiunile de formatare.
In plus acestea permit includerea altor tipuri de fişiere media la prezentarea

documentului, cum ar fi cele audio şi video.
SGML definește doar sintaxa, iar DTD (Document Type Definition) este necesar
pentru definirea semantică. Definiţia (DTD) din exemplul următor arată utilizarea de
identificatori publici şi de sistem:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
SGML poate utiliza, în plus, un document DSSSL1 (Document Style Semantics

and Specification Language) care este definit pentru standardizarea semantică a
aşezării în pagină.
Paginile Web si HTML
Cum World Wide Web a devenit tot mai popular, a apărut o cerere tot mai
mare pentru administrarea documentelor Web într-un CMS. Paginile web sunt
documente electronice care combină textul, imaginile, graficele, sunetele şi
elementele video dar şi unele mici programe executabile. Aceste documente sunt
stocate pe un server de unde utilizatorul le poate accesa. Diferitele elemente ale
paginilor Web nu trebuie codate în pagina propriu-zisă dar pot fi aduse în pagină, prin
referinţă la diferite linkuri. In cadrul unei pagini web pot exista mai multe documente
sau elemente esenţiale care sunt conectate prin linkuri.
Tag Descriere
<html>……</html> Declară un document HTML
<head>……</head> Conţine antetul documentului
<title>……</title> Defineşte titlul documentului
<body>……</body> Conţine corpul documentului
<hn>………</hn> Defineşte nivelul de adâncime a titlurilor
<li>………</li> Defineşte o listă
<br /> Carriage return
<p>………</p> Conţine un paragraf
<img src=”surs_imagine.jpg” /> Incarcă o imagine de la adresa specificată
<a href=”URL”>…….</a> Defineşte un hyperlink către un alt document
Pentru a administra paginile web în cadrul unui CMS, este necesar să fie definit
gradul documentului. De exemplu, imaginile şi fişierele audio sau video care sunt
accesate prin referinţă de către pagina web pot fi considerate parte din documentul de
unde este accesat linkul, ce poate fi chiar în exteriorul organizaţiei. Deci, când este
vorba de pagini web dintr-un CMS, este important să fie specificată adâncimea arhivei,
adică spaţiul unde obiectele ataşate ar trebui incluse în arhivele şi procesele de
management.
Paginile web sunt scrise folosind limbajul HTML (HyperText Markup Language).
HTML este un limbaj de marcare simplu, care este responsabil cu prezentarea
documentului pe ecran.
In comparaţie cu documentele SGML, documentele HTML sunt simple texte
ASCII care sunt structurate cu tag-uri. Aceste tag-uri pot fi văzute ca nişte comenzi de
control al formatului. Documentul HTML este structurat în trei părți, adică definiţia
tipului documentului, antetul documentului şi corpul documentului. In cadrul unui
document HTML, metadatele pot fi codate şi nu sunt accesibile utilizatorului pe ecran
dar pot fi folosite pentru a stabili autorul site-ului şi a evita probleme legate de
drepturile de autor sau, simplu, pentru a furniza unui motor de căutare web informaţii
despre pagina respectivă.
1
http://www.w3.org/Style/, http://dsssl.netfolder.com/
Tabelul de mai sus arată câteva tag-uri uzuale în HTML. După cum se observă
din tabel, unele tag-uri necesită semne de început şi de sfârşit pentru a include un
element. Dacă unul dintre tag-urile de început sau sfârşit nu se găsesc, documentul are
o eroare sintactică.
Aşa numita foaie de stil CSS poate fi utilizată în HTML pentru ca declararea
elementelor necesare să aibă aspectul cerut. Folosind foaia de stil, se separă aşezarea
în pagină de conţinutul propriu zis. Cu CSS (Cascading Style Sheets), aspectul unei
pagini web poate fi exact determinat. Foile de stil trebuie, de asemenea, administrate
într-un CMS care gestionează paginile web, referinţele din cadrul documentelor HTML
la foile de stil trebuind gstionate corect.
Studiu de caz: necesităţile experienţei clienţilor fac aplicaţiile WCM

esenţiale pentru operaţiunile online
Organizaţiile recunosc faptul că Web-ul a devenit principalul mijloc de

interacţiune cu clienţii, reinvestind în acest caz în iniţiative Web: actualizarea
sistemelor existente de tip WCM sau înlocuirea cu sisteme create la comandă. Deci
experţii în managementul cunoştinţelor şi al informaţiei în multe din aceste organizaţii
(mai ales în cele care deţin servicii financiare, de telecomunicaţii, de retail, de media şi
entertainment) nu caută doar sisteme care să le gestioneze conţinutul Web. În schimb,
aceştia caută:
 Sisteme care să servească cererilor de operaţii de bază: aceştia au
nevoie de software pentru operaţiuni de marketing, comunicări de
marketing, de software care să creeze şi gestioneze grupuri e-Business
care să suporte iniţiativele experienţei clienţilor, să-i ajute să gestioneze
şi să livreze conţinut către grupuri şi indivizi ţintă. Organizaţiile au
nevoie de ajutor în rezolvarea cerinţelor clienţilor precum branding
consistent pe mai multe site-uri Web şi canale (Web, wireless,
imprimate), livrînd utilizatorilor experienţe personalizate pe baza
profilului lor (informaţii explicite) sau pe baza comportamentului în site
(informaţii implicite);
 Suport pentru echipe şi organizaţii globale, precum şi pentru utilizatorii
de afaceri: din ce în ce mai mult, organizaţiile au nevoie de asistenţă
pentru globalizare pe măsură ce acestea caută să centralizeze şi să
restructureze operaţiunile, în acelaşi timp dând flexibilitatea necesară
echipelor locale de marketing pentru a servi clienţii locali. Operaţiunile
de marketing, comunicările de marketing şi grupurile e-Business din
organizaţii doresc mutarea administrării site-urilor de la supra-
aglomeratele departamente IT în mâna şi administrarea indivizilor care
sunt mai apropiaţi de nevoile şi experienţele clienţilor. Aceste persoane
(manageri de comunicare de marketing, manageri regionali sau
personal operaţional de marketing) au nevoie de posibilitatea de a crea
reguli personalizate, de a administra site-uri multiple, de a defini fluxuri
de lucru, de a gestiona navigarea şi de a privi în interiorul site-urilor şi a
utilizării conţinutului, astfel încât să creeze conţinut potrivit pentru
utilizatorii finali, clienţii1; echipa IT, dornică să se elibereze de aceste

responsabilităţi, va cere un produs WCM cât se poate de complet dar
uşor de folosit şi care nu necesită pregătire prea multă sau suport IT;
 Funcţionalităţi îmbunătăţite pentru autorii de conţinut: aceştia nu vor
mai fi mulţumiţi cu o versiune cu funcţionalităţi reduse a unui editor de
conţinut bazat pe web. Aceşti utilizatori doresc integrarea cu produse
familiare precum Microsoft Word, în care se poate crea şi edita
conţinut. Aceşti utilizatori doresc şi o gestiune mai bună a fluxului de
lucru şi a sarcinilor, nelăsând la o parte nici căutarea îmbunătăţită
pentru a-i ajuta să găsească şi să reutilizeze conţinut. Fluxul de lucru a
devenit din ce în ce mai important pe măsură ce organizaţiile încearcă
să-l utilizeze pentru a îmbunătăţii adoptarea WCM de către autorii de
conţinut2.
Cele mai multe iniţiative şi site-uri Web pot fi caracterizate în unul din cele cinci
stagii de maturitate, conform figurii următoare. Pe măsură ce organizaţiile evoluează
într-un alt stagiu de maturitate, acestea au nevoie de soluţii care să conveargă cu
nevoile de convingere de la exteriorul acestor stagii.
Stagiu Focus Model Criterii de evaluare

1) Încercări IT: Demararea şi Fonduri: proiect cu  Cost (soluţiile open
Echipa de dezvoltare IT funcţionarea site-urilor proiect source sunt
construieşte şi livrează web preferate)
site-ul Web împreună Gestiunea programului:  Suport pentru
cu unelte rudimentare gestionat şi condus de dezvoltatori
de gestiune a echipa IT  Publicarea de
conţinutului pagini statice
2) Funcţionalitate IT: Eliminarea IT din căile Fonduri: proiect cu  Separarea
Echipa de dezvoltare IT critice de publicare a proiect conţinutului de
conduce evaluarea şi conţinutului prezentare
selectarea tehnologiilor Gestiunea programului:  Managementul
WCM pentru a-i ajuta gestionat şi condus de schimbării în
să construiască şi să echipa IT procesul de
livreze site-uri Web mai publicare şi
bune automatizarea
procesului
 Formulare Web
 Integrarea cu un
Portal
 Publicarea de
pagini statice
3) Standardizare Stabilirea de procese IT Fonduri: departamentul  Management
Echipa de dezvoltare IT repetabile pentru IT obţine fondurile de la multi-site
împreună cu suportul dezvoltarea şi unităţile de business  Administrare
managementului managementul site- delegată
impune utilizarea urilor precum şi pentru Managementul  Workflow
standardizata a WCM în consolidarea programului:  Partajarea de
1
McNabb, K: Changing Perspective on Content Delivery:
http://www.forrester.com/Research/Document/Excerpt/0,7211,37196,00.html
2
McNabb, K: Use Workflow To Increase Web Content Management Adoption:
http://www.forrester.com/Research/Document/Excerpt/0,7211,41670,00.html
Stagiu Focus Model Criterii de evaluare
iniţiativele Web. iniţiativelor Web sponsorizat de afacere, conţinut între site-
condus de IT uri
 Exploatare în mai
mulţi paşi
 Integrarea cu un
portal
4) Capacitate de Suport pentru Fonduri: parte din  Editarea în-site şi
operaţiuni de operaţiunile de operaţiunile online în-context;
afaceri business pentru crearea  Diagnoza
Grupurile de operaţiuni şi gestionarea Managementul conţinutului;
de afaceri (e-Business, iniţiativelor online; programului: gestionat  Segmentare şi
operaţiuni de limitarea participării IT de operaţiunile de personalizare;
marketing, comunicări în administrare şi afaceri, administrare şi  Multi-canal (email,
de marketing) identifică personalizare suport pentru buletine de ştiri,
gestiunea conţinutului personalizare de la IT site-uri Web)
ca proces esenţial în
operaţiunile online
5) Servicii de afaceri Oferă operaţiuni online Fonduri: parte din  Site-uri de referinţă
Grupul de operaţiuni de eficiente, utilizează IT operaţiunile online  Workflow integrat,
afaceri oferă un serviciu pentru inovare diagnoză pentru
care asistă mai mult de Managementul site şi conţinut;
o unitate de programului: gestionat  Suport pentru
afaceri/canal. Grupul de de operaţiunile de testare
operaţiuni îmbrăţisează afaceri, suport pentru multivariantă;
utilizarea gestiunii inovaţii IT  Arhivarea şi
conţinutului pentru păstrarea
suportul operaţiunilor conţinutului şi a
în desfăşurare site-ului
Cei mai mulţi producători de aplicaţii WCM pot fi clasificaţi într-unul din
următoarele tipuri:
1) Concentraţi pe soluţii WCM generale;
2) Concentraţi pe suport pentru conţinut convingător.
Producătorii din prima clasă oferă facilităţi convenţionale şi esenţiale pentru

aplicaţiile de tip WCM, concentrate mai ales în publicarea de conţinut în site-uri şi
portaluri web multiple. Producătorii din cea de-a două categorie oferă soluţii pentru
gestionarea şi livrarea conţinutului către audienţe specifice ajutând, în consecinţă,
organizaţia să influenţeze comportamentul online al clienţilor, partenerilor etc.
Producătorii de aplicaţii WCM sunt înclinaţi să ofere facilităţi de administrare a
conţinutului şi de workflow, deseori existând o integrare puternică cu produse de tip
portal. De asemenea, producătorii care-şi oferă produsele către organizaţii cărora le
sunt necesare facilităţi de gestiune a unui conţinut „convingător” mai oferă
funcţionalităţi adiţionale precum personalizare, diagnoza conţinutului, livrarea multi-
canal şi gestiunea campaniilor.
Producătorii din ambele categorii livrează noi facilităţi precum blog-uri, suport
pentru RSS şi tagging, conform tabelului următor.
Facilităţi ale produselor generale Facilităţi ale produselor care oferă conţinut
de tip Web Content Management „convingător”
 Gestiunea ciclului de viaţă a  Funcţionalităţi de personalizare permițând
conţinutului folosind servicii de personalului netehnic să gestioneze segmente de
bibliotecă şi funcţionalităţile audienţă şi să direcţioneze conţinutul către
politicilor de păstrare (pe termen vizitatorii autentificaţi şi neautentificaţi ai site-ului;
lung)  Instrumente pentru analiza modului în care
 Securitatea conţinutului şi vizitatorii site-ului consumă conţinutul;
administrarea drepturilor pentru  Funcţionalităţi de testare multi-variantă permițând
protejarea conţinutului managerilor site-ului să testeze schimbările de
 Facilităţi de publicare tranzacţionale, conţinut pe segmente de audienţă;
permițând autorilor să publice  Suport pentru transmiterea conţinutului către
„pachete”de conţinut simultan canale multiple (Web, email, wireless);
 Instrumente care permit dezvoltarea  Facilităţi de globalizare permiţând administrarea mai
de workflow-uri complexe de către multor site-uri în mai multe limbi, cu conexiuni la
personal tehnic şi netehnic servicii de traducere automată
 Integrarea cu produse de tip portal
pentru managementul site-urilor
intranet şi extranet
CAPITOLUL III
ENTERPRISE CONTENT MANAGEMENT
ECM este una din strategiile şi tehnologiile folosite în industria tehnologiei

informaţiei pentru manevrarea capturii, stocării, securităţii, controlului de revizuire,
regăsirii, distribuirii, conservării şi distrugerii de documente şi continut.
ECM se concentreaza în special pe conţinutul importat în sau generat într-o
organizaţie în cursul funcţionarii lui şi include controlul accesului la acest conţinut din
afara proceselor organizaţionale.
Scopul şi definiţia
Sistemele ECM sunt construite pentru manevrarea conţinutului nestructurat (şi

într-o mai mică măsură a conţinutului structurat), astfel încât organizaţia, precum o
agenţie guvernamentala sau de afaceri, poate să-şi atingă scopurile mai eficient
(creşterea profitul sau îmbunătăţirea metodelor de a utiliza bugeturile eficient),
servirea clientilor (ca un avantaj competitiv) şi pentru a se proteja (împotriva
neînţelegerilor, încălcarea legii, departamente necoordonate). În multe organizaţii
mari, ECM nu este vazut ca o opţiune scumpă unde este esenţială conservarea
conţinutului, reutilizarea lui şi accesul la conţinut, controlat, pe când micile organizaţii
îşi pot mulţumi temporar necesităţile prin manevrarea folderelor partajate.
Tendintele recente în afaceri şi în guvernare indică faptul că ECM devine o
investiţie de bază pentru organizaţii de toate dimensiunile, mult mai legată de
scopurile organizatorice decât în trecut: dezvoltandu-se mai mult în centru – la ce face
respectiva întreprindere şi cum îşi îndeplineşte misiunea.
Definiţia “oficială” a ECM a fost creată de AIIM International, asociaţia

mondială de ECM, în anul 2000. Abrevierea ECM a fost reinterpretată şi redefinită de
multe ori în ultimii ani, înlocuind cuvinte precum ”creare” sau “personalizare”.
In toamna anului 2005, AIIM defineşte ECM astfel: „ECM este tehnologia care
utilizată pentru Captarea, Manevrarea, Stocarea, Menţinerea şi Distribuierea
conţinutului şi documentelor legate de procesele organizaţionale”.
In iarna anului 2006 AIIM adauga urmatorul paragraf definiţiei: „Instrumentele
şi strategiile ECM permit gestionarea informaţiei nestructurate, dacă aceasta există”.
Acest termen nou urmăreşte să depăşească în întregime problemele moştenite
din domeniile care au fost rezolvate în mod tradiţional de managementului
documentelor şi managementului înregistrarilor. De asemenea, include toate
problemele adiţionale implicate în convertirea la şi de la conţinut digital, la şi de la
căile tradiţionale ale acelor domenii problema (ca de exemplu sisteme fizice şi
computerizate de completare şi regăsire a conţinutului, adesea implicând hârtie şi
microformulare).
In cele din urmă, ECM este un nou domeniu problemă cu drepturile lui, el utilizând
tehnologiile şi strategiile managementului conţinutului (digital) pentru a rezolva
problemele proceselor de afaceri, precum înregistrări, partajarea de cunoştinţe,
personalizarea şi standardizarea conţinutului ş.a.
Noi suite de produse au rezultat din combinaţia de captură, căutare şi abilităţi
reţelistice cu managementul conţinutului, care au rezolvat în mod tradiţional arhivarea
digitală, managementul documentului şi a workflow-ul. In general, aceasta se întâmplă
când managementul conţinutului se trasforma în ECM.
Nomenclatura difertă tinde să conţină toate ariile de problema legate de
folosirea şi conservarea informaţiei într-o organizaţie, în toate formele ei, nu numai
faţa ei web expusă lumii exterioare. De aceea, cele mai multe soluţii se concentrează
pe sisteme ”afacere catre angajat” sau B2E. Oricum, odată cu dezvoltarea soluţiilor, au
apărut noi componente pentru managementul conţinutului.
De exemplu, pe măsura ce conţinutul nestructurat este înregistrat sau „ieşit”
din sistemul ECM, fiecare folosire poate să îmbogăţească profilul conţinutului, într-o
oarecare măsura în mod automat, astfel încât sistemul să poată dobândii sau “învăţa”
noi moduri de filtrare, moduri de routare şi căutare, taxonomii de corporaţie şi retele
semantice, care în schimb ajută la dezvoltarea deciziilor legate de regulile de reţinere,
determinând ce înregistrări sau documente să fie pastrate şi care să fie descărcate şi
când. Problemele de acest fel devin din ce în ce mai importante, pe măsura ce e-mailul
şi mesajul instantaneu sunt utilizate din ce în ce mai mult în stabilirea procesului
deciziei în cadrul organizaţiei
Astfel, termenul ECM se referă la soluţiile care se concentrează pe furnizarea
informaţiei “în casă”, deseori folosind tehnologiile Internet. Soluţiile tind să furnizeze
servicii Intranet personalului angajat (B2E), dar include de asemenea şi portaluri de
întreprindere pentru B2B, B2G, G2B etc. Această categorie include majoritatea
formelor de management al documentelor, de groupware şi soluţiile workflow care nu
şi-au transformat complet arhitectura, dar furnizează o interfaţă web pentru aplicaţiile
lor. Digital Asset Management (DAM) este, de asemenea, o formă a ECM care se ocupă
de stocarea conţinutului folosind tehnologia digitală electronică.
Caracteristicile
Gestiunea conţinutului are multe faţete, printre care şi ECM, WCM,

sindicalizarea conţinutului şi Digital Asset Management. ECM reprezintă o viziune, o
strategie sau chiar o nouă industrie dar nu este nici un sistem sau un produs distinct.
Astfel, împreună cu DRT (Document Related Technologies) sau DLM (Document
Lifecycle Management) ECM poate fi considerat un termen de tip “totul într-unul”
pentru o gamă largă de tehnologii şi producători.
O comparaţie a definiţiei diferitelor cîmpuri de aplicare ale EMC şi WCM face
clar faptul că distincţiile dintre categoriile existente astăzi nu vor mai dura mult timp,
fie pentru produse, platforme tehnice sau modele de utilizare. Soluţiile care sunt
utilizare astăzi ca soluţii interne vor fi făcute mîine disponibile către partenerii de
afaceri. Conţinutul şi structura portalului web de astăzi vor fi platforma pentru sistemul
informaţional intern de mîine. In articolul său din ComputerWoche, Ulrich
Kampffmeyer a concentrate pretinsele beneficii ale unui ECM în trei idei care disting o
asemenea soluţie de WCM:
 ECM sub forma unul middleware integrative: ECM este utilizat pentru a
depăşi restricţiile fostelor aplicaţii şi arhitecturi verticale. Utilizatorul,
practic, nu cunoaşte existenţa unei soluţii ECM. ECM oferă infrastructura de
bază pentru noua lume IT bazată pe web, stabilindu-se ca o a treia
platformă pe lîngă convenţionalele sisteme client/server. În consecinţă, EAI
(Enterprise Application Integration) şi SOA (Service Orinented Architecture)
vor juca un rol important in implementarea si utilizarea ECM;
 Componentele ECM ca servicii independente: ECM este utilizat pentru a
gestiona Informaţia fără a lua în considerare sursa sau necesitatea utilizării
acesteia. Funcţionalitatea este oferită ca un serviciu care poate fi utilizat în
orice fel de aplicaţie. Avantajul unui concept serviciul este acela că, pentru
orice fel de funcţionalitate, numai un serviciu general este diponibil, evitînd
astfel redundanţa, funcţiile scumpe, paralele şi dificil de menţinut. In
consecinţă standardele pentru interfeţele care conectează diferite servicii
vor juca un rol important în implementarea unui ECM;
 ECM ca un depozit uniform pentru toate tipurile de informaţii: ECM este
utilizat ca un depozit de conţinut (atît depozit de date cît şi de documente)
care combină informaţiile din organizaţie într-un depozit cu o structură
uniformă. Redundanţele scumpe şi problemele asociate acestora cu privire
la consistenţa informaţiei sunt eleminate. Toate aplicaţiile transmit
conţinutul către un singur depozit care, la rîndul lui, oferă informaţiile
necesare tuturor aplicaţiilor. În consecinţă, Content Integration şi ILM
(Information Lifecycle Management) vor juca un rol deosebit în
implementarea unui ECM.
ECM lucrează cel mai bine cînd este efectiv „invizibil” pentru utilizatori.
Tehnologiile ECM reprezintă infrastructuri care suportă aplicaţii specializare ca servicii
subordonate. ECM este, deci, o colecţie de componente de infrastrcutră care se
potrivesc într-un model multi-strat şi cuprinde toate tehnologiile legate de
documentele (DRT – Document Related Technologies) pentru gestiunea, transmiterea
şi gestiunea datelor structurate şi nestructurate. Deci, ECM este una din componentele
necesare, de bază, ale ariei de aplicaţii E-Business. ECM gestionează de asemenea
toate informaţiile unui WCM şi acoperă necesităţile de arhivare ca un depozit
universal.
Componentele unui sistem ECM
Sistemele ECM combină o largă varietate de tehnologii şi componente, o parte

din ele fiind adesea folosite ca sisteme de sine stătătoare fără a fi incorporate într-un
sistem al întregii organizaţii.
Aceste componente şi tehnologii ale ECM se împart în următoarele categorii:
 Captură;
 Manevrare;
 Stocare;
 Menţinere (păstrare);
 Distribuire;
Acest model este bazat pe cinci categorii de vârf ale AIIM International. Ariile
de aplicaţie tradiţionale sunt:
 Managementul documentelor;
 Colaborare (sau software de colaborare, groupware);
 Managementul conţinutului web (inclusiv portalurile web);
 Managementul înregistrarilor (arhivarea şi completarea sistemelor
manageriale pe unităţi de stocare pe termen lung);
 Workflow/Business process management (BPM).
Acestea formeaza componentele de “manevrare”, care conecteaza Captura,

Stocare, Distribuirea şi Menţinerea, şi care pot fi folosite în combinaţii sau separate.
Atât timp cât Managementul documentului, Managementul conţinutului web,
Colaborarea, Workflow-ul şi BPM sunt mai mult folosite pentru partea dinamică a
ciclurilor de informaţie, Managementul înregistrarilor are în vedere informaţia care nu
va mai fi schimbată. Utilizarea informaţiei este covârşitoare în totalitate, atât prin
clienţii independenţi ai sistemului de componente ECM, sau prin activarea anumitor
aplicaţii existente care accesează sistemul de funcţionare a serviciilor ECM şi
informaţia stocată. Integrarea tehnologiilor existente face mai clar faptul ca ECM nu
este un produs de categorie nouă, ci o forţă integrantă. Categoriile independente şi
componentele lor vor fi examinate în continuare.
Captura
Categoria ”Captură” conţine funcţionalităţi şi componente pentru generarea,

capturarea, pregatirea şi prelucrarea informaţie analogică şi electronică. Există câteva
nivele şi tehnologii, de la simpla captură a informaţiei la folosirea pregătirea complaxă
a informaţiei utilizând sortarea automată. Componentele “Captura” sunt adesea
numite componente de intrare/Input.
Informaţia capturată şi generată manual
Captura manuală poate să implice toate formele de informaţie, de la

documente de hârtie la documente electronice de birou, e-mail-uri, formulare, obiecte
multimedia, vocea digitizată, videoclipul şi microfilmul.
Captura automată şi semi-automată poate folosi documente EDI sau XML,
aplicaţii afacere şi ERP sau sisteme de aplicaţii specializate existente, acestea fiind
sursele de captură.
Tehnologii pentru prelucrarea informaţiei capturata
Tehnologii variate de recunoaştere sunt folosite să prelucreze documentele scanate şi

faxurile digitale, printre ele numărîndu-se:
 recunoaşterea caracterelor “optice” (OCR): aceasta transformă informaţia
imagine caractere recunoscute de maşină. OCR este folosit pentru tip;
 recunoaşterea caracterelor scrise de mînă (HCR): acest OCR îmbuătăţit
transformă scrisul de mînă sau scrisul sub formă de scrisoare în caractere
recunoscute de maşină, dar încă nu dă rezultate satisfacatoare pentru texte.
Oricum, pentru conţinutul de domeniu definit, a devenit foarte util;
 recunoaşterea inteligentă a caracterelor (ICR): este o dezvoltare suplimentară a
OCR şi HCR, care foloseşte comparaţii, conexiuni logice şi verificînd rezultatul cu
liste de referinţă pentru a îmbunătăţii rezultatele;
 recunoaşterea semnelor optice (OMR): de exemplu folosit pentru
recunoaşterea căsuţele de bifare, citeşte semnele speciale în campuri
predefinite cu foarte mare acurateţe. El îşi demonstrează valoarea în
chestionare şi alte formulare;
 codurile de bare de pe formularele expediate permit recunoaşterea automată
şi de completarea la revenire.
Imaginea de document
Tehnicile de prelucrare a imaginii de document sunt utilizate pentru

prezentarea imagininle scanate permîţind, de asemenea, dezvoltarea clarităţii
gradaţiilor pentru capturare. Funcţii ca “pistrui”, care şterge punctele izolate, sau
”reglare”, care îndreaptă imagini de pe foi care intră în dispozitiv într-un anumit unghi,
îmbunătăţesc rezultatele tehnologiilor de recunoaştere. Funcţiile imaginii de document
sunt folosite în controlul calităţii capturii.
Prelucrarea formularelor
In captura formularelor, există două grupe de tehnologii, deşi conţinutul

informaţiei şi caracterul documentului pot fi identice:
 Formularele pe hârtie: Procesarea formularelor înseamnă capturarea pe
scară industrială sau în mod individual a formularelor tipărite prin scanare.
Tehnologiile de recunoaştere sunt deseori folosite aici, din momentul în
care formularele bine create permit, în mare, procesarea automată.
 E-Forms/ Web-Forms: Prelucrarea automată poate fi folosită pentru
capturarea formularelor electronice atîta timp cît aranjamentul, structura,
logica şi conţinutul sunt cunoscute sistemului de capturare.
COLD
Cold/ERM sunt tehnologii pentru prelucrarea automată a structurii informaţiilor de

intrare. COLD semnifică Computer Output to Laser Disk şi este încă în folosinţă, cu
toate că discurile laser nu se mai găsesc pe piaţă de ani de zile. Acronimul ERM aici
semnifică Enterprise Report Management (managementul raportăii la nivel de
organizaţie). In ambele, datele de ieşire furnizate sunt prelucrate pe baza structurii
existente a informaţiei, astfel încît poate fi acestea pot fi indexate independent de
sistemul de provenienţă şi transferate în componente de depozitare care pot să fie
dinamice (stocare) sau în arhive(păstrare).
Agregarea
Este un proces de combinare a informaţiilor de intrare din diferite aplicaţii de creare,

de captură şi de distribuire. Scopul este să combine şi să unească informaţiile din
diferite surse, pentru a le trece mai departe în sistemele de depozitare şi prelucrare,
toate avînd o structură şi un format uniform.
Componente pentru indexarea subiectului informaţiei capturate
Sistemele încorporează de asemenea componenete pentru indexarea

subiectului transmiţînd informaţia capturată digital către destinatarii corespunzători.
Acestea sisteme cuprind:
 Indexarea (manuală): Indexarea se referă la atribuirea manuală de atribute
de indexare folosite în baza de data a componenetelor de gestiune pentru
administrare şi acces;
 Design de intrare(profiluri): Ambele atribuiri, automată şi manuală, pot fi
create mai usor şi mai rapid cu profiluri predefinite. Acestea pot descrie
clase de documente care limitează numărul de valori index posibile sau pot
atribui automat un anumit criteriu. Designul de intrare include de
asemenea, măşti de intrare şi logica acestora în indexarea manuală;
 Clasificare (clasificarea automată sau categorisire): Bazat pe informaţia
conţinută în obiectele informaţionale electronice, cum ar fi faxurile
convertite-OCR, fişierele de birou sau de ieşire, programele de clasificare
automată pot extrage indecşi, categorii şi transfera datele în mod autonom.
Aceste sisteme pot evalua informaţia bazîndu-se pe criterii predefinite sau
procese de cu învăţate automată.
Obiectivul tuturor componentelor de captură este aprovizionarea cu informaţie
pentru componenetele de “manevrare/gestiune” în vederea de prelucrari
suplimentare sau pentru arhivare.
Figura 3.1 – Captura datelor într-un ECM.
Gestionarea
Componenetele “manevra/gestiune” sunt pentru gestiunea, prelucrarea şi

folosirea informaţiei. Ele cuprind:
 Baze de date pentru administrare şi regăsire;
 Sistem de autorizate a accesului.
Scopul unui sistem închis ECM este să furnizeze aceste două componente doar
o singură dată, sub formă de servicii pentru toate soluţiile de gestiune cum ar fi
Managementul Documentelor, Colaborarea, Managemetul Conţinutului Web,
Managementul Înregistrarilor şi Workflow / Managementul Procesului de Afaceri.
Pentru a lega diverse componente de gestiune, ele ar trebui să aibă interfaţe
standardizate şi o procese de tranzacţionare securizate pentru comunicare inter-
componente.
Figura 3.2 – Aplicaţii de gestiune a conţinutului în cadrul ECM.
DM – Document Management
Managemetul documentelor, în acest context, nu se referă la industria

cunoscuta în Europa cu numele de DMS, ci la sistemul de management al
documentelor în sensul clasic, limitat. Aceste sisteme controlează documentele de la
crearea lor până la arhivarea pe termen lung. Managementul documentului cuprinde
funcţii precum:
 Înregistrare/ ieşire pentru verificarea informaţiei conţinute pentru
consistenţă;
 Managementul de versiuni pentru a urmări versiunile diferite ale aceloraşi
informaţii cu reviziuirile lor şi precum şi afişarea aceloraşi informaţii în
formate diferite;
 Căutare şi navigare pentru găsirea informaţiei şi contextele ei asociate;
 Vizualizarea pentru prezentarea informaţiei în structuri precum fişiere
virtuale, directoare şi vederi de ansamblu.
Cu toate acestea, funcţiile managementul documentelor se suprapun cu acelea
ale componentelor de gestiune, funcţionalităţile mereu în dezvoltare ale aplicaţiilor
office precum Outlook/Exchange sau Notes/Domino şi caracteristicile “Library
Services” pentru administrarea depozitării informaţiei.
Colaborarea (sisteme colaborative, groupware)
Colaborarea înseamnă, simplu, “lucrul împreună”. Totuşi, aceste soluţii care s-

au dezvoltat din groupware-ul conventional, acum merg şi mai departe şi includ
elemente de Knowledge Management. Colaborarea cuprinde următoarele funcţii:
 Utilizează informaţia comună din baze de date;
 Imbină, simultan, prelucrarea informaţiei controlate;
 Cunoştinţele bazate pe pricepere, resurse şi informaţii de fundal pentru a
procesa în comun informaţia;
 Componente de administrare cum ar fi “whiteboards” pentru brainsorming,
programarea întîlnirilor, managementul proiectelor etc.
 Aplicaţii de comunicare precum video conferinţe;
 Integrarea de informaţie din alte aplicaţii în contextul prelucrării comune a
informaţiei.
WCM – Web Content Management
ECM pretinde faptul că integrează WCM. Totuşi, informaţia prezentată pe

Internet şi Extranet sau pe un portal ar trebui să fie o informaţie care este deja
prezentă în companie, a carei distribuire este controlată de autorizarea accesului şi
depozitare. Managementul conţinutului web include următoarele funcţii, printre
altele:
 Crearea de noi informaţii sau editarea unora existente într-un proces de
generare şi publicare controlat;
 Distribuirea şi administrarea informaţiei pentru prezentarea web;
 Transformare automata pentru diverse formate de afişare, afişare
personalizată şi versiuni;
 Separarea securizată a accesului la informaţia publică şi non-publică;
 Vizualizarea pentru prezentarile pe Internet (browser, HTML,XML,etc).
Este notabil faptul ca mulţi din industrie nu considera WCM o componentă

integrantă a sistemului ECM. Exista foarte puţine exemple de implementări cu succes
care combină un depozit comun pentru documente (scopul central al ECM) şi conţinut
web, controlate împreună. Într-adevăr, tehnici şi filosofii foarte diferite pentru
structurarea şi organizarea conţinutului sunt utilizate pentru prezentarea externă a
conţinutului web comparativ cu cele pentru faţa internă, utilizate în managementul
conţinutului şi documentelor.
Gestiunea înregistrărilor - Records Management (gestiunea arhivelor

şi fişierelor)
Spre deosebire de sistemele tradiţionale de arhivare electronică,

managementul înregistrărilor (RM, managemetul înregistrarilor electronice sau ERM)
se referă la administrarea pură de înregistrări, informaţii importante şi date pe care
companiile sunt obligate să le arhiveze. Managementul înregistrărilor este

independent de mediile de depozitare, putînd de asemenea, să manevreze informaţia
stocată şi altfel decât în sistemele electronice. Printre funcţiile managementului
înregistrarilor se numără:
 Vizualizarea planului de fişiere şi alţi indecşi de structură pentru
depozitarea ordonată a informaţiei;
 Precisa indexare de informaţie, sprijinita de depozite sau liste de cuvinte
controlate;
 Managementul programelor de reţinere a înregistrărilor şi de stergere a
acestora;
 Protecţia informaţiei în conformitate cu caracteristicile ei, cîteodată pînă la
componentele individuale din documente;
 Folosirea de metadate standardizare internaţionale, specifice în industrie
sau cel puţin în interiorul companie pentru identificarea clară şi descrierea
informaţiei stocate.
Wf – Workflow / BPM – Business Process Management
Workflow şi managementul procesului de afaceri diferă substanţial. Există mai

multe tipuri de workflow, cum ar fi:
 “workflow de producţie”, care foloseşte succesiuni predefinite pentru a
îndruma şi a controla procesele.
 “ workflow ad-hoc” în care utilizatorul determină secvenţele de proces, din
mers.
Soluţiile de workflow pot fi implementate astfel:

 “Soluţiile de workflow” cu clienţi autonomi cu care lucrează utilizatorii de
obicei;
 “Motoare Workflow ”care acţionează precum un serviciu de fundal
controlînd informaţia şi fluxul de date, fără necesitatea unui client propriu
pentru aceasta.
Managementul workflow-ului include următoarele funcţii, printre altele:

 Vizualizarea proceselor şi structurilor de organizaţiei;
 Capturarea, administrarea, vizualizarea şi distribuirea de informaţii grupate,
împreună cu documentele sau informaţii asociate ei;
 Incorporarea de unelte de procesare a informaţiei (cum ar fi aplicaţiile
specifice) şi documente (cum ar fi produsele de birou);
 Prelucrarea paralelă sau secvenţială a procedurilor care cuprinde şi salvarea
simultană;
 Memento-uri, termene limită, delegări şi alte funcţionalitati administrative;
 Monitorizarea şi documentarea stărilor de proces, a routării şi a
rezultatelor;
 Unelte pentru proiectarea şi afişarea proceselor.
Obiectivul este în mare măsura automatizarea proceselor incorporînd toare
resursele necesare.
BPM sau Managementul Proceselor de Afaceri merge cu un pas inaintea
workflow-ului. Deşi termenii sunt adesea interschimbabili, BPM ţinteşte la integrarea
completă a tuturor aplicaţiilor din cadrul unei întreprinderi, prin monitorizarea
proceselor şi asamblarea tuturor infomatiilor necesare. Printre funcţiile BPM-ului se
regăsesc:
 Funcţionalitatea completă a workflow-ului;
 Monitorizarea proceselor şi informaţiei la nivel de server;
 EAI sau integrarea aplicaţiilor întreprinderii, pentru a lega diferite aplicaţii;
 BI (Business Intelligence) sau inteligenţa de afacere, cu structurile de reguli,
integrarea de depozite de informaţii şi utilitare ce asistă utilizatorii în munca
lor.
Astazi, componentele “manevra” sunt oferite în mod individual sau integrate în

suite. În multe cazuri ele deja includ componente de “stocare”.
Stocarea
Componentele de “stocare” sunt folosite pentru stocarea temporară a

informaţiei care nu este cerută sau dorită la arhivare. Chiar dacă foloseşte medii care
sunt potrivite pentru arhivarea pe termen lung, “stocarea” este încă separata de
“menţinere”.
Componentele de “stocare” listate de AIIM, pot fi împărţite în trei categorii:
“Depozite” ca locaţii de stocare, “Servicii de Bibliotecă” sub formă de componente de
administrare pentru Depoyite, precum şi „Tehnologii” de stocare.
Aceste componente de infrastructură sunt ţinute uneori la nivelul sistemului de
operare precum sistemul de fişiere, incluzînd de asemenea tehnologii de securitate,
care vor fi discutate mai departe în sectorul “distribuire”. Totuşi, tehnologiile de
securitate (incluzînd controlul de acces) sunt componente super-ordonate unei soluţii
a ECM.)
Figura 3.3 – Stocarea datelor în ECM.
Depozite/magazii
Diferitele tipuri de magazii ale ECM pot fi folosite în combinaţie. Printre tipurile
posibile putem găsi:
 Sistemul de fişiere: este folosit în primul rînd pentru stocarea temporară
(memoria temporară) ca cache intermediar de intrare sau ieşire. Scopul
ECM-ului este să reducă încărcarea sistemului de fişiere şi să facă informaţia
disponibila în general prin tehnologii de “manevrare”, “stocare” şi
”menţinere”.
 Sistemul de management al conţinutului: Acesta este sistemul actual de
stocare şi magazia pentru conţinut, care poate fi o bază de date sau un
sistem de stocare specializat;
 Baze de date: administrează informaţia de acces, dar pot fi, de asemenea,
folosite pentru depozitarea directă a documentelor, a conţinutului şi a
fişierelor media;
 Depozit de date/ Data Warehouses: acestea sunt sisteme de stocare
complexe bazate pe baze de date, care furnizează informaţie din toate
categoriile de surse. Ele pot fi de asemenea proiectate cu mai multe funcţii
globale, cum ar fi magaziile de documente şi informaţii.
Serviciile de Bibliotecă
Serviciile bibliotecă au de-a face doar în mod metaforic cu bibliotecile. Ele sunt
componentele administrative asemănătoare de sistemul care gestionează accesul la
informaţie. Serviciul de bibliotecă este raspunzator pentru luarea şi stocarea
informaţiei din componenetele “captura” şi ”manevrare”. El stabileşte, de asemenea,
locaţiile de stocare în memoria dinamică de stocare, “stocarea” reală şi arhivarea pe
termen lung, pentru “menţinere”. Locaţia de stocare este determinată doar de
caracteristicile şi clasificările informaţiei. Serviciul de bibliotecă lucrează în acord cu
baza de date a componentelor “manevră”. Acestea servesc funcţiilor necesare de:
 Căutare;
 Regăsire.
In timp ce baza de date nu “cunoaşte” locatia fizică a unui obiect stocat,

serviciul de bibliotecă gestionează:
 Depozitarea online (accesul direct la informaţie şi documente);
 Depozitarea „cvasi-online” (informaţie şi documente aflate pe un mediu de
stocare dar care pot fi accesate, dar pentru care sunt necesare instrumente
robotizate sau ceva similar pentru acces la ele);
 Depozitarea offline (informaţie şi documente aflate pe un mediu care nu
este la dispoziţia sistemul de acces).
În cazul în care nu există un sistem de management al documentelor

supraordonat pentru a furniza funcţionalitatea, serviciul de bibliotecă trebuie să
cuprindă:
 Managementul versiunilor, pentru controlul stărilor informaţiei;
 Intrarea sau ieşirea, pentru pregatirea informaţiei controlate.
O funcţionalitate importantă a Serviciului de Bibliotecă este aceea de a genera

jurnale care conţin intrări asupra utilizării informaţiei şi editărilor acesteia, jurnale
numit „audit trail”.
Tehnologii de stocare
O varietate largă de tehnologii pot fi întrebuinţate pentru stocarea informaţiei,

depinzînd de aplicaţii şi mediul sistemului:
 Citire şi scriere mediilor magnetice online: Aceasta include unităţile de

discuri magnetice ale serverelor, instalate în RAID (Redundant Array of
Independent Disks), Storage Area Networks (SAN) ca infrastructură de
depozitare şi Network-Attached Storage (NAS) ca şi arii de stocare
accesibile direct din reţea;
 Caseta Magnetică: În unităţile automatizate de depozitare precum
”bibliotecile” şi ”silozurile”, care folosesc unităţi robotice pentru acces, sau
folosite ca DAT în medii mai mici pentru copii de siguranţă, dar nu pentru
acces online;
 Medii optice-digitale: CD(CD-R pentru o singura scriere, compact disc doar
pentru citire, CD/RW compact disc pentru citire şi scriere), Digital Versatile
Disk(DVD), MO(Magneto Optical) şi alte formate pot fi folosite pentru
stocare şi distribuire sau în „tonomate” pentru stocare online.
Păstrarea
Componenetele de ”menţinere” ale ECM manipulează pe termen lung,

depozitarea sigură şi copia statică, care nu se mai schimbă a informaţiei, precum şi
stocarea temporară de informaţie care nu este dorită sau necesară la arhiva. Aceasta
este numită uneori “arhivare electronică”, dar aceasta are o funcţionalitate substantial
mai largă decât cea a “menţinerii”.
Sistemele de arhivare electronica astăzi constau în general într-o combinaţie de
aplicaţii de administrare precum managementul înregistrarilor, managementul
documentelor sau imaginilor, serviciile de bibliotecă (IRS-Information Retrieval System)
şi subsistemele de stocare.
Dar nu numai mediul electronic este potrivit pentru arhivarea pe termen lung.
Pentru securitate pura a informaţiei, microfilmul este încă viabil, şi este acum oferit în
sistemele hibride cu medii electronice şi acces prin intermediul bazelor de date.
Factorul decisiv pentru toate sistemele de depozitare pe termen lung este planificarea
oportună şi performanţa obişnuită a migrărilor, pentru a păstra informaţia disponibilă
în peisajul tehnic schimbător. Procesul continuu este numit migrare continuă
(Continous Migration). Componentele „menţinere” conţin vizualizatoare speciale,
unelte de transformare şi migrare şi medii de depozitare pe termen lung:
Figura 3.4 – Păstrarea datelor pe termen lung.
Medii de depozitare pe termen lung:
 Disc optic WORM: Write Once Read Many(WORM=scrie o data citeşte de

mai multe ori), mediu de stocare optic-digital rotitor, care cuprinde clasicele
5 ¼" sau 3 ½" în carcase protectoare, precum şi CD-R sau DVD-R. Metodele
de înregistrare variază pentru aceste medii, care sunt ţinute în „tonomate”
pentru accesul online şi accesul nearline automatizat;
 Banda magnetica WORM: benzile magnetice cu caracteristici WORM sunt
folosite în unitati speciale, care pot fi la fel de sigure ca mediul tradiţional
WORM dacă sunt folosite corect;
 hard disk-ul WORM: Stocarea pe discuri magnetice cu soft-uri speciale de
protectie împotriva rescrierii, ştergerii şi editării, permite o securitate
similară cu a unui mediu WORM tradiţional. Ca exemplu este CAS (Content
Addressed Storage);
 Retele de depozitare: Retele de depozitare precum NAS (Network Attached
Storage) şi SAN (Storage Area Networks) pot fi folosite dacă respectă
cerinţele de calitate acceptabila în privinţa auditării editării, protecţie
împotriva manipulării şi stergerii;
 Microfilm: Microformele precum microfilmul, cartele de deschidere, jackets
şi altele pot fi folosite pentru a salva informaţia care nu mai este în folosinţă
şi care nu mai necesită prelucrare;
 Hîrtia: Hîrtia încă are aplicaţii ca mediu de depozitare pe termen lung,
deoarece nu necesită migrare şi poate fi citită fără mijloace tehnice. Totuşi,
ca şi microfilmul, este folosită numai pentru a dubla securitatea informaţiei
electronice.
Strategii de conservare pe termen lung
Pentru a asigura pe termen lung disponibilitatea informaţiei sunt folosite

diferite strategii pentru arhivele electronice.
 Migrarea: Migrarea continuă a aplicaţiilor, a datelor de indecşilor, a meta-
datelor şi a obiectelor din sistemele mai vechi spre cele noi generează multă
muncă dar asigură acesibilitatea şi caracterul utilizabil al informaţie,
permiţînd, în timpul procesului, stergerea informaţiei care care nu mai este
semnificativă. Tehnologiile de conversie sunt utilizate pentru actualizarea
formatelor informaţiei stocate.
 Emularea: Emularea soft-ului mai vechi permite rularea şi accesarea
informaţiei originale şi a obiectelor. La fel se întîmplă cu aplicaţii de
vizualizare specializate, care pot identifica formatele obiectelor rezervate şi
pot afişa obiectele în mediul de lucru al noului software.
Standardele pentru interfaţă, meta date, structuri de date şi formatele

obiectelor sunt importante pentru asigurarea disponibilităţii informaţiei.
Transmiterea
Componentele de distribuţie ale ECM sunt folosite pentru prezentarea

informaţiei din componentele ”manevrare”, ”stocare”, ”menţinere”. De asemenea, ele
conţin şi funcţii care sunt folosite pentru a asigura introducerea informaţiei în sistem
(precum transferul de informaţie către medii sau generarea fişierelor formatelor ca şi
rezultat) sau pentru citirea (spre exemplu transformarea şi comprimarea) informaţiei
pentru componentele „menţinere” şi „stocare”. Deoarece modelul de componente
AIIM este bazat pe funcţii şi nu trebuie privit ca o arhitectură, putem să asignăm aceste
componente, precum şi alte aici. Funcţionalitatea în categoria “distribuire” este
cunoscută ca ”rezultat” şi rezumat sub termenul de Management al rezultatului
(Output Management) .
Componentele ”distribuire” cuprind trei grupuri de funcţii şi medii: tehnologii
de transformare, tehnologii de securitate şi distribuirea.
Transformarea şi securitatea ca servicii aparţin nivelului de mijloc (middleware) şi ar

trebui să fie disponibile tuturor componentelor ECM în acelaşi fel. Pentru Rezultat
două funcţii sunt de importanţă primară:
 Aranjare/Design: cu unelte pentru expunerea şi formatarea rezultatului
şi
 Publicarea: cu aplicaţii pentru prezentarea informaţiei pentru distribuire
şi publicare.
Figura 3.5 – Livrarea conţinutului către aplicaţiile şi utilizatorii finali din cadrul unui
ECM.
Tehnologii de transformare
Transformările ar trebui întotdeauna controlate şi urmărite. Acestea sunt

facute de către serviciile de fundal pe care, în general, utilizatorul final nu le vede.
Printre tehnologiile de transformare putem găsi:
 COLD/ERM (computer output to laser disk): Distinct fata de componentele
”captură”, acesta pregăteşte informaţia rezultată pentru distribuirea şi
transferul către arhivă. Aplicaţiile tipice sunt listele şi rezultatele formatate,
spre exemplu scrisorile individualizate către clienţi. Aceste tehnologii includ
de asemenea jurnale generate de componentele ECM. Spre deosebire de
majoritatea mediilor de imagini, înregistrările COLD sunt indexate în pozitii
bine stabilite în documentul lor şi nu într-o baza de date (de exemplu
pagina 1, linia 82, poziţia 12). Ca rezultat, cîmpurile index COLD nu pot fi
editate dupa transmitere decât dacă ele sunt convertite într-o baza de date
standard;
 Personalizarea: Aceasta nu este numai o funcţie a portalurilor web, ea
aplicîndu-se la toate componentele ECM. Personalizarea oferă utilizatorului
tocmai acele funcţii de care are nevoie;
 XML(eXtended Markup Language): Un limbaj de descriere care permite
descrierea de interfete, structuri, meta-date şi documente. XML a devenit
tehnologia universala pentru descrierea informaţiei;
 PDF (Portable Document Format): Un format inteligent de printare şi de
distributie care permite o prezentare a informaţiei independentă de
platformă. Spre deosebire de tipurile de imagini pure precum TIFF, PDF
permite căutarea în conţinut, adăugarea de meta-date şi implementarea
semnaturilor electronice;
 XPS (XML Paper Specification): Extensia XML a fost creată de Microsoft,
descriind tipuri de formate şi reguli pentru distribuirea, arhivarea,
transformarea şi procesarea documentelor XPS;
 Convertoare şi vizualizatoare: Servesc la reformatarea informaţiei pentru a
genera formaturi uniforme şi, totodată, pentru a afişa şi scrie informaţia din
diferite formate;
 Compresia: Este folosită pentru a reduce spaţiul de stocare utilizat de
informaţii. Procesul ITU este adesea utilizat pentru alb/negru pentru TIFF şi
JPEG2000 pentru imagini colorate. Aplicaţiile ZIP permit comprimarea
oricărui tip de date în vederea transferului;
 Sindicalizarea: Folosită pentru prezentarea conţinutului în diferite formate,
selecţii şi forme în contextul managementului conţinutului. Sindicalizarea
permite folosirea multiplă a aceluiaşi conţinut în diferite forme pentru
diferite scopuri.
Tehnologii de securitate
Tehnologiile de securitate sunt funcţii care se pot întinde pe mai multe secţiuni
şi care sunt folosite pentru toate componentele ECM. Spre exemplu, semnăturile
electronice sunt folosite nu numai când documentele sunt trimise, ci şi în culegerea
prin scanarea datelor, pentru documentarea completitudinii capturii.
PKI (Public/Private Key Infrastructure) este o tehnologie de bază pentru
semnăturile electronice. Ea gestionează soluţiile şi certificatele şi verifică autenticitatea
semnăturilor. Alte semnături electronice demonstrează identitatea expeditorului şi
integritatea datelor expediate, (faptul că acestea sunt complete şi neschimbate în
tranzit.)
In Europa există trei forme de semnături electronice, de calităţi şi protecţii
diferite: simple, avansate şi calificate. În cele mai multe ţări europene semnătura
electronică calificată este legal admisibilă în documente şi contracte legale. In cele din
urmă, există Digital Rights Management (Managementul Drepturilor Digitale) şi
Watermaking. Acestea sunt folosite în Content Syndication şi în MAM (Media Asset
Management) pentru gestionanrea şi securizarea proprietăţii drepturilor intelectuale şi
a drepturilor de autor. Acestea lucrează cu tehnici precum filigramele electronice care
sunt integrate direct în fişier şi caută să protejeze întrebuinţarea drepturilor şi a
conţinutului care este publicat pe Internet.
Distribuirea
Toate tehnologiile de mai sus servesc, în esenţă, furnizării diverselor conţinuturi

dintr-un ECM pentru a localiza utilizatorii ţintă prin rute diverse, într-un stil controlat şi
orientat către utilizator. Acestea pot fi componente active precum e-mail, medii de
informaţie, comentarii, şi publicatii pasive pe site-uri web sau portaluri, de unde
utilizatorii pot să-şi obţină singuri informaţiile. Posibile medii rezultat şi distributie
sunt:
 Internet, Extranet şi Intranet;
 Portaluri E-business;
 Portaluri Employee(angajat);
 E-mail şi fax;
 Transfer de informaţie prin EDI, XML sau alte formate;
 Dispozitive mobile precum telefoanele mobile, PDAs şi altele;
 Medii de date precum CD-uri şi DVD-uri;
 Digital TV şi alte servicii multimedia
 Hîrtia
Sarcina diverselor componente de Distribuire este de a oferi informaţia

utilizatorilor în cel mai bun mod posibil pentru aplicaţia în cauză, în acelaşi timp
controlînd utilizarea acesteia cît se poate de mult.
3.1. ENTERPRISE SERVICE BUS (ESB)
E-BUSINESS ŞI ARHITECTURILE ORIENTATE PE SERVICII (SOA)
Există o presiune constantă în a alege soluţia potrivită între cereri şi oferirea

unei flexibilităţi, între costuri şi eficienţă1.
Figura 3.6 identifică cheile componente ale cererii de e-business astfel:
1
www.oreilly.com/catalog/esb
Figura 3.6 - Diagrama cererii de e-business
Din perspectiva afacerii, e-business oferă o cale companiilor de a-şi dezvolta

afacerile într-un mediu al tehnologiei în care se îmbină cererile utilizatorilor.
Aceste tipuri de tehnologii putem spune că dispun de următoarele elemente
cheie:
 îndreptate spre o ţintă - dau posibilitatea firmei de a se
focaliza pe o ţintă, bazându-se pe propriile competenţe -
fapt care le face să aibă succes şi să fie unice; alianţele
strategice sunt formate pentru a face faţă nevoilor din
exterior pe baza competenţelor dobândite;
 oferă promt răspunsuri - au abilitatea de a oferi promt
răspunsuri clienţilor sau oportunităţilor oferite de piaţă
sau de alte elemente din mediul extern; aceste decizii
sunt îndreptate în special către compartimentul de
management care le analizează şi pe baza lor ia anumite
decizii viitoare;
 au avantajul flexibilităţii - la nivel operaţional cât şi la
nivelul proceselor de afaceri; adaptează diferitele costuri
structurale (fixe şi variabile) pentru a oferi un grad ridicat
de eficienţă operaţională;
 robusteţe - oferind capacitatea de a răspunde tuturor
schimbărilor atât la nivelul luării deciziilor în afaceri cât şi
la nivelul mediului tehnologic.
Companiile 1 îşi pot realiza necesităţile utilizând noile tehnologii bazate şi

dezvoltate pe experienţa avută din arhitecturile deja existente.
1
www.service-architecture.com
Cei care dezvoltă tehnologii de e-business care se cer, trebuie să se bazeze pe o

foarte bună arhitectură, în sensul bunei definiri a acesteia.
Atributele acestor tehnologii ce oferă flexibilitate, timp scurt de răspuns şi
eficienţă la nivelul cererii efectuate de organizaţiile care le implementează sunt:
 integrare;
 virtualizare;
 automatizare;
 standarde deschise (permisive).
Figura 3.7. ilustrează utilizarea atributelor pentru fiecare cerere de e-business.
Figura 3.7 - Utilizarea principalelor atribute
În cele ce urmează, aceste patru atribute sunt descrise pentru a explica

funcţionarea e-business pentru diferite cereri. În final aceste atribute sunt detaliate
pentru a demonstra corelarea e-business şi SOA.
A. Integrarea
Componenta fundamentală a infrastructurii cererii est integrarea. În anul 2002,
Sam Palsiano, şef executiv al IBM definea cererea în felul următor:
"O afacere de tip e-business apare într-o întreprindere a cărei procese de
afaceri, integrează partenerii, furnizorii şi consumatorii, putând răspunde rapid oricărui
consumator, oportunităţi de piaţă sau ameninţare exterioară." 1,
Integrarea poate atinge diferite nivele:
 persoanele
Pentru a funcţiona la un nivel operativ al cererii, apar procese de natură
om-om sau om-proces care interacţionează în măsură nelimitată până la
utilizatorul final. Partenerii de afaceri, consumatorii şi angajaţii reprezintă
cu toţii resurse importante ce se adaugă valorii cererii.
 procesele
1
www.ibm.com
Grupând elemente cum ar fi cele de securitate, al nivelului de service, de
monitorizare etc., se pot împărţi aplicaţiile pe diferite niveluri orizontale ale
serviciilor, prin decuplarea acestor componente ale aplicaţiilor.
 aplicaţiile
Foarte multe organizaţii au investit resurse deosebit de mult în dezvoltarea
pe cât posibil pe cont propriu a unei astfel de aplicaţii. Problema care a
apărut a fost integrarea acestor aplicaţii. Scopul integrării aplicaţiilor este de
a obţine un cost cât mai scăzut transformând bazele de date şi împărţind
informaţiile între ele.
 sistemele
Sistemele conduc, procesează şi livrează date utilizatorilor şi altor aplicaţii.
În cererea unui Mediu Operaţional este nevoie ca sistemul să fie
transparent pentru a putea fi uşor observabile elementele care
interacţionează în interiorul său.
 datele
Datele reprezintă elementul primar al unui sistem de afaceri. Datele
reprezintă sursele de informaţii. Ele pot fi împărţite complet pentru
adoptarea unor standarde.
B. Virtualizarea
Diverse niveluri ale tehnologiei exploatează concepte ale virtualizării, aici
putând include telefonia celulară, PDA-urile, conexiunea fără fir, etc.
Aspecte ale virtualizării au fost preluate de adoptarea conceptelor
arhitecturale, incluzând design-ul orientat-obiect, precum şi dezvoltarea serviciilor web
sau XML.
Un exemplu foarte bun de virtualizare a cererii este o colecţie de resurse
distribuite care sunt disponibile într-o reţea locală la un nivel universal şi care apar
unui utilizator final ca un singur sistem virtual.
Internetul este cel mai bun exemplu de virtualizare, oferind o reţea virtuală
prin care se furnizează şi se accesează date şi aplicaţii.
Virtualizarea se bazează pe un set de resurse:
 servere - acestea putând include partiţionale, emulatoare, virtualizarea
intrărilor şi ieşirilor, Ethernet virtual etc.
 stocare - aici punctul central fiind reprezentat de capacitatea reţelei;
 sisteme distribuite - aici putând fi incluse servicii Web, previzionare,
programare şi tranzacţii de management.
C. Automatizarea
Se adresează firmelor care astfel doresc obţinerea unor scăderi a costurilor şi a
timpului, ca rezultat al:
 supraaprovizionării;
 costurilor ridicate ale noilor aplicaţii;
 duratei de timp alocate pentru separarea platformelor
tehnologice între diferitele organizaţii;
 bugetului IT consumat pentru mentenanţă;
 complexităţii în operarea sistemelor eterogene.
Automatizarea autonomă poate fi rezumată la următoarele patru elemente

cheie:
1. auto-întreţinerea - un sistem trebuie să fie capabil să-şi menţină nivelul
de funcţionare. Pentru a realiza acest lucru, sistemul trebuie să
detecteze, să prevină şi să reconstituie căderile sistemului cu o
întreţinere umană minimă sau chiar fără aceasta. Necesarul de auto-
întreţinere al sistemului este direct proporţional cu gradul de
accesibilitate şi de cerinţele organizaţiei în cauză;
2. auto-configurarea - reprezintă abilitatea de adaptare dinamică la
schimbările mediului, de a adăuga sau îndepărta componente din
sistem, de a schimba mediul şi de a se adapta variabilelor externe;
3. auto-optimizarea - reprezintă configurarea la parametrii maximi
operaţionali a resurselor, în sensul eficienţei. Scopul este de a acorda
sistemelor posibilitatea de a răspunde schimbărilor apărute. Astfel
sistemele ar trebui să se monitorizeze şi să se modifice continuu,
adaptându-se şi învăţând din mediu.
4. auto-protejarea - securitatea reprezintă unul dintre principalii inhibitori
ai adoptării SOA, organizaţiile pregătindu-se să împartă date în mediul
extern. Auto-protejarea presupune ca sistemul să aibă alternative sigure
pentru a putea securiza informaţiile şi datele. Auto-protejarea
autonomă funcţionează prin anticipare, detectare, identificare şi
protecţia sistemelor de ameninţările externe.
D. Implicaţiile standardelor în SOA

Standardele1 afectează cererea mediului de operare de-a lungul nivelelor deja
definite incluzând automatizarea, integrarea şi virtualizarea. Fiecare din aceste
elemente sunt dependente de standarde, de specificaţii pentru a putea funcţiona bine
şi de a realiza obiectivele.
Standardele oferă elementul cheie pentru obţinerea flexibilităţii şi
interoperabilităţii dintre diversele sisteme eterogene.
Adoptarea globală a standardelor face ca diferitele sisteme să poată
interacţiona între ele.
Fiind platforme diferite, separate şi independente, dar folosind aceleaşi
standarde se poate face o procesare comună a acestora.
Chei necesare în flexibilitatea integrării

Pentru ca un sistem de a afaceri să aibă maximum de flexibilitate în cazul
implementării, avem nevoie de reunirea următoarelor elemente:
1
www.infoage.idg.com.au
Cuplarea proceselor de afaceri
Decuplarea tehnologiilor Realizarea infrastructurii
Figura 3.8 -
 cuplarea proceselor de afaceri:

- Cum se realizează un model de afaceri?
- Cum se transpune afacerea în procese, componente şi servicii care
pot interacţiona dinamic?
 decuplarea tehnologiilor:
- Cum se susţin mediile de afaceri cu aceste sisteme care
interacţionează?
- Cum putem să schimbăm şi să dezvoltăm aceste sisteme în timp?
 realizarea infrastructurii:
- Cum construim o infrastructură care să suporte, să execute să
conducă şi să măsoare interacţiunile, componentele şi procesele?
Corelarea E-business cu Service Oriented Arhitecture1
Funcţiunile infrastructurii ce sunt necesare pentru a face efectivă cererea sunt

oferite de servicii. Serviciile pot fi utilizate independent pe medii interne sau externe
pentru a procesa funcţii simple, sau pentru a lucra împreună la o implementare globală
ce va furniza rapid noi funcţionalităţi ale proceselor existente.
SOA pot utiliza servicii Web ca un set de standarde flexibile şi interoperabile.
Acesta este un element important de natură complementară între SOA şi serviciile
Web.
SOA implică patru elemente cheie de e-business, astfel2:
1. standarde deschise
- SOA oferă o metodă de standarde ce invocă serviciile Web (la nivel
logic şi funcţional) pentru organizaţii disparate care îşi împart
graniţele la nivelul reţelei;
1
en.wikipedia.org/wiki/Service-oriented_architecture
2
http://emergingtech.ittoolbox.com/documents/industry-articles/serviceoriented-architecture-
elements-of-good-design-1868
- serviciile Web folosesc standarde deschise pentru a obţine

conectarea dintre întreprinderi prin intermediul reţelei şi Internet-
ului;
- protocoale de mesagerie (SOAP)
- protocoale de transport (incluzând HTTP, HTTPS, JMS);
- securitate ce poate fi obţinută prin nivele de transport (HTTPS)
şi/sau protocoale de nivel (WS-Security)
-"părţi de standarde" - în care se pot include WS-I, W3C şi OASIS
folosind tehnologii dezvoltate de marile firme de software (IBM,
BEA, ORACLE, MICROSOFT) pentru a accelera şi a ghida aceste
standarde deschise în crearea şi adoptarea lor.
2. integrarea
- interfeţele sunt furnizate pentru a "ambala" aceste servicii şi de a
oferi un sistem independent arhitectural;
- SOA poate furniza servicii dinamice de căutare şi negociere, ceea ce
înseamnă că integrarea serviciilor vine în întâmpinarea cererii.
3. virtualizarea
- principala cheie a SOA este faptul că serviciile solicitate trebuie
însoţite de service de implementare, incluzând localizarea,
platforma, cel mai probabil scenariu de afaceri, uneori chiar şi
identitatea provider-ului de servicii.
4. automatizarea
- aplicarea principiilor SOA asupra implementării infrastructurii
serviciilor va oferi o creştere a automatizării.
ENTERPRISE SERVICE BUS (ESB)
ESB este unul din cele mai importante modele ale SOA. ESB unifică conceptele
într-o infrastructură. Conceptul de ESB1 a fost la început descris ca fiind "o nouă
arhitectură care exploatează serviciile Web, trimiţând mesaje, realizând o rutare
inteligentă precum şi transformare" spune Roy Schulte în lucrarea sa "Predicts 2003:
Enterprise Services Buses Emerge", 2002.
Din acel moment, ESB a devenit un subiect al dezbaterilor specialiştilor în SOA şi
în servicii Web.
Figura următoare prezintă metoda SOA, precum şi componentele sale. Aceasta
arată că SOA se bazează pe existenţa mai multor metode şi tehnici ce combină
tehnologiile şi disciplinele serviciilor Web cu ESB.
1
www.oreilly.com/catalog/esb
Figura 3.9 - Componentele metodei SOA
Putem spune că ESB oferă o imagine a capabilităţii infrastructurii,

implementate în centrul serviciilor în cadrul SOA.
ROLUL ESB ÎN CADRUL SOA
În ideea implementării1 SOA, atât aplicaţiile cât şi infrastructura trebuie să

suporte principiile SOA. Existenţa aplicaţiilor presupune crearea interfeţelor de service
pentru noi funcţii în mod direct sau prin intermediul unor adaptoare.
Existenţa infrastructurii 2 la nivelul de bază presupune existenţa clauzei
capacităţii de rutare şi transport a serviciilor cerute prin intermediul provider-ului
corect. Rolul ESB este acela de a permite infrastructurii această legătură.
Adevărata valoare a ESB este de a permite accesarea infrastructurii pentru SOA,
în scopul satisfacerii nevoilor actuale ale întreprinderii - de a oferi servicii la diferite
nivele, de a putea opera în diferite medii eterogene.
ESB trebuie să fie capabil să substituie un serviciu de implementare cu altul fără
a rezulta un efect negativ asupra clientului final (figura 1.18).
1
www.infoworld.com/article/03/06/13/24FEesb_1.html
2
www.ibm.com/developerworks/ webservices/library/ws-esbscen/
Figura 3.10 - Funcţionarea ESB
ESB centralizează controlul şi distribuie procesele

ESB este descris şi ca o infrastructură distribuită. Figura următoare ilustrează
acest lucru. Integrarea "HUB-AND-SPOKE" caută să centralizeze controlul configuraţiei:
routarea informaţiei, numirea serviciilor, etc.
În modelul integrării proceselor de e-business un ESB poate fi clasificat ca un
bus, ce este văzut ca un hub (figura 3.10, figura 3.11):
Figura 3.11 - Integrarea HUB AND SPOKE
Astfel, se poate spune că nu există nici o diferenţă între un bus distribuit şi

soluţiile hub-and-spoke.
Figura 3.12. Bus-ul o variaţie a Hub-ului
Când gradul implementării creşte, infrastructura poate deveni la nivel fizic

distribuită, ca un bus, în timp ce se păstrează la nivel logic controlul configuraţiei1.
Figura 3.13 prezintă rezultatele implementării unui ESB2.
Figura 3.13 - Rezultatele implementării unui ESB
1
www.ftponline.com/ea/magazine/ spring/columns/architectstoolbox
2
www.sonicsoftware.com/solutions/ soa_enterprise/enterprise_service_bus/index.ssp
Figura 3.14 - Relaţia între hub, bus şi ESB
3.2. PORTALURI
Portalurile, indiferent de tipul acestora, au în esenţă aceleaşi funcţionalităţi,

variaţia percepută între diferitele tipuri fiind doar de suprafaţă. Deşi conţinutul,
structura şi prezentarea portalurilor poate să varieze în mod drastic, în funcţie de
design şi de necesităţi, infrastructura şi mecanismele portalurilor sunt aceleaşi pentru
un portal la nivel de organizaţie, pentru un Internet call center, un portal intranet de
tip b2b, un portal extranet sau un portal de tip self-service.
În comparaţie cu paginile de web statice, portalurile trebuie să ofere funcţii de
bază cum ar fi agregare, personalizare, căutare, colaborare şi securitate. Nivelul exact
al funcţionalităţii acestor servicii de bază necesare pentru un anumit portal poate varia
în funcţie de tipul portalului, mai ales când este vorba de securitate, autentificare,
colaborare sau personalizare. Un portal intranet sau extranet poate necesita mai multă
securitate şi personalizare decât un portal de tip self-service care oferă informaţii
publice. Pe de altă parte, un portal self-service, care gestionează date financiare
personale şi permite persoanelor să-şi plătească facturile prin intermediul lui, poate
necesita la fel de multă personalizate şi securitate ca şi un portal intranet utilizat doar
de angajaţi.
Ceea ce subliniem aici este faptul că portalurile vor oferi întotdeauna
funcţionalităţi unificate, unitare, indiferent care este numele acestora. De asemenea,
este importat de apreciat această unitate, deoarece portalurile corporative, mai ales
cele de nouă generaţie bazate pe XML şi pe servicii Web, vor începe să consolideze
diferite tipuri de portaluri într-o singură entitate unificată, pe baza personalizării
bazate pe autentificare.
Funcţiile cu valoare adăugată asociate cu un anumit portal pot avea
aplicabilitate mai largă, indiferent de tipul de portal. Spre exemplu, funcţionalitatea
familiară de tip „shopping-cart” oferită de site-urile de comerţ electronic, în
accepţiunea clasică, ar putea fi restricţionată la portalurile de comerţ electronic de tip
b2c sau portaluri de afaceri de tip b2b.
De obicei persoanele nu asociază această funcţionalitate cu un portal intranet,

utilizat numai de angajaţi. În acest tip de portal, managementul şi administrarea
asigurărilor angajaţilor este una din cele mai populare şi productive aplicaţii. Orice
companie cu mai mult de 250 angajaţi care menţine un portal intranet poate să ofere
angajaţilor opţiuni diferite în ceea ce priveşte tipurile de asigurare oferite angajaţilor
(scheme de asigurare, asigurare stomatologică sau de sănătate). Angajaţii aleg aceste
tipuri de asigurări prin intermediul coşului de cumpărături, la fel ca şi alegerea
produselor dintr-un site de comerţ electronic.
Acceptarea şi procesarea cărţilor de credit este o altă funcţionalitate care este
în mod normal asociată cu site-urile de comerţ electronic. Din ce în ce mai multe
organizaţii încurajează angajaţii să achiziţioneze produse cu sigla companiei sau chiar
produse ale companiei prin intermediul portalului intern, unele companii oferind chiar
discount-uri sau promoţii speciale. Această facilitate internă este în cele din urmă
oferită angajaţilor pe baza operaţiunilor de comerţ electronic, chiar dacă funcţionează
într-un portal de tip business-to-employee.
Cele de mai sus încearcă să demonstreze faptul că linia care demarca
portalurile pe baza funcţionalităţii începe să se estompeze, portalurile devenind
multifuncţionale şi multiscop. Noua generaţie de portaluri la nivel de organizaţie va
deveni centrul acestor portaluri totul-în-unul, astfel încât, în loc să se menţină portaluri
separate, cu conţinut şi funcţionalităţi duplicat pentru diferite comunităţi de utilizatori
(parteneri, clienţi, investitori etc.) se pot reduce costurile şi complexitatea prin crearea
unui singur portal consolidat, dar totuşi partiţionat. În cele din urmă contează că
pentru o companie nu există imperative tehnice sau de implementare în ceea ce
priveşte menţinerea mai multor tipuri de portalului. Tehnologiile care şi-au dovedit
stabilitatea, sub forma cadrelor de lucru de tip portal ale IBM, SAP, BEA, Oracle,
Plumtree sau Microsoft, ca să enumerăm numai câteva, sunt disponibile pentru
construirea de portaluri atât pentru comunităţi Internet de utilizatori, cât şi pentru cele
externe.
Portaluri publice şi portaluri la nivel de organizaţie
Cea mai mare problemă care apare în diferenţierea tipurilor de portaluri

provine din definiţii şi percepţii diferite asupra acestora. Pentru a evita aceste confuzii,
cel mai sigur drum pe care-l putem urma este de a defini tipurile de portal diferite pe
măsură ce înaintăm în explicaţii. Astfel, cea mai semnificativă distincţie este între
portaluri publice şi portaluri interne sau portaluri publice şi la nivel de organizaţie.
În cazul în care utilizatorul are o experienţă semnificativă cu site-urile Internet
de tip Yahoo!, MSN sau AOL, aceste site-uri pot fi considerate portaluri publice.
Portalurile publice sunt echivalentul bibliotecilor publice, în care oricine poate veni şi
viziona datele pe ecran. În zilele noastre toate aceste portaluri publice mari oferă,
conţinut şi servicii personalizate membrilor sau utilizatorilor înregistraţi, pentru a
promova loialitatea utilizatorilor.
Spre deosebire de portalurile publice, deschise tuturor utilizatorilor, există şi
portaluri intranet, adică portaluri ale organizaţiilor cu interfaţă de tip web, care sunt
accesibile publicului larg. După acest criteriu, portalul FedEx.com, de exemplu, este un
portal public.
Figura 3.15 - Portalul public "my.yahoo.com".
Această caracterizare este totuşi logică, iar pentru rezolvarea problemei în

privinţa definiţiei portalurilor la nivel de organizaţie, aceasta poate fi extinsă conform
figurii următoare. Figura defineşte taxonomia de bază în ceea ce priveşte portalurile şi
scoate în evidenţă diferenţele dintre portaluri Internet şi portaluri la nivel de
organizaţie cu interfeţe externe.
Între portalurile publice şi cele la nivel de organizaţie, dar care sunt accesibile din
Internet, există o demarcaţie semnificativă, în funcţie de tipul de model de afacere.
Astfel, în cazul unui portal precum Yahoo!, afacerea principală a organizaţiei este
portalul însuşi.
Un portal la nivelul unei organizaţii în sine nu este scopul principal al
organizaţiei respective, indiferent că acesta este accesibil publicului larg sau nu.
Portalul FedEx.com, în ciuda popularităţii sale, nu este partea principală din spatele
FedEx. Acelaşi lucru este valabil şi pentru Amazon.com: chiar dacă prezenţa sa pe web
este realizată prin intermediul unui portal de comerţ electronic cu o mulţime de
legături de publicitate, partea principală a afacerii este vânzarea de cărţi, electronice
sau altele. Pe de altă parte, afacerea principală a Yahoo! sau Excite este a vinde
publicitate, sindicalizare şi afiliere la portalurile respective.
Pentru diferenţierea portalurilor Internet publice de cele la nivelul
organizaţiilor, pot fi aplicate şi alte criterii. Astfel, portalurile la nivel de organizaţie
sunt specifice organizaţiei respective şi evoluează în jurul organizaţiei pe care o
reprezintă. Misiunea principală a unui portal corporativ care este deschis către public
este de a promova produsele, serviciile, imaginea şi cultura organizaţiei respective. În
contrast, scopul expres al unui portal Internet este de a transmite cât mai mult
conţinut posibil în vederea atragerii şi reţinerii unui număr cât mai mare de utilizatori
web.
Deoarece portalurile Internet publice acoperă o asemenea gamă largă de
subiecte şi servicii de interes general, acestea mai sunt denumite şi portaluri
orizontale. Prin această definiţie, portalurile corporative devenind portaluri verticale
sau vortaluri, deoarece scopul este îngustat şi restricţionat de scopul specific al
afacerii. Cu toate acestea, definiţiile de tip orizontal-vs.-vertical nu sunt la fel de clare
ca şi cele care fac demarcarea între portalurile publice şi cele private. Motivul este
acela că există anumite portaluri Internet publice care au ca ţintă numite constituente.
iVillage.com, un portal de succes destinat femeilor, poate fi un bun exemplu în acest
scop. iVillage este considerat de către unele persoane ca fiind un portal vertical, date
fiind adâncimea şi gama largă de conţinut, ne mai luând în consideraţie şi modelul de
afaceri. Alte persoane pot să îl considere şi portal orizontal, în ciuda specializării
înguste a conţinutului.
Figura următoare este bazată pe imaginea de mai sus, pentru a introduce
conceptele de portal vertical şi portal orizontal. Alte exemple de portaluri verticale pot
fi considerate guru.com, cars.com, boats.com etc.
Figura 3.16 - Portaluri verticale şi orizontale
Tipuri de portaluri corporative
Astăzi există o mulţime de portaluri al căror scop pe termen mediu şi lung este
consolidarea, precum am menţionat şi mai sus. Această diversitate de tehnologii
reflectă în esenţă evoluţia tehnologică cu adoptarea cu grijă a tehnologiei. Principala
problemă a portalurilor corporative a fost accesul public prin Internet. Deci, primele
două generaţii de portaluri la nivel de organizaţii, din intervalul de timp 1995-1999, au
fost portaluri intranet care puteau fi utilizate doar de către angajaţi. Portalurile
intranet de astăzi pot fi caracterizate ca portaluri business-to-employee, acest termen
câştigând teren după larga răspândire a unor termeni precum business-to-business sau
business-to-consumer.
Restricţionarea portalurilor corporative la utilizatorii interni şi, posibil, la
anumiţi parteneri selectaţi, avea sens în zilele de început ale acestei tehnologii. Mai
mult, aceasta era şi perioada în care intraneturile, în general, erau la mare modă, iar
corporaţiile au adoptat rapid reţelele locale bazate pe IP. Deoarece portalurile intranet
dominau cultura organizaţională, aceste portaluri au fost numite în mod natural
portaluri de întreprindere sau portaluri corporative.
Prima generaţie de portaluri intranet s-a concentrat pe asigurarea conectivităţii
universale în organizaţie şi pe oferirea accesului la conţinutul web din ce în cel mai
bogat. Funcţionalitatea tranzacţională era iniţial limitată la operaţii simple, precum
căutarea în agende de telefon sau transmiterea cererilor pentru concedii. Mai apoi, au
fost descoperite potenţialul portalurile în ceea ce priveşte funcţiile legate de resurse

umane sau administrative.
Nu a trecut mult timp până ce portalurile au devenit baza pontajului electronic
de mare acurateţe, administrarea asigurărilor angajaţilor, completarea rapoartelor,
publicarea de locuri de muncă în interiorul organizaţiei, monitorizarea şi aplicaţii de
gestiunea a resurselor. În cazul companiilor hi-tech care au oferit opţiuni de stocuri sau
acţiuni angajaţilor, o altă aplicaţie larg utilizată a fost aplicaţia de management şi
schimb a acţiunilor sau hârtiilor de valoare emise de către companie prin intermediul
portalului. De asemenea, unele companii care s-au bazat pe mainframe-urile IBM sau
pe sistemele din seria IBM AS/400 (acum zSeries) pentru gestiunea aplicaţiilor, au
oferit acces la acele aplicaţii prin intermediul portalului intranet cu ajutorul diverselor
soluţii de tip web-to-host. Soluţiile iniţiale de tip web-to-host, care se bazau în
totalitate pe o soluţie de acces prin intermediul browser-ului, s-au dezvoltat iniţial în
două varietăţi:
1. emulatoare de tip thin-client bazate pe Java sau ActiveX, care
puteau fi menţinute pe maşina client după ce erau iniţial descărcate
de pe serverul web odată cu crearea unei noi versiuni (figura
următoare);
2. soluţii de tip „zero footprint”, prin care nu se instala nici o aplicaţie
prin intermediul browser-ului, fiind în totalitate bazate pe HTML.
Aceste soluţii converteau stream-urile de date de la nivelul
terminalelor în HTML şi invers, astfel încât utilizatorii portalurilor să
interacţioneze în mod direct cu aplicaţiile host direct prin fereastra
browser-ului.
Pe lângă cele două soluţii de mai sus, există astăzi şi o a treia opţiune în ceea ce
priveşte accesul la calculatoare mainframe prin intermediul portalurilor. Aceasta este
integrarea host-urilor sau integrarea aplicaţiilor de întreprindere (enterprise
application integration sau EAI), în care orientările de tip thin-client sau zero-footprint
sunt încă utilizate, dar soluţia se concentrează pe reutilizarea logicii aplicaţiilor din
calculatoarele de tip host în e-aplicaţii sau servicii web.
Cea de-a doua generaţie de portaluri business-to-employee, construită pe baza
expertizei şi aşteptărilor din ce în ce mai mari ale prime generaţii, a început să ofere
funcţii specializate. Cele două tipuri de portaluri care au câştigat supremaţia acestei
perioade sunt portalurilor colaborative şi portalurile de tip business intelligence. Tot
acum, termenul de „enterprise information portals (EIP)” câştigă popularitate, fiind
conceput sub forma unei umbrele colective pentru aceste două noi tipuri de portaluri.
Portalurile colaborative sunt specializate în sprijinirea angajaţilor organizaţiei în
găsirea, organizarea, partajarea şi actualizarea informaţiilor, uneori nestructurate, din
diverse surse, precum e-mail, documente de birou, foi de calcul tabelar, calendare,
specificaţii de produs sau informaţii de contact.
Figura 3.17 - Soluţie de tip web-to-host folosind OnWeb de la NetManage pentru
conversia host-to-HTML, împreună cu plug-in pentru FrontPage.
Instrumentele de colaborare sunt componente integrante ale portalurilor

corporative. Astăzi, pentru activarea facilităţilor de colaborare, se poate implementa
un portal corporativ cu scopuri multiple, în care instrumentele de colaborare sunt
incluse, fiind baza întregului portal. Aceste instrumente de colaborare nu vor fi folosite
numai de angajaţi ci şi de parteneri, colaboratori sau investitori, care vor avea acces
selectiv la anumite instrumente, dintre care e-mail-ul devine mediul de comunicare
omniprezent.
Scopul portalurilor de tip business intelligence este de a permite managerilor şi
directorilor organizaţiilor în care sunt implementate să ia decizii în timp util, pe baza
accesului la cele mai pertinente date existente în organizaţie. În consecinţă, aceste
tipuri de portaluri sunt specializate în suport pentru o gamă largă de tipuri de
informaţii, bazate pe indexarea conţinutului, cross-linking şi facilităţi de căutare în
vederea facilitării accesului şi analizei datelor. Datele de tip business intelligence
disponibile în aceste tipuri de portalului cuprind date financiare analizate deja,
performanţe ale lanţului de aprovizionare, rapoarte de vânzări, analize de piaţă,
statistici de producţie, starea stocurilor, trenduri ale relaţiilor cu clienţii sau analize de
suport pentru produse. În plus, pentru luarea deciziilor şi analiză, aceste portaluri
cuprind o serie de instrumente de tip business intelligence pentru analiză analitică
online (OLAP), generarea rapoartelor şi data mining.
Ca şi portalurile colaborative, portalurile business intelligence nu vor rămâne
portaluri strict specializate, deoarece corporaţiile se îndreaptă din ce în ce mai mult
spre portaluri cu facilităţi XML. Instrumentele de tip business intelligence, ca şi
instrumentele de colaborare, vor deveni servicii de bază în aceste portaluri, servicii
care vor fi disponibile unei game largi de utilizatori, pe bază de personalizare şi
drepturi obţinute în urma autorizării.
Partiţionarea portalurilor colaborative
Abilitatea de a converge către un singur portal, consolidat şi orientat către mai

multe scopuri, care să fie utilizat atât de utilizatorii interni, cât şi de cei externi
organizaţiei depinde în mod evident de capacitatea organizaţiei de a menţine o
compartimentare strictă între comunităţile de utilizatori. Figura următoare extinde
taxonomia tipurilor de portal dezvoltată mai sus pentru a arăta convergenţa
portalurilor corporative către un portal partiţionat şi cu scopuri multiple.
Figura 3.18 - Trendul către portaluri corporative consolidate, dar partiţionate.
Partiţionarea eficientă a portalurilor corporative se realizează cel mai bine prin

intermediul autentificării şi personalizării, utilizate în tandem.
Personalizarea
Personalizarea este cealaltă tehnică utilizată pentru partiţionarea efectivă şi

creativă a unui portal. Odată ce s-a utilizat autentificarea pentru determinarea fără
echivoc a identităţii utilizatorului, personalizarea poate fi utilizată atât pentru a
îmbogăţi experienţa utilizatorului în portal cât şi pentru a stabili o afinitate cu portalul,
conţinutul şi serviciile pe care le oferă. În cazul utilizatorilor publici neprivilegiaţi, care
vizitează ariile publice ale portalului, tehnologia simplă a cookie-urilor poate fi utilizată
pentru a identifica utilizatorul la vizite repetate, oferindu-le o experienţă
semipersonalizată, bazată pe informaţiile înregistrate la vizita anterioară.
Personalizarea nu reprezintă decât faptul că utilizatorii au acces la informaţii
autorizate, servicii şi aplicaţii care au o relevanţă mare pentru aceştia. Portalurile
publice precum Yahoo! sau Excite au făcut din personalizare o artă, cu condiţia ca
utilizatorii să activeze opţiunile sau pe baza preferinţei acestora. Tehnologia cookie-
urilor este utilizată pentru a identifica utilizatorii şi, în unele cazuri, pentru a menţine
preferinţele acestora.
Şi unele portaluri de comerţ electronic, precum Amazon.com, excelează în
personalizare; personalizarea de la Amazon este creată pe baza urmăririi şi analizării
intereselor, comportamentelor şi şabloanelor de cumpărare ale vizitelor anterioare. În
cazul cumpărării de DVD-uri, CD-uri sau cărţi de la Amazon.com, portalul va asigura că
utilizatorul este conştient de alte oferte asemănătoare la vizitele următoare. Tipul de
automatizare şi urmărirea transparentă a comportamentului utilizatorului pentru
personalizarea se numeşte „profilare implicită”, deoarece utilizatorul nu este angajat
implicit în alegerea preferinţelor, iar informaţia adunată în acest fel este utilizată
pentru data mining sau pentru „filtrare colaborativă” (collaborative filtring). În
consecinţă, metoda Yahoo! sau Excite prin care utilizatorii specifică preferinţele prin
intermediul unui chestionar, este cunoscută sub denumirea de profilare explicită
(explicit profiling).
Există alte două tipuri de profilare care pot fi utilizate pentru personalizarea
portalurilor corporative. Una din metodele evidente şi obligatorii este de a personaliza
portalul pe baza tipului utilizatorului şi a relaţiei dintre acesta şi companie. Cealaltă
metodă este personalizarea pe baza datelor istorice şi specifice utilizatorului. În mod
normal, ambele metode ar putea fi utilizate împreună pentru a se completa una pe
cealaltă. Deci, clienţii, de exemplu, ca grup, vor avea în mod automat o personalizare
diferită de a furnizorilor sau a investitorilor, de exemplu. Apoi datele istorice pot fi
utilizate pentru o personalizare mai aprofundată a acestor categorii mai largi. De
exemplu, clienţii sau furnizorii ar putea avea o personalizare în funcţie de regiunea
geografică sau tipul de industrie de care aparţin. În acest sens există o mulţime de
opţiuni care să realizeze personalizarea rapid, uşor şi fără să încetinească experienţa cu
portalul.
Aceeaşi personalizare bazată pe tipul utilizatorilor şi a datelor istorice se aplică,
chiar mai mult, angajaţilor organizaţiei. Angajaţii din departamentul de resurse umane
vor începe cu o „categorie” de personalizare diferită de cea a angajaţilor din
departamentele de marketing sau vânzări. Personalizarea poate fi mai apoi
îmbunătăţită, după autentificare, în funcţie de nivelul de responsabilitate, titlu, grad
sau altceva. Figura următoare conţine o schemă în care se observă cum pot fi utilizate
personalizarea şi autentificarea pentru partiţionarea unui portal corporativ.
Figura 3.19 - Autentificarea şi personalizarea utilizatorilor într-un portal.

Cel mai mare pericol din punct de vedere al personalizării este acela de
intimidare a utilizatorilor prin impresia care se poate face acestora în ceea ce priveşte
încălcarea confidenţialităţii. Toate organizaţiile mari care au implementat portaluri au
secţiuni speciale pentru explicarea politicilor de confidenţialitate sau chiar a unor
tehnici utilizate pentru urmărirea şi profilarea utilizatorilor.
Produsele de personalizare ale portalurilor sau facilităţile acestora sunt bazate
pe reguli şi orientate către scopuri. Există de obicei un „motor de reguli”, care
determină şi gestionează conţinutul şi serviciile oferite fiecărui utilizator în funcţie de
profile şi reguli. În cazul în care se utilizează profilul implicit, „motorul de reguli” va fi
complementat de un „motor de recomandări”, care va urmări comportamentul
utilizatorilor pe bază de tehnici statistice sofisticate, actualizând mai apoi regulile de
personalizare, astfel încât utilizatorul poate influenţa experienţa cu portalul pe baza
vizitelor anterioare.
Portaluri business-to-employee
Portalurile de tip business-to-employee permit angajaţilor să fie informaţi,

simplifică multe din sarcinile pe care ar trebui să le execute şi, în plus, dă angajaţilor,
un puternic sentiment de afiliere. Portalurile business-to-employee pot implanta
identitatea organizaţiei în angajaţi, îmbunătăţind astfel loialitatea. Un portal business-
to-employee bine creat şi menţinut devine o comunitate cu propriile drepturi, de care
angajaţii se pot ataşa şi chiar pot invoca unele drepturi de proprietate, chiar dacă nu
sunt direct asociaţi cu menţinerea portalului. Un portal business-to-employee poate fi
deci un bun puternic şi valoros al organizaţiei, neputând să fie ignorat sau să i se dea
un grad mic de prioritate.
Odată implementat, un portal business-to-employee menţinut la zi are
potenţialul de a deveni chiar un „spirit” al organizaţiei respective, putând fi utilizat
pentru menţinerea tonusului organizaţiei şi putând în acest fel reflecta, în mod subtil,
aspiraţiile şi valorile organizaţiei. Un portal business-to-employee este unul din cele
mai importante instrumente de „condiţionare a angajaţilor”, unele organizaţii
utilizând, de exemplu, video-over-IP pentru anumite întâlniri cu managementul sau
pentru a permite contactul „direct” cu angajaţii sau cu managerii prin video conferinţă.
Un portal business-to-employee este de asemenea şi un bun legat de resursele umane,
cu condiţia ca managementul resurselor umane să fie implicat într-o iniţiativă de tip
business-to-employee încă din prima zi.
Motivaţia existenţei portalurilor business-to-employee este aceea că portalurile
vor îmbunătăţi productivitatea angajaţilor şi vor facilita o luare a deciziilor mai bună şi
mai rapidă. Deşi sunt greu de găsit date empirice care să valideze aceste afirmaţii,
toate informaţiile de la companiile mari care au adoptat portaluri business-to-
employee indică succesul investiţiei făcute. Se poate totuşi aprecia, în mod intuitiv,
cum un portal business-to-employee, mai ales cu instrumentele de rigoare, poate
moderniza accesul la informaţie, facilita colaborarea, elimina munca pe hârtie sau
accelera procesarea tranzacţiilor. În mod evident, aceste beneficii sunt mai mari
pentru organizaţiile mari, care au angajaţi dispersaţi pe întregul glob, un portal
business-to-employee asigurând prezenţa organizaţiei respective 24/7.
Accesul la Internet maximizează eficienţa portalului business-to-employee şi
asigură costuri minime de acces la acesta pentru toţi angajaţii, oriunde s-ar găsi
aceştia. Securitatea este, desigur, o problemă, iar răspunsul este o autentificare
puternică. Un portal competitiv şi cooperativ, cu o interfaţă web prietenoasă se poate
obţine şi muncă suplimentară, cu costuri zero, mai ales în ceea ce priveşte sarcinile
colaborative sau legate de e-mail. Acest lucru înseamnă şi că portalul trebuie
monitorizat şi susţinut 24/7, devenind astfel o altă resursă critică pentru organizaţie.
Deşi un portal accesibil din Internet poate conduce şi încuraja la munca
suplimentară, există şi un revers al medaliei: angajaţii vor petrece mai mult timp decât
este necesar navigând prin portal, motivând acest timp ca fiind legat de munca depusă.
Un portal business-to-employee poate fi distractiv şi poate aduce diversitate, dar
scopul său este de a economisi timp preţios prin funcţionalităţile pe care le pune
angajaţilor la dispoziţie.
În ceea ce priveşte serviciile care vor fi oferite de portalurile business-to-
employee, există, din fericire, o regulă care poate fi utilizată: tot ceea ce necesită
completări de formulare pe hârtie, apeluri telefonice în interiorul organizaţiei sau
oameni care se plimbă pe coridoare, pot fi considerate buni candidaţi pentru
automatizarea prin intermediul portalului. Funcţiile colaborative, precum calendare de
grup, e-mail sau forumuri de discuţii vor fi primite cu entuziasm.
Portaluri business-to-consumer
Termenul „b2c” este acronimul de la „business-to-consumer”, termen asociat

de cele mai multe ori cu portaluri de comerţ electronic precum Amazon.com, buy.com
etc. Cu toate acestea, nu există nici un motiv pentru a restricţiona b2c doar la portaluri
de comerţ electronic. O apropiere mai realistă şi reprezentativă ar fi aceea de a asocia
portalurile b2c cu toate tipurile de portaluri business-to-consumer, în care
consumatorii ar fi atât clienţii/consumatorii existenţi cât şi cei potenţiali. Aceasta ar
însemna că portalurile b2c ar acoperi şi portalurile publice de tip self-service sau call-
center-urile. De asemenea, tot aici s-ar putea lua în considerare posibilităţile acestor
portaluri în ceea ce priveşte băncile, serviciile financiare, rezervările pentru călătorie,
companiile de utilităţi etc.
În comparaţie cu alte metode de marketing sau vânzări directe, obţinerea de
avantaje competitive prin intermediul unui portal b2c sofisticat este relativ mai ieftină,
mai ales cînd un portal b2c va permite justificarea diminuării operaţiunilor dintr-un
call-center fără diminuarea satisfacţiei consumatorilor. Totul depinde aici numai de
inovaţia şi creativitatea companiilor.
În aproape toate cazurile, o organizaţie care doreşte un portal b2c deţine deja o
pagină web cu informaţii. Un portal b2c va evolua din această primă pagină prin
introducerea tranzacţiilor şi a funcţiilor de tip self-service. Nevoia de autentificare va
depinde de vulnerabilitatea informaţiilor care fac obiectul tranzacţiilor sau care sunt
utilizate pentru tranzacţii. În cazul unui catalog electronic standard de tip „găseşte un
obiect”, precum bilete de avion, cărţi sau diverse alte lucruri, nu e nevoie de
autentificare. Totuşi, în cazul în care căutarea în catalog conduce la o tranzacţie de tip
comerţ electronic, va fi nevoie de un cont (şi deci de autentificare) care va fi utilizat şi
în vizitele următoare.
În unele cazuri se pot impune anumite niveluri de înregistrare cu

username/parolă sau alte modalităţi de autentificare pentru urmărirea şabloanelor,
atât pentru încurajarea unui simţ al comunităţii cât şi pentru colectarea de date
statistice. Spre exemplu, multe portaluri de presă sau alte media online favorizează
această metodă. Deşi informaţia pe care o colectează nu este, în mod evident,
confidenţială, necesitatea autentificării adaugă un anumit prestigiu tranzacţiei din
punct de vedere al consumatorului, oferind în acelaşi timp producătorului sau
distribuitorului de conţinut anumite statistici legate de utilizatori. Această nevoie de
autentificare, dacă nu este realizată automat printr-un cookie, nu permite utilizatorilor
să „sară” peste portal, direct în categoria pe care o doresc (în acest caz – ştirile). În
acest fel, schema de logon poate servi ca o modalitate complicată dar eficientă de a
obţine loialitatea în portal.
Portaluri business-to-business
Portalurile b2b ar trebui să fie baza viitorului comerţ electronic. Portalurile b2b
pot fi utilizate pentru două scopuri diferite:
1. interacţiunea cu partenerii existenţi, distribuitori sau furnizori, în
toate aspectele mutuale ale managementului lanţului de
aprovizionare şi a managementului relaţiilor cu clienţii;
2. identificarea şi localizarea noilor oportunităţi de afaceri, împreună
cu noi parteneri, distribuitori sau furnizori de afaceri.
Identificarea şi localizarea noilor proiecte sau scheme de afaceri nu ar trebui

confundată cu încercarea de a identifica şi atrage parteneri, distribuitori sau furnizori
adiţionali. Orice portal b2b sau portal de organizaţie conţine informaţii de contact,
care pot fi utilizate cu scopul devenirii de partener acreditat. Acest aspect de „nouă
afacere” ar trebui să găsească noi contracte, noi pieţe, noi teritorii sau noi tehnologii.
Este posibil ca aceste două obiective să fie obţinute într-un singur portal b2b, dar
există o demarcaţie strictă a modalităţii de rezolvare a acestor probleme. În cele din
urmă se va ajunge la:
1. portaluri b2b specifice companiilor sau regiuni b2b cu un portal de
organizaţie;
2. portaluri „publice” b2b specifice industriei sau afacerii.
Conceptul de portal b2b specific companiilor, utilizate pentru managementul

partenerilor existenţi sau al lanţului de aprovizionare este înţeles repede, cele mai
multe din marile companii (Cisco, Disney, Boeing) se bazează deja pe portaluri b2b ca
mijloace de execuţie rapidă, eficientă şi ieftină a tranzacţiilor de afaceri.
Portalurile publice b2b specifice unei industrii sau afaceri sunt, spre deosebire
de cele de mai sus, echivalentul b2b al portalurilor Internet. Afacerea lor, la fel ca
Yahoo! sau Excite, este a rula şi întreţine un portal b2b, scopul acestor portaluri fiind
acela de a acţiona sub forma unei pieţe comune sau clearinghouse pentru companiile
angajate într-o piaţă sau industrie specifică (automobile, aluminiu etc.)
Dat fiind interesul în ceea ce priveşte b2b, există portaluri index de tip b2b,
precum b2btoday.com sau b2byellowpages.com. Deşi b2b trebuie să ajungă la
aşteptările create în era „dot-com” în ceea ce priveşte volumul afacerilor, portalurile
b2b specifice anumitor industrii sau portalurile index b2b continuă să prolifereze şi să
se dezvolte.
Există de asemenea şi portaluri b2b închise, destinate unui grup restrâns de
utilizatori din anumite industrii. Consumatori mari de componente, precum
producătorii de automobile, companiile din industria chimică, firmele de electronice
sau companiile de telecomunicaţii generează portaluri b2b special pentru furnizorii lor.
Unele din aceste site-uri sunt site-uri de licitaţii în vederea obţinerii celui mai bun
aranjament în ceea ce priveşte bunurile oferite spre licitaţii. Site-urile de licitaţii
publice precum eBay oferă un bun model pentru structurarea şi operarea acestor
grupuri închise de portaluri de licitaţie.
Portalurile b2b sunt utilizate din ce în ce mai mult pentru oferirea accesului
controlat la aplicaţii de tip ERP selectate, astfel încît partenerii pot partaja în mod
direct şi dinamic informaţii actualizate (înregistrări despre facturare, nivelul stocurilor,
limite de creditare, planificări ale producţiei etc.) fără a fi necesară contactarea unui
reprezentant din organizaţia care pune aceste date la dispoziţie. Accesul direct la
aplicaţii ERP îmbunătăţeşte productivitatea de ambele părţi şi grăbeşte schimbul de
informaţii.
Portaluri wireless
Portalurile de tip wireless nu mai sunt la fel de importante astăzi precum erau
la un moment dat, acest lucru nedatorându-se creşterii continue a pieţei de acces la
Internet prin wireless ci, mai ales, datorită faptului că oamenii au realizat că
dispozitivele wireless, dată fiind creşterea importanţei acestora, sunt cel mai bine
gestionate ca parte a portalului organizaţiei şi nu prin portaluri specifice. Acest fapt
elimină nevoia de a menţine şi actualiza conţinut separat în cele două tipuri de
portaluri. Cea mai mare problemă cu dispozitivele mobile este că acestea nu au încă
lăţimea de bandă necesară, aria de prezentare sau capacităţile de navigare necesare
portalurilor din ce în ce mai sofisticate sau pline de grafică.
Soluţiile populare de tip portal de astăzi înţeleg necesitatea suportului pentru
clienţii wireless şi oferă pentru aceştia instrumente pentru conversie şi filtrarea
conţinutului pentru a asigura faptul că acelaşi conţinut sau servicii pot fi accesate atât
de clienţii legaţi prin reţele clasice cât şi pentru cei wireless. Pe lângă acestea există
instrumente puternice precum WebSpere Transcoding Publisher (WSTP) de la IBM sau
MobileSys MX pentru simplificarea integrării dispozitivelor wireless, promovând în
acest fel accesul universal la portal.
WSTP facilitează suportul noilor tipuri de dispozitive şi limbaje de marcare
(WML, de exemplu), permiţând administratorilor de portal concentrarea pe
promovarea şi menţinerea unui singur portal consolidat, independent de tipul de
client. WSPT adaptează în mod dinamic conţinutul cerut pentru a răspunde cerinţelor
dispozitivelor wireless. Deoarece conţinutul web actual este scris în HTML şi nu într-un
limbaj specific anumitor dispozitive sau clienţi, WSTP rezolvă problema integrării
dispozitivelor wireless prin legarea dinamică a diferitelor structuri HTML la structuri
dependente de dispozitiv, transmiţând astfel conţinutul în formatul necesar.
WSTP conţine transformări de conţinut standard (transcoderi) pentru

următoarele limbaje:
 HTML către WML;
 HTML către iMode
 HTML către HDML
 XML către XSLT;
 Imagini JPEG către bitmap şi GIF specific dispozitivelor mobile;
 Imagini GIF către bitmap şi JPEG specific dispozitivelor mobile.
Toate semnele curente indică faptul că XML şi XSLT vor reprezenta modalitatea
strategică şi acceptată de gestionare a dispozitivelor mobile de către portalul
organizaţiilor. Astfel, pot exista transformări XSLT care să gestioneze tipuri de
dispozitive diferite sau chiar grupuri de dispozitive, în funcţie de necesităţi. În mod
evident, utilizarea XML pentru integrarea wireless presupune existenţa conţinutului în
format XML, format care se poate obţine extrem de uşor.
Arhitectura şi tehnologiile portalurilor
La momentul actual nu există încă vreun standard industrial pentru arhitectura

portalurilor la nivel de organizaţie. Cu toate acestea, toate portalurile, indiferent de
tipul acestora sau de orientarea companiei producătoare, partajează un set de
funcţionalităţi de bază obligatorii. La nivel minim, aceste funcţionalităţi de bază pentru
un portal cuprind:
1. interfaţă către web;
2. managementul interfeţei cu utilizatorul (servicii de prezentare, de
exemplu);
3. mecanisme de acces la date externe;
4. servicii de management al datelor;
5. securitate, autentificare şi personalizare;
6. instrumente de dezvoltare a portalului;
7. instrumente de administrate şi management ale portalului.
Necesitatea acestor componente de funcţionalitate discrete, în care fiecare

componentă are o legătură logică şi foarte specifică cu celelalte componente, asigură o
structură comună pentru portalurile corporative. Acest cadru de lucru de bază, comun
pentru toate portalurilor, poate fi extins cu uşurinţă pentru a servi ca fundaţie de
referinţă pentru viitoarele portaluri corporative. Figura următoare ilustrează această
arhitectură de referinţă pentru toate portalurile corporative contemporane, construite
pe funcţiile obligatorii de mai sus, în vederea realizării unor portaluri credibile.
Funcţiile de agregare, căutare, colaborare, sindicalizarea, managementul
documentelor, workflow management pot fi adăugate sub formă de componente sau
servicii de management a datelor, pentru a completa şi mai mult această arhitectură.
În mod similar, componenta de interfaţă web, care în practică este realizată printr-un
server de aplicaţii web, poate fi extinsă pentru a cuprinde servicii web care să utilizeze
protocoalele uzuale SOAP, WSDL şi UDD. Flexibilitatea şi extensibilitatea incrementală
a acestei arhitecturi este reflectată cu acurateţe în cele mai puternice soluţii portal de
astăzi. Implementarea unui portal de succes la nivelul unei organizaţii nu trebuie să fie
de tip „totul-sau-nimic”, la serviciile interactive de bază adăugate paginii web existente
putându-se adăuga în mod sistematic şi gradual diverse componente, în funcţie de
bugetul şi timpul alocat.
La ora actuală se poate implementa un portal la nivel de organizaţie în două
moduri diferite: prin crearea de programe/aplicaţii necesare, scripturi customizate şi
servicii individuale peste un server web; sau prin utilizarea unui portal „gata făcut”.
Înainte de 1997, utilizarea scripturilor Perl sau a aplicaţiilor CGI era singura soluţie, în
timp ce astăzi există o mulţime de servere portal „totul în unul”, pentru diferite
bugete.
Figura 3.20 - Arhitectura de bază a portalurilor contemporane.
Optarea pentru o soluţie portal de bază nu implică o schemă rigidă. În schimb,

majoritatea serverelor de tip portal, anticipând necesităţile clienţilor, oferă o
multitudine de opţiuni pentru customizarea, îmbunătăţirea şi creşterea implementării
portalului prin plug-in-uri sau API-uri. Serviciile web sunt o altă modalitate modernă de
extindere a funcţionalităţii şi îmbunătăţirii funcţionalităţilor unui portal.
În zilele noastre, cea mai bună soluţie pentru ca o organizaţie să aibă propriul
portal este ca unul gata făcut (off-the-shelf) să fie achiziţionat, construindu-se mai apoi
alte componente, pe măsură ce echipa de dezvoltare/implementare capătă mai multă
experienţă cu portal achiziţionat. Printre cele mai importante portaluri la nivel mondial
se numără (ordinea este aleatorie): mySAP Enterprise Portal, IBM WebSphere Portal,
Oracle Application Server (cu portal inclus), Plumtree Corporate Portal, Microsoft
SharePoint, iPlanet Portal Server, Hummingbird EIP, Ione Netegrity Interaction Server,
CA CleverPath Portal, Epicentric Foundation Server, Corechange Coreport, Verity K2
Enterprise, BroadVision InfoExchange Portal, Brio Portal etc. Nu trebuie, de asemenea,
să uităm nici portalurile open-source, care ar putea fi implementate la nivel de
organizaţii (mai mici).
Un număr din ce în ce mai mare de producători de portaluri scot în evidenţă

rolul serviciilor web în viitorul portalurilor, aproape toţi producătorii oferind suport
pentru acestea. În timp ce rolul IBM, BEA, Oracle sau Microsoft este binecunoscut în
promovarea serviciilor web şi ceilalţi jucători încep să realizeze importanţa acestor
servicii web în produsele pe care le creează, indiferent că au la bază aplicaţii Java sau
aplicaţii bazate pe Microsoft .NET. Utilizarea unui server portal va facilita şi accelera
adoptarea acestor noi şi promiţătoare metodologii pentru aplicaţi web.
Serverele portal, într-un efort pentru a simplifica dezvoltarea şi menţinerea
portalului, ca şi pentru a obţine anumite avantaje competitive unele faţă de altele, au
introdus în ultimii ani noi şi inovative concepte. Printre acestea notăm portlet-urile,
digital dashboard cu web parts, gadgets, breadcrumbs, skin-uri, roluri, domenii, sau
iView-uri. Dintre acestea, conceptul de „portlet” (sau alte concepte înrudite precum
„pagelet”) sunt cele mai importante. Portlet-urile sunt create şi suportate de IBM, BEA,
Oracle, Sybase, Viador, Verity şi alţii.
În cazul unei soluţii portal care le suportă, portlet-urile devin blocurile de
construcţie sau cărămizie portalului. Portlet-urile sunt, în esenţă, componentele active
vizibile pe care utilizatorul final le vede în pagina web a portalului. Figura următoare
ilustrează conceptul de portlet-uri relativ la pagina unui portal.
Figura 3.21 - Portle-uri în pagina unui portal.
După cum se poate observa şi în figură, portlet-ul deţine o parte din fereastra
browser-ului sau a ecranului dispozitivului mobil în care este afişată pagina curentă
portalului. Din perspectiva unui utilizator, un portlet este o „fereastră” sau un canal de
conţinut, completată cu controalele necesare.
Arhitectura de bază a portalurilor
Figura „Arhitectura de bază a portalurilor contemporane” de mai sus, arată o

structură simplă dar validă şi reprezentativă a arhitecturii portalurilor actuale.
Numeroase arhitecturi ale portalurilor enumerate mai sus, sunt în esenţă, variaţii ale
acestei structuri de bază. Figura următoare ilustrează arhitectura portalului
WebSphere de la IBM.
Figura 3.22 - Arhitectura conceptuală a WebSphere.
Servicii pentru managementul datelor
Funcţiile de publicare a conţinutului, managementul conţinutului, căutare,

colaborare, sindicalizare şi funcţiile legate de workflow fac parte din categoria
serviciilor pentru managementul datelor, chiar dacă nu sunt enumerate explicit în
figura respectivă. Funcţiile care vor fi incluse în mod obligatoriu în această arhitectură
sunt următoarele:
 managementul conţinutului:
o publicarea conţinutului: includerea manuală şi automată a datelor în
formulare diferite, accesate de utilizatorii autorizaţi ai portalului;
o structurarea conţinutului: mecanisme de tip portlet sau şabloane;
o sindicalizarea conţinutului: abilitatea de a subscrie la furnizori de
date externi prin intermediul standardelor RSS, OCS, PRISM, NITF,
xmlnews etc.;
o agregarea conţinutului: asimilarea şi sinteza datelor din diverse
surse, în funcţie de regulile de personalizare ale unui anumit
utilizator şi prezentarea acestor date;
o transmiterea conţinutului: cuprinde gestionarea automată a
schemelor de tip „push” sau a serviciilor de subscripţie, care permit
utilizatorilor să ceară actualizări periodice sau să fie notificaţi în
cazul apariţiei unui anumit eveniment;
o director de conţinut: index care unifică şi mapează toate datele,
serviciile şi aplicaţiile disponibile în portal;
o categorii de conţinut: clasificarea automată şi continuă a
conţinutului portalului în categorii pertinente, cunoscute şi sub
numele de taxonomii, utilizând tehnologii de tip „web crawler”, care
indexează automat conţinutul, luând în calcul şi meta-datele
asociate unui anumit tip de conţinut, adăugându-le în directorul de
conţinut;
 Căutarea, care cuprinde căutări în mai multe surse şi tipuri de conţinut;
 Colaborarea;
 Managementul fluxului de lucru, care permite utilizatorilor să monitorizeze
şi să controleze fluxul tranzacţiilor multi-pas necesare pentru execuţia unui
anumit proces al afacerii (exemple: acceptarea unui ordin, expediţia unui
produs, facturarea unui client, recepţionarea plăţii de la clienţi etc.).
Motoare de reguli, directoare şi acces la date externe
Figura următoare extinde arhitectura de bază din figura de mai sus pentru a
reflecta funcţionalitatea discutată în paragraful anterior. Cu toate că este o arhitectură
funcţională, mai trebuie incluse anumite funcţii pentru a asigura o autenticitate totală.
De exemplu, regulile joacă un rol din ce în ce mai important în managementul şi
operaţiunile unui portal. Personalizarea bazată pe reguli este unul din exemplele
discutate mai sus. Directoarele de reguli, care conţin motoare de „forţare” a acestora,
pot fi utilizate pentru transmiterea conţinutului, managementul subscripţiilor,
împărţirea pe categorii a conţinutului sau managementul fluxurilor de lucru.
Figura 3.23 - Arhitectura portalurilor, cu detalierea serviciilor de acces la date.
În cazul transmiterii conţinutului sau a managementului subscripţiilor, regulile

pot fi utilizate pentru a customiza şi actualiza toate datele de tip „push” ca şi
declanşatoarele de alertare automată. Alertarea bazată pe reguli poate fi extinsă
pentru a acoperi şi procesarea fluxurilor de lucru. De exemplu, un reprezentant de
vânzări poate fi alertat automat când organizaţia primeşte plata pentru un ordin primit
de acel reprezentant, în acest fel reprezentantul putând determina data obţinerii
comisionului. Regulile pot fi utilizate de asemenea pentru împărţirea în categorii a
conţinutului, cu avantajul că se pot face schimbări rapide între categorii prin simpla
schimbare a regulilor. Aceste componente de reguli vor avea, cum este şi normal,
interfeţe către componentele de administrare a portalului, de personalizare şi către
componenta de management a datelor.
O altă capacitate importantă a unui portal modern este posibilitatea reutilizării
informaţiilor deja conţinute şi menţinute în directoarele utilizatorilor, asigurând în
acest fel faptul că aceste informaţii, inclusiv drepturile de acces, pot fi administrate şi
controlate în mod centralizat. Pe lângă simplificarea şi reducerea volumului de muncă
necesar întreţinerii directorului, lucrul dintr-un director centralizat previne problemele
de sincronizare sau actualizare a acestuia.
O componentă director a unui portal permite în mod normal existenţa mai
multor subdirectoare, într-o schemă federativă, acest lucru asigurând că un portal
poate lucra într-o schemă a unui director care este lărgită de către informaţiile
specifice portalului, menţinute într-un alt director. Interfaţa către aceste directoare
poate fi unul din uzualele LDAP (Lightweigh Directory Access Protocol), Microsoft
Active Directory sau Novell NDS eDirectory.
Componenta de acces la date externe a unui portal se concentrează pe oferirea
unui număr cît mai mare de adaptoare pentru diverse surse de date externe, precum
baze de date diferite sau accesul la date menţinute în mainframe-uri.
Având în vedere popularitatea pachetelor ERP, CRM, SCM, de management al
cunoştinţelor şi a aplicaţiilor de control al procesului, cele mai multe servere portal
oferă de asemenea adaptoare specifice aplicaţiilor.
Figura 3.24 - Arhitectura actualizată a portalului.

Tehnici de prezentare a datelor: portlet-uri, gadget-uri şi web parts
Portlet-urile sau alte mecanisme similare sunt facilităţi de profil ale multor
servere de tip portal în sensul că simplifică design-ul şi întreţinerea portalului şi
accelerează disponibilitatea conţinutului. Există numeroase căi în care portlet-urile
simplifică design-ul şi micşorează timpul necesar activării conţinutului; astfel portlet-
urile oferă funcţii de modularizare şi izolare. Fiecare aplicaţie portal va fi asociată unui
portlet specific, deci fiecare aplicaţie împreună cu portlet-ul corespunzător poate fi
dezvoltată, întreţinută şi actualizată în mod independent. În consecinţă, fiecare portlet
este o entitate autonomă independentă. De exemplu, inbox-ul e-mail-ului va fi un
portlet, aplicaţia de tip calendar un alt portlet iar agenda de contacte a organizaţiei va
fi un alt portlet. Funcţia de agregare a portalului va afişa în timp real diferite portlet-
uri, corespunzătoare diferitelor aplicaţii ale portalului.
Un alt factor cheie care face portlet-urile atât de atractive este disponibilitatea
portlet-urile gata construite atât de producătorul serverului de tip portal cât şi de la
alţi producători.
Printre cele mai utilizate portlet-uri gata construite, disponibile în pachetul de
instalare al portal-ului sau care pot fi instalate separat se numără:
 Portlet XSL, care va afişa conţinutul de tip XML prin utilizarea
transformărilor XSL (XSLT);
 Portlet WML, care va converti HTML către WML pentru ca portalul să
suporte dispozitive mobile;
 Portlet de ştiri, cu suport pentru RSS sau alt protocol, astfel încît conţinutul
sindicalizat să fie direct integrat în pagina portalului;
 Portlet-uri de colaborare, specifice Microsoft Exchange, Microsoft Outlook
sau Lotus Notes, cu opţiuni pentru e-mail, agendă de contacte, calendar şi
funcţie de tip „to-do list”;
 Portlet pentru acces la baze de date;
 Portlet pentru mesagerie instantanee;
 Portlet de căutare, oferit în combinaţie cu motoare de căutare cunoscute
precum Google;
 Portlet-uri specifice aplicaţiilor, cu suport pentru aplicaţii populare precum
ERP, resurse umane, CRM sau SCM, care simplifică integrarea acestor
aplicaţii larg utilizate în cadrul de lucru al portalului.
Producătorii de servere portal care suportă portlet-uri oferă pe Internet

cataloage cu toate portlet-urile disponibile pentru serverel produs de ei. De asemenea,
mai sunt oferite şi kit-uri de dezvoltare sau API-uri, astfel încât se pot construi propriile
portlet-uri.
Digital dashboard, web parts, iView şi skin-uri
Conceptul natural şi intuitiv de portlet, în ceea ce priveşte facilitarea dezvoltării

portalului, are, în mod evident, propriile corespondenţe în piaţa portalurilor actuale. În
cele mai multe cazuri, diferenţa este doar de terminologie, conceptul care stă la baza
acestor componente sau module care se pot ataşa portalurilor, fiind acelaşi. Microsoft,
de exemplu, a adoptat conceptul de digital dashboard.
Un digital dashboard este o pagină a portalului compună din diferite
componente web numite web parts, componente care pot fi combinate şi customizate
pentru a îndeplini cerinţele individuale ale utilizatorilor. Fiecare digital dashboard este
o pagină web separată care conţine una sau mai multe web parts, în care fiecare web
part este un obiect reutilizabil care conţine date sau script-uri, utilizate în vederea
prezentării de informaţii către utilizatori. Microsoft SharePoint, promovat ca şi „portal
într-o cutie” este centrat în totalitate pe digital dashboard, astfel încât serverul
SharePoint face referire la portaluri sub forma site-urilor digital dashboard. Pe lângă
componentele (web parts) gata create, există posibilitatea implementării digital
dashboard cu alte produse Microsoft, mai ales cu Microsoft Office, Microsoft SQL
Server sau Microsoft Exchange. În contextul unui digital dashboard, web parts devin
echivalentul portlet-urilor.
Microsoft oferă, de asemenea, la fel ca şi producătorii de portlet-uri, galerii cu
web parts, care conţin, de exemplu şi plug-in-uri către aplicaţii precum SAP sau Sibel.
Microsoft oferă de asemenea web parts pentru business intelligence, CRM, ERP,
transmiterea informaţiilor (recepţionarea de ştiri), knowledge management şi
colaborare, managementul proiectelor şi, în general, către toate aplicaţiile Microsoft.
Există, de asemenea, un kit pentru construirea de web parts, pe baza ASP.NET.
iView, acronimul de la Integrated View, este echivalentul SAP al unui portal.
Arhitectura SAP a unui portal din figura de mai sus conţine un „Server iView”, în care
Java şi .NET pot fi utilizate pentru afişarea/utilizarea mai multor iView-uri. Un iView
permite conţinutului şi aplicaţiilor să fie integrate într-un portal SAP. SAP defineşte un
iView sub forma unui element de prezentare autonom, bazat pe XML. Faptul că un
iView este bazat pe XML este singurul lucru care-l diferenţiază de celelalte modalităţi
de afişare a conţinutului precum portlet-uri sau web parts, care, deşi suportă XML, nu
necesită ca toate datele să fie bazate pe XML. iView de la SAP se pot conecta la diferite
tipuri de date şi aplicaţii prin intermediul construcţiilor cunoscute sub numele de
„conectori iView” (iView Connectors).
Skin-urile, un termen popularizat de BEA, nu sunt echivalentul portlet-urilor,
web part-urilor sau iView-urilor, deşi sunt utilizate de portlet-urile BEA. Skin-urile mai
pot fi asemuite şi temelor disponibile în Microsoft FrontPage, PowerPoint sau oricare
aplicaţie desktop din Windows. Un skin defineşte modalitatea de afişare (look and feel)
a fiecărei ferestre sau pagini a portalului. Deoarece un portal BEA este alcătuit din
portlet-uri, un skin specifică fonturile, culorile şi icoanele utilizate de un anumit portlet,
de aici venind şi asemănarea cu conceptul de „temă”. La fel ca şi în cazul temelor,
modalitatea de afişare a paginii unui portal se poate schimba în totalitate prin alegerea
unui nou skin.
Domenii, roluri, gadget, breadcrumbs
Domeniile şi rolurile sunt combinate de obicei şi sunt legate de personalizarea

unui portal. Conceptul de domeniu a fost utilizat în reţele pentru a indica o reţea
autonomă. Pe Internet termenul este întâlnit în numele de domeniu, utilizat pentru
identificarea prezenţei pe Internet a unei organizaţii (cisco.com, w3.org etc.). În
contextul unui server de tip portal, un domeniu defineşte cel mai înalt nivel al unui
anumit portal.
În cazul în care o organizaţie doreşte un singur portal consolidat, atunci întregul
portal poate fi un singur domeniu din punct de vedere al serverului care găzduieşte
portalul. Dacă organizaţia respectivă deţine mai multe portaluri, fiecare din acestea va
fi un domeniu separat dacă sunt implementate pe acelaşi server portal. Dintr-un alt
unghi, tot ceea ce este reunit sub aceeaşi adresă web aparţine unui singur domeniu;
deci, utilizarea de adrese web diferite (nume de domenii şi URL-uri) pentru portaluri
diferite dintr-o organizaţie conduce la domenii portal diferite. Domeniile sunt
importante pentru portaluri în cazul în care se doreşte execuţia mai multor portaluri pe
acelaşi server, permiţând identificarea portalurilor pe de-o parte, iar pe de alta
defineşte apartenenţa la o comunitate de utilizatori.
Personalizarea este implementată de obicei în servere portal prin intermediul
unui mecanism bazat pe roluri. În esenţă, fiecare utilizator autentificat primeşte unul
sau mai multe roluri în cadrul portalului, în timp ce utilizatorii neautentificaţi primesc
doar un rol implicit. Rolurile utilizatorilor definesc experienţa utilizatorului cu portalul
respectiv, ceea ce cuprinde modalitatea de afişare, controlul conţinutului şi serviciilor
precum şi accesul la aplicaţii.
Rolurile ar trebui definite ierarhic, într-o structură arborescentă, care să
oglindească structura organizaţiei, cel puţin din punct de vedere al organigramei,
permiţând asignarea uşoară către grupuri înrudite de oameni. De exemplu, se poate
defini un rol pentru toţi angajaţii din departamentul de resurse umane, alt rol pentru
cei din departamentul de marketing şi un altul pentru departamentul IT. Urmează apoi
asignarea de roluri specifice fiecărui departament către persoanele care au drepturi de
acces diferite la conţinut. Ca şi orice schemă ierarhică, rolurile pot moşteni
proprietăţile rolurilor de deasupra lor, existând şi mecanisme pentru modificarea şi
restricţionarea proprietăţilor moştenite. Rolurile ierarhice au marele avantaj de a
simplifica şi accelera procesul de personalizare şi administrare a portalurilor.
Gadget-urile, termen popularizat de Plumtree, este foarte asemănător unui
portlet sau web part, cu o singură mare diferenţă: un gadget este o componentă a unui
portal care operează pe un alt calculator. Gadget-urile sunt utilizate pentru integrarea
resurselor din aplicaţii şi plug-in-ul surselor de conţinut, ambele externe. În acest
context, resursele aplicaţiilor existente pot cuprinde instrumente de colaborare
precum e-mail, calendar sau directoare la nivel de organizaţie.
Numele întreg şi formal al unui gadget este „gadget web service”. Potrivit
Plumtree, gadget-urile sunt „servicii web” grafice disponibile utilizatorilor portalurilor,
care interacţionează direct cu acestea prin intermediul unui interfeţe cu utilizatorul
specifică gadget-urilor.
Ca şi în cazul portlet-urilor sau web part-urilor, mai multe gadget-uri pot si
combinate pentru a obţine o pagină a unui portal, în vederea oferirii utilizatorilor de
conţinut şi servicii personalizate. Figura de mai sus desemnează o vedere de ansamblu
a unui portal din punctul de vedere al Plumtree.
Breadcrumb, nume inventat de PeopleSoft, descrie o facilitate foarte utilă prin
care se poate face navigarea ierarhică, categorie cu categorie, pe măsură ce utilizatorul
navighează în portal urmărind link-urile oferite.
Utilizare WEB CMS Utilizare Portaluri Utilizare ECM
Simplu Locaţii Utilizare business
Broşură companie
Site orientat pe comunităţi Publicare Web Volum mare de capturi
Interacţiuni primare Dezvoltarea aplicaţiilor Web Procesare formulare
SMB/Internet departamental Portaluri de colaborare Conform cu reglementările în
vigoare
Portaluri self-service Management
Nivelul de mijloc Intranetul organizaţieii Colaborare de grup
Intranetul organizaţiei Portal de e-business Informaţii de marketing
Mgmt
E-business Integrarea aplicaţiilor în Documentaţie tehnică
organizaţii
Organizaţie – mod general Publicare organizaţie pe web
Publicare multi-canal
Micro-site-uri Orientarea spre industrie
Sănătate
Complex Guvernare
Intranet global Servicii profesionale
E-business Energie
Organizaţie – mod general Educaţie
Publicare multi-canale Sistem bancar
Siteuri de mari dimensiuni Asigurări
Producţie
Media / Divertisment
Sursa: CMS Watch – www. cmswatch.com
CAPITOLUL IV
APLICAŢII OPEN SOURCE CMS/PORTAL
Conceptul Open Source descrie metoda prin care sunt realizate şi dezvoltate
produse finite la care accesul utilizatorilor este liber. Utilizatorii pot acţiona şi asupra
procesului de producţie sau de dezvoltare ulterioară.
Potrivit unor accepţiuni, conceptul open source este privit din punct de vedere
ştiinţific, iar alţii văd open source ca o metodologie pragmatică.
Software "open source"

Metodologia open source este des utilizată în realizarea programelor software.
Astfel, mulţi specialişti consideră că termenul open source este legat doar de realizarea
de programe software. Metodologia open source este folosită şi în dezvoltarea de
aplicaţii în medicină, cultură, tehnologie etc.
Prin termenul open source înţelegem dezvoltarea de produse software de o
comunitate, de o companie sau de o persoană şi oferirea acestora spre utilizare şi
perfecţionare sub licenţă GPL (GNU General Public License). GPL este o licenţă de
distribuire liberă a programelor software.
Exemple de programe open source:
 Azureus (client bit-torrent),
 Blender (grafică 3D),
 Gaim (client pentru mesagerie),
 Mozilla Firefox (browser),
 OpenOffice.org (suita office),
 Linux (sistem de operare bazat pe open-source)
Software-ul liber are ca principală trăsătura libertatea acordată utilizatorilor de

a-l utiliza gratuit, de a-l distribui sau îmbunătăţi.
În ceea ce priveşte free software, este bine să se evite traducerea termenului
"free" ca gratuit, este mult mai potrivită traducerea acestui termen ca liber. Principala
caracteristică a software-ului liber este faptul că accesul la el este nemijlocit, atât în
varianta executabilă cât şi in varianta de cod sursă. Există cazuri când distribuirea
acestui tip de software este contra cost, deci utilizarea termenului de gratuit este
greşită.
Se observă existenţa a patru caracteristici esenţiale ale software-ului liber:

1. Libertatea de a utiliza programul, în orice scop (libertatea 0) de
oricine.
2. Libertatea de a studia funcţionarea programului, şi de a-l
îmbunătăţii conform nevoilor proprii (libertatea 1). (Accesul la
codul sursă al programelor este liber.)
3. Libertatea de a redistribui copii gratuite (libertatea 2).
4. Libertatea de a pune îmbunătăţirile la dispoziţia tuturor, în
folosul întregii comunităţi (libertatea 3).
Orice software este numit software liber dacă întruneşte toate cele 4
caracteristici de mai sus.
În acest sens "libertatea" se traduce prin posibilitatea de a redistribui, de a
efectua copii ale produsului, de modifica şi pune la dispoziţia comunităţii modificările
făcute în mod gratuit.
Libertatea de utilizare înseamnă că produsul program poate fi utilizat de orice
persoană fizică sau organizaţie, pentru orice fel de activitate (chiar şi comercială) fără
să comunice autorului programului sau unei alte entităţi acest fapt.
Libertatea de distribuire a programului presupune atât distribuirea acestuia sub
formă de cod cât şi sub formă executabilă. Distribuirea programelor în forma
executabilă este necesară pentru simplificarea instalării şi lucrului pe o altă maşină de
calcul, în timp ce forma cod este utilizată doar pentru modificare, adaptare şi corectare
a programelor. Există cazuri când datorită unor reglementări vamale sau a unor
sancţiuni comerciale internaţionale se limitează libertatea de distribuire a copiilor
programelor.
În urma mentenanţelor aduse pachetelor de programe rezultă versiuni
îmbunătăţite. Acest fapt se poate deci realiza doar pe baza existenţei codului sursă
care este modificat. Deci existenţa codului sursă pentru programele libere este o
necesitate.
Foarte important este ca toate acest libertăţi ce caracterizează software-ul
liber să fie irevocabile în timp. În cazul în care autorul programului poate revoca licenţa
fără a justifica acest lucru prin comiterea unei fapte de către utilizator, se consideră că
software-ul nu este liber.
Din acest motiv există o serie de reguli acceptate privind distribuirea de
software liber. De exemplu, copyleft (un termen derivat din copyright) înlătură
restricţiile de distribuire ale copiilor şi a versiunilor modificate, făcând ca versiunile
ulterioare realizate să fie caracterizate prin aceleaşi caracteristici de software liber ca şi
software-ul iniţial.
În concluzie, prin copyleft nu se pot adăuga limitări libertăţilor fundamentale
ale altor utilizatori. Copyleft-ul protejează libertăţile fundamentale.
Deoarece produsele software liber pot fi şi comercializate, poate exista cazul în
care pentru anumite programe GNU trebuie plătit unui distribuitor şi în acelaşi timp să
existe distribuitori care să ofere în mod gratuit acelaşi program. Odată intrat în posesia
unui program GNU, în calitate de distribuitor puteţi atât vinde respectivul produs, cât
şi să-l distribuiţi gratuit.
Software liber nu înseamnă non-comercial. Orice program caracterizat ca
software liber poate fi utilizat şi în scopuri comerciale şi trebuie să fie disponibil pentru
dezvoltare şi distribuţie comercială.
Software liber şi documentaţie liberă
Documentaţia este o parte esenţială a pachetului program. Documentaţia

liberă, ca şi software-ul liber, este caracterizată prin faptul că accesul la ea este realizat
în mod liber, nefiind obligatorie plata.
Criteriile ca o documentaţie să fie considerată liberă sunt foarte asemănătoare
criteriilor software-ului liber - sunt acordate tuturor utilizatorilor anumite libertăţi.
Redistribuirea (chiar şi cea comercială) trebuie să fie permisă, pentru ca fiecare pachet
software să fie însoţit de documentaţia aferentă. Documentaţia poate fi atât sub formă
digitală cât şi sub formă tipărită.
Totodată este absolut necesar ca documentaţia să poată fi modificată.
Comunitatea are dreptul de a modifica software-ul şi în consecinţă trebuie să opereze
şi în documentaţie modificările realizate.
Licenţa GNU pentru Documentaţie liberă (GNU Free Documentation Licence)1

versiunea 1.2 din noiembrie 2002.
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite
330, Boston, MA 02111-1307 USA
Oricine poate copia şi distribui copii identice ale acestui document, dar modificarea lui
nu este permisă.
0. PREAMBUL
Scopul acestei Licenţe este de a conferi unui set de instrucţiuni, manual şcolar sau altui
document folositor "libertate", înţeleasă în sensul următor: asigură tuturor libertatea
de a copia şi redistribui textul, cu sau fără modificări, în scopuri comerciale şi
necomerciale. Ca scop secundar, această Licenţă rezervă pentru autor şi editor dreptul
de a fi creditaţi pentru munca lor şi de a nu fi responsabili pentru modificările efectuate
de alţii.
Această Licenţă conferă un fel de "stânguri de autor" ("copyleft"), ceea ce înseamnă că
lucrările derivate trebuie să fie şi ele libere în sensul de mai sus. Această Licenţă este
inspirată de Licenţa Publică Generală GNU (GNU General Public License, GNU GPL),
care este o licenţă similară concepută pentru a acoperi softul liber.
Această Licenţă a fost scrisă pentru a oferi manuale pentru soft liber, pentru că softul
liber necesită documentaţie liberă: un program trebuie însoţit de manuale care oferă
aceeaşi libertate în folosire ca şi softul. Această Licenţă nu este limitată la manuale
pentru soft şi poate fi folosită pentru a acoperi orice lucrare, indiferent de subiect sau
de modul de publicare. Această Licenţă este recomandată în principal pentru lucrări
care servesc drept referinţă sau au fost scrise în scop de instruire.
1. APLICABILITATE ŞI DEFINIŢII
Această Licenţă se aplică oricărui manual sau lucrări, în orice mediu, care conţine o
notă inclusă de către deţinătorul dreptului de autor ce permite distribuţia sub
acoperirea acestei Licenţe. Nota conferă dreptul universal (world-wide), fără
indemnizaţie şi nelimitat ca durată de a folosi această lucrare în condiţiile descrise de
această Licenţă. Termenul "Documentul" folosit mai jos se referă la manualul sau
1
http://ro.wikipedia.org/wiki/Wikipedia:GNU_FDL
lucrarea acoperită de Licenţă. Orice membru al publicului este un beneficiar al acestei
Licenţe şi va fi desemnat prin termenul "Dvs." sau prin folosirea persoanei a doua. Se
consideră în mod automat că aţi acceptat termenii acestei Licenţe dacă copiaţi,
modificaţi sau distribuiţi Documentul într-un mod ce necesită permisiunea autorului în
conformitate cu legea drepturilor de autor.
O "Versiune Modificată" a Documentului este orice lucrare conţinând Documentul sau
o porţiune din Document, copiată identic sau cu modificări şi/sau tradusă într-o altă
limbă.
O "Secţiune Secundară" este o anexă cu titlu, sau o secţiune menţionată în cuprins care
are ca scop exclusiv descrierea relaţiei editorilor sau a autorilor Documentului cu
subiectul Documentului (sau cu subiecte legate de acesta) şi care nu conţine subiecte
incluse în mod direct în subiectul Documentului. (Aşadar, dacă Documentul este în
parte manual de matematică, o Secţiune Secundară nu poate conţine explicaţii
matematice.) Relaţia poate fi o conexiune istorică cu subiectul sau cu problemele
înrudite cu subiectul, sau puncte de vedere juridice, comerciale, filosofice, etice sau
politice legate de acesta.
"Secţiunile Invariante" sunt anumite Secţiuni Secundare ale căror titluri sunt specificate
ca fiind titluri de Secţiuni Invariante din Document în nota ce permite distribuţia
Documentului sub acoperirea acestei Licenţe. Dacă o secţiune nu este conformă cu
definiţia de mai sus a unei Secţiuni Secundare, ea nu poate fi desemnată drept Secţiune
Invariantă. Documentul poate să nu conţină nici o Secţiune Invariantă.
"Textele De Copertă" sunt pasaje scurte de text care sunt listate ca Texte Pentru
Coperta I (coperta din faţă) şi Texte Pentru Coperta IV (coperta din spate) în nota ce
permite distribuţia Documentului sub acoperirea acestei Licenţe. Un Text Pentru
Coperta I poate avea cel mult 5 cuvinte, iar un Text Pentru Coperta IV poate avea cel
mult 25 de cuvinte.
O copie "Transparentă" a Documentului este o copie în format electronic, reprezentată
într-un format a cărui specificaţie este disponibilă publicului. Aceasta este uşor de
modificat folosind un editor de text generic, sau un editor grafic generic (pentru
imagini compuse din pixeli) sau un editor larg răspândit de grafică vectorială (pentru
desene) şi poate fi folosită deprograme de formatare de text sau de programe de
conversie. O copie făcută într-un format de fişier Transparent, dar care prin prezenţa
sau absenţa anumitor elemente specifice formatului descurajează sau împiedică
modificările ulterioare nu este o copie Transparentă. Un format grafic - o imagine - nu
este un format Transparent dacă este folosit pentru a reprezenta o cantitate
substanţială de text. O copie care nu este "Transparentă" este "Opacă".
Exemple de formate compatibile cu copiile Transparente: text ASCII fără
marcare, format de intrare Texinfo, format de intrare LaTeX, SGML şi XML folosind un
DTD public, HTML simplu şi standard, fişiere PostScript şi PDF modificabile.
Exemple de formate Transparente pentru imagine: PNG, XCF şi JPG.
Formatele Opace includ formate de text ce pot fi citite şi editate doar de
procesoare de text particulare (proprietary), SGML şi XML pentru care DTD-ul şi/sau
uneltele de procesare nu sunt disponibile, HTML generat automat, documente
PostScript şi PDF produse de diverse procesoare de text exclusiv în scopul
printării/afişării.
"Pagina de Titlu" înseamnă, pentru o carte tipărită, pagina cu titlul şi paginile
următoare necesare pentru a tipări lizibil materialul care trebuie tipărit conform acestei
Licenţe pe Pagina de Titlu. Pentru lucrări care nu au o pagină cu titlu propriu-zisă

"Pagina de Titlu" este textul aflat lângă principala apariţie a titlului lucrării, precedând
începutul corpului Documentului.
O secţiune "Numită XYZ" este o secţiune din Document al cărei titlu este fie XYZ sau
conţine XYZ în paranteze după textul care traduce XYZ în altă limbă. (Aici XYZ
înlocuieşte nume specifice ce vor fi menţionate mai jos, ca de exemplu "Mulţumiri",
"Dedicaţii", "Giruri" (Endorsement) şi "Istorie".) A "Păstra Titlul" unei astfel de secţiuni
atunci când modificaţi Documentul înseamnă că aceasta rămâne "Numită XYZ"
conform acestei definiţii.
Documentul poate include Limitări de Responsabilitate (Warranty Disclaimers) ataşate
notificării care afirmă că această Licenţă se aplică Documentului. Aceste Limitări de
Responsabilitate se consideră a fi incluse pentru referinţă în această Licenţă: orice alte
implicaţii pe care aceste Limitări de Responsabilitate le-ar putea avea sunt nule şi nu au
nici un efect asupra înţelesului acestei Licenţe.
2. COPII IDENTICE
Puteţi copia şi distribui Documentul pe orice mediu, comercial sau necomercial, atâta
timp cât această Licenţă, notificările de drepturi de autor şi notificarea de licenţă care
spune că această Licenţă se aplică acestui Document sunt reproduse în toate copiile, şi
atâta timp cât nu adăugaţi nici un fel de altă condiţie în afară de cele prezente în
această Licenţă. Nu aveţi dreptul să luaţi măsuri tehnice de a obstrucţiona sau controla
citirea sau recopierea copiilor pe care le faceţi sau le distribuiţi. Aveţi totuşi dreptul să
acceptaţi compensaţii în schimbul copiilor. Dacă distribuiţi un număr suficient de mare
de copii trebuie să respectaţi şi condiţiile din secţiunea 3.
Aveţi de asemenea dreptul să împrumutaţi copii în aceleaşi condiţii ca cele de mai sus,
şi aveţi dreptul să afişaţi copii.
3. COPIEREA ÎN CANTITĂŢI MARI
Dacă publicaţi copii tipărite (sau copii în medii care folosesc de obicei coperţi tipărite)
ale Documentului, în număr mai mare de 100 şi dacă notificarea de licenţă a
Documentului cere Texte de Copertă, trebuie să includeţi copiile pe coperţi care să
conţină, clar şi lizibil, toate aceste Texte de Copertă: Textele Pentru Coperta I pe
coperta I şi Texte Pentru Coperta IV pe coperta IV. Ambele coperţi trebuie de asemenea
să vă identifice în mod clar şi lizibil ca editor al respectivelor copii. Coperta I trebuie să
prezinte titlul în întregime, cu toate cuvintele din titlu la fel de vizibile şi proeminente.
Puteţi adăuga alte materiale pe copertă în plus. Copierea cu modificările limitate la
coperţi, atâta timp cât satisfac aceste condiţii, pot fi tratate în toate celelalte aspecte
ca şi copii identice.
Dacă textele necesare pentru oricare dintre coperţi sunt prea voluminoase pentru a
încăpea în mod lizibil, trebuie să le includeţi pe primele în ordinea originală (atâtea câte
încap în mod rezonabil) pe coperta efectivă şi să continuaţi cu restul pe pagini
adiacente.
Dacă publicaţi sau distribuiţi copii Opace ale documentului în număr mai mare de 100,
trebuie ori să includeţi câte o copie Transparentă în format electronic împreună cu
fiecare copie Opacă, sau să specificaţi în sau împreună cu fiecare copie Opacă o locaţie
de reţea electronică la care publicul general care foloseşte reţeaua să aibă acces pentru
a descărca, folosind un protocol standard public, copii complete Transparente ale
documentului, fără adăugarea oricărui material adiţional. Dacă folosiţi a doua opţiune
trebuie să faceţi demersuri rezonabil de prudente ca atunci când începeţi distribuirea
copiilor Opace să vă asiguraţi că această copie Transparentă va rămâne accesibilă în
acest fel la locaţia respectivă timp de cel puţin un an după distribuţia ultimei copii
Opace (în mod direct sau prin agenţi sau distribuitori) a acelei ediţii pentru public.
Se cere, dar nu în mod necesar, să contactaţi autorii Documentului cu o perioadă bună
înainte de a distribui orice cantitate mare de copii, pentru a le da ocazia să vă pună la
dispoziţie o versiune actualizată a Documentului.
4. MODIFICĂRI
Puteţi copia şi distribui o Versiune Modificată a Documentului în condiţiile secţiunilor 2
şi 3 de mai sus, cu condiţia de a acoperi Versiunea Modificată sub exact această
Licenţă, cu Versiunea Modificată ţinând locul Documentului, astfel licenţiind
distribuirea şi modificările Versiunii Modificate oricui intră în posesia unei copii ale
acesteia. În plus, trebuie să faceţi următoarele lucruri în Versiunea Modificată:
 A. Folosiţi în Pagina de Titlu (şi pe coperţi, dacă există) un titlu diferit de cel al
Documentului, şi de versiunile sale anterioare (care trebuie, dacă există, să fie
listate în secţiunea de Istorie a Documentului). Puteţi folosi acelaşi titlu ca o
versiune anterioară dacă editorul original al acelei copii vă dă permisiunea.
 B. Listaţi pe Pagina de Titlu, ca autori, una sau mai multe dintre persoanele sau
entităţile responsabile în calitate de autori pentru modificările Versiunii
Modificate, împreună cu cel puţin cinci dintre autorii principali ai Documentului
(toţi autorii principali, dacă are mai puţin de cinci), în afară de cazul că aceştia
vă eliberează de această obligaţie.
 C. Includeţi pe Pagina de Titlu numele editorului Versiunii Modificate în calitate
de editor.
 D. Păstraţi toate notificările de drepturi de autor ale Documentului.
 E. Adăugaţi o notificare de drepturi de autori relevantă pentru modificările Dvs.
adiacent celorlalte notificări de drepturi de autor.
 F. Includeţi, imediat după notificările de drepturi de autor, o notificare de
licenţă dând permisiune publică de a folosi Versiunea Modificată în condiţiile
acestei Licenţe, sub forma prezentată în Apendicele de mai jos.
 G. Păstraţi în acea notificare de licenţă lista integrală a Secţiunilor Invariante şi
Textele de Copertă necesare date în notificarea de licenţă a Documentului.
 H. Includeţi o copie nealterată a acestei Licenţe.
 I. Păstraţi secţiunea Numită "Istorie", păstraţi-i Titlul şi adăugaţi-i un element
care să indice măcar titlul, anul, noii autori şi editorul Versiunii Modificate aşa
cum este dat pe Pagina de Titlu. Dacă nu există o secţiune Numită "Istorie" în
Document, creaţi una în care indicaţi titlul, anul, autorii şi editorul
Documentului aşa cum este dat pe Pagina de Titlu al acestuia şi apoi adăugaţi
un element care să descrie Versiunea Modificată aşa cum a fost cerut în fraza
precedentă.
 J. Păstraţi locaţia de reţea, dacă există, dată în Document pentru acces public la
o copie Transparentă a Documentului, cât şi locaţiile de reţea date în Document
pentru versiunile mai vechi pe care s-a bazat acesta. Acestea pot fi incluse în
secţiunea Numită "Istorie". Puteţi omite locaţia de reţea a unei lucrări care a
fost publicată cu cel puţin patru ani înainte de Documentul în sine, sau dacă
editorul original al versiunii la care se referă vă dă permisiunea.
 K. Pentru orice secţiune Numită "Mulţumiri" sau "Dedicaţii", păstraţi Titlul

secţiunii şi păstraţi în secţiunile respective toată substanţa şi tonul mulţumirilor
şi dedicaţiilor fiecărui contribuitor.
 L. Păstraţi toate Secţiunile Invariante ale Documentului, nealterate ca text şi ca
titluri. Numerotarea secţiunilor sau echivalentul numerotării nu sunt
considerate ca făcând parte din titlurile secţiunilor.
 M. Ştergeţi orice secţiune Numită "Giruri". O astfel de secţiune nu poate fi
inclusă în Versiunea Modificată.
 N. Nu modificaţi titlul nici unei secţiuni existente pentru a fi Numită "Giruri" sau
pentru a intra în conflict cu vreo Secţiune Invariantă.
 O. Păstraţi toate Limitările de Responsabilitate.
Dacă Versiunea Modificată include secţiuni noi incluse în titlu sau anexe care se califică
drept Secţiuni Secundare şi nu conţin material copiat din Document, aveţi dreptul la
alegerea Dvs. să numiţi unele sau toate acestea ca fiind secţiuni invariante. Pentru a
face aceasta, adăugaţi-le titlurile la lista de Secţiuni Invariante în notificarea de licenţă
a Versiunii Modificate. Aceste titluri trebuie să fie distincte faţă de toate celelalte titluri
de secţiune.
Puteţi adăuga o secţiune Numită "Giruri" doar dacă aceasta conţine numai girurile a
diverse entităţi asupra Versiunii Modificate - de exemplu recenzii sau faptul că textul a
fost aprobat de o organizaţie ca fiind o definiţie autoritară a unui standard.
Puteţi adăuga un pasaj de cel mult cinci cuvinte ca Text Pentru Coperta I şi un pasaj de
cel mult 25 de cuvinte ca Text Pentru Coperta IV la sfârşitul Textelor De Copertă în
Versiunea Modificată. Numai un singur pasaj poate fi adăugat la Textul Pentru Coperta
I şi unul la Textul Pentru Coperta IV de către (sau prin aranjament cu) orice entitate.
Dacă Documentul conţine deja texte de copertă pentru coperta respectivă, adăugat în
prealabil de Dvs. sau prin aranjament cu aceeaşi entitate în numele căreia acţionaţi,
atunci nu puteţi adăuga un altul, însă puteţi să-l înlocuiţi pe cel vechi numai cu
permisiunea explicită a editorului anterior care l-a adăugat pe cel vechi.
Autorul (autorii) şi editorul (editorii) Documentului nu vă dau prin această Licenţă
permisiunea de a le folosi numele pentru publicitate sau pentru a pretinde sau implica
vreo girare a oricărei Versiuni Modificate.
5. COMBINAREA DOCUMENTELOR
Puteţi combina Documentul cu alte documente acoperite de această Licenţă sub
termenii definiţi în secţiunea 4 de mai sus pentru versiuni modificate, cu condiţia să
includeţi în versiunea combinată toate Secţiunile Invariante ale tuturor documentelor
originale, nemodificate, şi să le listaţi pe toate ca Secţiuni Invariante ale versiunii
combinate în notificarea de licenţă, cât şi să păstraţi toate Limitările de
Responsabilitate.
Versiunea modificată nu trebuie să conţină decât o singură copie a acestei Licenţe, iar
duplicatele identice ale Secţiunilor Invariante pot fi înlocuite cu o singură copie. Dacă
există Secţiuni Invariante cu nume identice şi conţinut diferit, schimbaţi-le numele
adăugând la sfârşitul titlului, în paranteză, ori numele autorului sau al editorului
original al acelei secţiuni dacă acesta este cunoscut, ori un număr unic. Faceţi aceleaşi
modificări respective titlurilor secţiunilor în lista de Secţiuni Invariante din notificarea
de licenţă a versiunii combinate.
În versiunea combinată trebuie să combinaţi şi toate secţiunile Numite "Istorie" din
diversele documente originale, creând o secţiune unică Numită "Istorie"; la fel trebuie
să combinaţi şi toate secţiunile Numite "Mulţumiri" cât şi cele Numite "Dedicaţii".
Trebuie să ştergeţi toate secţiunile Numite "Giruri".
6. COLECŢII DE DOCUMENTE
Puteţi crea o colecţie formată din Document şi alte documente acoperite de această
Licenţă şi să înlocuiţi copiile individuale ale acestei Licenţe din diversele documente cu o
singură copie care să fie inclusă în colecţie cu condiţia să urmaţi regulile acestei Licenţe
pentru copii identice pentru fiecare document în toate celelalte privinţe.
Puteţi să extrageţi un document dintr-o astfel de colecţie şi să-l distribuiţi individual sub
această Licenţă cu condiţia de a include o copie a acestei Licenţe în documentul extras
şi să urmaţi condiţiile acestei Licenţe în toate celelalte privinţe în legătură cu copiile
identice ale acelui document.
7. AGREGAREA CU LUCRĂRI INDEPENDENTE
O compilaţie a Documentului sau a unui derivat al său cu orice document sau lucrare
separată independentă, în sau pe un volum de stocare sau distribuire se numeşte
"agregat" dacă drepturile de autor rezultate în urma compilării nu sunt folosite pentru
a limita drepturile legale ale utilizatorilor compilaţiei mai mult decât permit lucrările
individuale. Când Documentul este inclus într-un agregat, această Licenţă nu se aplică
celorlalte lucrări din agregat care nu sunt ele însele rezultate derivate ale
Documentului.
Dacă cerinţele legate de Textele de Copertă din secţiunea 3 se aplică acestor copii ale
Documentului, atunci dacă Documentul este mai puţin de jumătate din întregul
agregat atunci Textele de Copertă ale Documentului pot fi puse pe coperţi care să
separe Documentul în cadrul agregatului, sau pe un echivalent electronic al acestora,
dacă Documentul se prezintă în format electronic. Altfel ele trebuie să apară pe
coperţile tipărite care îmbracă întreg agregatul.
8. TRADUCERE
Traducerea este considerată o formă de modificare, drept care puteţi distribui traduceri
ale Documentului sub cerinţele secţiunii 4. Înlocuirea Secţiunilor Invariante cu traduceri
ale acestora necesită permisiune specială din partea celor care deţin drepturile de
autor, însă puteţi include traduceri ale unora sau tuturor Secţiunilor Invariante
împreună cu variantele originale ale acestora. Puteţi include o traducere a acestei
Licenţe cât şi toate notificările de licenţă din Document, cât şi Limitările de
Responsabilitate atâta timp cât includeţi şi versiunea originală în engleză a acestei
Licenţe, plus versiunile originale ale respectivelor notificări de licenţă şi limitări de
responsabilitate. În cazul apariţiei oricăror discrepanţe între versiunea tradusă şi
versiunea originală a acestei Licenţe, a vreunei notificări de licenţă sau a vreunei
limitări de responsabilitate, versiunea originală are prioritate.
Dacă vreo secţiune din Document este Numită "Mulţumiri", "Dedicaţii" sau "Istorie"
cerinţa (din secţiunea 4) de a-i Păstra Titlul (secţiunea 1) va necesita în mod normal
schimbarea titlului în sine.
9. REZILIERE
Nu puteţi copia, modifica, sublicenţia sau distribui Documentul decât în condiţiile
specificate explicit în această Licenţă. Orice copiere, modificare sau redistribuire a
Documentului în vreo altă condiţie este nulă şi vă va anula în mod automat drepturile
conferite de această Licenţă. Pe de altă parte, terţilor cărora le veţi fi transmis copii sau
drepturi în conformitate cu această Licenţă nu li se vor anula aceste drepturi atâta timp
cât i se conformează.
10. VERSIUNI VIITOARE ALE ACESTEI LICENŢE

Fundaţia Free Software (Free Software Foundation) poate publica versiuni noi, revizuite
ale acestei Licenţe (GNU Free Documentation License) din timp în timp. Aceste noi
versiuni vor păstra spiritul acestei versiuni dar pot diferi în privinţa detaliilor, cu scopul
de a se adresa unor noi probleme reale sau potenţiale.
Fiecărei versiuni ale acestei Licenţe îi este asociat un număr de versiune distinct. Dacă
Documentul specifică un anumit număr de versiune "sau orice versiune ulterioară" al
acestei Licenţe, aveţi de ales între a vă conforma termenilor şi condiţiilor ori ale
versiunii specificate explicit sau ale oricărei variante ulterioare publicate (nu ca
variantă preliminară) de către Free Software Foundation. Dacă Documentul nu
specifică un număr de versiune al acestei Licenţe atunci puteţi alege orice versiune
publicată (nu ca variantă preliminară) de către Free Software Foundation.
Figura 4.1. – Categorii de software după licenţă.
 Software liber (Free software) - este un software care are permisiunea de a

putea fi utilizat de oricine, de a putea fi copiat şi distribuit în forma iniţială sau
cu modificări atât gratuit cât şi contra cost. Este obligatoriu să fie distribuit şi
codul sursă al software-ului.
 Software Open Source - este un software ce face parte din aceeaşi categorie cu
software-ul liber dar are o serie de trăsături caracteristice. Software-ul open
source nu se referă la aceeaşi clasă de software, având licenţe cu caracter mai
restrictiv. În acest sens observăm că orice software liber are disponibil codul
sursă şi este gratuit, în timp ce software-ul open source are disponibil codul
sursă dar nu este neapărat gratuit.
 Software public - este un software care nu are drepturi de copyright. Există
situaţii când pentru un program, versiunea executabilă este de tip software
public, dar versiunea cod sursă nu este disponibilă. Acesta nu este software
liber, deoarece software-ul liber cere ca şi codul sursă să fie disponibil. Uneori
noţiunea de software public este utilizată greşit pentru software gratuit sau
software liber. Utilizarea corectă a termenului de software public este doar în
situaţia când lipseşte dreptul de copyright.
 Software copyleft - este acea categorie de software în care distribuţia tuturor
copiilor şi ale tuturor versiunilor se încadrează software-ului liber. Aceasta
înseamnă că nu este permisă adăugarea de condiţii suplimentare software-ului
şi în plus varianta cod sursă a software este disponibilă. Copyleft este un
concept general. Pentru ca un program să fie caracterizat de licenţă copyleft,
este necesară utilizarea unor termeni speciali de distribuţie.
 Software non-copyleft - este un software pentru care autorul are permisiunea
de a distribui, modifica precum şi de a adăuga restricţii suplimentare în cadrul
licenţei. Dacă un program este liber, dar nu este din categoria copyleft, atunci
există posibilitatea să existe versiuni sau copii care nu sunt libere. Orice
companie sau persoană poate să realizeze varianta executabilă a programului,
care va avea licenţă proprietar.
 Software GPL (General Public License) - este un software liber, cu licenţă
copyleft. Acest tip de licenţă se poate aplica atât software-ului cât şi altor
produse. Licenţele marii majorităţi a software-urilor au menirea de a înlătura
libera distribuire şi schimbul. În opoziţie, licenţele GNU-GPL garantează
libertatea de distribuire şi schimb a tuturor versiunilor de program, pentru ca
software-ul să fie liber tuturor utilizatorilor. Acest tip de licenţă se referă în
primul rând la libertatea de a distribui software-ul şi nu la gratuitatea acestui
lucru.
 Software ne-liber - este acel software care nu face parte din software-ul liber.
Această categorie include software-ul semi-liber şi software-ul brevetat.
 Software-ul semi-liber - este un software care nu este liber şi care are o serie
de permisii acordate indivizilor de a-l utiliza, copia, distribui şi modifica (inclusiv
distribuirea versiunilor modificate) în scopuri non-profit.
 Software-ul brevetat - este un software care nu este nici liber nici semi-liber.
Modificarea, redistribuirea, utilizarea sunt interzise sau sunt contra cost.
 Software freeware - este acel software ce permite redistribuire dar nu permite
modificare şi nici codul sursă nu este disponibil. Acesta nu face parte din acest
motiv din categoria software-ului liber.
 Software shareware - este o categorie de software care are permisia de a
putea fi redistribuit. Orice utilizator care continuă să folosească programul în
continuare trebuie să plătească. Pentru majoritatea programelor shareware,
codul sursă nu este disponibil, de aceea nu face parte din categoria
programelor libere.
 Software privat - este acel software dezvoltat numai pentru un singur utilizator
(organizaţie sau companie). Acest utilizator păstrează programul şi codul sursă
fără a-le distribui altor potenţiali utilizatori.
 Software comercial - este un software dezvoltat în scop comercial, de a se
obţine remuneraţii din vânzarea sa. Software comercial şi Software brevetat nu
este acelaşi lucru. Marea parte a software-urilor comerciale sunt brevetate, dar
pe de altă parte există şi software-uri libere care sunt supuse actelor
comerciale.
Scurtă istorie a proiectului GNU
GNU este un sistem de operare ce se încadrează în categoria software liber.

În septembrie 1983, Richard Stallman a făcut anunţul iniţial de lansare a
proiectului GNU. O versiune îmbunătăţită a manifestului iniţial a fost publicată în 1985
şi a fost tradusă în mai multe limbi.
GNU este acronimul de la GNU's Not Unix.
În anul 1980 mare parte din software-ul existent era brevetat, ceea ce făcea ca
utilizatorii să nu aibă acces la codul sursă al programelor. Acest lucru împiedica
cooperarea dintre utilizatori. De aici a reieşit necesitatea apariţiei proiectului GNU.
Dezvoltatorii proiectului GNU au hotărât ca sistemul de operare realizat de ei să
fie compatibil Unix deoarece mare parte din design era realizat şi prin compatibilitate,
mulţi utilizatori de Unix puteau trece rapid la GNU.
Compatibilitatea cu Unix făcea ca GNU să includă şi compilatoare, editoare,
software de mail, tip de formatare a textului etc.
În octombrie 1985 s-a înfiinţat Free Software Foundation care avea ca scop
principal strângerea de fonduri în folosul proiectului GNU.
În 1991 apare Linux, un sistem de operare compatibil cu Unix, creat de Linus
Torvalds. Prin combinarea Linux-ului cu sistemul GNU (aproape finalizat) a rezultat un
sistem de operare complet: sistemul GNU/Linux. Estimările spun că 10 milioane de
utilizatori folosesc în prezent sistemul de operare GNU/Linux, şi este distribuit prin
Slackware, Debian, Red Hat etc.
Proiectul GNU nu s-a limitat la realizarea unui sistem de operare. În continuare
proiectul prevede dezvoltarea unui spectru larg de programe software.
De asemenea, s-a încercat dezvoltarea unor aplicaţii cum ar fi GNOME
(graphical desktop) cu scopul facilitării utilizării sistemului de operare GNU printr-o
interfaţă grafică.
4.1. LIFERAY PORTAL / CMS 4.3
Liferay este considerat principalul open-source portal ce permite publicarea

web şi managementul conţinutului. Portalul Liferay completează elementele unui CMS
cu elemente de managementul utilizatorilor/grupurilor/rolurilor, permisii şi securitate,
servicii web, suport, utilizarea temelor, navigare dinamică etc.
Noile elemente din versiunea 4.2 includ integrarea cu Alfresco ECM, elemente
SOA cum ar fi ESB, creşterea uneltelor de colaborare cum ar fi Instant Messanger sau
forumuri. Versiunea 4.3 va include lucrul cu tag-uri, plug-inuri de arhitectură pentru
updateuri.
Liferay Inc. oferă o echipă dedicată dezvoltării precum şi servicii de consultare
cu privire la produs, oferind suport tehnic, training şi servicii profesionale.
Figura 4.2 - Arhitectura Liferay
4.2. NUXEO CPS 5.0
Nuxeo CPS (portal server colaborativ) este un sistem de managementul

conţinutului extins, implementat pe Zope şi CMF.
Nuxeo CPS oferă organizaţiilor să implementeze cu uşurinţă, rapid şi eficient
aplicaţii de tip colaborare atât într-un intranet cât şi pe Internet. Este construit ca o
aplicaţie modulară cu mai multe componente şi servicii (structurarea documentelor,
notificarea evenimentelor, evidenţa versiunilor...), servicii de interfaţă pentru utilizator
(managementul skin-urilor portalului, editarea documentelor...) şi servicii de business
(forum, groupware, chat, formulare...).
Exemple de proiecte construite cu Nuxeo CPS sunt: intranet şi extranet pentru
ministerele de cultură francez şi de interne (având peste 10.000 de utilizatori).
Figura 4.3 – Arhitectura Nuxeo.
4.3. DOTNETNUKE - PORTAL OPEN SOURCE
Instalarea portalului DotNetNuke
În continuare vom discuta despre instalarea portalului DotNetNuke. De altfel,

actualul proces de instalare al DNN nu este foarte dificil, el constând dintr-o serie de
paşi ce trebuie parcurşi. În timpul procesului de instalare, utilizatorul trebuie să ia o
serie de decizii critice ce vor afecta aplicaţia. Pentru evitarea diferitelor erori trebuie
fixate de la început noţiunile de hardware, de software şi de găzduire prestabilite
pentru mediul DNN.
Instalarea portalului DNN putem să o divizăm în patru etape principale:

 analiza scopurilor utilizării DNN, bazată pe un plan hardware,
software şi de găzduire
 paşii de implementare
 explorarea elementelor din timpul instalării
 modele de instalare, ce introduc noi metode de personalizare a
instalării
Pregătirea instalării
Aplicaţia DNN va fi instalată ca un director virtual al unui URL existent de forma:
http://<nume server>/DNN/
<nume server> din URL reprezintă serverul (localhost), serverul de web din
interiorul reţelei intranet, sau serverul web din extranet.
Analiza hardware
DNN nu necesită pregătiri hardware prestabilite, dar necesită o serie de
elemente software ce trebuie instalate pe o configuraţie hardware minimală.
Următoarele cerinţe sunt minimale pentru funcţionarea bazelor de date SQL

SERVER:
Procesor - Intel Pentium sau compatibil la 166 MHZ
Memorie RAM - versiunea Enterprise: 64 MB, 128 MB
recomandat
- versiunea Standard: 64 MB
- versiunea de evaluare: 64 MB, 128 MB
recomandat
- versiunea Developer: 64 MB
- versiunea Personal: 128 MB pentru Windows XP;
64 MB pentru Windows 2000; 32 pentru alte
sisteme de operare
- MSDE: pentru Windows XP; 64 MB pentru
Windows 2000; 32 pentru alte sisteme de operare
Hard Disk
- Versiunile Enterprise, Standard, Evaluation,
Developer şi Personal necesită:
- 95-270 MB disponibil pe hard disk pe server; 250
MB instalare obişnuită
- 50 MB disponibil pe hard disk pentru o instalare
minimă a Analysis Services; 130 MB instalare
obişnuită
- 80 MB disponibil pe hard disk pentru English
Query. MSDE necesită 44 MB disponibil pe hard
disk.
Deoarece DNN este o aplicaţie web este de preferat ca serverul de web să aibă
mai multă memorie RAM (peste 1 GB).
Analiza software
Pentru funcţionarea aplicaţiei DNN este necesar ca pe server-ul respectiv să fie

instalate următoare aplicaţii:
Server de web - Microsoft Internet Information Server 5 sau

superior (conţinut de Windows 2000 Server, Windows XP
Professional, Windows 2003 Server)
Microsoft .NET Runtime - ASP.NET 1.1 sau superior
Baze de date - Microsoft SQL Server 2000 sau superior
Analiza hosting
După analiza elementelor de hardware şi software este necesară analiza

elementelor de hosting ale portalului.
Permisiunile fişierelor - DNN necesită ca procesele ASP.NET să

aibă permisiunea de FULL CONTROL asupra directorului rădăcină de
instalare (de root)
DNN utilizează termenul de portal pentru a face diferenţa între site-urile web
pe care o singura aplicaţie le poate conţine. Portalul poate fi văzut ca o poartă de
intrare către alte web site-uri, de obicei oferind acces şi motoare de căutare a
informaţiilor.
În realitate DNN este mai mult decât o simplă poartă de acces către alte
aplicaţii. DNN oferă posibilitatea găzduirii mai multor web site-uri ce au acelaşi cod de
bază, fiecare conţinând diferite informaţii. Din punctul de vedere al funcţionării
portalului observăm două tipuri de portaluri: părinte şi copil. În calitate de
administrator orice utilizator poate realiza sute de site-uri într-un portal. În momentul
rulării aplicaţiei se determină conţinutul corect care trebuie afişat pe baza PortalID,
adică a identificării portalului accesat.
Portalurile părinte/copil
Diferenţa între portalurile părinte şi copil este vizibilă în URL-ul fiecăruia. Un
portal părinte are URL-ul de forma http://www.domeniu.ro iar portalul copil are forma
http://www.domeniu.ro/portalcopil. Aplicaţia odată instalată poate suporta orice
combinaţie a portalurilor părinte şi copil. Singura diferenţă existentă între tipurile de
portal este dată de definirea portalului. Figura următoare prezintă setările disponibile
în momentul instalării.
Setările portalului - părinte/copil
Figura 4.4 – Crearea unui site/portal folosind DotNetNuke.
Modulul de configurare a portalului dă posibilitatea câtorva opţiuni. În

momentul selectării unui portal copil nu este necesară o altă configurare suplimentară
a aplicaţiei. Pentru un portal părinte, însă este necesară o configurarea în IIS Manager
cu privire la numele domeniului şi de a crea legăturile DNS cu adresa IP a serverului.
Paginile
Paginile sunt un concept relativ nou în DNN. Începând cu versiunea 3.X, acestea
sunt referite ca şi tab-uri. Acest lucru a fost realizat pentru a permite un lucru mai facil
din partea utilizatorului începător. În acest sens noţiunea de pagină poate fi văzută ca
o pagină statică html. Diferenţa este că pagina este încărcată pe baza unei serii de
parametrii.
În realitate, există doar o singură pagină care este afişată utilizatorilor, doar
conţinutul schimbându-se. Pentru administrarea paginilor portalului sunt disponibile o
serie de opţiuni ca în figura următoare:
Figura 4.5 - Opţiunile oferite pentru modificarea paginilor

Funcţiile paginii permit utilizatorului gestionarea paginilor.
Funcţie Descriere
Adăugare (Add) Permite adăugarea unei noi pagini în portal. După selectarea acestei
opţiuni din meniu se utilizează panoul de Management al Paginii, în care
se pot definii proprietăţile paginii (cum ar fi numele paginii, titlul, cuvinte
cheie, securitate etc.)
Setări (Settings) Meniul Setări permite modificarea paginii create precedent. Utilizatorul
poate modifica pagina curentă precum şi proprietăţile paginii.
Ştergere (Delete) Permite ştergerea sau înlăturarea paginii curente din cadrul portalului.
Copiere (Copy) Permite copierea modulelor alocate paginii curente. De asemenea este
posibilă duplicarea conţinutului în module în pagina curentă. Aceasta
presupune o salvare în timp real a setărilor portalului.
Vizualizare (Preview) Permite vizualizarea paginii în aceeaşi manieră în care o vor vedea şi
internauţii obişnuiţi. Această opţiune ajută în verificarea manierei în care
internauţii sunt afectaţi de setările paginii.
Figura următoare ilustrează opţiunile disponibile în tabloul de comandă al

Managementului paginii.
Figura 4.6 - Managementul paginii
DNN utilizează o orientare bazată pe obiecte în care toate funcţiile sunt

fezabile. Acest lucru permite ca aplicaţia să reutilizeze o serie de componente ceea ce
creează utilizatorului o impresie de mai multe funcţii existente. Aplicaţia utilizează
aceleaşi controale ale utilizatorului în mai multe sectoare, prin care se îndeplinesc
astfel mai multe funcţii.
Containerele
Containerele permit creşterea imaginii portalului fără a aduce modificări skin-
ului. Scopul utilizării containerelor este de a le pune într-un modul cu câteva elemente
grafice, ce vor atrage mai multă atenţie asupra informaţiilor din respectivul modul.
Există posibilitatea şi utilizării unui singur portal pentru întreg portalul sau se
pot utiliza separat pentru fiecare modul.
De exemplu pentru modulul de Legături (Links) se utilizează un container în
pagina principală.
Figura 4.7 - Utilizarea containerelor
Se poate vedea din acest exemplu că utilizarea containerelor oferă multă

flexibilitate în controlul afişării conţinutului utilizatorilor.
Module
Modulele reprezintă cea mai importantă componentă a aplicaţiei. Modulele
permit afişarea informaţiilor utilizatorului. Sunt disponibile sute de module pe baza
cărora se pot extinde funcţionalităţile aplicaţiei. Acesta este un mare avantaj deoarece
este foarte uşor să se modifice aplicaţiile după reguli şi necesităţi proprii.
Modulul - Logare cont

Modulul de logare cont oferă o interfaţă de logare. Modulul poate fi instalat în
următoarele două variante:
 modulul este integrat în pagina de bază, astfel încât utilizatorul nu trebuie
să intre într-o pagina destinată numai logării;
 modulul se găseşte într-o singură pagină cu destinaţie unică acestui modul.
Modulul - Anunţuri
Aşa cum sugerează şi numele, modulul Anunţuri este utilizat pentru afişarea
unei liste de anunţuri. Fiecare anunţ include titlu, text şi un link către "Detalii
suplimentare". Opţional, fiecare anunţ poate fi setat să expire la o anumită dată,
moment după care nu va mai fi afişat.
Modulul - Banner
DNN oferă un bogat set de management al vânzărilor de spaţiu publicitar. Acest
modul este utilizat pentru afişarea bannerelor cu reclame. Acest modul oferă facilităţi
în selectarea numărului bannerelor afişate şi a tipurilor disponibile.
Modulul - Contacte
Modulul contacte oferă informaţii despre un grup de oameni; exemple de
grupuri pot fi echipe de proiect, de sport, de personal sau din interiorul unui
departament. Acest modul oferă posibilitatea de editare a paginii, de către utilizatori
autorizaţi.
Modulul - Discuţii
Acest modul oferă grupuri de mesaje pe baza unui topic. Fiecare mesaj include
elementele Citire/ Mesaj de răspuns, pentru utilizatorii autorizaţi prin care aceştia pot
citi şi adăuga noi mesaje temei propuse. Acesta nu este un modul de forum propriu-zis,
el oferă doar funcţionalităţi asemănătoare dar mult mai puţine.
Modulul - Documente
Modulul Documente oferă o listă a documentelor, incluzând un link prin care se
poate downloada documentul ales. Acest modul include o pagină în care utilizatorii
autorizaţi pot adăuga noi documente şi informaţii despre acestea.
Modulul - Evenimente
Acest modul oferă o listă cu evenimentele viitoare, incluzând ora şi locaţia. Data
de expirare a evenimentelor poate fi setată automat sau manual. Modulul include o
pagină de editare prin care utilizatorii autorizaţi pot adăuga noi evenimente.
Modulul - FAQ
Modulul Frequently Asked Questions conţine întrebările cel mai des puse de
internauţi precum şi răspunsul aferent. Acest modul poate reduce suportul oferit de un
call center sau de un alt serviciu specializat.
Modulul - Feedback
Feedback permite vizitatorilor să trimită mesaje administratorului portalului.
Acest modul permite trimiterea de e-mail-uri în interiorul organizaţiei în funcţie de
conţinutul mesajului feedback.
Modulul - IFrame
Acest modul permite ca într-un browser web gen Internet Explorer să poată fi
afişate pagini cu o structură de frameuri (în pagina web este definit un loc în care este
afişat conţinutul altei pagini).
Modulul - Image
Modulul Image permite afişarea de imagini pe baza unui tag Html Img. Modulul
include şi o pagină de editare ce permite utilizatorilor autorizaţi să aleagă dintr-o
locaţie internă sau externă o imagine ce va fi afişată în portal. Totodată, utilizatorul
poate specifica dimensiunile imaginii precum şi atributele sale.
Modulul - Links
Acest modul oferă o listă de hyperlinkuri. Modulul include o pagină de editare
prin care utilizatorii autorizaţi pot edita şi adăuga noi linkuri. Fiecare link poate fi
personalizat pentru a deschide o nouă fereastră sau de a înregistra de câte ori un link
este apăsat.
Modulul - News Feeds (RSS)

Modulul News Feeds (RSS) permite sindicalizarea ştirilor în formatul Rich Site
Summary (RSS). Acest modul include o pagină de editare prin care utilizatorii autorizaţi
pot specifica locaţia ştirilor şi stilul XSL utilizat pentru transformarea ştirilor.
Modulul - Search Input

Acest modul oferă posibilitatea de a efectua o căutare in informaţiile portalului.
Modulul - Search Results

Oferă posibilitatea de afişare a rezultatelor căutării.
Modulul - Text/HTML
Modulul Text/HTML permite scrierea editarea conţinutului paginilor din
interiorul portalului. Paginile pot fi scrise direct în HTML sau se poate utiliza un
generator de cod HTML pe baza căruia text se introduce asemănător unui editor de
text.
Modulul - User Accounts

Acest modul permite utilizatorilor să se înregistreze şi să îşi organizeze un cont.
Modulul XML/XSL
Permite transformarea în XML/XSL. Acest modul include o pagină de editare
prin care utilizatorii autorizaţi pot specifica locaţia documentului XML sau celui XSL
utilizat în transformare.
4.4. EXO PLATFORM 2.0
Nucleul eXo
In cadrul platformei eXo, toate afacerile logice sunt încapsulate în servicii ce
sunt dependente.
Cuplarea acestor servicii se pierde prin Inversion of Control (IoC).
Din această cauză fiecare produs este compus dintr-un set de servicii.
Containerul eXo este responsabil cu atribuirea serviciilor.
Nucleul mai conţine şi un set minim de servicii ca de exemplu: Cache sau Command.
Figura 4.8 – Niveluri de arhitecturi în portalul Java eXo.
Depozitul de conţinut eXo Java (JCR - JSR 170)

eXo JCR este o variantă optimizată a JSR 170. Suportă toate elementele
specifice inclusiv unele elemente opţionale cum ar fi căutare SQL, evidenţa versiunilor
sau a tranzacţiilor.
Modulul este însoţit de o serie de extensii cum ar fi: REST, WebDAV, DeltaV,
DASL, FTP sau protocoale CIFS. Suportă şi plug-inuri de genul Kofax (utilizat pentru OCR
sau scanare) şi elemente de Office (sunt disponibile plug-inuri de OpenOffice sau
Microsoft Office).
Scopul principal al standardizării Depozitului de conţinut Java este oferirea unei
standardizări care să intermedieze legătura între aplicaţia principală şi datele stocate.
Documentele trebuie să fie stocate într-o bază de date relaţională sau într-o bază de
date de tip XML. Dezavantajul este faptul că clientul nu poate să încarce propriul cod.
Figura 4.9 – Depozitul de conţinut Java (JCR-JSR 170).
Avantaje pentru dezvoltatorii de aplicaţii

 Datele din depozitul de date şi aplicaţia sunt izolate de ceilalţi dezvoltatori de
aplicaţii, astfel încât nu este necesar ca aceştia să cunoască informaţii
particulare despre stocarea sau interfeţe şi se pot concentra pe construirea
aplicaţiilor la nivel de vârf al JCR.
 Depozitele pot fi schimbate cu uşurinţă între diferite aplicaţii fără a se schimba
aplicaţia în sine. Acesta este un avantaj care reiese din configurarea
depozitului.
 Datele stocate de diferite tipuri sau versiuni pot fi combinate într-un singur
model de depozit. Cu toate acestea munca necesară construirii interfeţelor
între depozite şi datele stocate nu dispare.
Avantaje pentru manageri

 Utilizând depozite standardizate pentru managementul conţinutului se reduce
riscul dependinţei de un anume dezvoltator de software sau de interfeţe API.
 Datorită layere-lor JCR API este posibilă legarea subsistemului de stocare unor
noi interfeţe.
Figura 4.10 – Modelul de aplicaţie eXo JCR.
Depozitul de portlet-uri
Depozitul de portlet-uri eXo este implementarea a două specificaţii, şablonului
API şi Web Service pentru Remote Portals (WSRP).
Versiunea curentă este implementată utilizând Portlet-ul API 1.0 şi WSRP 1.0.
Versiunea eXo PC 2.0 suportă de asemenea portlet-ul 2.0 (JSR 286) şi WSRP 2.0
Figura 4.11 – Depozitul de portlet-uri în eXo.
Portal şi WebOS
Portalul eXo este o nouă versiune ce are o interfaţă a utilizatorului
revoluţionară.
Datorită utilizării AJAX s-a obţinut un portal puternic, ce poate reproduce un
sistem de operare prin intermediul unui browser.
Imaginea afişată utilizatorului depinde de configurarea portalului,i de meniul de
navigare, precum şi de rolurile şi grupurile din care face parte utilizatorul.
Figura 4.12 – eXo ca sistem de operare Web (WebOS).
Modalitatea uzuală de redare a unei pagini în portal este cea statică, unde este
necesar un şablon sau un model. Acest lucru face ca dezvoltatorii să fie dependenţi de
şabloanele şi modelele existente.
eXo are o modalitate dinamică prin care creează o structură arborescentă a
containerelor ce conţin şabloane. Fiecare container este responsabil cu redarea
copiilor.
În plus prin manipularea structurii arborescente cu editorul WYSIWYG se pot
crea noi containere, definii modul în care se redau copii şi se pot adăuga noi portlet-
uri.
Figura 4.13 – Portlet generic in eXo, conform JSR 168.
Majoritatea portalurilor utilizează un mecanism static prin care se poate

"trage" informaţia dintr-o locaţie în alta.
Portalul eXo permite "tragerea" containerelor şi a şabloanelor în structura

arborescentă a componentelor. Această particularitate a portalului este unică.
Managementul conţinutului
Produsul eXo ECM oferă avantajele unui sistem de management de conţinut
fiind construit cu ajutorul eXo JCR şi eXo Portal într-un mediu integrat - Web Content
Management (WCM).
Sunt suportate elemente de managementul documentelor, managementul
înregistrărilor, evidenţa versiunilor, extrageri de metadate sau căutare avansată.
Elemente de colaborare
eXo Collaboration oferă un set de aplicaţii de colaborare cum ar fi calendare,
webmail, forum, listă de contacte. Ideea utilizării acestor elemente este de a valorifica
avantajele WebOS de interfaţă eficientă cu utilizatorul precum şi de stocare utilizând
eXo JCR.
4.5. OPENPORTAL CMF 2.8
OpenPortal oferă un cadru de dezvoltare ce constă din reunirea unor aplicaţii

web PHP mici şi disparate într-un sistem comun. Proiectul doreşte să ofere un sistem
front-end cu o autentificare a utilizatorilor standardizată, reunirea tuturor claselor,
abstractizarea datelor şi simplificarea modelului de instalare a aplicaţiei şi modulelor.
4.6. COMPARAŢIA PORTALURILOR PREZENTATE
Comparația 1 a fost realizată pentru cinci portaluri: DotNetNuke 4.8, eXo

Platform 2.0, Liferay Portal CMS 4.3, Nuxeo CPS 5.0, OpenPortal CMF 2.8 din
următoarele puncte de vedere:
 Cerințe de sistem;
 Securitate;
 Performanță;
 Management;
 Ușurința utilizării;
 Interoperabilitate;
 Flexibilitate;
 Construirea aplicațiilor;
 Comerț.
1
WWW.CMSMATRIX.ORG
DotNetNuke eXo Platform Liferay Portal / OpenPortal
Portal Nuxeo CPS 5.0
4.8 2.0 CMS 4.3 CMF 2.8
Ultima variantă 11/29/2007 10/26/2007 7/27/2007 1/26/2006 12/19/2004
Liferay Portal / OpenPortal
Cerinţe de sistem DotNetNuke eXo Platform Nuxeo CPS
CMS CMF
Compatibilitate
testată cu
Borland ES 6.5,
JBoss 4.0.2,
JOnAS 4.4.3,
Aplicaţia Server JRun 4 Updater
Tomcat, JOnAS
Aplicaţia server sau 3, OracleAS
IIS or Oricare J2EE Zope Apache
aplicaţia necesară 10.1.2, Orion
server
pentru CMS. 2.0.6, Pramati
4.1, RexIP 2.5,
Sun JSAS 8.01,
WebLogic 8.1
SP4,
WebSphere 5.1
Cost aproximativ
Costul aproximativ de
Gratuit Gratuit Gratuit 0
licenţiere al CMS.
DB2, Firebird,
MSSQL
Baza de date utilizată Oricare Hypersonic,
2005/2000,
pentru stocarea (depinde doar InterBase,
MSSQL Zope MySQL
conţinutului şi a de driverele JDataStore,
Express
setărilor. JDBC) MySQL, Oracle,
2005, MSDE
PSQL
MIT Open
Tipul de licenţă şi de BSD
GNU GPL Source fără GNU GPL GNU GPL
distribuire (Modificată)
resticţii
Sistemul de operare Windows, Mac
cu care CMS-ul este Windows Oricare OS X, BSD, Oricare Oricare
compatibil Linux, Solaris
Limbajul de
PHP 4.2.2
programare în care ASP.NET 2.0,
Java Java 1.4. + Python sau
este scris CMS-ul sau VB.NET, C#
superior
în care poate fi extins.
Este necesar acces
administrator pentru Nu Nu Da Da Nu
instalarea aplicaţiei?
Este necesară logarea
pe server pentru
Nu Da Da Da Nu
instalare sau este
suficient FTP?

4.8 2.0 CMS 4.3 CMF 2.8
Securitate
Auditul operaţiilor
(Sistemul păstrează
cine a făcut Limitat Da Da Da Da
modificări, update-uri
sau ştergeri?)
Aprobarea
conţinutului
(Sistemul oferă
Limitat Da Da Da Limitat
posibilitatea de
aprobarea a
conţinutului?)
Sistemul trimite o
cheie de activare
Adăugare
utilizatorilor pentru a Da Nu Da
gratuită
se asigura ca adresa
de email este valida?
Sistemul permite
citirea şi scrierea de
privilegii pe pagină Da Da Da Da Da
sau conţinut separat
de celelalte funcţii?
Sistemul suportă
Adăugare
autentificare prin Nu Da Da Nu
gratuită
Kerberos?
Sistemul permite
autentificare bazată Nu Da Da Da Nu
pe LDAP?
Sistemul reţine date
despre cine a fost
logat şi când?
Sistemul permite
reţinerea unor Da Nu Da Nu Da
informaţii cum ar fi:
tipul browserului,
adresa IP, accesări
nereuşite?
Sistemul suportă Cost
Nu Nu Da Nu
autentificare prin NIS? suplimentar
Sistemul suportă
autentificare prin Da Nu Da Da Nu
NTLM?
Sistemul permite un
administrator ce
poate adăuga
suplimentar scheme Da Da Da Da Nu
de autentificare sau
un mecanism de
autentificare LDAP?
4.8 2.0 CMS 4.3 CMF 2.8
Sistemul oferă un
mecanism de alertare
a administratorilor
(prin email, instant Da Nu Nu Da Da
messanger, telefon
mobil) când sunt
detectate probleme?
Sistemul permite o
secţiune privată
pentru managementul
conţinutului unde se Da Nu Da Da Nu
pot face teste fără să
afecteze restul site-
ului?
Session Management
Sistemul oferă
facilităţi
administratorului
Da Nu Da Nu Limitat
pentru a-i spune cine
este logat, ce face şi
eventual să-l
delogheze?
Sistemul suportă
autentificare prin Nu Nu Nu Nu Nu
SMB?
Poate sistemul să fie
utilizat cu un certificat Da Da Da Da Da
SSL pe web server?
Poate fi setat sistemul
să schimbe modul SSL
pentru anumite pagini Da Da Da Nu Nu
şi să utilizeze HTML
pentru alte pagini?
Suport
Există un certificat
profesional sau
Da Da Da Nu Nu
program de instruire
pentru acest CMS?
Sistemul oferă modele
de cod pentru ca
Da Nu Da Da
dezvoltatorii sa scrie
plugin-uri?
Există cărţi sau alte
documentaţii
Da Da Nu Da Nu
disponibile pentru
acest CMS?

4.8 2.0 CMS 4.3 CMF 2.8
Există o organizaţie
care dezvoltă gratuit, Da Da Da Da Nu
on-line produsul?
Există un ajutor (Help)
Da Da Limitat Da Nu
on-line?
Sistemul poate fi
extins printr-o
interfaţă de Da Da Da Da Nu
programare a
aplicaţiilor (API)?
Există un program de
găzduire personalizat
sau certificat ca Da Nu Limitat Da Nu
partener al
programului?
Sunt servicii
comerciale disponibile
organizaţiilor care
doresc să Da Da Da Da Da
personalizeze şi să
administreze servicii
ale CMS-ului?
Există un forum
Da Da Da Da Nu
public?
Există o listă publică
de email a acestui Da Da Da Da Nu
sistem?
Sistemul are un
serviciu prin care
Da Nu Limitat Da
poate fi testat codul
pentru a verifica
Există dezvoltatori
care produc plug-inuri Da Da Da Da Nu
pentru sistem?
Există o conferinţă
anuală pentru acest
sistem unde Da Da Da Da Nu
utilizatorii se pot
întâlni?
Uşurinţa utilizării
Produsul permite
utilizatorilor tehnica Da Da Da Da Nu
drag and drop?
4.8 2.0 CMS 4.3 CMF 2.8
Este sistemul capabil
să redimensioneze Adăugare
Nu Da Nu
imaginile încărcate de gratuită
utilizatori?
Există un limbaj macro
ce permite
managerilor de
Da Da Da Da Nu
conţinut să obţină o
funcţionalitate
sporită?
Are sistemul
posibilitatea de a
încărca/importa mai
Da Da Da Da
multe fişiere dintr-o
dată pentru a scurt
din timp?
Sistemul permite
utilizatorilor să îşi
creeze setări pentru
Da Nu Limitat Nu
diferite tipuri de
obiecte şi să le
salveze?
Există un limbaj ce
ajută în
Da Da Da Da Da
funcţionalitate cum ar
fi PHP, JSP, sau ASP?
Sistemul oferă
utilizatorului opţiuni
în crearea ariilor de Nu Nu
conţinut, a stilurilor în
timpul instalării?
Sistemul are un
Adăugare
corector gramatical Nu Da Nu Nu
gratuită
încorporat?
Sistemul are un
generator (wizard)
pentru crearea Da Nu Limitat Da
stilurilor, temelor,
modelelor?.
Pot utilizatorii să
subscrie unor secţiuni
diferite pentru a primi
Da Nu Da Da Nu
notificări cu noutăţi
sau încărcări de
conţinut?

4.8 2.0 CMS 4.3 CMF 2.8
Sistemul permite
utilizatorilor operaţii
de întoarcere (undo) Limitat Da Nu Da Nu
în cadrul în care fac o
greşeală?
Există un editor prin
care se pot publica
texte în mod avansat Da Da Da Da Da
în afară de HTML, CSS,
XML sau XLS?
Sistemul permite
utilizatorilor să
încarce fişiere zip ce Da Nu Da Da
apoi să fie publicare
pe site?
Performanţă
Sistemul oferă
posibilitatea replicării
bazei de date pentru Nu Nu Limitat Da Nu
o mai bună
scalabilitate?.
Sistemul permite
încărcare echilibrată
Da Da Da Da Nu
utilizând mai multe
servere?
Sistemul are un
mecanism pentru
captarea conținutului
paginii, deci în cazul
Da Da Da Da Da
unei noi cereri să se
sară peste toate
etapele creării
paginii?
Sistemul are
posibilitatea
exportului Da Nu Da Nu Nu
conţinutului într-un
format static HTML?
Management
Sistemul CMS are
bannere sau
Da Nu Da Nu Nu
management de
sistem?
Există un loc de
depozitare în care se
pot încărca imagini
Da Nu Da Da Da
sau alte fişiere ce pot
fi reutilizate apoi în
site?
4.8 2.0 CMS 4.3 CMF 2.8
Există noţiunea de
clipboard, în care pot
fi păstrate elemente
Limitat Nu Nu Da Nu
pentru copiere sau
mutare dintr-o
secţiune în alta?
Sistemul permite ca
conţinutul să fie
adăugat automat sau Da Da Da Da Da
înlocuit dintr-un site
în funcţie de dată?
Conţinutul poate fi
creat pe un server şi Cost
Da Nu Da Nu
apoi copiat pe un suplimentar
altul?
Conţinutul este direct
editat în pagina unde Da Nu Da Da Da
va fi plasat?
Poate fi sistemul
complet organizat
Da Da Da Da Da
prin intermediul unui
browser web?
Sistemul suportă sub-
site-uri cu conţinut
propriu, navigaţie Da Da Da Da Da
proprie şi ierarhie a
conţinutului?
Sistemul are un
mecanism de
transport a stilurilor,
Da Da Da Da Da
modelelor între site-
uri pentru a putea fi
reutilizate?
Există un sistem de
"trash" prin care
utilizatorii pot Da Nu Nu Da Da
recupera din
informaţiile şterse?
Sistemul construieşte
statistici cum ar fi:
numărul de vizitatori Da Nu Limitat Nu Da
pe pagină, numărul de
vizitatori pe timp etc.?
Există o interfață prin
care pot fi adăugate
Da Da Da Da Da
stiluri şi modele în
sistem?

4.8 2.0 CMS 4.3 CMF 2.8
Interoperabilitate
Sistemul suportă
sindicalizare Da Da Da Da Nu
RSS/XML?
Sistemul permite
utilizatorilor să
Da Da Limitat Da Da
încarce fişiere prin
FTP?
Dacă sistemul permite
implementarea de
calendare, se pot Da Da
importa sau exporta
după standardul iCal?
Sistemul suportă
codare a caracterelor
UTF-8 pentru mai
multe limbi, fără ca Da Da Da Da Nu
conţinutul să fie
disponibil în mai
multe limbi?
Sistemul permite
utilizatorilor să Cost
Da Da Da Nu
încarce conţinut sau suplimentar
fişiere prin WebDAV?
Flexibilitate
Sistemul poate rula
sub CGI pentru
Nu Nu Nu Da Nu
dezvoltare sau
utilizare?
Sistemul permite ca
conținutul să fie
Da Da Da Da Da
copiat spre
reutilizare?
Sistemul este
internaţionalizat,
astfel încât prin
instalarea într-o altă Da Da Da Da Nu
ţară să ia preferinţele
locale cu privire la
dată şi oră?
Sistemul suportă
adăugarea
suplimentară de
Da Da Da Da Da
proprietăţi de
metadate asupra
tuturor obiectelor?
4.8 2.0 CMS 4.3 CMF 2.8
Sistemul suportă
versiuni pentru mai
Adăugare
multe limbi fără a Da Da Da Da
gratuită
republica conţinutul
obiectului?
să găzduiască mai Cost
Da Da Da Da
multe site-uri pe suplimentar
aceeaşi platformă?
să rescrie URL-ul
pentru a oferi un URL Da Nu Da Da Nu
mai scurt sau mai
"prietenos"?
Construirea
aplicaţiilor
Sistemul are blog? Da Nu Da Da Nu
Sistemul are o
Adăugare
aplicaţie de chat on- Da Nu Da Da
gratuită
line?
Sistemul are o
aplicaţie prin care se
Adăugare
pot crea arbitrar Da Nu Da Nu
gratuită
intrări de date în
aplicaţii?
Sistemul are o
aplicaţie prin care se Cost
Da Nu Nu Nu
pot crea liste din suplimentar
bazele de date?
Sistemul are un Adăugare
Da Da Da Da
forum? gratuită
Sistemul are o
aplicaţie pentru
organizarea offline a Da Da Da Da Limitat
documentelor stocare
şi a versiunilor?
Sistemul are o
aplicaţie pentru
trasarea Adăugare
Da Da Da Da
evenimentelor şi gratuită
afişarea lor într-un
calendar?
Sistemul are o
modalitate de creare
de evenimente şi de a
permite utilizatorilor Da Nu Limitat
să de înregistreze
pentru aceste
evenimente?

4.8 2.0 CMS 4.3 CMF 2.8
Sistemul are o
aplicaţie de
Adăugare
organizare a Da Nu Limitat Da
gratuită
întrebărilor frecvente
(FAQ)?
Sistemul are o
aplicaţie pentru
distribuirea fişierelor Adăugare
Da Da Da Da
pe baza privilegiilor gratuită
de
vizualizare/download?
Sistemul are o
aplicaţie ce permite
utilizatorilor să Adăugare Cost
Da Nu Nu
genereze grafice pe gratuită suplimentar
baza datelor din baza
de date?
Sistemul are email şi Adăugare Adăugare
Da Da Da
organizare de grup? gratuită gratuită
Sistemul are o
aplicaţie pentru Da Nu Da Nu Nu
"guest book"?
Sistemul are o
Cost Cost Cost Adăugare
aplicaţie pentru Nu
suplimentar suplimentar suplimentar gratuită
raportarea erorilor?
Sistemul are un
mecanism de proxy
Adăugare Cost
sau de mirror HTML Nu Da Da
gratuită suplimentar
pentru alte servere
web?
Sistemul are o
aplicaţie de Cost Adăugare
Da Nu Da
organizare a suplimentar gratuită
legăturilor?
Sistemul are o
aplicaţie pentru Adăugare Adăugare
Da Da Da
creare personalizată a gratuită gratuită
contactelor?
Sistemul le permite
utilizatorilor să se
Adăugare Adăugare
adauge/şteargă pe o Da Nu Da
gratuită gratuită
listă pentru a primi
ştiri prin email?
Sistemul are o
aplicaţie pentru Adăugare
Da Nu Da Da
afişarea depozitelor gratuită
de imagini?
4.8 2.0 CMS 4.3 CMF 2.8
Sistemul are o
aplicaţie pentru Cost Cost Adăugare
Nu Nu
organizarea cererilor suplimentar suplimentar gratuită
de proiect?
Sistemul are un motor
de căutare integrat ce
poate indexa
Da Da Da Da Da
conţinutul şi permite
utilizatorilor să caute
anumite informaţii?
Sistemul poate genera
o structură
Adăugare
arborescentă în Da Da Da Da
gratuită
legătură cu paginile
conţinute (Site Map)?
Sistemul are o
aplicaţie pentru
primirea şi afişarea
Da Da Da Da Nu
conţinutului
RDF/RSS/XML
sindicalizat?
Sistemul are o
Cost Adăugare Adăugare
aplicaţie pentru Nu Da
suplimentar gratuită gratuită
realizarea de teste?
Comerţ
Sistemul are o
aplicaţie care să
Da Nu Nu Nu Da
traseze site-urile
partener?
Sistemul permite
proprietarului site-
ului să adauge noi
elemente de plată Da Nu Limitat Nu
(PayPal, PayFlowPro,
2checkout, iTransact,
Authorize.net, etc)?
Sistemul permite
proprietarului site- Cost
Nu Limitat Nu
ului să adauge noi suplimentar
taxe?
Sistemul are un
mecanism prin care
utilizatorii îşi fac o Cost
Da Nu Da Nu
listă de cumpărături şi suplimentar
plătesc o singură
dată?
Sistemul permite
utilizatorilor să îşi facă Nu Nu Nu Nu
liste cu preferinţe?
BIBLIOGRAFIE
1. ABBYY & DocWorks: AthletiCo’s Paper-Heavy Billing Department Gets into Shape,
www.kmworld.com;
2. AIIM International, www.aiim.org: Distributed Capture: Moving Capture Closer to
Document Creation;
3. AIIM International: What is ECM? http://www.aiim.org/about-ecm.asp
4. Asipenko S., Zukerman, Y.: CMS Review: OpenCms 6.0:
http://www.cmswire.com/cms/cms-reviews/;
5. Best Practices in Enterprise Content Management, www.kmworld.com;
6. Best Practices in Enterprise Search: www.kmworld.com;
7. Boiko, B.: Content Management Bible, www.metatorial.com;
8. Bracken, J.: Dicovering Hidden Information Treasures in ECM,
www.kmworld.com;
9. Business Process Management and Workflow, AIIM International, www.aiim.org;
10. Byrne, T.: A Lexicon for Document Analysis, http://www.cmswatch.com/ECM/;
11. Byrne, T.: A Scenario-based Approach to Evaluating CMS Vendors,
http://www.cmswatch.com;
12. Byrne, T.: Do you need an ECMS, WCMS, or a Portal?
http://www.cmswatch.com/CMS/
13. Capture - Setting the Scene for ECM, www.aiim.org.uk;
14. Cellucci, B.: Balancing Control and Distributed Capabilities For Web Content and
Site Management, www.kmworld.com;
15. Chen, H. and Dumais, S. (2000). Bringing Order to the Web: Automatically
Categorizing Search Results. In: T. TURNER, ed. Proceedings of the SIGCHI
conference on Human factors in computing systems, Netherlands 01-06 April
2000. USA: ACM Press, pp 145-152;
16. Clapp, M.: Collaboration First, Then Knowledge Management,
http://www.cmswatch.com/Portal/;
17. CMS Watch: CMS Report, Sample Edition, 2007, http://www.cmswatch.com;
18. CMS Watch: Enterprise Search Report, www.cmswatch.com;
19. CMS Watch: Information Management Software Product Landscape,
http://www.cmswatch.com;
20. CMS Watch: Web Content Management Vendor List,
http://www.cmswatch.com/Reports/Vendors/;
21. CMS Wire: Tridion, Fatwire and Interwoven Lead External Web Content
Management, http://www.cmswire.com/cms/web-cms/;
22. Cochrane, R. (1997). Unleashing the intranet. BT Technology Journal, 15 (2), pp
107-113. Available from:
http://www.springerlink.com/content/m681547155j581p1/fulltext.pdf;
23. Content Management Problems and Open Source Solutions,
http://contenthere.blogspot.com/;
24. Content Manager. (2004). ECM Market to reach $9B in Software and Services,
http://www.contentmanager.net/magazine/article_445_ecm_market_software_
services.html;
25. Daydream’s Digital Asset Management (DAM) Blog: What Is Digital Asset
Management?
26. Dell (2005). Standardization, consolidation, scaling, interoperability, data
management, portfolio management. USA: Dell,
http://www.dell.com/downloads/global/solutions/ dell_it_we_are_scalable.pdf;
27. DM Review. (2003). The problem of unstructured date,
http://www.dmreview.com/article_sub.cfm?articleId=6287;
28. Document and Content Capture, AIIM International, www.aiim.org;
29. Document and Content Output and Presentation, AIIM International,
www.aiim.org;
30. Document and Web Content Management, AIIM International, www.aiim.org;
31. Dunwoodie, B. (2004). Global ECM Market Still Likely to Consolidate. CMS Wire.
http://www.cmswire.com/cms/enterprise-cms/global-ecm-market-still-likely-to-
consolidate-000301.php;
32. ECM at Work, www.aiim.org.uk;
33. ECM West. (2006). Matthew Glotzbach Google Enterprise.
http://ecmwest.com/ecmwest/v42/conference/ speaker_bio.cvn?profileID=151;
34. Eddleman, T.: Managing Mission Critical Content, http://www.kmworld.com/
35. Emery, P. (2003). Document and Records Management: Understanding The
Differences and Embracing Integration. USA: Zlyab Technologies,
http://www.lightindustries.com/pdf/Document%20Management%20vs%20Recor
ds%20Management.pdf;
36. Emery, P.: Why Records Management?, http://cmswatch.com/ECM/;
37. Enterprise Content Management THE AIIM Guide to to ECM Purchasing, AIIM
International, www.aiim.org;
38. Enterprise Open Source Journal, http://www.eosj.com;
39. Flynn, D. (1998) Information System Requirements: Determination and Analysis.
Berkshire, England: McGraw-Hill;
40. Forrester Consulting: Open Source Software’s Expanding Role in the Enterprise.
Companies Adopt Open Source as Standard, 2007;
41. Forrester. (2005). ECM Growth Outpaces the Overall Software Market,
http://www.forrester.com/Research/Document/Excerpt/ 0,7211,36935,00.html;
42. Forrester. (2006). Information Management 101,
http://www.forrester.com/Research/Document/Excerpt/ 0,7211,38472,00.html;
43. FRASER, S.: Real-World ASP.NET—Building a Content Management System,
Apress, 2002;
44. Gartner Research: Magic Quadrant for Enterprise Content Management, 2006;
45. Gartner Research: Magic Quadrant for Enterprise Content Management, 2007;
46. Gartner: MarketScope for Records Management, 2005,
http://mediaproducts.gartner.com/reprints/emc/vol2/article1/article1.html#top;
47. Gingrande,A.: Processing Unstructured Documents: Challenges and Solutions,
AIIM International, www.aiim.org;
48. Groff, T.; Jones, T.: FileNet. A Consultant’s
49. Guide to Enterprise Content Management, Elsevier Butterworth–Heinemann,

2004;
50. Headway Technology Group: Document & Data Capture;
51. Hertzberg, R.: Enterprise Content Management (ECM): An Overview,
www.kmworld.com;
52. Hodgson, C.: Planning for an Enterprise Content Management System, AIIM
International, www.aiim.org;
53. http://www.cmswatch.com/CMS/: Introduction to Web Content Management;
54. Intranet Roadmap Wallchart,
http://www.steptwo.com.au/products/roadmap/index.html;
55. Kampffmeyer, U.: Enterprise Content Management, http://dnb.ddb.de;
56. Kathuria, G.: Web Content Management with Documentum,Packt Publishing,
2006;
57. Kemp, J.: A Critical Analysis into the Use of Enterprise Content Management
Systems in the IT Industry;
58. Kerner, S, M. (2003). Choose between a commercial, open source, or customised
CMS, http://builder.com.com/5100-6374-5054863.html;
59. LaMonica, M. (2003). The Evolving ECM Market. ZD News,
http://news.zdnet.com/2100-3513_22-5094630.html;
60. Lamont, J.: DAM: agile and effective, http://www.kmworld.com/;
61. Lamont, J.: Managing Web content: ECM or pure-play WCM?,
http://www.kmworld.com/Articles/Editorial/Feature/Managing-Web-content-
ECM-or-pure-play-WCM--18049.aspx;
62. Line 56. (2006). The Evolving ECM Market
http://www.line56.com/articles/default.asp?ArticleID=5579;
63. Locke, B., How Do You Protect Your Digital Assets: What’s what in Digital Asset
Management solutions, http://enterpriseinnovator.com/index.php?sectionID=5;
64. MacMillan, A.: Enterprise Content Management—Thinking Beyond the
Repository, www.kmworld.com;
65. Magan, A.: Intro to Digital Asset Management: Just what is a DAM?,
http://www.cmswatch.com/ECM/;
66. Mancini, J.: Payback Time – The Practical Applications of ECM Technologies,
www.aiim.org.uk;
67. Mancini, J.:State of the ECM Industry Moving from Why? To How?: The Maturing
of ECM Users, www.aiim.org;
68. Mason, C.: How Do You Manage the Unmanageable?, www.kmworld.com;
69. Mauthe, A.U.; Thomas, P: Professional Content Management Systems,
www.wiley.com, 2004;
70. McConnell, J.: Global Intranet Strategies Survey Results,
http://netjmc.typepad.com/globally_local/;
71. McConnell, J.: Global Intranets - Different Challenges, Different Paths,
72. McConnell, J.: Global intranets - more on paths, strategies and global integration,
73. McConnell, J.: How Intranet & Portal Landscapes Evolve,
74. McConnell, J.: Increasing findability in large, complex intranets, Online
Information 2005;
75. McConnell, J.: Making a Business Case for CMS, NetStrategyJMC, KMWorld &
Intranets 2005;
76. McConnell, J.: Making intranets meaningful, www.iabc.com/cw;
77. McConnell, J.:Intranet Strategies Today & Tomorrow, www.netjmc.com;
78. Merrem, T.L.: Time is Money. Data Capture Software Saves Government Agency
Days, http://www.kmworld.com/;
79. Miller, E.: Beyond Hammers and Nails, www.kmworld.com;
80. Moore, A.: Capture Moves to the Head of the Class, http://www.kmworld.com/;
81. Moore, A.: The Motor or the Fan?: ECM Moves From Pure-Play to Every Day,
www.kmworld.com;
82. Nielsen, J. (2004). Information intelligence: content classification and enterprise
taxonomy practice, Boston: Delphi Group,
http://www.delphigroup.com/research/whitepapers/20040601-taxonomy-
WP.pdf;
83. OpenConcept: Content Management System Report. On Alternatives to Back-
End;
84. Optaros Research Report: The Growth of Open Source Software in Organizations,
2005;
85. Optaros WhitePaper: Assemble Enterprise 2.0 with Open Source;
86. Optaros Whitepaper: Content Management Problems and Open Source
Solutions;
87. Optaros WhitePaper: Understanding Free and Open Source Licenses, Version 2.1,
2006;
88. Optaros: Open Source Catalogue 2007, Realize the Benefits of Open Source,
2007;
89. Optaros: Unleashing the Power of Open Source in Document Management;
90. Pelz-Sharpe, A.: Enterprise Content Management Marketplace: Opportunities
and Risks, http://www.cmswatch.com/ECM/;
91. Pery,A.: Keep Information Moving With Intelligent Capture and Exchange,
http://www.kmworld.com/;
92. Porter-Roth, B.:RFP Guidelines for an Enterprise Content Management System,
AIIM International, www.aiim.org;
93. Price. (2006). Getting Unified: The Evolution of Enterprise Content Management,
http://www.dmreview.com/editorial/newsletter_article.cfm?articleId= 1054124;
94. Products, www.steptwo.com.au;
95. Robertson J.: 11 usability principles for CMS;
96. Robertson, J.: So, what is a content management;
97. Robertson, J.: Using scenarios to select a CMS, www.steptwo.com.au;
98. Skyrme, D.: Is Content King?, http://www.skyrme.com/updates/u57.htm;
99. Step Two Designs: Content Management Requirements Toolkit,
www.steptwo.com.au;
100. Step Two Designs: Is it document management or content management?,
www.steptwo.com.au;
101. Step Two Designs: Plan before CMS implementation, www.steptwo.com.au;
102. Step Two Designs: Separate design and the CMS, www.steptwo.com.au;
103. Step Two Designs: What are the goals of a content management system,
www.steptwo.com.au;
104. Stephenson, J.: Intelligent Imaging, Scanning Only What You Need, Only When
You Need It http://www.kmworld.com/
105. Thrasher, D.: Managing in Place Isn’t Managing, www.kmworld.com;
106. Velikin, P.: Automating Your Technical Publishing Processes, www.kmworld.com;
107. Waldron Martin IFC: European Study on Electronic Archiving;
108. Walker, P.: Best Practices in ECM Document Consolidation and Migration,
www.kmworld.com;
109. Watson, J. and Patel, J. and Chambers, B. (2006). ECM in 2007: What's Top-of-
Mind for the Coming Year.
http://www.edocmagazine.com/article_new.asp?ID=32227;
110. Wikipedia.org: Collaborative software;
111. Wikipedia.org: Content management system;
112. Wikipedia.org: Content management;
113. Wikipedia.org: Digital asset management;
114. Wikipedia.org: Digital asset;
115. Wikipedia.org: Document management system;
116. Wikipedia.org: Electronic document;
117. Wikipedia.org: Enterprise content management;
118. Wikipedia.org: Extranet;
119. Wikipedia.org: Information repository;
120. Wikipedia.org: List of content management frameworks;
121. Wikipedia.org: List of content management systems;
122. Wikipedia.org: Metadata;
123. Wikipedia.org: Separation of presentation and content;
124. Wikipedia.org: Template engine (web);
125. Wikipedia.org: Template processor;
126. Wikipedia.org: Template system (computing);
127. Wikipedia.org: Web content management system;
128. Wikipedia.org: Web content;
129. Wikipedia.org: Web template system;
130. Wikipedia.org: Workgroup Support Systems;
131. www.asg.com : Electronic Document Archiving with ASG-Cypress, Whitepaper;
132. www.asg.com: Managing and Delivering Knowledge from Disparate Applications
and Platforms;
CUPRINS
CAPITOLUL I
INTRODUCERE ÎN MANAGEMENTUL CONȚINUTULUI ................................................. 1
1.1. SISTEME DE MANAGEMENT AL CONȚINUTULUI (CMS) .....................................8
1.2. METADATE ........................................................................................................16
1.3. TAXONOMIA CONȚINUTULUI ŞI A UNUI PORTAL .............................................30
1.4. ŞABLOANE .........................................................................................................35
1.5. PUBLICAŢII.........................................................................................................43
1.6. INDEXAREA ŞI CĂUTAREA CONŢINUTULUI .......................................................53
1.7. DEPOZITUL BAZAT PE XML ................................................................................65
1.8. CANALE DE CONȚINUT ......................................................................................73
CAPITOLUL II
SOFTWARE DE COLABORARE ȘI DE MANAGEMENT AL DOCUMENTELOR ................. 81
2.1. CAPTURĂ DE DATE ȘI DE DOCUMENTE ............................................................87
2.2. DOCUMENT MANAGEMENT SYSTEM .............................................................102
2.3. DIGITAL ASSET MANAGEMENT .......................................................................119
2.4. MANAGEMENTUL ÎNREGISTRĂRILOR .............................................................125
2.5. WEB CONTENT MANAGEMENT ......................................................................134
CAPITOLUL III
ENTERPRISE CONTENT MANAGEMENT.................................................................. 150
3.1. ENTERPRISE SERVICE BUS (ESB) ......................................................................167
3.2. PORTALURI ......................................................................................................177
CAPITOLUL IV
APLICAȚII OPEN SOURCE CMS/PORTAL ................................................................. 199
4.1. LIFERAY PORTAL / CMS 4.3 .............................................................................209
4.2. NUXEO CPS 5.0 ................................................................................................210
4.3. DOTNETNUKE - PORTAL OPEN SOURCE..........................................................211
4.4. EXO PLATFORM 2.0 .........................................................................................219
4.5. OPENPORTAL CMF 2.8 ....................................................................................223
4.6. COMPARAȚIA PORTALURILOR PREZENTATE ..................................................223

Sisteme Informatice Pentru Managementul Continutului PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sisteme Informatice Pentru Managementul Continutului PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Sisteme informatice pentru managementul conţinutului 1

Sistemele de management al conţinutului au evoluat într-o piaţă mare şi

Pagini Web şi componente de conţinut

În practică se observă că cele mai multe sisteme de CM nu sunt utilizate în

Figura 1.1 – Pagini web şi componente de conţinut.

Un document este alcătuit din component de conţinut. Sistemele de gestiune a

In mod normal, un CMS constă din cel puţin trei elemente:

Aplicaţia de gestiune a conţinutului

Gestionează întreg ciclul de viaţă al componentelor de conţinut, de la crearea

Aprobarea: înaintea finalizării oricărui stagiu din ciclul de viaţă şi de începerea

Figura 1.2 – Arhitectură generică pentru Aplicaţie de Management a Conţinutului

Design-ul: este locul în care sunt identificate şi descrise toate componentele de

Aplicaţia de gestiune a metaconţinutului

Aplicaţia de livrare a conţinutului

Scopul acestei aplicaţii este de a afişa componentele de conţinut din depozit

1.1. SISTEME DE MANAGEMENT AL CONŢINUTULUI (CMS)

Noţiunea de CMS este greu de definit, multe produse pretinzând a fi soluţii

Un CMS poate avea următoarele funcţii:

Un sistem de management al conţinutului oferă următoarele facilităţi cheie:

După Stephen R.G. Fraser 1, un system de gestiune al conţinutului ar trebui să

Conform Documentum2, un CMS:

Tipuri de sisteme CM:

 CMS bazate pe module – majoritatea sarcinilor din ciclul de viaţă al unui

Sisteme open source de gestiune a conţinutului

Spre deosebire de soluţiile comerciale, CMS-urile open source nu încearcă să

Baze de date Ultima

Impactul Open Source în evoluţia CMS1

 Componentele modulare ce apar în rezultatul proiectelor comune vor

Studiu de caz: alegerea unui CMS open source:

Următoarele hotărâri ar putea ajuta la alegerea unui CMS:

După determinarea sistemului de bază şi a caracteristicilor addon-ului, este

Primele 3 CMS-uri open source din 2007 au fost:

“Meta” în sine (Oxford English Dictionary) semnifică o coloană care marchează

 standarde - metadatele reprezintă un set de elemente standard pe care

Conform1 metadatele reprezintă date care descriu structura şi funcţionarea

Ciclul de viaţă al metadatelor

Chiar începând din fazele de planificare şi design al unei aplicaţii trebuie să se

În plus, există o întrebare legată de formatul metadatelor: stocarea acestora

Aplicaţii care utilizează metadate

Bazele de date relaţionale utilizează metadate sub forma cataloagelor (tabele

Metadata în aplicaţiile de Content Management

Dacă “managementul conţinutului” ar fi o artă de a denumi informaţiile,

Figura 1.3 – Utilizarea Metadatelor în sisteme de gestiune a conţinutului.

În continuare vor fi prezentate câteva tipuri de metadate care ar putea fi

Conform1 metadatele pot fi clasificate astfel:

In următoarea secţiune vor fi prezentate pe rând aceste tipuri de metadate,

Metadatele de structură furnizează informaţii de tipul: “poţi numi acest obiect

marcat deoarece se pot aplica metadatele de formatare la nivelul

Caracteristicile comune ale tuturor acestor diviziuni structurale sunt că fiecare

Componenta <MEDIA> (in acest caz, o imagine) este plasata înăuntrul

<IMG SRC="img.jpg" WIDTH="100" HEIGHT="200" />

<SECTION LEVEL="1"> O sectiune </SECTION>

Se poate transforma acest exemplu în metadată de format pentru a prezenta o

<H1> O sectiune </H1>

Destul de frecvent , metadatele de format se află sub controlul Content

Deşi se trişează oarecum aici, prin punerea unor elemente de formatare în

Metadatele de acces pot fi interpretate astfel: „Iată cum această structură se

Pentru a specifica asocierile se adaugă un tag <LINK>. Acest tag include un

Pentru mai multe informatii, <A HREF="C123.htm">click aici</A>.

La imprimare, link-ul poate arăta în acest fel după transmitere:

Pentru mai multe informatii, vedeti "Links" in 5.

Metadatele de acces se pot găsi la fel de des în afara structurii conţinutului ca şi

Noţiunea metadatelor de tip management este foarte apropiată de noţiunea