Chestiuni documentaristice (inclusiv bibliologice)

Dan Matei (care își dă și el cu părerea).

Culturalia: Un portal românesc (?) [2]

leave a comment »

În postarea anterioară  — unde am început să schițez „arhitectura” bazei de date care ar sta la baza saitului culturalia.ro  (cam ezit să-i spun portal) — am promis că o să explic și indexul general. Amân, pentru că prieteni programatori (mai programatori ca mine) mi-au semnalat un serios punct slab la jurnalizare, adică la mecanismul de monitorizare a modificărilor, adică al trasabilității genealogiei fiecărei resurse. Așa că, o re-gândire a dus la modificări. Structura nouă a tabelei-jurnal apare în figura 1.

Fig. 1. Culturalia. Structura unei înregistrări în tabela-jurnal

O intrare constă din:

  • resourceGuid – identificatorul resursei (entitate sau aserțiune) afectate;
  • provenanceGuid – identificatorul entității-eveniment (de tip „asignare de atribut”) care agregă informațiile despre cine și pe ce bază a operat asupra resursei;
  • timeStamp – momentul în care s-a produs intervenția asupra resursei;
  • previousStatus – starea resursei înainte de intervenție.

Dacă acțiunile asupra resurselor (i.e. înregistrărilor) ar fi:

  • creare;
  • modificare;
  • ștergere (din motive de redondanță);
  • revizie (validare, invalidare, punere la îndoială);
  • fuziune a două (sau mai multe);
  • scindare,

atunci stările posibile ale resurselor (i.e. ale înregistrărilor) ar fi:

-4

arhivată (clonă)

-3

arhivată (invalidată)

-2

arhivată (redondantă)

-1

arhivată (înlocuită)

0

creată

1

creată (înlocuitoare)

2

problematică

3

validată

iată tranziția stărilor, în funcție de acțiuni (și de drepturile editorilor) ar fi:

a) asupra celor originare/înlocuite:

Creare

Punere la îndoială

Validare

Înlocuire

Fisiune

Ștergere

Invalidare

0

2

3

0

2

3

-1

-4

-2

-3

1

2

3

-1

-4

-2

-3

2

3

-1

-4

-2

-3

3

2

-1

-4

-2

-3

-1

2

3

-2

3

-1

-3

2

3

-1

-4

b) asupra celor înlocuitoare:

Înlocuire

Fisiune

Punere la îndoială

Validare

1

1

2

3

Scenariile editoriale importante ar fi:

a) modificările unei aserțiuni individuale, care ar fi:

  • subiectul: înlocuirea identificatorului resursei (unificare de identificatori);
  • predicatul: 1) înlocuirea identificatorului predicatului (unificare de identificatori), 2) rafinare (înlocuirea cu o subproprietate);
  • obiectul unei proprietăți: înlocuirea identificatorului resursei (unificare de identificatori);
  • obiectul unui atribut: corecție;
  • celelalte elemente: 1) adăugare, 2) modificare, 3) ștergere.

b ) fuziunea a două relații (provenite din surse diferite):

Exemplu: două atribute:

subiect

predicat

object

id1(Twain) id(nume) Mark Twain

subiect

predicat

object

id2(Twain) id(nume) Twain, Mark

fuzionează în:

subiect

predicat

object

id2(Twain) id(nume) Mark Twain

dacă se preferă id2(Twain) din a doua relație, dar se preia literalul din prima.

Fig. 2. Fuziunea a două atribute, plus două revizii

În exemplificarea din figura 2 avem trei momente:

  • t1 – cele două atribute fuzionează, dând naștere celei de-a treia, fapt consemnat în trei înregistrări de jurnal distincte;
  • t2 – o revizie pune la îndoială noul atribut (starea lui trece din 1 în 2), fapt consemnat în jurnal;
  • t3 – o nouă revizie validează noul atribut (starea lui trece din 2 în 3), fapt consemnat în jurnal.

Aserțiunile modificate sunt arhivate (întră în starea -1) și punctează către aserțiunile înlocuitoare/succesoare (care intră în starea 1)  — cum se sugerează și în figură. Identificatorul aserțiunii succesoare este consemnat în câmpul „successorGuid” (vezi figurile 5 și 6).

c) fisiunea unui atribut:

Exemplu: un atribut:

subiect

predicat

object

id(Zenobia) id(autor) Gellu Naum

… fisionează în trei aserțiuni (o relație și două atribute):

subiect

predicat

object

id(Zenobia) id(autor) id(Naum)
id(Naum) id(prenume) Gellu
id(Naum) id(nume de familie) Naum

Fig. 3. Fisiunea unui atribut (cu clonele evidențiate)

În exemplificarea din figura 3 se sugerează soluția (nu prea elegantă — poate-mi sugerează cineva una mai isteață) prin care se memorează legătura dintre o aserțiune și succesoarele ei: aserțiunea originară este clonată (starea -4), doar ca să fie loc pentru fiecare pointer către succesoarele sale (în „successorGuid”). În plus, clonele memorează (refolosind „predicateTypeGuid”) pointeri către aserțiunea clonată. (Pentru economie de spațiu, s-ar putea renunța la stocarea literalului în clonele atributelor.)

Această soluție (care consumă spațiu, prin clonele generate și înregistrările de jurnal aferente) — i.e. cu pointeri de la aserțiunile înlocuite către cele înlocuitoare (în loc de invers) — fac mai „ieftine” fuziunile decât fisiunile. Și asta, din pricină că presupun — știind datele cu care vom avea de-a face — că fuziunile vor fi mai multe decât fisiunile. Iar dacă practica va dovedi că se consumă cam mult spațiu cu clonele, poate că s-ar putea adăuga o tabelă specifică pentru memorarea pointerilor de la aserțiunile înlocuite spre cele înlocuitoare.

Figurile 4, 5 și 6 arată noile versiuni ale tabelelor „entitate”, „instanță de relație” și „atribut”. La fiecare, noutatea semnificativă este „successorGuid”.

Fig. 4. Culturalia. Structura unei intrări din tabela „entitate”

Fig. 5. Culturalia. Structura unei intrări din tabela instanțelor de relație

Fig. 6. Culturalia. Structura unei intrări din tabela instanțelor de atribut

Abia în postarea următoare se va comenta (promisul) index general.

Anunțuri

Written by poliptic

17 Iunie 2012 la 11:34 pm

Lasă un răspuns

Completează mai jos detaliile tale sau dă clic pe un icon pentru a te autentifica:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s

%d blogeri au apreciat asta: