[Nepomuk] [KFileMetaDataWidget] Grouping of interconnected information

[Evgeny Egorochkin]

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