Hi Henry,
I completly and thouroughly understand your problem,
as (who would have thought) we implement a very very similar gui in nepomuk.
I think that you give fresnel not the chance it deserves in your GUI,
because we did exactly the same you did but based on fresnel.
The KEY to understand fresnel in this regard is that you cannot use
complex fresnel selectors when it comes to editing, as you need to know
where each triple came from. Also, fresnel MUST be extended to support
editing.
We created the FREDIT extension vocabulary to fresnel for editing,
I would strongly appreciate us two continuing and refining it
*http://www.semanticdesktop.org/ontologies/2008/05/23/fredit*
The actual source N3 which I edit by hand is here:
http://www.semanticdesktop.org/ontologies/2008/05/23/fredit/fredit.n3
Let me give you the example from the pimoeditor (see
*http://tinyurl.com/58tu5v)*
:ThingLens rdf:type fresnel:Lens ;
fresnel:classLensDomain pimo:Thing;
fresnel:purpose fresnel:defaultLens;
fresnel:showProperties (
nao:description
pimo:isRelated
pimo:hasTopic
pimo:isTopicOf
pimo:hasPart
pimo:partOf
fresnel:allProperties
pimo:groundingOccurrence
pimo:referencingOccurrence
)
.
In your case, it would be adapted to:
@prefix uij: <urn:java:net.java.sommer.addressbook.ui.> . # not sure of
java uri
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix ctct: <http://www.w3.org/2000/10/swap/pim/contact#> .
@prefix fredit:
<http://www.semanticdesktop.org/ontologies/2008/05/23/fredit#> .
@prefix fresnel: <http://www.w3.org/2004/09/fresnel#> .
uij:EditableContentPanel a fresnel:Lens;
fresnel:showProperties (
owl:sameAs
rdfs:seeAlso
foaf:birthday
foaf:homePage
foaf:work
foaf:weblog
foaf:workplaceHomepage
foaf:openid
[ rdf:type fresnel:PropertyDescription ;
fresnel:property ctct:hasAddress; # ctct:hasAddress made up now, I
don't know what is needed here
fresnel:sublens :ContactEditor ]
).
uij:ContactEditor
fresnel:showProperties ( ctct:phone ctct:fax foaf:basedNear
ctct:address)
.
# now what you want and FREDIT gives you
uij:BirthdayFormat a fresnel:Format;
:valueWidget [ a fredit:DateFieldWidget ];
fresnel:propertyFormatDomain foaf:birthday.
.... etc
In my view, this epxresses exactly what you wanted, but based on fresnel
and fredit.
If you agree, I would appreciate us working together on
* on the FREDIT vocabulary
* hacking GnoGno to render Swing widgets that interpret FREDIT. (this is
optional, you already have your code and I understand if you don't want
to switch to gnogno...)
best
Leo
It was Story Henry who said at the right time 16.06.2008 20:20 the
following words:
What would a Swing User Interface driven by N3 look like? Here I look
at perhaps a first very light weight step to moving more information
into an rdf form.
I am building the right hand panel of the Address Book which currently
looks like
http://www.flickr.com/photos/bblfish/2570176779/sizes/l/
which I am extending to have contact (location) information looking
somewhat like this
http://www.flickr.com/photos/bblfish/2570033671/sizes/l/
The code for this is in the EditableContentPanel class (see
http://tinyurl.com/3tpjog )
Writing this I keep wondering if passing through the so(m)mer mapped
object layer is the right thing to do. There is for example a lot of
code to create statements and remove statements, and code to create
maps (which are just relations) to feed to a list box so that the list
box knows what the URI of say the "mbox" relation is. So why not
create the UI structure directly in N3, and have the code read that?
Perhaps something like this could be used to build the UI:
@prefix uij: <urn:java:net.java.sommer.addressbook.ui.> . # not sure
of java uri
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix ctct: <http://www.w3.org/2000/10/swap/pim/contact#> .
@prefix : <https://sommer.dev.java.net/ont/AddressBook/test> .
#something very local
uij:EditableContentPanel
:contains ([ a uij:RelationsEditor;
ui:rel owl:sameAs, rdfs:seeAlso;
ui:range uij:URIEditor;
]
[ a uij:RelationsEditor;
ui:rel foaf:birthday;
ui:range uij:DateEditor;
ui:cardinality 1;
]
[ a uij:RelationsEditor;
ui:rel foaf:homePage, foaf:work, foaf:weblog,
foaf:workplaceHomepage, foaf:openid
ui:range uij:URLEditor;
]
[ a uij:RelationsEditor;
ui:rel cnct:office, cnct:vacationHome,
ctct:mobile, ctct:home, ctct:emergency
ui:range uij:ContactEditor
]) .
uij:ContactEditor
:contains ([ a uij:RelationsEditor;
ui:rel ctct:phone, ctct:fax ]
[ a uij:LatLongEditor;
ui:cardinality 1 ]
[ a uij:RelationsEditor;
ui:rel foaf:basedNear;
uij:LatLongEditor;
]
[ a uij:RelationsEditor;
ui:rel ctct:address
ui:range uij:AddressEditor
] ) .
notes:
- :contains is a relation to a list, for ordering reasons, and
given the relatively static nature of the information it is placed
directly on the class.
- the uij:AddressEditor is not specified in the N3, as it is quite
a static component
This is a lot less generic that the framwork m2n showed me (very
quickly) a year ago [1], which could be used to replace a lot of swing
development. The vocabulary here is very specific to the components
being build. It is also a lot less generic than the fresnel [2] vocab.
Neither is this as generic as gnogno [3] UI development toolkit.
What would the advantages of this be? Perhaps the following:
(a) the RDF would act just like a properties file for the interface.
The human readable labels for relations and can be found by looking up
rdfs:label of the relations. So some internationalization issues can
be dealt with like this
(b) a lot of the java code currently consists of
+ iterators that extract RDF statements out of so(m)mer mapped
java objects to make up statement objects out of them. We could bypass
the mapped objects and query the rdf store directly
+ code that creates hash maps to store the relation between the
name and the uri of a relation
(c) this could lead to more reusablity, which down the road could
help build something similar for more swing components
some disadvantages:
- the missing OO layer between the UI and the rdf store could make
caching more difficult. Currently there is a (simple) caching layer in
sommer mapped objects: as long as the DB does not change, all objects
cache their results in their fields. Here the same queries would have
to be made each time a person's info is displayed.
(vice versa: there may be a lot less caching, so memory will be
less heavily stressed)
- is this perhaps a lot more complicated than I need for an
application this simple?
Does anyone else have experience with this type of coding
[1] http://blogs.sun.com/bblfish/entry/m2n_building_swing_apps_with
[2] http://simile.mit.edu/wiki/Fresnel
seems to be designed for web browsers anyway, as it links up with
css styles
[3] GnoGno provides Eclipse based Matisse/VB like graphical editor
http://dev.nepomuk.semanticdesktop.org/wiki/GnognoComp
Home page: http://bblfish.net/
------------------------------------------------------------------------
_______________________________________________
people mailing list
[email protected]
http://lists.semanticdesktop.org/mailman/listinfo/people
--
____________________________________________________
DI Leo Sauermann http://www.dfki.de/~sauermann
Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080 Fon: +49 631 20575-116
D-67663 Kaiserslautern Fax: +49 631 20575-102
Germany Mail: [EMAIL PROTECTED]
Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________
_______________________________________________
people mailing list
[email protected]
http://lists.semanticdesktop.org/mailman/listinfo/people
