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.
the big requirements we have in plasma is the ability to have a named
"context" that can be associated with locations, people, documents ...
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.
> So, what is the best way to do this?
here is a document that Luca Beltrame had started on:
http://docs.google.com/View?id=dcp4ww55_76gdhhk6ch
there may be useful things in there as well.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
