[Nepomuk] Re: [KFileMetaDataWidget] Grouping of interconnected information
Roman Evstifeev
someuniquename at gmail.com
Sun Oct 3 16:24:04 CEST 2010
2010/9/28 Leo Sauermann <leo.sauermann at gnowsis.com>:
> uh, why invent something new when this has been implemented in "fresnel"
> before?
>
> there is a standard for such configuration files:
> http://www.w3.org/2005/04/fresnel-info/
>
> I would try to base my approach on fresnel and extensions, for example a
> scripting language...
>
> Here an example we used in nepomuk for showing/hiding properties
> @prefix :
> <http://www.semanticdesktop.org/ontologies/2007/11/01/pimo-fresnel#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix XMLSchema: <http://www.w3.org/2001/XMLSchema#> .
> @prefix nao: <http://www.semanticdesktop.org/ontologies/2007/08/15/nao#> .
> @prefix ncal: <http://www.semanticdesktop.org/ontologies/2007/04/02/ncal#> .
> @prefix nco: <http://www.semanticdesktop.org/ontologies/2007/03/22/nco#> .
> @prefix nfo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#> .
> @prefix nmo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#> .
> @prefix nie: <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#> .
> @prefix nrl: <http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#> .
> @prefix pimo: <http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix wgs84_pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
> @prefix fresnel: <http://www.w3.org/2004/09/fresnel#> .
> @prefix fredit: <http://www.semanticdesktop.org/ont/2008/05/23/fredit#> .
>
> # our extensions
>
> # we filter beforehand showing only
> # sub-properties of objectProperty and datatypeProperty
>
> # a lens applying to all instances of pimo:Thing
> :ThingLens rdf:type fresnel:Lens ;
> fresnel:classLensDomain pimo:Thing;
> fresnel:purpose fresnel:defaultLens;
> fresnel:showProperties (
> pimo:isRelated
> pimo:hasTopic
> pimo:isTopicOf
> pimo:hasPart
> pimo:partOf
> fresnel:allProperties
> pimo:groundingOccurrence
> pimo:referencingOccurrence
> )
> .
Isn't this shorthand for RDF collection, which is discouraged in nepomuk?
Moreover this collection will use blank nodes, which is also
discouraged in nepomuk.
> :PropertyLens rdf:type fresnel:Lens ;
> fresnel:classLensDomain rdf:Property;
> fresnel:showProperties (
> rdfs:label
> rdfs:comment
> rdfs:domain
> rdfs:range
> rdfs:subPropertyOf
> nrl:inverseProperty
> fresnel:allProperties
> )
> .
>
> :ClassLens rdf:type fresnel:Lens ;
> fresnel:classLensDomain rdfs:Class;
> fresnel:showProperties (
> rdfs:label
> rdfs:description
> rdfs:subClassOf
> fresnel:allProperties
> )
> .
>
> :naoDescriptionFormat a fresnel:Format;
> fredit:valueWidget [ a fredit:TextAreaWidget ];
> fresnel:propertyFormatDomain nao:description .
>
> # a Purpose to show metadata
> :MetadataLens a fresnel:Purpose;
> rdfs:comment "Show the metadata of a something".
>
> # a Purpose to show all properties including relating properties
> :FullLens a fresnel:Purpose;
> rdfs:comment "Show the data and relations of something".
>
>
> # a lens to show the metadata of a thing
> :ThingMetadataLens rdf:type fresnel:Lens ;
> fresnel:classLensDomain pimo:Thing;
> fresnel:purpose :MetadataLens;
> fresnel:showProperties (
> rdfs:comment
> nao:created
> nao:lastModified
> nao:creator
> pimo:groupOwner
> pimo:isDefinedBy
> )
> .
>
> # A lens to show information elements and things in full
> :GenericLens rdf:type fresnel:Lens ;
> fresnel:classLensDomain nie:InformationElement, pimo:Thing;
> fresnel:purpose :FullLens;
> fresnel:showProperties (
> rdfs:label
> nie:subject
> nie:title
> nfo:fileName
> rdf:type
> rdfs:comment
> nie:description
> pimo:wikiText
> nie:comment
> nao:created
> nao:lastModified
>
> nao:creator
> nco:publisher
> nco:creator
> nie:contentSize
>
> pimo:groupOwner
> pimo:isDefinedBy
>
> nie:identifier
> nie:isStoredAs
> nie:keyword
> nie:relatedTo
>
> fresnel:allProperties
> # plaintextcontent AFTER allproperties to have place
> nie:plainTextContent
> nmo:plainTextMessageContent
> nie:dataSource
> nfo:belongsToContainer
> );
> fresnel:hideProperties (
> nao:created
> nao:lastModified
> nie:contentCreated
> nie:contentLastModified
> nie:generator
> nie:generatorOption
> nie:hasLogicalPart
> nie:hasPart
> nie:informationElementDate
> nie:isLogicalPartOf
> nie:language
> nie:legal
> nie:links
> nie:rootElementOf
> nie:mimeType
> nie:version
> nfo:fileLastModified
> nie:interpretedAs
> )
> .
>
>
>
> It was Sebastian Trueg who said at the right time 16.09.2010 10:49 the
> following words:
>
> I took some time on the train and here is one proposal that we could
> discuss:
>
> I started with the following issues that the display rules need to address:
> input:
> * 1 resource or resource type
> * 1 or more properties (using multiple properties allows to merge
> them like with image dimensions or to combine information that
> matches into a readable expression)
> * value for each property (as Variant, ie. lists are supported)
>
> output:
> * a Qt-style richt-text string with optional links (queries or other
> local or remote URLs)
> * how about pixmaps? icons should be easy to integrate...
> * how about a template system which allows to replace variables with
> values or query results. the latter would require a tool for query
> generation
>
> rule registration:
> * supported type
> * supported property
> * optional: supported value type (in case of non-literal ranges)
>
> rule selection:
> * be greedy
> * try to find the best matching rule via type and properties that are
> as specialized as posssible
>
> The I drafted one random example trying to include the full syntax:
> <rule>
> <resourceType uri=foobar />
> <resourceType uri=xyz />
> <propertyGroup>
> <property name=p1 uri=abc />
> <property name=p2 uri=def />
> </propertyGroup>
> <variable name="a" type=string>
> <propertyValue property=p1 />
> </variable>
> <variable name="b" type=uri>
> <propertyValue property=p2 />
> </variable>
> <query name="myquery">
> <sparql>select ?r where { ?r nao:hasTag <%r> . }</sparql>
> </query>
> <variable name="c" type=domain>
> <binding query="myquery" bindingName="r" />
> </variable>
> <query name="queryThatDependsOnAnotherVariable">
> <sparql>select ?r where { ?r <foobar> <%c> . }</sparql>
> </query>
> <query name="q1" queryFiles="true" queryFolders="true" limit="0"
> offset="0" fullTextScoring="false" fullTextScoringOrder="asc"
> flags="">
> <comparison
> property="http://www.semanticdesktop.org/ontologies/2007/08/15/nao#hasTag"
> comparator="=" inverted="false">
> <resource uri="%r"/>
> </comparison>
> </query>
> <variable name="d">
> <binding query="q1" bindingIndex=0 />
> </variable>
> <template>Something blabla <a href="%b">%a</a></template>
> <icon name="nepomuk" />
> </rule>
>
> The generic fallback rule (the absence of resourceType and property uri
> mean: no restriction, i.e. all apply):
> <rule>
> <propertyGroup>
> <property name=p1 />
> </propertyGroup>
> <variable name="a"><propertyLabel property=p1 /></variable>
> <variable name="b"><propertyValue property=p1 /></variable>
> <template>%a: %b</template>
> </rule>
>
> Example 1: download location
> <rule name="download location">
> <resourceType uri=nfo:FileDataObject />
> <propertyGroup>
> <property uri=ndo:copiedFrom name="copiedFrom" />
> </propertyGroup>
> <query name="referrerQuery"><sparql>select ?ref where { ?dl a
> ndo:DownloadEvent . ?dl nuao:involces <%r> . ?dl ndo:referrer ?ref . }
> limit 1</sparql></query>
> <variable name=refUrl type=uri>
> <binding query="referrerQuery" bindingName="ref" />
> </variable>
> <variable name=refUrl type=label>
> <binding query="referrerQuery" bindingName="ref" />
> </variable>
> <template i10l-context="blablabla blabla">Downloaded from <a
> href="%refUrl">%label</a></template>
> <template lang="de">Geladen von <a
> href="%refUrl">%label</a></template>
> </rule>
>
>
> A few facts:
> * There is one special variable: %r which is always replaced by the
> resource's URI.
> * With a sparql or desktop query only the first binding is used.
> * A variable can have an optional type. This is mostly useful to get
> the genericLabel for resources or specifically select the URI
> - uri - the resource URI - will be ignored for literal bindings
> By default all values are converted into strings creating pretty
> values for dates and times and number values. TODO: let
> Resosurce:genericLabel() extract the domain from http URLs?
> * Use %% to include a percent character in the template.
> * If a variable has no value (empty query results) the rule fails and
> then next is used
> * What is a PropertyGroup? The idea is to support multiple properties
> in a single rule. But since a rule can also "merge" several
> properties' values we need a distinction between a group of
> properties that can be "merged" and properties that can all be
> handled by the rule. As an example a rule may provide the same
> formatting for property A and B which would be realized as 2
> propertyGroups. Another rule would take two properties as input and
> put them in a single template. This would be done using a single
> propertyGroup.
> * The syntax for the queries is the same as created and parsed by
> Query::toString() and Query::fromString(). The only exception is the
> additional "name" attribute.
> * Do we need if/then/else constructs? Answer: even if we do we can
> perfectly introduce them later on as variable constructs which allow
> to choose between other variables or constants.
>
> Open Questions:
> * How do we create query links? By specifying the nepomuksearch:/ URL
> directly? That would make dynamic queries harder. But how would we do
> dynamic queries anyway?
> * Does the "icon" make sense? It would be displayed in front of the
> label or something.
> * We could use some sort of rule weight to prioritize them in addition
> to the automatic priorization mentioned above
> * Why XML and not RDF: 1. XML is simpler in this case. 2. I don't see
> the advantage of having the rules in the database (I might be
> mistaken though). 3. FIXME: check the RDF dialect again which allows
> to describe something like this but AFAIK without queries. ON THE
> OTHER HAND: If we had an RDF dialect we could 1. store rules with the
> ontologies, 2. query appropriate rules via SPARQL, 3. have a database
> that supports the formatting rule through a sparql extension...
>
> Well, this is my braindump. Now please ask, comment, and discuss away. :)
>
> Cheers,
> Sebastian
>
> On 09/14/2010 05:19 PM, Sebastian Trüg wrote:
>
> 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
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
>
> --
> Leo Sauermann, Dr.
> CEO and Founder
>
> mail: leo.sauermann at gnowsis.com
> mobile: +43 6991 gnowsis
> http://www.gnowsis.com
>
> helping people remember,
>
> so join our newsletter
> http://www.gnowsis.com/about/content/newsletter
> ____________________________________________________
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
>
More information about the Nepomuk
mailing list