faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Nepomuk use case
by Lee on Saturday 09/Feb/2008, @02:36
|
| Nepomuk has been HUGELY undersold, imho. It's based on RDF ontologies (ie, a very simple, but flexible and powerful database of knowledge), which essentially makes it the core of an AI engine. Theoretically, it should be possible to store ANY knowledge in it, and to ask any question. Some complex questions might not be answered as efficiently as others, as they'd resemble complex SQL queries. However, given that other systems might not do what you want at all, the imperfect solution is still better than lack of a solution. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Nepomuk use case
by Robert Knight on Saturday 09/Feb/2008, @05:22
|
> Nepomuk has been HUGELY undersold, imho.
I think one important lesson from development leading up to KDE 4.0 is that it is best to keep mum until there is something cool to show.
Sure, the semantic desktop does have a lot of potential, but right now, as far as the end user is concerned, it gives them simple tagging and rating of files in Dolphin.
Pitching to the developers is a different story. You want to get them fired up about the potential of a particular project and encourage them to use it to improve their own software. The difficulty is making sure that a pitch to developers or potential developers doesn't land on the front page of Slashdot as a promise that KDE version X will do Y.
|
[
Reply To This | View ]
|
Re: Nepomuk use case
by Lee on Sunday 10/Feb/2008, @13:21
|
Yep, agreed. It's a tough balance to find. Nepomuk's APIs have a really nice simplicity to them though, so I'm confident that development will catch up soon enough :) One thing that would really help though, is better documentation. The examples on techbase are great, but there aren't many of them, and they're fairly limited in terms of use cases. I haven't yet seen any examples of soprano/nepomuk use from python/ruby/kross -- don't even know if any of those bindings are implemented yet.
|
[
Reply To This | View ]
|
|
Re: Nepomuk use case
by Martin on Saturday 09/Feb/2008, @12:29
|
Is there some thinking on how to migrate NEPOMUK data?
Data that is automatically scraped from files or email messages is one thing; you can just redo the scaping. But the other type of data is that which cannot be recreated if the database is lost; for instance user entered tags, and the history of files (where they came from).
For me at least, I would neither manually enter any tags if they will be lost when I switch machines, nor would I make myself dependent on such metadata that cannot be synchronized or at least migrated between machines. Also, I would like control over the synchronization/migration process; I might not want the metadata for my private stuff on my work machine.
Any plan for this? Of course, a prerequisite is that files etc. are primarily identified by checksums rather than paths, which I am assuming to be the case?
Thanks in advance for any info!
|
[
Reply To This | View ]
|
Re: Nepomuk use case
by Lee on Sunday 10/Feb/2008, @13:16
|
There's a command line tool, sopranocmd, which you can query for anything related to a particular file. Tools like star (a modern tar replacement) have long-since supported file attributes. Patching star (or KDE's ark) to support asking Nepomuk/soprano for this data before archiving shouldn't be too hard at all. Worst case scenario, you can manually run the query, save it along with your files, and import it on a new machine. But there's really no excuse for archivers not supporting this stuff as standard. File attributes have been around for AGES in the unix world, and star has no issue with it. They also work fine on other platforms like BeOS, Mac OS, etc.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
