[Gzz-commits] manuscripts/SemFen article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/05/01 13:52:53

Modified files:
        SemFen         : article.rst 

Log message:
        Today's slow progress on intro

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/SemFen/article.rst.diff?tr1=1.20&tr2=1.21&r1=text&r2=text

Patches:
Index: manuscripts/SemFen/article.rst
diff -u manuscripts/SemFen/article.rst:1.20 manuscripts/SemFen/article.rst:1.21
--- manuscripts/SemFen/article.rst:1.20 Thu May  1 08:52:25 2003
+++ manuscripts/SemFen/article.rst      Thu May  1 13:52:53 2003
@@ -3,7 +3,7 @@
 ==========================================================================
 
 
-.. :Stamp: $Id: article.rst,v 1.20 2003/05/01 12:52:25 tjl Exp $
+.. :Stamp: $Id: article.rst,v 1.21 2003/05/01 17:52:53 benja Exp $
 
 .. Authors: Benja Fallenstein, Tuukka Hastrup, Tuomas J. Lukka
 
@@ -18,29 +18,25 @@
 Abstract
 ========
 
-We describe the design of a desktop environment 
-in which applications blend by
-storing data in a shared RDF graph. 
-For example, a calendar and a
-genealogy application could share data about a person's birthday. 
-We use a Model-View-Controller (MVC) architecture in which the shared
-RDF graph acts as the model. 
-Applications provide *views* of the RDF data;
-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.
+We describe the design of a desktop environment in which applications
+blend by storing data in a shared RDF graph.  For example, a calendar
+and a genealogy application could share data about a person's
+birthday.  We use a Model-View-Controller (MVC) architecture in which
+the shared RDF graph acts as the model.  Applications provide *views*
+of the RDF data; 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.
 
 Data retrieved from the Semantic Web can be seamlessly integrated into
-the user's personal data by merging it with the shared RDF graph; e.g.,
-one's friends' appointments could be retrieved by a query and
-shown alongside with one's own appointments. Semantic
-interoperability achieved by ontologies and inference may be used to
-allow independently developed applications to share data.
+the user's personal data by merging it with the shared RDF graph;
+e.g., one's friends' appointments could be retrieved by a query and
+shown alongside with one's own appointments. Semantic interoperability
+achieved by ontologies and inference may be used to allow
+independently developed applications to share data.
 
 Fenfire is currently under development as Free Software. At the
 moment, we have partial prototypes and are in the process of
-integrating them. 
+integrating them.
 
 - Keyword 1: Semantic Interoperability
 - Keyword 2: User Interfaces
@@ -50,6 +46,102 @@
 Introduction
 ============
 
+Assume that a user needs to coordinate the activities of her
+workgroup. She has at her disposal applications for email,
+project planning, scheduling appointments with her colleagues, 
+keeping track of unresolved issues, creating presentations,
+text documents, and spreadsheets.
+
+In a traitional desktop system, she will keep track of the
+project's goals in one application, write them up as a
+presentation in another, schedule the presentation in a
+third application, and write the agenda in a fourth. If the
+presentation is also a deliverable of her project, she will
+use the first application to keep track of it.
+
+All this information will belong together in her mind, but in
+her computer, it will be scattered across different files.
+
+In this article, we describe the design of Fenfire,
+a desktop environment allowing applications like these
+to be integrated into a seamless whole. 
+
+In Fenfire, all of the above applications would store
+their data as RDF [ref]. The applications might use
+vocabularies existing today, such as the iCalendar mapping
+defined by the RDF Calendar taskforce [ref] (identified
+by the ``cal`` namespace, below),
+the DAML Project Plan Ontology [ref] (``plan``), 
+or the RDF Core Working Group's vocabulary 
+for issue tracking [ref] (``issue``).
+
+It would then be possible to represent the relationships 
+between the different applications' information 
+as RDF statements -- "anybody can say anything about anything" [ref],
+even if it's in a different application.
+
+For example, a presentation document can be 
+a Project Plan ``plan:Deliverable``. Deliverables 
+have a due date (``plan:planDate``). This date can
+be an appointment in the calendaring application.
+Her colleague's comments on the presentation
+or parts of it can be represented through the
+``issue:comments`` property; each comment would be
+``issue:raisedIn`` an email received by her
+email application (XXX figure of simplified graph).
+
+The desktop environment would make these connections visible.
+Whenever an email raising a comment is shown
+by the email application, Fenfire would show
+issues raised by it floating in a margin (XXX figure n-a)),
+rendered by the issue tracking application.
+When clicking on an issue, it would become
+the main view, as when following an HTML link
+(XXX figure n-c)). The email would become a marginal note
+or *buoy* connected to the issue.
+
+.. The figure above should have three parts:
+   original state, during animation, after animation.
+   The figure caption should explain that the animation
+   takes place.
+
+   I think this shouldn't be screenshots, but line drawings,
+   in order not to distract from the point by irrelevant detail.
+
+Similarly, the connections from issue to presentation,
+and from presentation to project milestone/calendar appointment
+would be shown. Simply by clicking through a chain of connections,
+each of which is inherent in the information stored,
+the user could navigate from the email to the appointment
+and back. Popular desktop environments are not able
+to show such interconnections.
+
+It is important to note that the applications would not
+normally be designed to interoperate with each other.
+It suffices that each is implemented using the API
+provided by Fenfire; the desktop environment takes care
+of the rest.
+
+Each Fenfire 'application' is implemented as a set of
+views of and actions on RDF data. Each application
+registers with Fenfire the kinds of information it can display,
+and the properties that Fenfire should show as connections
+between applications.
+
+In the above example, the issue tracking application would
+register ``issue:raisedIn`` as a property to show
+as a connection. When displaying an issue, Fenfire
+looks for ``raisedIn`` statements and notices that
+the email application is able to display the object
+of the statement. (If one particular issue were raised
+by postal mail, the letter could be scanned and
+the associated resource made the target of the
+``raisedIn`` statement; Fenfire would then use a different
+application's view to show the letter.)
+
+.. end example about here, give more general explations
+   now as listed below
+
 MAIN POINTS (the "real" abstract...)
 
 - application framework with a single, global RDF-graph (?)
@@ -57,9 +149,10 @@
     - Ted's "an application is a prison"; data should work
       across borders
 
-    - connection with ontologies &c!!!: ontologies
+    - connection with semantic interoperability: ontologies
       and inferencers can **make** a single, global graph
-      from disjoint fragments using different data models!!!
+      from disjoint fragments using different vocabularies,
+      and keep the different representations in sync.
 
     - buoys
 
@@ -71,9 +164,6 @@
        - show connections spatially / temporally
          between instances of same node
 
-
-    
-
 MISTAKES NOT TO MAKE:
 
     - comparing our system only to production-level systems!
@@ -85,6 +175,10 @@
     - we're not discussing ontologies
 
     - we're not discussing semantic interoperability
+      (we only discuss how to *use* it to integrate FF apps)
+
+    - we're not discussing how to integrate data
+      from legacy applications
 
 - co-operation between "applications":