Questa interessante anteprima del desktop semantico “Nepomuk” nel file manager di KDE4 “Dolphin” ci è offerta dall’ottimo liquidat, che ha registrato uno screencast commentato:
[vodpod id=ExternalVideo.437019&w=425&h=350&fv=]
Ho abbondantemente parlato di Nepomuk in passato (cfr “Nepomuk-KDE: continua la saga con Soprano“) esaltandone le possibilità e guardando a KDE come terreno di sperimentazione all’avanguardia (cfr “Nepomuk-KDE: il *vero* desktop semantico sarà KDE4“).
Finalmente comincia a poter essere chiaramente dimostrabile, anche ai meno addentro, il significato e le potenzialità del tanto anticipato “desktop semantico”. Se volete guardare il video della presentazione relativa, svoltasi all’aKademy 2007, vi consiglio di puntare il vostro download manager a questo URL ;)
È vero, questo concetto di desktop semantico sta rischiando di diventare un tormentone un po’ abusato, ancora prima che software rilasciato e usabile, ma tant’è. In ogni caso è meglio parlarne e diffonderlo per poi essere preparati al suo uso una volta rilasciato… piuttosto che parlane e poi non avere un bel niente da usare¹ :D
Se cercate qualcosa del genere per GNOME sappiate che ne ho scritto già a riguardo, e ha a che uno dei miei progetti preferiti. Vi invito a leggere un mio vecchio post perché l’ho appena riletto io stesso e devo dire che mi sembra abbastanza decente :) e spiega in poche parole la situazione in casa GNOME. Per favore quindi se volete commentare su GNOME fatelo in quel post, che è più adeguato: Su Beagle, Tracker, la luccicanza¹ …e Strigi.
Tornando in tema invece, non vedo l’ora di poter utilizzare KDE4/Nepomuk/Dolphin in maniera stabile!
—
[¹] Allusione impercettibile ed eterea a qualcosa di tanto sbandierato ma mai esistito, il cui nome cominciava per “Win” e finiva per “FS” ;)
wow!!! *aspettando ottobre*
Anch’io faccio qualcosa di simile con Nautilus – XMP Manager e Beagle,..
http://grigio.org/tagging_images_xmp_manager_and_beagle
Ma ci vorrebbe qualcosa di più integrato con l’ambiente :P
veramente molto interessante :D lo sviluppo di kde4 corre a quanto pare :D
bisogna vedere quanto tutto questo influirà sulla presenatzione delle informazioni e quindi sulle prestazioni dell’indicizzazione, delle anteprime, in generale dulle letture da disco del file manager.
in visssta (per fare un esempio) il tutto ora, non essendo integrato nel filesystem, è mooooolto pesante e il sistema soffre molto nelle operazioni di apertura e copia (forse winfs non era poi una pensata così malvagia).. speriamo che i nostri abbiano messo in forno qualche “trucco sveglio” per non cadere negli stessi erroi di mamma MS.
A dire il vero a me tutta questa ‘integrazione’ fa un pò paura….
Me ne rendo conto quando uso Microsoft che ti costringe ad usare tutto quello che è loro! Troppa informazione = Niente Informazione.
Per ora questo ‘desktop semantico’ non mi sconvolge.
effettivamente queste cose mi interessano poco…
dal punto di vista dell’interfaccia, poi, aggiungere tag in quel modo mi pare piuttosto scomodo, forse meglio un campo di testo diviso da virgole?
ciao
L’idea è ottima, il problema è che non penso oggi esista un file system semantico utilizzabile in Linux.
Correggetemi se sbaglio.
@quelli del filesystem
non esiste un filesystem semantico (tuttavia alcuni supportano i tags), ma non serve! WinFS non era un filesystem in realtà, era semplicemente un livello di astrazione sopra NTFS che era il “vero” filesystem. infatti per funzionare necessitava di un piccolo server SQL.
ma questa si è dimostrata una strada un pò troppo esosa di risorse.. attualmente indicizzare è la cosa migliore (a questo ci penserà strigi), anche perchè quasi sempre non serve che tutto il filesystem sia semantico, ma solo i documenti.
@Stefano
senza nepomuk in background tutte queste funzionalità non sono nemmeno visibili.. a te la scelta ;)
il desktop semantico: OS/2 lo aveva già 8 anni fà /ora c’è eComStation (qualcuno lo conosce???)….
beh io sarei + per una divisione a tags che per l’inserimento di commenti liberi.. e poi quell’icona gigante a destra non si può vedere…
@stefano
Per la verità nell’Opensource solitamente questo problema non sussiste, non ci può essere nessun blocco all’interoperabilità e alla scelta.
Comunque ci sta che alcuni pezzi di KDE (come Neponuk ma forse anche strigi) potranno essere in qualche modo essere riutilizzati anche da GNOME.
Here is another movie : http://pl.youtube.com/watch?v=i4HS1v0a9Xs
ma i dati dove vengono salvati? effettivamente senza un filesystem appositamente creato rischia di essere un bel collo di bottiglia
Forse un file system totalmente semantico no , ma imho della gestione dei tags e dei metadati relativi ai documenti non deve occuparsene l’ambiente desktop, ma il file system o almeno un’astrazione sopra questo. L’ambiente desktop dovrebbe fare da interfaccia , ma l’implementazione dovrebbe essere a livello di file system , sempre imho.
@lostbob
Liquidat altrove ha spiegato che non può occuparsene il filesystem, perché molti metadati non sono associabili a file.
Pensa per esempio a e-mail o a voci di rubrica.
Inoltre fare ricerca in un database è molto più veloce.
E’ possibile che si avranno doppi tag, sia nel database, sia nei file che li supportano (come mp3 e immagini) e che verranno aggregati al database da strigi.
Inoltre immagino si vorrebbe anche farlo funzionare per aggregare e condividere le informazioni sulle reti.
(p.s. ext3 supporta già i tag, se si è scelto di non usarli avranno i loro motivi)
grazie dell’informazioni mercurio :D
@Mercurio
Da quel che ho capito ad oggi Strigi indicizza solo i file quindi niente mail o rubrica. Comunque ho capito il concetto.
Il problema è fare in modo che le applicazioni utilizzino lo stesso database per i metadati, per esempio nel mondo Mac esiste Spotlight ottima cosa imho , peccato che l’indicizzazione delle mail avviene solo per iMail e non per Thunderbird . Però la natura open source del progetto mi fa ben sperare.
Un’ altro buon motivo per cui evitare filesystem semantici è la portabilità. KDE con la versione 4 vuole sbarcare anche su sistemi come Windows e Mac dove non sarebbe possibile cambiare filesystem del sistema e quindi tutte queste funzioni non sarebbero accessibili.
Inoltre strigi è, se non sbaglio, accessibile da dbus in questo modo anche applicazioni esterne come Gnome possono accedervi senza dover dipendere minimamente da librerie di KDE.
@lostbob
Le applicazioni KDE useranno una particolare API per i metadati, quindi digikam, kmail etc potranno scrivere direttanebte sul database semantico, mentre strigi indicizza i file.
Firefox 3.0 ha una nuova gestione dei preferiti/keyring che si potrà integrare con quella del sistema operativo. Non è improbabile facciano qualcosa di simile anche per Thunderbird, (anzi penso sia molto più semplice).
Ho visto ora, strigi non usa neanche le Qt, è scritto in C++ purissimo a quel che sembra, (uomini valorosi!) e dovrebbe essere accessibile anche tramite uno standard di freedesktop basato su dbus.
Però sarebbe molto molto più figo se le applicazioni gnome accedessero anche al database semantico.
speriamo si lavori sull’integrazione, a differenza di windows e osx, linux non ha un suo “standard”, e questo porta a molti problemi di integrazione. un esempio banale sono le app gnome su kde e viceversa, un’altro è ad esempio l’implementazione delle swing di java davvero pessima su linux
Ma quand’è che quelli KDE smetteranno di usare quei divisori con i pallini davvero orendi (come si dice a Roma..) ?
Luk, invece tutte le app di Windows (e OSX) hanno un loo’n’feel integrato, come per esempio MSN, Skype o decine di altre, no? O in OSX le app Aqua e Brushed Metal sono esattamente uguali, no?
Pingback:Raccolta di informazioni su Nepomuk e KDE4 « pollycoke :)