User talk:Harikrishna/Architecture/design decisions

From KDE TechBase

A separate framework

Though the initial discussions were towards using a Nepomuk::Service for this, the current discussions side more with creating this as a separate framework.

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.

Hide Nepomuk backend from Dikku's APIs

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.

this will be critical for usage in plasma widgets which tend towards using simplistic APIs. Nepomuk is awesome, but we need to hide it a bit in this case i think to make the idea of Context as approachable as possible so it gets widely used.

Keeping number of context types low

Aaron Seigo says:
i begin to grow concerned that we'll end up with N different active contexts and it will become rapidly unwieldly for the user and/or application developer. i really think that keeping it as simple as possible is critical to getting wide adoption and usage.

we can come up with something that models the Real World perfectly, and then probably nobody will actually use it because it will be too complex.

i'm looking for some simple abstractions that map to real world use scenarios here. those include things like:

  • "I am currently working on my book, but will be working on my programming project in a few hours."
  • "I'd like to get widgets relevant to the train station I'm lost in."

these are things that users find useful (some of them are already exposed in Plasma today and being used successfully!).


Times in contexts

Sebastian Trüg says:
> we should put start times on all
> Contexts (the creation time is an implied start time) and make end times
> optional, that way we can timeline all of them.

all resources have a creation time. But I think the start time of a task or project can differ from that. So I would still vote for start and end times assigned to a subclass of Context.

> yeah, the more i think about the time aspect of things, the more i think we
> shouldn't make it optional.

Conceptionally a context does not have an end time so it does not make much sense IMHO.

> personally i'd like at least a start time with ActivityContext as well so
> they can be put onto a timeline.

all resources have a creation time. So that's covered I think. But as I mentioned earlier, projects can have an additional different starting time.

Sven Schwarz says:
A "start time" is fine, but an "end time" will be seldomly used and if it is used then what does it tell us? What I do myself, and what I suggest to do here, too, is to have a set of ACTIVATION INTERVALS. I know, that this will yield scalability problems, but these could and should be overcome. Don't we want to see and search(!) really ALL the activations of a context (on a timeline for instance)? I do think so!

Hari krishna says:
It is always nice to have the computer remember things like the project was last deactivated on 1/1/1900, but wouldn't it be better if the user can explicitly say the project has been closed so that it can be archived. I think both activation intervals and endTime would be needed. Remember to always give control to the user when he wants it, else he is likely to get angry ;)

Reuse PIMO when applicable

Leo Sauermann says:
in NEPOMUK-java we decided not to include things in context that are modelled in the user's personal information model (PIMO) anyway. For example, if you are during a meeting, and the meeting has several attendees, then the attendees may not be explicitly mentioned in context, because they are part of the PIMO anyway.

It would be very good to model geographic location and other relations, such as "persons in the same room", but I would rather reuse PIMO ontology here PIMO defines a class for "location", and for "event" and "meeting", and for "room".

Define borders of Context

Leo Sauermann says:
This is important: context has no borders. If we don't define them, everybody new to the discussion will say "oh, but clicking on a mail is context, so the mail is context, so the person sending the mail is context, so the other mails sent by the same person are context, so european policits in 1890 are context..."

Hence, "work" context (notice the prefix work! it helped us a lot in previous discussions) only models

  • which of the many resources is in the attention of the user now,
  • but not what resources there exist (we got NIE/strigi/xesam for that) or how they relate (this is PIMO ontology)

We experienced this as a good tradeoff: you have all metadata about the world of the user stored in Soprano anyway, you don't have to represent them again for context - just reference them via URI.

We could, and this would be helpful, add classes and/or properties to the UserWorkContext that we can capture current Event, current Location.

An event then has attendees, and a location, and we can assume that the attendees are together with us in the same location, etc.

The current location/event could be modelled as property of the UserContext object or the ShortTermContext. (see the UserWorkContext ontology)

Retrieved from "https://techbase.kde.org/index.php?title=User_talk:Harikrishna/Architecture/design_decisions&oldid=32420"