On Monday 13 September 2010 10:53:36 Sebastian Trüg wrote: > Hi Matthias, > > thanks for putting the problem out there. > So far most of the information we have on files are legacy key/value > pairs with literal values like file size, image dimensions, title, and > so on. And even resource values like artists and albums could simply be > handled by displaying the corresponding resource's label. But as more > and more elaborate information enters Nepomuk this solution does not > work anymore. > The first time this happened (download locations) I create an ugly hack > which queries the download event for details like the download and the > referrer URL. This is of course a bad solution since we cannot create a > special case for all types of information we could encounter. > Thus, the idea is in fact to create a rule system. > > Such a rule system would consist of rules (who would have thought) which > convert a property into something displayable. As input it needs more > than just the value which is obvious. But I think it even needs more > than the property and the value since we have rather generic properties > like "creator" which are used in all kinds of situations. A typical > example are audio files where "creator" is used for the artist. Thus, > the rule needs to know the type of the subject in order to decide > whether to use "artist" or "author" or the generic "creator". > Thus, one rule needs at least the following input: > * The resource type (maybe even a list of types of the resource > itself?) > * The property > * The value > Based on this information the rule should be able to > * Add fixed text (maybe even rich-text formatted) > * Add links (to other resources and web URLs and even to queries) > [* Define actions?] > > I already tried this at least once. And in playground[1] you can find a > very bad first version of such a rule system. > So we need to come up with a much better system and syntax as the one I > drafted in playground. An idea is to use XML since it is easy to parse. > But writing and reading it can be a pain. > > Thus - ideas and comments please.
How about using one of scripting languages that kde can embed to actually do formatting and querying? Or is this going to be a performance nightmare? > [1] > http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat > ion/ and > http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat > ion/sample.rules?view=markup > > On 09/10/2010 11:50 PM, Matthias Fuchs wrote: > > Hi, > > > > I discussed a problem on irc and sebastian trueg mentioned that I should > > also write on it here. > > > > The problem is that there is no graphical representation of information > > that is interconnected. > > > > Take NFO::hashAlgorithm and NFO::hashValue as example. At the moment both > > are displayed in their own line and there is no visual link between > > them. Now if more algorithms and values were added it would get a little > > complicated for the user to associate the correct values with the > > algorithms. > > > > Ideally both would be displayed in one line, e.g. "SHA1 hash: > > 325e69d24514f7b26834a93ad260f3024127714b". > > > > > > Though this solution would most likely not apply to other information > > that should also be graphically grouped. Sebastian mentioned that he > > tried to create a solution for this once with having an xml file and > > another time with a custom format. > > > > So as he put it there is a need for a rule system to graphically > > represent the information. -- Evgeny _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
