Nepomuk use case

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent

Nepomuk use case
by Patcito on Friday 08/Feb/2008, @19:55

I guess we're not too far away from the "search all pictures received from user X and tagged funny" or "select all pdf downloaded from website Y" (that one would need some work from kget or khtml I guess) ?

Very cool anyway.

Related Links

·   Articles on Developer
·   Also by Patcito
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Nepomuk use case
by anonimouse on Friday 08/Feb/2008, @21:08

The ability to have smart folders in dolphin would also be cool.
Smart Folders are folders which contain links to files of a certain search query eg. all *.odp files. Its really handy and with nepomuk there would be many catehories to search through.

[ Reply To This | View ]

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.

[ Reply To This | View ]

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 )


		"In my free time I try to avoid computers as far as possible." -- Matthias Elter
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.