18 |
Abstract |
Abstract |
19 |
======== |
======== |
20 |
|
|
21 |
We describe the design of a desktop environment |
We describe the design of a desktop environment in which applications |
22 |
in which applications blend by |
blend by storing data in a shared RDF graph. For example, a calendar |
23 |
storing data in a shared RDF graph. |
and a genealogy application could share data about a person's |
24 |
For example, a calendar and a |
birthday. We use a Model-View-Controller (MVC) architecture in which |
25 |
genealogy application could share data about a person's birthday. |
the shared RDF graph acts as the model. Applications provide *views* |
26 |
We use a Model-View-Controller (MVC) architecture in which the shared |
of the RDF data; in the margins around the main view, a *view manager* |
27 |
RDF graph acts as the model. |
shows other applications' views of related information. Selecting a |
28 |
Applications provide *views* of the RDF data; |
view in the margin animates it to the center, making it the main view. |
|
in the margins around the main view, a *view manager* shows other |
|
|
applications' views of related information. |
|
|
Selecting a view in the margin |
|
|
animates it to the center, making it the main view. |
|
29 |
|
|
30 |
Data retrieved from the Semantic Web can be seamlessly integrated into |
Data retrieved from the Semantic Web can be seamlessly integrated into |
31 |
the user's personal data by merging it with the shared RDF graph; e.g., |
the user's personal data by merging it with the shared RDF graph; |
32 |
one's friends' appointments could be retrieved by a query and |
e.g., one's friends' appointments could be retrieved by a query and |
33 |
shown alongside with one's own appointments. Semantic |
shown alongside with one's own appointments. Semantic interoperability |
34 |
interoperability achieved by ontologies and inference may be used to |
achieved by ontologies and inference may be used to allow |
35 |
allow independently developed applications to share data. |
independently developed applications to share data. |
36 |
|
|
37 |
Fenfire is currently under development as Free Software. At the |
Fenfire is currently under development as Free Software. At the |
38 |
moment, we have partial prototypes and are in the process of |
moment, we have partial prototypes and are in the process of |
39 |
integrating them. |
integrating them. |
40 |
|
|
41 |
- Keyword 1: Semantic Interoperability |
- Keyword 1: Semantic Interoperability |
42 |
- Keyword 2: User Interfaces |
- Keyword 2: User Interfaces |
46 |
Introduction |
Introduction |
47 |
============ |
============ |
48 |
|
|
49 |
|
Assume that a user needs to coordinate the activities of her |
50 |
|
workgroup. She has at her disposal applications for email, |
51 |
|
project planning, scheduling appointments with her colleagues, |
52 |
|
keeping track of unresolved issues, creating presentations, |
53 |
|
text documents, and spreadsheets. |
54 |
|
|
55 |
|
In a traitional desktop system, she will keep track of the |
56 |
|
project's goals in one application, write them up as a |
57 |
|
presentation in another, schedule the presentation in a |
58 |
|
third application, and write the agenda in a fourth. If the |
59 |
|
presentation is also a deliverable of her project, she will |
60 |
|
use the first application to keep track of it. |
61 |
|
|
62 |
|
All this information will belong together in her mind, but in |
63 |
|
her computer, it will be scattered across different files. |
64 |
|
|
65 |
|
In this article, we describe the design of Fenfire, |
66 |
|
a desktop environment allowing applications like these |
67 |
|
to be integrated into a seamless whole. |
68 |
|
|
69 |
|
In Fenfire, all of the above applications would store |
70 |
|
their data as RDF [ref]. The applications might use |
71 |
|
vocabularies existing today, such as the iCalendar mapping |
72 |
|
defined by the RDF Calendar taskforce [ref] (identified |
73 |
|
by the ``cal`` namespace, below), |
74 |
|
the DAML Project Plan Ontology [ref] (``plan``), |
75 |
|
or the RDF Core Working Group's vocabulary |
76 |
|
for issue tracking [ref] (``issue``). |
77 |
|
|
78 |
|
It would then be possible to represent the relationships |
79 |
|
between the different applications' information |
80 |
|
as RDF statements -- "anybody can say anything about anything" [ref], |
81 |
|
even if it's in a different application. |
82 |
|
|
83 |
|
For example, a presentation document can be |
84 |
|
a Project Plan ``plan:Deliverable``. Deliverables |
85 |
|
have a due date (``plan:planDate``). This date can |
86 |
|
be an appointment in the calendaring application. |
87 |
|
Her colleague's comments on the presentation |
88 |
|
or parts of it can be represented through the |
89 |
|
``issue:comments`` property; each comment would be |
90 |
|
``issue:raisedIn`` an email received by her |
91 |
|
email application (XXX figure of simplified graph). |
92 |
|
|
93 |
|
The desktop environment would make these connections visible. |
94 |
|
Whenever an email raising a comment is shown |
95 |
|
by the email application, Fenfire would show |
96 |
|
issues raised by it floating in a margin (XXX figure n-a)), |
97 |
|
rendered by the issue tracking application. |
98 |
|
When clicking on an issue, it would become |
99 |
|
the main view, as when following an HTML link |
100 |
|
(XXX figure n-c)). The email would become a marginal note |
101 |
|
or *buoy* connected to the issue. |
102 |
|
|
103 |
|
.. The figure above should have three parts: |
104 |
|
original state, during animation, after animation. |
105 |
|
The figure caption should explain that the animation |
106 |
|
takes place. |
107 |
|
|
108 |
|
I think this shouldn't be screenshots, but line drawings, |
109 |
|
in order not to distract from the point by irrelevant detail. |
110 |
|
|
111 |
|
Similarly, the connections from issue to presentation, |
112 |
|
and from presentation to project milestone/calendar appointment |
113 |
|
would be shown. Simply by clicking through a chain of connections, |
114 |
|
each of which is inherent in the information stored, |
115 |
|
the user could navigate from the email to the appointment |
116 |
|
and back. Popular desktop environments are not able |
117 |
|
to show such interconnections. |
118 |
|
|
119 |
|
It is important to note that the applications would not |
120 |
|
normally be designed to interoperate with each other. |
121 |
|
It suffices that each is implemented using the API |
122 |
|
provided by Fenfire; the desktop environment takes care |
123 |
|
of the rest. |
124 |
|
|
125 |
|
Each Fenfire 'application' is implemented as a set of |
126 |
|
views of and actions on RDF data. Each application |
127 |
|
registers with Fenfire the kinds of information it can display, |
128 |
|
and the properties that Fenfire should show as connections |
129 |
|
between applications. |
130 |
|
|
131 |
|
In the above example, the issue tracking application would |
132 |
|
register ``issue:raisedIn`` as a property to show |
133 |
|
as a connection. When displaying an issue, Fenfire |
134 |
|
looks for ``raisedIn`` statements and notices that |
135 |
|
the email application is able to display the object |
136 |
|
of the statement. (If one particular issue were raised |
137 |
|
by postal mail, the letter could be scanned and |
138 |
|
the associated resource made the target of the |
139 |
|
``raisedIn`` statement; Fenfire would then use a different |
140 |
|
application's view to show the letter.) |
141 |
|
|
142 |
|
.. end example about here, give more general explations |
143 |
|
now as listed below |
144 |
|
|
145 |
MAIN POINTS (the "real" abstract...) |
MAIN POINTS (the "real" abstract...) |
146 |
|
|
147 |
- application framework with a single, global RDF-graph (?) |
- application framework with a single, global RDF-graph (?) |
149 |
- Ted's "an application is a prison"; data should work |
- Ted's "an application is a prison"; data should work |
150 |
across borders |
across borders |
151 |
|
|
152 |
- connection with ontologies &c!!!: ontologies |
- connection with semantic interoperability: ontologies |
153 |
and inferencers can **make** a single, global graph |
and inferencers can **make** a single, global graph |
154 |
from disjoint fragments using different data models!!! |
from disjoint fragments using different vocabularies, |
155 |
|
and keep the different representations in sync. |
156 |
|
|
157 |
- buoys |
- buoys |
158 |
|
|
164 |
- show connections spatially / temporally |
- show connections spatially / temporally |
165 |
between instances of same node |
between instances of same node |
166 |
|
|
|
|
|
|
|
|
|
|
|
167 |
MISTAKES NOT TO MAKE: |
MISTAKES NOT TO MAKE: |
168 |
|
|
169 |
- comparing our system only to production-level systems! |
- comparing our system only to production-level systems! |
175 |
- we're not discussing ontologies |
- we're not discussing ontologies |
176 |
|
|
177 |
- we're not discussing semantic interoperability |
- we're not discussing semantic interoperability |
178 |
|
(we only discuss how to *use* it to integrate FF apps) |
179 |
|
|
180 |
|
- we're not discussing how to integrate data |
181 |
|
from legacy applications |
182 |
|
|
183 |
- co-operation between "applications": |
- co-operation between "applications": |
184 |
|
|