[Gzz-commits] manuscripts/FutureVision oplan.txt vision.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/13 15:52:22

Modified files:
        FutureVision   : oplan.txt vision.rst 

Log message:
        integration

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/oplan.txt.diff?tr1=1.32&tr2=1.33&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/vision.rst.diff?tr1=1.182&tr2=1.183&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/oplan.txt
diff -u manuscripts/FutureVision/oplan.txt:1.32 
manuscripts/FutureVision/oplan.txt:1.33
--- manuscripts/FutureVision/oplan.txt:1.32     Thu Nov 13 15:32:44 2003
+++ manuscripts/FutureVision/oplan.txt  Thu Nov 13 15:52:18 2003
@@ -327,6 +327,11 @@
 NEW 3.3 A real-world example
 ==========================================
 
+Add to 3:
+
+    We then give a real-world example for the use of hyperstructure.
+
+
 **[30] Poems example:**
 
 In this section, we give a example of hyperstructure
Index: manuscripts/FutureVision/vision.rst
diff -u manuscripts/FutureVision/vision.rst:1.182 
manuscripts/FutureVision/vision.rst:1.183
--- manuscripts/FutureVision/vision.rst:1.182   Thu Nov 13 15:38:28 2003
+++ manuscripts/FutureVision/vision.rst Thu Nov 13 15:52:18 2003
@@ -339,6 +339,7 @@
 we present zzStructure and RDF [#zzstructure-rdf]_, 
 two hyperstructures actually used
 in systems aiming at the goals we have described above 
[#databases-as-hyperstructure]_.
+We then give a real-world example for the use of hyperstructure.
 
 
 
@@ -393,21 +394,54 @@
 3.2 Resource Description Framework (RDF, used in Fenfire)
 ---------------------------------------------------------
 
-The RDF structure (`Lassila and Swick 1999`_) is, for our purposes,
-a set of triples *(a,b,c)* with *a* and *b* ranging over the "atoms"
-of the structure and *c* ranging over the atoms and *literals* (explicit
-values such as strings or numbers).
-By interpreting the components of the triple
-(as is usual) as subject, predicate, and object, the structure
-can be divided to orthogonal
-components for the different applitudes
-by using non-overlapping sets of predicates and objects 
-in different applitudes. 
+Our work is based on using the Resource Description Framework
+(RDF, `Lassila and Swick 1999`_) as a hyperstructure.
+In the examples we have given above, we have assumed the use of RDF.
+
+RDF is a directed labelled graph structure in which nodes and edge labels
+are identified by URIs. Nodes can also be blank, that is,
+have identifiers local to a particular graph, or literal
+(explicit values such as strings and numbers, rather than URIs).
+An RDF graph can be seen as a set of *(subject, predicate,
+object)* triples, where each triple is an edge between the
+subject and the object and with the predicate as its label.
+
+When discussing RDF, URIs are often abbreviated,
+for example ``foaf:Person`` for ``http://xmlns.com/foaf/0.1/Person``.
 
 While the zzstructure is simple to browse locally,
+because it has higher-level (user-centred) semantics,
 programming is often easier in RDF, because many-to-many
 relationships can be represented more naturally.
 
+As an example, consider making a list of attendants of a meeting.
+In RDF, these would be connected directly for the meeting.
+In zzstructure, the meeting would be connected to the first
+attendant, and on a different dimension, the first attendant
+would be connected to the second, the second to the third,
+and so on. Removing one attendant from the set is not as
+straight-forward as in RDF (you need to special-case
+the case of the first attendant being removed).
+
+Using RDF as a hyperstructure, items are nodes. 
+Two data structures can independently connect information
+to the same item by using different properties. Properties
+are the RDF equivalent to zzstructure's dimensions.
+
+RDF triples are not associated with a context.
+For example, one cannot create two triples saying that
+"Paper A supports paper B" and "Paper A contradicts paper B,"
+and then say that the first triple is true under one set
+of assertions and the second under another set. 
+
+To represent this information in RDF, one would not 
+use a direct connection between the papers; rather,
+one would create new nodes for both statements,
+and connect them to the two papers as well as to the
+sets of assetions under which either statement is true.
+(This is how statements about more than two nodes
+are generally represented in RDF.)
+
 Visualizations of RDF are generally a two-dimensional
 layout of a whole graph, as if drawn on a sheet of paper.
 Graphical editors normally let the
@@ -421,14 +455,123 @@
 anything in such a visualization representing *all* the items
 a user stores in their computer seems bound to be a herculean task.
 
-Visualizations that change the layout when the user moves
-from node to node are not as common, but for example
-Ontorama (`Eklund 2002`_) uses hyperbolic spaces for this.
+XXXX Ontorama cloning technique!
+(`Eklund 2002`_)
 
-We describe our visualizations of RDF
+These visualizations are therefore not useful for using
+RDF as a hyperstructure as introduced above.
+However, it is quite possible to build focus+context
+views for RDF; we discuss our RDF visualizations
 in `Section 4.2.1`_.
 
 
+.. `Section 3.3`:
+
+3.3 A real-world example
+------------------------
+
+In this section, we give a example of hyperstructure
+in real-world use.
+We present how Christel Fallenstein, a fan of Austrian author
+Friederike Mayröcker, uses hyperstructure to keep track of the information 
+she wants to remember about Mayröcker's work.
+
+This is currently done in zzstructure
+(using our implementation, Gzz), because the Fenfire implementation
+is in too early prototype stage. Below, we will give a
+list of the different information structures in this applitude
+and show how they could be realized in RDF. We can unfortunately not
+include screenshots because of the copyrighted and unpublished
+material as well as the private character of the information
+in this space.
+
+Poems
+    The heart of this information space is a collection
+    of published and unpublished poems by Friederike Mayröcker
+    (node type ``poems:Poem``). For each poem, we store
+    the ``poems:dateWritten`` and for some the ``poems:dateRevised``;
+    also, we store the ``poems:title`` and ``poems:text`` of the poem.
+    Finally, we store who the poems are ``poem:dedicatedTo``
+    as connections to the items representing these people.
+
+    The collection of poems is primarily viewed sorted by
+    date written and by *day and month* written, i.e.
+    ignoring the year. The latter is useful to see the
+    influence of seasons on Mayröcker's work, i.e., to see
+    how two poems from February, but from two different years,
+    may be similar.
+
+    Most poems are published in at least one ``poems:Book``.
+    Here, it is important to be able to keep track of the
+    page numbers of each poem *in each book it was published*.
+    To realize this, we need an additional RDF node--
+    type ``poems:PublicationInfo``; a ``poems:Poem`` is connected
+    on ``poems:publishedAs`` to the ``poems:PublicationInfo``,
+    which has connections on ``poems:pageNumber`` and
+    ``poems:book``, the latter to a ``book:Book``.
+    A ``book:Book`` has a ``book:title``,
+    a ``book:publicationDate`` and a ``book:abbreviation``--
+    for example, Fallenstein abbreviates *Das Besessene Alter*
+    to "BA."
+
+Contacts
+    For people (node type ``foaf:Person``) we store their
+    ``foaf:name`` and possibly their contact information:
+    ``foaf:mbox`` (the e-mail address), ``person:address``,
+    and ``person:phoneNumber``.
+
+    A relatively common use is to look for a person by name,
+    then look for poems dedicated to this person. The
+    contact information is useful because the user of this
+    system often knows the people poems are dedicated to
+    and exchanges letters or e-mails with them.
+
+Correspondence
+    In addition to the poems, the space contains correspondence
+    with Mayröcker and other people interested in Mayröcker's work,
+    for example translators of Mayröcker's work in different
+    languages, by e-mail and paper mail. A ``m:Letter`` or ``m:Mail``
+    (subclasses of ``m:Correspondence``) has ``m:from`` and ``m:to``
+    properties connecting them to instances of ``foaf:Person``, 
+    as well as an ``m:date``. Mails also have an ``m:subject``.
+
+    A usual task is to view all the correspondence with
+    (from or to) a particular person in chronological order.
+
+    Finally, and most importantly, correspondence is connected
+    on ``m:about`` to poems it discusses. This way, it is
+    possible to see, when looking at a particular poem,
+    all correspondence discussing this poem. This is the most
+    important reason for using hyperstructure in this context.
+
+Telephone notes
+    Fallenstein and Mayröcker talk on the phone almost daily.
+    During these conversations, Fallenstein takes notes about
+    their discussions. For each call (``m:Call``), there is a list
+    of short notes (``m:CallNote``). A call has a ``m:callDate``
+    and possibly some text connected on ``m:callInfo``, noting
+    additional information, for example if Mayröcker was on
+    vacation. A call would be connected on ``m:callNotes`` to
+    an RDF *collection* (`Brickley 2003`_) of the notes,
+    providing order for them.
+
+    Call notes have their text connected on ``m:noteText``,
+    and again, they are connected to poems they discuss
+    on ``m:about``. They are viewed either by looking at the
+    poem they discuss, or by browsing them by date.
+
+Readings
+    Finally, Fallenstein stores in this space readings
+    that Mayröcker gives (``reading:Reading``). Readings have
+    a ``reading:date`` and a non-exhaustive list of
+    ``reading:attendant`` connections-- people that
+    Fallenstein wants to remember have attended the event.
+    Readings also have a ``reading:program``, an RDF collection
+    of the poems or other texts read that day.
+
+
+
+
 .. _`Section 4`:
 
 4 The Fenfire project
@@ -437,11 +580,6 @@
 Fenfire is a free software project aiming at implementing
 the applitude-oriented user interface concepts on top of an RDF graph.
 
-Fenfire is, against some trends, a relatively monolithic system -
-to be able to avoid compromises on the user interface side
-we have to simultaneously replace the 
-backend structure and the entire user-interface framework.
-
 4.1 Structures
 --------------
 
@@ -969,6 +1107,13 @@
 **Berners-Lee, T.** (1998) "Semantic Web Road map".
 Available online as
 ``http://www.w3.org/DesignIssues/Semantic.html``
+
+.. _Brickley 2003:
+
+**Brickley, D., and Gupta, R.V.,** (2003)
+"RDF Vocabulary Description Language 1.0: RDF Schema".
+W3C Working Draft 10 October 2003. Available at
+``http://www.w3.org/TR/rdf-schema/``
 
 .. _`Bush 1945`: