Danilo Poccia - Tecnologia et al.

Abbiamo ancora bisogno delle directory nei file system?

Riguardando il video sulla rivoluzione/evoluzione dell'informazione, mi viene il dubbio che il concetto stesso di directory, all'interno di un file system, sia "superato".

Fin dall'origine dell'informatica domestica siamo stati abituati a riporre i nostri documenti (file) all'interno di una struttura gerarchica (directory), con il risultato che spesso, oggi, mi ritrovo lo stesso file salvato più volte, in differenti directory, proprio perché il documento non è associabile solo ad una sola categoria (directory), ma ad esempio a due o tre contemporaneamente, ed io utilizzo ogni volta quella che in quel momento ritengo la più "importante". Viceversa, quando ricerco un file, rischio di cercarlo nella directory sbagliata.

Una evoluzione simile a questa vi è già stata con la gestione dei bookmark, che dalla classica struttura gerarchica nei menu dei browser sono passati ad un catalogo online gestito associando ad ogni link una o più "etichette" (tag), come ad esempio permette di fare il sito del.icio.us. Quando la gestione dei tag è condivisa tra più utenti, in un modello di social networking, si usa il termine folksonomy. Con questo modello associare più di una etichetta (tag) ad un link equivale, nella pratica, a riporlo allo stesso tempo in più di un una categoria (directory), ma senza avere una effettiva duplicazione del dato.

Lo stesso approccio di indicizzazione basato su tag può essere utilizzato da un file system che (senza entrare in un discorso più complesso di semantic file system) può catalogare i file al proprio interno non in base alle directory, ma in base ai tag ad essi associati. In tal caso si può definirlo un "tagged file system".

Ovviamente si aprono un certo numero di dubbi su come un tagged file system può essere implementato:

• Per identificare in modo univoco un file in un tagged file system (privo di directory), esiste un insieme minimo di tag da indicare assieme al nome del file? O si devono (dopo una opportuna ricerca) utilizzare sempre tutti i tag?
  
• Possono esserci due file con lo stesso nome ed un sottoinsieme di tag in comune? Se sì, nel caso di un accesso che identifica il file con tale nome ed un insieme di tag uguale al sottoinsieme di tag in comune, come gestire il possibile conflitto? Indicando, con un codice di ritorno, che c'è bisogno di più informazioni per trovare il file corretto?
  
• E' possibile eliminare completamente il concetto di directory, o conviene comunque affiancare una struttura gerarchica ai tag?

Per maggiore chiarezza provo a riportare un esempio. Quando in una applicazione, al termine delle modifiche, si deve salvare un file in un tagged file system, le informazioni da indicare sono:

• il file system (potrebbe esserci un file system separato per ogni utente, con una flessibilità nel creare file system simile a quella di ZFS)
• il nome del file
• i tag che descrivono il file (alcuni tag potrebbero indicare il tipo di file, al posto dell'estensione nel nome del file stesso)

I tag sostituiscono in questo esempio l'uso delle directory. I tag già usati possono essere suggeriti, come nel modello folksonomy, in modo da evitarne la proliferazione.

Usando dei tag con un formato del tipo "parametro:valore" si possono aggiungere con flessibilità dei metadati che vanno oltre il semplice tagging. Si deve valutare se l'aumento nella complessità controbilancia le potenzialità espressive di una sintassi di questo genere.

Credo sia chiaro che in questo ambito ci sia molto spazio per l'analisi e la ricerca. Uno dei passi necessari è senz'altro la definizione di un insieme standard di API per l'accesso ai file che vada oltre l'interfaccia standard POSIX. Potrebbe essere utile il lavoro in corso sullo standard XAM. Si può per semplicità valutare la possibilità di costruire il modello a tag sopra un file system normale, ad esempio ricavando la directory in cui collocare un file a partire dai tag ad esso associati. Ogni idea è la benvenuta.

Posted at 10:54AM apr 15, 2008 by danilop in Internet  |  Comments[1]