/[gzz]/manuscripts/SemFen/article.rst
ViewVC logotype

Diff of /manuscripts/SemFen/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.20 by tjl, Thu May 1 12:52:25 2003 UTC revision 1.21 by benja, Thu May 1 17:52:53 2003 UTC
# Line 18  Fenfire: Using Semantic Web technologies Line 18  Fenfire: Using Semantic Web technologies
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
# Line 50  integrating them. Line 46  integrating them.
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 (?)
# Line 57  MAIN POINTS (the "real" abstract...) Line 149  MAIN POINTS (the "real" abstract...)
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    
# Line 71  MAIN POINTS (the "real" abstract...) Line 164  MAIN POINTS (the "real" abstract...)
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!
# Line 85  MAKE CLEAR Line 175  MAKE CLEAR
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    

Legend:
Removed from v.1.20  
changed lines
  Added in v.1.21

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26