Actually I only meant the rule thing, not the whole resource-visualization plugin stuff. So in the end the goal is "only" to come up with a way to describe the points I outlined using XML or some other format. Then we need to parse that and implement a generator which should be fairly easy. Thus, all in all the problematic part is the rule format.
Cheers, Sebastian On 09/14/2010 05:08 PM, Matthias Fuchs wrote: > Looks really complex, I guess this is over my knowledge of most Nepomuk > Ontologies -- thus also what could be an requirement. > > You mentioned one of your tries. Do you think that future tries would involve > less code, e.g. looking at the bibtex example? > Because that example really outlines that either using C++ is not that useful > for this task -- too code needed, e.g. subclassing -- or maybe a system > depending on something different should be used. > > In that case I am afraid that I'm not really useful in drafting such system > that would really work and be efficient. I guess I could implement support > for > some ontologies once it is drafted but I suppose this would be the easiest > part anyway. > > Am Montag 13 September 2010, 09:53:36 schrieb Sebastian Trüg: >> 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. >> >> Cheers, >> Sebastian >> >> [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. >>> >>> >>> >>> PS.: Grouping information graphically would also the advantage of making >>> information easier hideable/collapsible. >>> PPS.: I created a bug report for this >>> https://bugs.kde.org/show_bug.cgi?id=250819 >>> >>> _______________________________________________ >>> Nepomuk mailing list >>> [email protected] >>> https://mail.kde.org/mailman/listinfo/nepomuk >> >> _______________________________________________ >> Nepomuk mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/nepomuk > > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
