(19:14:33) trueg: let me give you a quick overview on what a diploma student in Zurich is working on
(19:14:40) andersfeder: ok
(19:14:50) trueg: the idea is to allow applications to add rdf data to the clipboard
(19:14:55) trueg: other apps can then paste it
(19:15:00) trueg: now this is still quite simple
(19:15:13) trueg: the nice thing is the translation and enrichment stuff
(19:15:43) trueg: it means we provide a service that trnslates data from one onto into the other (typical example: FOAF -> NCO)
(19:16:02) andersfeder: i see
(19:16:04) trueg: also there will be a service which downloads additional data from the internet
(19:16:12) trueg: again FAOF is the example
(19:16:24) trueg: one entry might reference remote resources
(19:16:36) trueg: the application can request to gather these, too
(19:16:53) andersfeder: ok
(19:16:59) trueg: once it works one should be able to copy an address from some homepage (which provides rdf)
(19:17:05) trueg: and then paste it into the addressbook
(19:17:10) trueg: or into the email client
(19:17:16) jprieur [n=jprieur@hoasb-ff03dd00-31.dhcp.inet.fi] trådte ind i rummet.
(19:17:22) trueg: which would then create a new email with the "to" field filled
(19:17:35) andersfeder: nice
(19:17:39) trueg: or into the text processing app which would open a letter template
(19:17:44) trueg: stuff like that
(19:17:50) andersfeder: right
(19:18:13) trueg: this is quite cool but from a technical point of view it does only touch the rest of the nepomuk system
(19:18:33) trueg: as it does not necessarily use data that is already stored (except for maybe ontologies)
(19:19:08) andersfeder: ok
(19:19:25) trueg: but it is another cool step towards sementic desktop
(19:19:27) trueg: anyway
(19:20:00) trueg: like I said before i think it would be great to share at least interfaces
(19:20:08) andersfeder: right
(19:20:29) trueg: should I sum up the different ones I have in mind (and exist) again?
(19:20:43) andersfeder: please do ..
(19:20:52) trueg: ok
(19:20:58) trueg: the most basic one would be Soprano
(19:21:08) trueg: Soprano is a plain RDF storage API
(19:21:27) trueg: meaning you have methods like addStatement, listStatements, or of course executeQuery
(19:21:34) andersfeder: i see
(19:21:51) trueg: this is pretty generic and is exported via DBus (and a closed socket connection)
(19:22:27) andersfeder: ok
(19:22:33) trueg: on top of that we so far have a lib that tries to abstract from the ontologies by providing a Resource object for each, well, resource
(19:22:45) trueg: there is no dbus api for that yet
(19:23:05) andersfeder: for each resource in Soprano?
(19:23:09) trueg: then there is search (or virtual fodlers)
(19:23:14) vkrause forlod rummet (quit: Read error: 104 (Connection reset by peer)).
(19:23:31) trueg: I meant each nepomuk resource which essentially means a subset of the RDF resources in the Soprano store
(19:23:41) andersfeder: ok
(19:23:53) trueg: (there are also ontologies stored in there but the user should never be bothered with Class or Property resources)
(19:24:03) andersfeder: right
(19:24:07) trueg: ok then
(19:24:27) trueg: for the desktop search we have Xesam which is not semantic aware. thus, we need more
(19:24:50) trueg: the idea was to "restrict" it to virtual fodlers for every kind of information (not only files like in Xesam)
(19:25:14) trueg: here I started to define an API but so far I "only" have an integration in the KDE VFS KIO
(19:25:19) leobard forlod rummet (quit: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org").
(19:25:29) trueg: meaning, you can create virtual folders on-the-fly in the filemanager
(19:26:01) trueg: now that I talk about it I see that not much API has been defined in DBus yet
(19:26:11) trueg: so there is a lot room for discussion :)
(19:26:15) andersfeder: ok
(19:27:00) andersfeder: a virtual folder is .. a NRL view?
(19:27:06) trueg: sadly, no
(19:27:17) trueg: like I mentioned in the email, NRL has not been implemented yet
(19:27:21) andersfeder: ok
(19:27:29) trueg: it is something that the RDF storage would have to provide, like SQL views
(19:27:46) trueg: a virtual folder is a search which is done using SPARQL and lucene
(19:27:51) trueg: and combining the results
(19:28:01) andersfeder: aha
(19:29:01) trueg: having NRL views would be great but...
(19:29:13) trueg: well, I dont think we can rely on them being implemented. :(
(19:29:32) trueg: anyway, should I explain more?
(19:29:45) trueg: about the ontologies and the overall architecture maybe?
(19:30:35) andersfeder: i'm wondering where GNOME would 'fit in' .. if/what we would need to produce to plug into your architecture? 
(19:31:08) trueg: well, atm you would have to perform actual SPARQL queries yourself
(19:31:24) trueg: but I figure that we could join forces to define the API of at least the virtual folder service
(19:31:34) trueg: then gnome and kde apps could use the same folders
(19:32:26) andersfeder: in which cases would this be useful? the same folders meaning .. ?
(19:32:36) trueg: we could also think about which parts of the KDElibs needs to be exported over DBus for better interoperability
(19:33:13) trueg: I just mean that gnome apps could benefit from the vf service
(19:33:26) andersfeder: ok
(19:33:29) trueg: if the user would have kde and gnome apps (most do I think)
(19:33:35) andersfeder: ah of course
(19:33:39) trueg: stored folders would appear in both
(19:33:42) andersfeder: right
(19:33:46) trueg: less confusing
(19:33:50) andersfeder: sure
(19:34:37) trueg: a problem is of course the storage which atm uses kde
(19:34:56) trueg: gnome would probably have its own storage, right?
(19:35:15) trueg: I mean even Soprano is based on QT4
(19:35:16) andersfeder: soprano depends on KDE, you mean?
(19:35:18) andersfeder: ok
(19:35:35) trueg: soprano depends on qt, and the nepomuk server and the services on kdelibs
(19:35:39) andersfeder: yes, something natively would probably be done, for the sake of consistency
(19:35:43) andersfeder: native*
(19:35:46) trueg: right
(19:36:10) andersfeder: what does the nepomuk server do?
(19:36:14) trueg: at that point one would maybe need converters or make the whole nepomuk server a thing independant from kde and gnome
(19:36:35) trueg: the nepomuk server basically does only one thing:
(19:36:44) trueg: it manages the nepomuk services
(19:37:09) trueg: the most imporant one being the storage service which uses Soprano and the Soprano fulltext index extension
(19:37:25) trueg: then there is a service which imports standard ontologies into the storage
(19:37:56) trueg: a service which tris to react on moved or renamed files
(19:38:00) vandenoever [n=vandenoe@ip5657eb5b.direct-adsl.nl] trådte ind i rummet.
(19:38:32) trueg: and so on
(19:38:36) andersfeder: ok
(19:38:57) trueg: the nepomuk server is intended to be the main configuration point
(19:39:07) trueg: oh, and then there is the strigi service
(19:39:25) trueg: which runs and controls strigi for file analysation
(19:39:40) trueg: (that would be tracker in gnome I think)
(19:39:47) andersfeder: ok
(19:40:04) vandenoever: trueg: that's not definitive according to the gnomies i talked to at fosscamp
(19:40:19) vandenoever: they are moving to supporting xesam, not a specific indexer
(19:40:27) trueg: very good
(19:40:59) andersfeder: and this clipboard board is a nepomuk service as well? or it relies on nepomuk services?
(19:41:02) andersfeder: -board
(19:41:06) trueg: right
(19:41:55) trueg: I figure the best thing we can do atm is to ensure that our apis are consitent and that our data is organized in the same way (ie. we use the same ontologies)
(19:42:03) andersfeder: ok
(19:42:15) andersfeder: is there any documentation on the nepomuk server or the nepomuk services?
(19:42:27) trueg: yes
(19:42:32) trueg: techbase.kde.org
(19:42:34) andersfeder: ok
(19:42:38) trueg: or better:
(19:42:41) trueg: nepomuk.kde.org
(19:42:47) trueg: then follow the link for developers
(19:42:54) trueg: it should provide links to all docu
(19:42:58) andersfeder: ok thanks
(19:45:33) andersfeder: it all sounds like much what i have had in mind ...
(19:45:39) trueg: cool
(19:46:23) andersfeder: my basic idea was that one day practically all storage and messaging should go through the semantic layer .. is this realistic,  you think? 
(19:46:36) trueg: I hope so
(19:46:39) andersfeder: ok
(19:46:46) trueg: at least that is the plan. ;)
(19:46:52) andersfeder: cool :)
(19:47:33) trueg: people are very interested but the topic is hard to communicate (for me at least) and development is slow
(19:47:47) trueg: rdf is young which means storage has not many features
(19:47:56) trueg: sparql is a joke compared to sql
(19:48:02) trueg: these are the problems. :)
(19:48:10) andersfeder: i see ..
(19:48:13) trueg: but it is fun and goes step by step
(19:48:40) andersfeder: is hard to communicate it to app developers, you mean?
(19:48:50) trueg: yes, I s*** at that I suppose
(19:48:59) andersfeder: lol ok
(19:49:06) trueg: although basic stuff keeps to appear
(19:49:13) trueg: like in the download manager kget
(19:49:27) trueg: and in akonadi the kdepim thing
(19:49:36) andersfeder: nice
(19:50:22) vandenoever: web devs understand this stuff pretty well
(19:50:40) vandenoever: and there are quite a few smaller projects using semantic priniciples
(19:50:54) vandenoever: so app devs will catch on eventually
(19:51:10) trueg: i think so too
(19:51:44) andersfeder: yeah, its inevitable i think .. it'll be hard to get around semantic data in a few years
(19:52:03) trueg: right
(19:52:27) trueg: doing the gound work is always hard I suppose
(19:52:54) andersfeder: yes probably
(19:53:55) vandenoever: andersfeder: so you work on a semantic project too?
(19:54:25) andersfeder: i'm looking informally at making GNOME semantic .. something like NEPOMUK-KDE for GNOME
(19:55:56) vandenoever: andersfeder: nice, i hope we can share a lot of stuff like ontologies and hopefully also libraries
(19:56:05) andersfeder: yeah, me too
(19:56:23) trueg: ontologies should be easy to share
(19:56:27) trueg: libs on the other hand
(19:56:30) vandenoever: andersfeder: i think the xesam approach with ontologies and a dbus spec is pretty nice
(19:56:51) andersfeder: right
(19:57:18) trueg: andersfeder: I just thought of another thing which is sort of in the pipeline (like so many)
(19:57:22) vandenoever: andersfeder: although we do have a lot of separate efforts now
(19:57:38) vandenoever: but that's normall for foss
(19:57:51) andersfeder: vandenoever: sure
(19:57:59) andersfeder: trueg: do tell
(19:59:25) trueg: andersfeder: it is the API which I mentioned before for managing resources instead of plain rdf data
(19:59:37) trueg: there is a draft for that which is based on another ontology
(19:59:44) trueg: called PIMO
(20:00:01) trueg: actually that is the part which should be extensible by the user
(20:00:11) trueg: meaning the user can create new classes and properties
(20:00:53) trueg: everything in there is an abstract concept
(20:01:08) trueg: which can have actual stuff like files as "grounding resources"
(20:01:31) trueg: but so far there is not much implemented here
(20:02:01) trueg: I only have a sort of maintenance shell which lists all classes and properties and allows to change them
(20:02:37) trueg: but at some point you could imagine the user creating a new class of contacts like "friends" or "ex-girlfriends" ;)
(20:02:47) andersfeder: ah ok
(20:04:38) vandenoever: i hope the database performs well
(20:05:00) andersfeder: lol
(20:05:56) andersfeder: trueg: so, would there be any sense in developing, say, the nepomuk server as desktop-independent, you think?
(20:06:45) trueg: honestly I think it would be much more important to get the "real" semantic stuff rolling.
(20:06:54) andersfeder: ok .. such as?
(20:07:11) trueg: for example the APi I just mentioned
(20:07:22) trueg: or good app integrations as examples
(20:07:32) vandenoever: andersfeder: if you accept qtcore as ok to use i guess it is easy
(20:07:44) trueg: I mean, it is easier to design the api properly once we have more test cases (apps)
(20:07:59) vandenoever: dbus is also using glib, which kde folks dont mind
(20:08:01) trueg: later the server can be changed to be kde-independant
(20:08:08) andersfeder: vandenoever: i see
(20:08:20) andersfeder: trueg: ok
(20:08:54) vandenoever: it's important to not fight about technology too much, dbus can be tranlation layer between services writting on different platforms
(20:09:04) trueg: right
(20:09:30) vandenoever: esp. gui independent stuff should be  a no-brainer to share libs on
(20:09:47) trueg: andersfeder: and in the end the server is not the important thing. The imporant thing is the onto-awareness of the applications
(20:10:05) trueg: and that could be achieved with a good API
(20:10:08) andersfeder: vandenoever: definitely .. its not so much about fighting, though, but rather the obligation to deliver a 'complete' an independent desktop, i think
(20:10:17) trueg: what happens behind that API can be changed at any point in time
(20:10:33) andersfeder: trueg: right
(20:10:56) vandenoever: andersfeder: independent of what? none of it is proprietary
(20:11:56) vandenoever: i think 99% of all users has both qtcore and glib installed anyway so no point in making trying to avoid using either
(20:12:40) vandenoever: but anyway, discussing cool services is more important, sorry for the digression
(20:13:16) andersfeder: vandenoever: indeed and i agree .. i'm just relaying the sentiment :) .. i think some devs will feel that its important to deliver a product where all components are developed according to the same principles, if you understand what i mean
(20:13:41) trueg: andersfeder: sure, that has always been a problem.
(20:13:46) andersfeder: right
(20:14:05) trueg: It would just be cool to be able to show nice stuff before that
(20:14:12) andersfeder: it's not a matter of "eww.. we don't want no stinky KDE dependencies"
(20:14:13) trueg: like:
(20:14:32) vandenoever: andersfeder: they'll not achieve consistency that way, any desktop uses at least  four different programming language
(20:14:57) vandenoever: for gui consistency, i agree
(20:19:54) andersfeder: so, the job in GNOME now, would be to implement the NEPOMUK API's, in your opinion? like virtual folders
(20:22:07) vandenoever: gnome vfs for using virtual folders would be nice
(20:22:17) andersfeder: ok