Plasma activities and Nepomuk

[Sebastian Kügler]

On Saturday 01 August 2009 00:25:19 Aaron J. Seigo wrote:
> On Friday 31 July 2009, Ivan Čukić wrote:
> > The most basic thing that comes to mind is a nepomuk resource, which the
> > other application listen to using the sopranoStatementAdded() signal in
> > SopranoModel.
> >
> > The other approach (DanielW pointed it out) is something like the nepomuk
> > service example located in playground
> > (/base/nepomuk-kde/usercontext/service/)
>
> personally, i prefer the idea of a nice API behind which the real work can
> hide (as the usercontext thing provides). direct access to what's going on
> in Soprano seems fragile and overly difficult to me from an application
> developer's POV.
>
> another big question is what the ontology to use is. when i last left off
> discussing this with the nepomuk people there was a long discussion being
> had about what that ontology should look like. i'm not sure what the end
> result was, tbh.
>
> personally, i favor something simpler and reflective of what we need rather
> than complex and theoretical.

Yes, definitely. We need to break down the functionality Nepomuk can provide to 
specific things we want to do with it.

I've been thinking about this for Lion Mail, which makes for an interesting and 
supposedly relatively simple example what *I* would like to do with Nepomuk. Lion 
Mail can show different "sets" of email (for example folders, but in the future also 
search results, virtual folders so to say). I would like to be able to know about the 
context the user is working in, so if the context is "work" (work-work really), the 
plasma lion mail thing shows work-related emails, including notifications of new 
ones. At 5'o clock, you're free and you start doing freetime things, so the context 
you're in changes from "work" to "freetime". Lion mail gets a notification that the 
context has changed, and now loads emails related to this activity.
Implementation-wise, I'd basically only need a context object with a signal 
contextChanged(QString), and then have the user tell me which emails belong to which 
context (or rather, which emails to show or not to show).
Thinking one step further, Lion Mail could just display all emails that are tagged 
with a tag belonging to our context.

On the other end of integration, it would be cool to make some plasmoids understand 
RDF resources, and know how to display them. One possible plasmoid could be a person, 
or a place (your current one). Dropping such an RDF resource onto plasma displays 
content related to this resource then. This is comparable to one of the things I'm 
working on in the background, making Plasma understand KIO (dropping an object from a 
webpage should for example Just Work, i.e. if you drag an image from a webpage to 
your desktop, it creates a picture frame of that image there). Something similar 
could be done to RDF resources (which can also be identified by a URL, right?). 

Maybe think of dragging a tag onto the desktop and a folder view of all the files / 
objects belonging to this tag. (That last one is super simple to do of course 
(essentially a folderview entry with a nepomuksearch:/ URL), but it lacks the last 
bit of chrome to make it an accessible, visible feature.

Another relatively easy thing would be an applet much like the pastebin applet, you 
drop a file or a URL onto it and it asks you which tag(s) you want to apply (in a 
tag-cloud popup, for instance), the result is then saved to Nepomuk and it'll show up 
in other applications that work with tags (i.e. a picture in Gwenview's tag-view).

> the big requirements we have in plasma is the ability to have a named
> "context" that can be associated with locations, people, documents ...

projets, tasks, time periods, ... :)

> context+location will likely end up being a pretty important pairing to at
> least some of our users since if i'm doing work related activities, what
> that looks like when i'm in the office vs in an airport is pretty different
> (e.g. vpn access, NDA'd documents, etc).
>
> in any case, if the nepomuk team could give us some pointers to where the
> ontology for this ended up, that'd be great.

Yes, it would be good to know more practical things, i.e. how this would look like in 
a Nepomuk-enabled application, what are possible ontologies that could be used, how 
do those ontologies look like, etc. 
From what I've seen when I played around with Nepomuk code, it looked like a nice and 
easy API, so I guess it's time to do something really useful with it.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090802/b1a10510/attachment.sig