The Context framework would provide the access to what the current context is (by name), a list of all currently known contexts (again, by names), etc, thus hiding any Nepomuk details from its APIs.
We plan to take this approach because there are some parts of the context which probably are not suitable to Nepomuk. an example of this is the current location of the system/user; we'd probably use geoclue for this, and will change orthogonally to the user's current activity (or project). e.g. just because i am on a train from France to Germany, it doesn't mean what i'm working on magically changes when i cross the border ;)
things can certainly be "geotagged" using Nepomuk, of course, but i want to give easy access to what the current location is separate from that since that is hardly the only use for it (the clock, for instance, may want to change timezones automatically) and things should not need to speak directly to geoclue for that information IMHO.
> if location is going to end up being broadcast by nepomuk, that implies > making nepomuk a "front end" to things like geoclue, does it not?
I don't think the location should be broadcasted by Nepomuk. I think that is a different source which should be kept separate. We could map the current location into Nepomuk though, to make things simpler for queries.