Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 10:38 AM, Ivan Čukić wrote:
by this score and combine that with the restrictions you list which can
all be expressed using a single Term.
Ok
kstandardactions) and add the method and the enum to the
Nepomuk::Query::StandardQueries namespace.
Yet another Ok :)
please check the attached header and tell me if the API is acceptable. I
did not define special standard queries for fav res of type X since
that ca easily be done via:
Query q = standardQuery(MostImportantResourcesQuery);
q.setTerm( ResourceTypeTerm(type) q.term() );
Also I am not quite sure what for an application would mean in a query...
- only resources that have an event related to the app
- only resources of supported mimetype or resource type
both do not really seem useful though as IMHO there would be too many
false-negatives.
Cheers,
Sebastian
/*
This file is part of the Nepomuk KDE project.
Copyright (C) 2010 Sebastian Trueg tr...@kde.org
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) version 3, or any
later version accepted by the membership of KDE e.V. (or its
successor approved by the membership of KDE e.V.), which shall
act as a proxy defined in Section 6 of version 3 of the license.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library. If not, see http://www.gnu.org/licenses/.
*/
#ifndef _NEPOMUK_STANDARD_QUERIES_H_
#define _NEPOMUK_STANDARD_QUERIES_H_
#include nepomukquery_export.h
#include QtCore/QDate
namespace Nepomuk {
namespace Query {
class Query;
/**
* A set of predefined queries that can be created vis standardQuery().
*
* \since 4.6
*/
enum StandardQuery {
/**
* Creates a query that returns all files sorted by descending modification date.
*/
LastModifiedFilesQuery,
/**
* Creates a query that returns all resources sorted by descending score (as calculated
* by the DataMaintenanceService)
*/
MostImportantResourcesQuery,
/**
* Creates a query that returns all files with a usage count of 0
* sorted by descending modification date.
*/
NeverOpenedFilesQuery
};
/**
* Modificators to influence the behaviour of dateRangeQuery().
*
* \since 4.6
*/
enum DateRangeFlag {
/**
* Query for the modification date (nie:lastModified)
*/
ModificationDate = 0x1,
/**
* Query for the content creation date (nie:contentCreated)
*/
ContentDate = 0x2,
/**
* Query for usage events referring to the resource.
*/
UsageDate = 0x4,
/**
* Query for all possible dates.
*/
AllDates = ModificationDate|ContentDate|UsageDate
};
Q_DECLARE_FLAGS( DateRangeFlags, DateRangeFlag )
/**
* Create a standard query as defined by \p query.
* To get a query that only returns files (this is already true for some of the predefined queries)
* use something like the following:
*
* \code
* Query::FileQuery query = Query::standardQuery( Query::LastModifiedFilesQuery );
* \endcode
*
* \since 4.6
*/
NEPOMUK_QUERY_EXPORT Query standardQuery( StandardQuery query );
/**
* Create a query that returns resources/files that have been modified/accessed in the range
* from \p start to \p end. The flags specified in \p dateFlags can be used to influence the
* type of dates that are queried.
*
* \since 4.6
*/
NEPOMUK_QUERY_EXPORT Query dateRangeQuery( const QDate start, const QDate end, DateRangeFlags dateFlags = AllDates );
}
}
Q_DECLARE_OPERATOR_FOR_FLAGS( Nepomuk::Query::DateRangeFlags )
#endif
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
- only resources that have an event related to the app ^^ to be used instead of the 'recently opened documents' both do not really seem useful though as IMHO there would be too many false-negatives. If the app uses this system to notify us of open/modify/close events, there wouldn't be any false-negatives. If not, then it can't really expect the above to work. please check the attached header and tell me if the API is acceptable. I did not define special standard queries for fav res of type X since that ca easily be done via: How do we get MostImportantResources for a specific activity? Intersecting the results of MIR and resources-related-to-DE-related-to-activity? Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 08/03/2010 08:41 PM, Ivan Čukić wrote:
I know you're going to hate me, but I have to - recent documents in
the app should be restricted to the activity as well.
Would it work if the term provided would be ResTerm('activity')
ResTerm('application')
Currently this
Comparison( xxx, ResTerm(a) ResTerm(b) )
would result in a broken query.
I could add support for that in the standardQuery call though. But then
again what did we decide? Will the activity be linked to the graph or
the event? I think it was the former in which case we need two different
terms anyway which means we could use the approach of combining standard
queries like so:
standardQuery( ResourcesForActivityQuery, ResourceTerm(activity) )
standardQuery( ResourcesForApplicationQuery, ResourceTerm(app) )
standardQuery( MostImportantResourcesQuery )
IMO, the enum approach provides versatility on one level, but can be
rather restricting if we don't cover most of the use-cases at the
beginning.
how so? and which approach is better? Adding dedicated methods for all
cases has no advantage since that can be done at any point in time once
we reach the boundaries of the enum approach.
But if you don't like the enum - we can also use dedicated methods. I
just think a combination to keep the number of methods small makes sense.
And I also added a hint as to how standard queries can be combined to
I didn't see the hint here
it is in the docs for standardQuery.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
Here's the proposal for the new scoring formula. If you are not able to read .tex or .dvi, you can get the .pdf from here: http://poincare.math.rs/~ivan/files/other/scoring.pdf --- Not related to the above part: We need unique rating for every activity. Any ideas about how to do that in a simple way? Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun scoring.tex Description: TeX document scoring.dvi Description: TeX dvi file ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/22/2010 01:25 PM, Ivan Čukić wrote: 1. Methods that return Nepomuk::Query::Query objects For the time being we could go for this one. We could always add (4.) if needed (if we or somebody else finds it useful to have) later. OK, then how one method combined with an enumeration? Maybe in a dedicated namespace or even in the Nepomuk::Query namespace as a generic access to typical queries used very often. Cheers, Sebastian Eventually, we could even turn this into a data model or something like we have for files. Cheerio, Ivan p.s. You've forgotten to cross-post :) original message: agreed. One question that remains: How do we do that? We have the following possibilities: 1. Methods that return Nepomuk::Query::Query objects 2. Methods that return a Nepomuk::Query::QueryServiceClient (weird) 3. Methods that return a list of results (blocking and thus, no good) 4. Methods that return a custom class which emits the results one by one 4.1. emit results as Nepomuk::Query::Result objects 4.2. emit results as custom objects I like 1 the best - mostly because I find working with Query object so convenient. 2 and 3 are not great and 4 is the most work. The question is whether it is worth the trouble. To answer that I suppose we need some use cases. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
Well, first we need to see what do we want exactly. From my point of view: - fav* resources for an application (to be shown inside the app itself) - fav resources independent on application (to be shown in activity kio) - fav applications (for launchers) - fav resources of a certain type (file, directory, web address, contact...)** * fav as in automatically sorted by access times and access count ** this one seems least important and all of the above should be activity (or something more generic) dependent. Maybe in a dedicated namespace or even in the Nepomuk::Query namespace as a generic access to typical queries used very often. Both are fine with me. Maybe those are too specific to be in Nepomuk::Query, but that's essentially your call. Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 09:36 AM, Ivan Čukić wrote: Well, first we need to see what do we want exactly. From my point of view: - fav* resources for an application (to be shown inside the app itself) - fav resources independent on application (to be shown in activity kio) - fav applications (for launchers) - fav resources of a certain type (file, directory, web address, contact...)** * fav as in automatically sorted by access times and access count ** this one seems least important and all of the above should be activity (or something more generic) dependent. This is all very simple. The only thing we need to run is my scoring service and then it is just a matter of have the case query which sorts by this score and combine that with the restrictions you list which can all be expressed using a single Term. Maybe in a dedicated namespace or even in the Nepomuk::Query namespace as a generic access to typical queries used very often. Both are fine with me. Maybe those are too specific to be in Nepomuk::Query, but that's essentially your call. You might be right here. It might be too specific. On the other hand developers would probably search the query API for standard queries. So we could also introduce a file standardqueries.h (very much like kstandardactions) and add the method and the enum to the Nepomuk::Query::StandardQueries namespace. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
by this score and combine that with the restrictions you list which can all be expressed using a single Term. Ok kstandardactions) and add the method and the enum to the Nepomuk::Query::StandardQueries namespace. Yet another Ok :) BTW, how the scoring works? (as in which parameters are involved, and with what weight) Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 10:38 AM, Ivan Čukić wrote: by this score and combine that with the restrictions you list which can all be expressed using a single Term. Ok kstandardactions) and add the method and the enum to the Nepomuk::Query::StandardQueries namespace. Yet another Ok :) BTW, how the scoring works? (as in which parameters are involved, and with what weight) Currently I use an exponential function to weight the usage events. In addition the last modification has a slightly higher weight. Then the rating and the file type are taken into account. I tuned the values randomly so they show the desired behavior for my files. This could of course use further tuning. The algorithm (rather simple) can also be found in the mentioned playground code. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
For me that always was nepomuk queries but maybe it would be nice to have convenience methods for some special cases. The problem with this approach is that people would need to know how we save the data so that they could write queries. Most of the time, for simple things, this would be too much for a not-interested-in-nepomuk devs to do. Other thing is that we'd get a lot of code duplication - just imagine that everybody implements its own query and logic for the File Recent Documents menu. And the third reason for the convenience methods - we can later modify the inner-stuff without changing the apps. Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
1. Methods that return Nepomuk::Query::Query objects For the time being we could go for this one. We could always add (4.) if needed (if we or somebody else finds it useful to have) later. Eventually, we could even turn this into a data model or something like we have for files. Cheerio, Ivan p.s. You've forgotten to cross-post :) original message: agreed. One question that remains: How do we do that? We have the following possibilities: 1. Methods that return Nepomuk::Query::Query objects 2. Methods that return a Nepomuk::Query::QueryServiceClient (weird) 3. Methods that return a list of results (blocking and thus, no good) 4. Methods that return a custom class which emits the results one by one 4.1. emit results as Nepomuk::Query::Result objects 4.2. emit results as custom objects I like 1 the best - mostly because I find working with Query object so convenient. 2 and 3 are not great and 4 is the most work. The question is whether it is worth the trouble. To answer that I suppose we need some use cases. -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
I'm updating the d-bus service and merging the currently separated nepomuk service into it. (and the playground thingie) Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
I think we forgot one thing to discuss - API for data retrieval. We have the API for apps to tell us what they are doing, but we don't have the API for the apps to get, for example, a list of recent/popular/high-rated docs Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
