/[gzz]/manuscripts/FutureVision/vision.rst
ViewVC logotype

Diff of /manuscripts/FutureVision/vision.rst

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

revision 1.182 by benja, Thu Nov 13 20:38:28 2003 UTC revision 1.183 by benja, Thu Nov 13 20:52:18 2003 UTC
# Line 339  In the remainder of this section, Line 339  In the remainder of this section,
339  we present zzStructure and RDF [#zzstructure-rdf]_,  we present zzStructure and RDF [#zzstructure-rdf]_,
340  two hyperstructures actually used  two hyperstructures actually used
341  in systems aiming at the goals we have described above [#databases-as-hyperstructure]_.  in systems aiming at the goals we have described above [#databases-as-hyperstructure]_.
342    We then give a real-world example for the use of hyperstructure.
343    
344    
345    
# Line 393  as applitudes without special code. Line 394  as applitudes without special code.
394  3.2 Resource Description Framework (RDF, used in Fenfire)  3.2 Resource Description Framework (RDF, used in Fenfire)
395  ---------------------------------------------------------  ---------------------------------------------------------
396    
397  The RDF structure (`Lassila and Swick 1999`_) is, for our purposes,  Our work is based on using the Resource Description Framework
398  a set of triples *(a,b,c)* with *a* and *b* ranging over the "atoms"  (RDF, `Lassila and Swick 1999`_) as a hyperstructure.
399  of the structure and *c* ranging over the atoms and *literals* (explicit  In the examples we have given above, we have assumed the use of RDF.
400  values such as strings or numbers).  
401  By interpreting the components of the triple  RDF is a directed labelled graph structure in which nodes and edge labels
402  (as is usual) as subject, predicate, and object, the structure  are identified by URIs. Nodes can also be blank, that is,
403  can be divided to orthogonal  have identifiers local to a particular graph, or literal
404  components for the different applitudes  (explicit values such as strings and numbers, rather than URIs).
405  by using non-overlapping sets of predicates and objects  An RDF graph can be seen as a set of *(subject, predicate,
406  in different applitudes.  object)* triples, where each triple is an edge between the
407    subject and the object and with the predicate as its label.
408    
409    When discussing RDF, URIs are often abbreviated,
410    for example ``foaf:Person`` for ``http://xmlns.com/foaf/0.1/Person``.
411    
412  While the zzstructure is simple to browse locally,  While the zzstructure is simple to browse locally,
413    because it has higher-level (user-centred) semantics,
414  programming is often easier in RDF, because many-to-many  programming is often easier in RDF, because many-to-many
415  relationships can be represented more naturally.  relationships can be represented more naturally.
416    
417    As an example, consider making a list of attendants of a meeting.
418    In RDF, these would be connected directly for the meeting.
419    In zzstructure, the meeting would be connected to the first
420    attendant, and on a different dimension, the first attendant
421    would be connected to the second, the second to the third,
422    and so on. Removing one attendant from the set is not as
423    straight-forward as in RDF (you need to special-case
424    the case of the first attendant being removed).
425    
426    Using RDF as a hyperstructure, items are nodes.
427    Two data structures can independently connect information
428    to the same item by using different properties. Properties
429    are the RDF equivalent to zzstructure's dimensions.
430    
431    RDF triples are not associated with a context.
432    For example, one cannot create two triples saying that
433    "Paper A supports paper B" and "Paper A contradicts paper B,"
434    and then say that the first triple is true under one set
435    of assertions and the second under another set.
436    
437    To represent this information in RDF, one would not
438    use a direct connection between the papers; rather,
439    one would create new nodes for both statements,
440    and connect them to the two papers as well as to the
441    sets of assetions under which either statement is true.
442    (This is how statements about more than two nodes
443    are generally represented in RDF.)
444    
445  Visualizations of RDF are generally a two-dimensional  Visualizations of RDF are generally a two-dimensional
446  layout of a whole graph, as if drawn on a sheet of paper.  layout of a whole graph, as if drawn on a sheet of paper.
447  Graphical editors normally let the  Graphical editors normally let the
# Line 421  may be in a completely different part of Line 455  may be in a completely different part of
455  anything in such a visualization representing *all* the items  anything in such a visualization representing *all* the items
456  a user stores in their computer seems bound to be a herculean task.  a user stores in their computer seems bound to be a herculean task.
457    
458  Visualizations that change the layout when the user moves  XXXX Ontorama cloning technique!
459  from node to node are not as common, but for example  (`Eklund 2002`_)
 Ontorama (`Eklund 2002`_) uses hyperbolic spaces for this.  
460    
461  We describe our visualizations of RDF  These visualizations are therefore not useful for using
462    RDF as a hyperstructure as introduced above.
463    However, it is quite possible to build focus+context
464    views for RDF; we discuss our RDF visualizations
465  in `Section 4.2.1`_.  in `Section 4.2.1`_.
466    
467    
468    .. `Section 3.3`:
469    
470    3.3 A real-world example
471    ------------------------
472    
473    In this section, we give a example of hyperstructure
474    in real-world use.
475    We present how Christel Fallenstein, a fan of Austrian author
476    Friederike Mayröcker, uses hyperstructure to keep track of the information
477    she wants to remember about Mayröcker's work.
478    
479    This is currently done in zzstructure
480    (using our implementation, Gzz), because the Fenfire implementation
481    is in too early prototype stage. Below, we will give a
482    list of the different information structures in this applitude
483    and show how they could be realized in RDF. We can unfortunately not
484    include screenshots because of the copyrighted and unpublished
485    material as well as the private character of the information
486    in this space.
487    
488    Poems
489        The heart of this information space is a collection
490        of published and unpublished poems by Friederike Mayröcker
491        (node type ``poems:Poem``). For each poem, we store
492        the ``poems:dateWritten`` and for some the ``poems:dateRevised``;
493        also, we store the ``poems:title`` and ``poems:text`` of the poem.
494        Finally, we store who the poems are ``poem:dedicatedTo``
495        as connections to the items representing these people.
496    
497        The collection of poems is primarily viewed sorted by
498        date written and by *day and month* written, i.e.
499        ignoring the year. The latter is useful to see the
500        influence of seasons on Mayröcker's work, i.e., to see
501        how two poems from February, but from two different years,
502        may be similar.
503    
504        Most poems are published in at least one ``poems:Book``.
505        Here, it is important to be able to keep track of the
506        page numbers of each poem *in each book it was published*.
507        To realize this, we need an additional RDF node--
508        type ``poems:PublicationInfo``; a ``poems:Poem`` is connected
509        on ``poems:publishedAs`` to the ``poems:PublicationInfo``,
510        which has connections on ``poems:pageNumber`` and
511        ``poems:book``, the latter to a ``book:Book``.
512        A ``book:Book`` has a ``book:title``,
513        a ``book:publicationDate`` and a ``book:abbreviation``--
514        for example, Fallenstein abbreviates *Das Besessene Alter*
515        to "BA."
516    
517    Contacts
518        For people (node type ``foaf:Person``) we store their
519        ``foaf:name`` and possibly their contact information:
520        ``foaf:mbox`` (the e-mail address), ``person:address``,
521        and ``person:phoneNumber``.
522    
523        A relatively common use is to look for a person by name,
524        then look for poems dedicated to this person. The
525        contact information is useful because the user of this
526        system often knows the people poems are dedicated to
527        and exchanges letters or e-mails with them.
528    
529    Correspondence
530        In addition to the poems, the space contains correspondence
531        with Mayröcker and other people interested in Mayröcker's work,
532        for example translators of Mayröcker's work in different
533        languages, by e-mail and paper mail. A ``m:Letter`` or ``m:Mail``
534        (subclasses of ``m:Correspondence``) has ``m:from`` and ``m:to``
535        properties connecting them to instances of ``foaf:Person``,
536        as well as an ``m:date``. Mails also have an ``m:subject``.
537    
538        A usual task is to view all the correspondence with
539        (from or to) a particular person in chronological order.
540    
541        Finally, and most importantly, correspondence is connected
542        on ``m:about`` to poems it discusses. This way, it is
543        possible to see, when looking at a particular poem,
544        all correspondence discussing this poem. This is the most
545        important reason for using hyperstructure in this context.
546    
547    Telephone notes
548        Fallenstein and Mayröcker talk on the phone almost daily.
549        During these conversations, Fallenstein takes notes about
550        their discussions. For each call (``m:Call``), there is a list
551        of short notes (``m:CallNote``). A call has a ``m:callDate``
552        and possibly some text connected on ``m:callInfo``, noting
553        additional information, for example if Mayröcker was on
554        vacation. A call would be connected on ``m:callNotes`` to
555        an RDF *collection* (`Brickley 2003`_) of the notes,
556        providing order for them.
557    
558        Call notes have their text connected on ``m:noteText``,
559        and again, they are connected to poems they discuss
560        on ``m:about``. They are viewed either by looking at the
561        poem they discuss, or by browsing them by date.
562    
563    Readings
564        Finally, Fallenstein stores in this space readings
565        that Mayröcker gives (``reading:Reading``). Readings have
566        a ``reading:date`` and a non-exhaustive list of
567        ``reading:attendant`` connections-- people that
568        Fallenstein wants to remember have attended the event.
569        Readings also have a ``reading:program``, an RDF collection
570        of the poems or other texts read that day.
571    
572    
573    
574    
575  .. _`Section 4`:  .. _`Section 4`:
576    
577  4 The Fenfire project  4 The Fenfire project
# Line 437  in `Section 4.2.1`_. Line 580  in `Section 4.2.1`_.
580  Fenfire is a free software project aiming at implementing  Fenfire is a free software project aiming at implementing
581  the applitude-oriented user interface concepts on top of an RDF graph.  the applitude-oriented user interface concepts on top of an RDF graph.
582    
 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.  
   
583  4.1 Structures  4.1 Structures
584  --------------  --------------
585    
# Line 970  References Line 1108  References
1108  Available online as  Available online as
1109  ``http://www.w3.org/DesignIssues/Semantic.html``  ``http://www.w3.org/DesignIssues/Semantic.html``
1110    
1111    .. _Brickley 2003:
1112    
1113    **Brickley, D., and Gupta, R.V.,** (2003)
1114    "RDF Vocabulary Description Language 1.0: RDF Schema".
1115    W3C Working Draft 10 October 2003. Available at
1116    ``http://www.w3.org/TR/rdf-schema/``
1117    
1118  .. _`Bush 1945`:  .. _`Bush 1945`:
1119    
1120  **Bush, V.** (1945) "As We May Think". *The Atlantic Monthly*, 176(1),  **Bush, V.** (1945) "As We May Think". *The Atlantic Monthly*, 176(1),

Legend:
Removed from v.1.182  
changed lines
  Added in v.1.183

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