<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
uh, why invent something new when this has been implemented in
"fresnel" before? <br>
<br>
there is a standard for such configuration files:<br>
<a class="moz-txt-link-freetext" href="http://www.w3.org/2005/04/fresnel-info/">http://www.w3.org/2005/04/fresnel-info/</a><br>
<br>
I would try to base my approach on fresnel and extensions, for
example a scripting language... <br>
<br>
Here an example we used in nepomuk for showing/hiding properties<br>
@prefix :
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo-fresnel#"><http://www.semanticdesktop.org/ontologies/2007/11/01/pimo-fresnel#></a>
.<br>
@prefix rdfs: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/01/rdf-schema#"><http://www.w3.org/2000/01/rdf-schema#></a> .<br>
@prefix XMLSchema: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema#"><http://www.w3.org/2001/XMLSchema#></a> .<br>
@prefix nao:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao#"><http://www.semanticdesktop.org/ontologies/2007/08/15/nao#></a> .<br>
@prefix ncal:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/04/02/ncal#"><http://www.semanticdesktop.org/ontologies/2007/04/02/ncal#></a> .<br>
@prefix nco:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/03/22/nco#"><http://www.semanticdesktop.org/ontologies/2007/03/22/nco#></a> .<br>
@prefix nfo:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#"><http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#></a> .<br>
@prefix nmo:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#"><http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#></a> .<br>
@prefix nie:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/01/19/nie#"><http://www.semanticdesktop.org/ontologies/2007/01/19/nie#></a> .<br>
@prefix nrl:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#"><http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#></a> .<br>
@prefix pimo:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#"><http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#></a> .<br>
@prefix rdf: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><http://www.w3.org/1999/02/22-rdf-syntax-ns#></a> .<br>
@prefix wgs84_pos: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2003/01/geo/wgs84_pos#"><http://www.w3.org/2003/01/geo/wgs84_pos#></a>
.<br>
@prefix fresnel: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2004/09/fresnel#"><http://www.w3.org/2004/09/fresnel#></a> .<br>
@prefix fredit:
<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ont/2008/05/23/fredit#"><http://www.semanticdesktop.org/ont/2008/05/23/fredit#></a> .<br>
<br>
# our extensions<br>
<br>
# we filter beforehand showing only<br>
# sub-properties of objectProperty and datatypeProperty<br>
<br>
# a lens applying to all instances of pimo:Thing<br>
:ThingLens rdf:type fresnel:Lens ;<br>
fresnel:classLensDomain pimo:Thing;<br>
fresnel:purpose fresnel:defaultLens;<br>
fresnel:showProperties ( <br>
pimo:isRelated<br>
pimo:hasTopic<br>
pimo:isTopicOf<br>
pimo:hasPart<br>
pimo:partOf<br>
fresnel:allProperties<br>
pimo:groundingOccurrence<br>
pimo:referencingOccurrence <br>
)<br>
.<br>
<br>
:PropertyLens rdf:type fresnel:Lens ;<br>
fresnel:classLensDomain rdf:Property;<br>
fresnel:showProperties ( <br>
rdfs:label<br>
rdfs:comment<br>
rdfs:domain<br>
rdfs:range<br>
rdfs:subPropertyOf<br>
nrl:inverseProperty<br>
fresnel:allProperties<br>
)<br>
.<br>
<br>
:ClassLens rdf:type fresnel:Lens ;<br>
fresnel:classLensDomain rdfs:Class;<br>
fresnel:showProperties ( <br>
rdfs:label<br>
rdfs:description<br>
rdfs:subClassOf<br>
fresnel:allProperties<br>
)<br>
.<br>
<br>
:naoDescriptionFormat a fresnel:Format;<br>
fredit:valueWidget [ a fredit:TextAreaWidget ];<br>
fresnel:propertyFormatDomain nao:description .<br>
<br>
# a Purpose to show metadata<br>
:MetadataLens a fresnel:Purpose;<br>
rdfs:comment "Show the metadata of a something".<br>
<br>
# a Purpose to show all properties including relating properties<br>
:FullLens a fresnel:Purpose;<br>
rdfs:comment "Show the data and relations of something".<br>
<br>
<br>
# a lens to show the metadata of a thing<br>
:ThingMetadataLens rdf:type fresnel:Lens ;<br>
fresnel:classLensDomain pimo:Thing;<br>
fresnel:purpose :MetadataLens;<br>
fresnel:showProperties ( <br>
rdfs:comment<br>
nao:created<br>
nao:lastModified<br>
nao:creator<br>
pimo:groupOwner<br>
pimo:isDefinedBy<br>
)<br>
.<br>
<br>
# A lens to show information elements and things in full<br>
:GenericLens rdf:type fresnel:Lens ;<br>
fresnel:classLensDomain nie:InformationElement, pimo:Thing;<br>
fresnel:purpose :FullLens;<br>
fresnel:showProperties ( <br>
rdfs:label<br>
nie:subject<br>
nie:title<br>
nfo:fileName<br>
rdf:type<br>
rdfs:comment<br>
nie:description<br>
pimo:wikiText<br>
nie:comment<br>
nao:created<br>
nao:lastModified<br>
<br>
nao:creator<br>
nco:publisher<br>
nco:creator<br>
nie:contentSize<br>
<br>
pimo:groupOwner<br>
pimo:isDefinedBy<br>
<br>
nie:identifier<br>
nie:isStoredAs<br>
nie:keyword<br>
nie:relatedTo<br>
<br>
fresnel:allProperties<br>
# plaintextcontent AFTER allproperties to have place<br>
nie:plainTextContent <br>
nmo:plainTextMessageContent<br>
nie:dataSource<br>
nfo:belongsToContainer<br>
);<br>
fresnel:hideProperties (<br>
nao:created<br>
nao:lastModified<br>
nie:contentCreated<br>
nie:contentLastModified<br>
nie:generator<br>
nie:generatorOption<br>
nie:hasLogicalPart<br>
nie:hasPart<br>
nie:informationElementDate<br>
nie:isLogicalPartOf<br>
nie:language<br>
nie:legal<br>
nie:links<br>
nie:rootElementOf<br>
nie:mimeType <br>
nie:version<br>
nfo:fileLastModified<br>
nie:interpretedAs<br>
)<br>
.<br>
<br>
<br>
<br>
It was Sebastian Trueg who said at the right time 16.09.2010 10:49
the following words:
<blockquote cite="mid:4C91DA17.3090901@kde.org" type="cite">
<pre wrap="">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=<a class="moz-txt-link-rfc2396E" href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao#hasTag">"http://www.semanticdesktop.org/ontologies/2007/08/15/nao#hasTag"</a>
comparator="=" inverted="false">
<resource uri="%r"/>
</comparison>
</query>
<variable name="d">
<binding query="q1" bindingIndex=0 />
</variable>
<template>Something blabla &lt;a href="%b"&gt;%a&lt;/a&gt;</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 &lt;a
href="%refUrl"&gt;%label&lt;/a&gt;</template>
<template lang="de">Geladen von &lt;a
href="%refUrl"&gt;%label&lt;/a&gt;</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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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]
<a class="moz-txt-link-freetext" href="http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat">http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat</a>
ion/ and
<a class="moz-txt-link-freetext" href="http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat">http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat</a>
ion/sample.rules?view=markup
On 09/10/2010 11:50 PM, Matthias Fuchs wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="https://bugs.kde.org/show_bug.cgi?id=250819">https://bugs.kde.org/show_bug.cgi?id=250819</a>
_______________________________________________
Nepomuk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/nepomuk">https://mail.kde.org/mailman/listinfo/nepomuk</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Nepomuk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/nepomuk">https://mail.kde.org/mailman/listinfo/nepomuk</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Nepomuk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/nepomuk">https://mail.kde.org/mailman/listinfo/nepomuk</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Nepomuk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/nepomuk">https://mail.kde.org/mailman/listinfo/nepomuk</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Nepomuk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/nepomuk">https://mail.kde.org/mailman/listinfo/nepomuk</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Leo Sauermann, Dr.
CEO and Founder
mail: <a class="moz-txt-link-abbreviated" href="mailto:leo.sauermann@gnowsis.com">leo.sauermann@gnowsis.com</a>
mobile: +43 6991 gnowsis
<a class="moz-txt-link-freetext" href="http://www.gnowsis.com">http://www.gnowsis.com</a>
helping people remember,
so join our newsletter
<a class="moz-txt-link-freetext" href="http://www.gnowsis.com/about/content/newsletter">http://www.gnowsis.com/about/content/newsletter</a>
____________________________________________________
</pre>
</body>
</html>