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 |
|
|
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 |
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 |
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 |
|
|
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), |