[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/SemFen article.rst
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] manuscripts/SemFen article.rst |
Date: |
Thu, 01 May 2003 13:52:54 -0400 |
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":
- [Gzz-commits] manuscripts/SemFen article.rst, Tuomas J. Lukka, 2003/05/01
- [Gzz-commits] manuscripts/SemFen article.rst, Tuomas J. Lukka, 2003/05/01
- [Gzz-commits] manuscripts/SemFen article.rst, Tuomas J. Lukka, 2003/05/01
- [Gzz-commits] manuscripts/SemFen article.rst, Tuomas J. Lukka, 2003/05/01
- [Gzz-commits] manuscripts/SemFen article.rst,
Benja Fallenstein <=
- [Gzz-commits] manuscripts/SemFen article.rst, Tuomas J. Lukka, 2003/05/02
- [Gzz-commits] manuscripts/SemFen article.rst, Tuomas J. Lukka, 2003/05/02
- [Gzz-commits] manuscripts/SemFen article.rst, Tuukka Hastrup, 2003/05/02
- [Gzz-commits] manuscripts/SemFen article.rst, Benja Fallenstein, 2003/05/02