Identificazione di nodi e documenti - Architettura di riferimento e modelli semantici per siste

3.6 Identificazione di nodi e documenti

Affinch´e un elemento informativo sia correttamente condiviso, divulgato e riusato, deve possedere due propriet`a fondamentali: essere individuabile ed accessibile. Spesso nei sistemi telematici le risorse sono individuate attraverso il loro indirizzamento e l’indirizzo stesso viene utilizzato anche per l’accesso fisico (come nel caso degli URL 7).

All’interno di IDN-IM l’identificazione dei nodi è una proprietà indipendente dai dettagli dell’accesso fisico, dato che quest’ultimo non rappresenta un contesto di interesse per un Information Model. In altre parole è importante disporre di identificatori che vadano ad astrarre dalla localizzazione fisica delle risorse e siano quindi indipendenti dalla stessa.

Tale affermazione è conseguenza della percezione che l’essere umano ha del concetto di “documento”: ad esempio con “categoria della patente di guida di Mario Rossi” si intende un’informazione ben precisa ed indipendente dal luogo e dal formato in cui viene conservata e acceduta. In pratica la categoria è la stessa informazione sia che questa venga memorizzata negli archivi elettronici della Motorizzazione Civile sia che si trovi stampata sul documento in formato cartaceo per il titolare della patente. Questo esempio evidenzia come l’identificazione delle risorse sia un’operazione concettual- mente diversa dall’accesso e pertanto, in generale, è opportuno che le due operazioni siano distinte per rispettare la separation-of-concern. In tal caso, una volta effettuata l’identificazione in una prima fase, è possibile procedere, in una fase successiva, all’accesso.

Le risorse8 all’interno di IDN sono identificate mediante il ricorso agli LRI (Logical Resource Identifier); sebbene siano stati definiti come sotto- classe degli HTTP-URI, essi garantiscono la completa separazione fra indirizzamento ed accesso. Grazie al principio di responsabilità l’authority dell’URI 9 permette di individuare non tanto il server che detiene l’informazione a cui l’URI fa riferimento bens`ı il server “responsabile” su quella informazione. Come risulterà più chiaro nel seguito (dopo la descrizione di IDN-SA) l’informazione verrà infatti ricostruita dinamicamente attivando una serie di elaborazioni che, partendo dal server responsabile, interesse- ranno altri server, fino al reperimento effettivo di tutti i dati necessari, che risiederanno su sistemi remoti, per la ricomposizione dell’informazione di interesse. Il responsabile non detiene quindi l’informazione, ma è colui il quale deve orchestrare tutti i processi necessari per ricostruire l’informazio-

Gli Uniform Resource Locator (o URL) [Hof05a, Hof05b] sono gli indirizzi utilizzati nel web al fine di identificare ed accedere alle risorse. Sono un caso particolare di URI (Uniform Resource Identifier [BLFM05]).

8_{In questo contesto, con il termine risorsa si indica un documento IDN, un nodo di}

un documento, un dato/metadato in esso contenuto; in generale una qualunque entit`a

definita dal modello stesso.

9_{L’authority `}_{e la componente compresa fra ://” ed il primo “/” successivo, vedi la}

ne; inoltre come responsabile stabilisce le condizioni sotto le quali rendere fruibili l’informazione, negando ad esempio l’accesso ai soggetti che non ne hanno diritto.

Gli LRI che fanno riferimento alla medesima informazione sono considerati equivalenti, nel senso che permettono di operare sull’informazione allo stesso modo. La necessità di assegnare più nomi logici alla medesima informazione deriva dal fatto che essa è calata all’interno di un contesto di massimo riu- so, ovvero la stessa informazione riusata in contesti diversi assumerà nomi diversi: questo è un dato di fatto che deriva dal comune modo di ragionare dell’essere umano. Infatti la “patente di Mario Rossi” è il nome che chiunque potrebbe assegnare alla patente di guida di Mario Rossi; per Mario Rossi invece, il nome sarebbe “la mia patente”, mentre per la Motorizzazione Civile potrebbe essere qualcosa del tipo “. . . /FI/2012/NUM XYZ”.

IDN-IM prevede l’utilizzo di due diverse sotto-classi di LRI: i canonici e gli alias. Ogni informazione è identificata per convenzione tramite uno o più nomi canonici e zero, uno o più alias; quando il nodo è creato gli viene assegnato un LRI canonico invariabile nel tempo che dipende dal contesto nel quale esso viene creato. Gli LRI canonici possono essere assimilati agli hard-link dei filesystem Unix in quanto rappresentano una “maniglia” per l’accesso diretto all’informazione a cui fanno riferimento.

Gli utenti possono arbitrariamente assegnare ulteriori LRI ai vari nodi, se- condo le loro necessit`a: questi sono gli alias, ovvero LRI che fanno riferimento ad altri LRI (i quali possono essere a loro volta canonici o alias), in analogia ai link simbolici presenti nei filesystem Unix.

Infine, poich´e come illustrato nel paragrafo 3.4, i nodi fanno parte di documenti strutturati, possono essere assegnati ad essi ulteriori LRI determinati dalla posizione assunta nella struttura; ognuno di essi assumer`a la seguente forma [PPI+09]:

node parent name + / + link name dove:

• node parent name `e il nome del nodo genitore; • + `e l’operatore di concatenazione tra stringhe;

• link name `e il nome del collegamento che mette in relazione il genitore con il nodo da indirizzare.

Si consideri ad esempio la figura 3.2, nella quale `e mostrato un documento IDN di nome Doc1, che contiene quattro nodi e quattro collegamenti di aggregazione di nome 1, 2, 3, e 4.

Il nodo Doc1URI/1/3 ha questo nome in quanto figlio del nodo Doc1URI/1 attraverso il collegamento di nome 3. Per lo stesso motivo, ha anche il nome

3.6 Identificazione di nodi e documenti 63 1 2 3 4 nome: Doc1URI nome: Doc1URI/2 nome: Doc1URI/1 nomi: Doc1URI/1/3 Doc1URI/2/4

Documento IDN - Doc1

Figura 3.2: Esempio di relazioni tra documenti IDN-IM.

Doc1URI/2/4 perch´e `e raggiungibile anche dal nodo Doc1URI/2 attraverso il collegamento di nome 4.

Se si considera il nodo Doc1URI come radice locale, ai suoi successori sono automaticamente assegnati i seguenti nomi relativi: ./1, ./2, ./1/3 e ./2/4.

Una ulteriore convenzione utilizzata per gli LRI (ancora analoga a quanto accade nei filesystem) `e la seguente: gli LRI che terminano con “/” sono considerati come identificatori di documenti, mentre gli altri (ovvero gli LRI che non terminano con “/”) come identificatori di nodi.

La convenzione `e inoltre tale che se “...xyz/unLRI/” rappresenta il documento “X” allora il nome LRI “...xyz/unLRI” (senza slash finale) rappresenta il nodo radice di “X”.

E interessante notare infine che gli alias offrono sempre la dereferenziabilità diretta, ovvero se “A” è un alias di “B” è sempre possibile raggiungere “B” partendo da “A”.

Invece, per quanto riguarda la risoluzione inversa `e possibile trovarsi di fronte a due casi:

• invertibilità globale; in questo caso a livello globale è possibile risalire ad “A” partendo da “B”. Questo tipo di invertibilità offre un legame bidirezionale fra i due soggetti interessati dalla relazione instaurata dall’alias. In questo modo il legame è reso più forte, ma può essere limitata la scalabilità e la semplicità di realizzazione dell’alias, opera-

zione che richiede la collaborazione dell’organizzazione a cui fa capo l’elemento referenziato;

• invertibilità locale; in questo caso è possibile risalire ad “A” partendo da “B” limitatamente al contesto dell’organizzazione a cui fa capo “A”. In altre parole all’interno di ogni organizzazione è possibile effettuare la risoluzione inversa di tutti gli alias invertibili globalmente e di tutti gli alias definiti internamente all’organizzazione stessa.

Nel documento Architettura di riferimento e modelli semantici per sistemi di gestione di documenti strutturati distribuiti in rete (pagine 85-88)