231 |
a person's name and e-mail, while a genealogy structure might |
a person's name and e-mail, while a genealogy structure might |
232 |
give their parents, children, and spouses. |
give their parents, children, and spouses. |
233 |
|
|
234 |
XXX using hyperstructure for internal data |
To be used in this way, a hyperstructure must have a |
235 |
XXX thus, explorability. Nelson: "Look under the world, find a turtle..." |
simple visualization that allows a user to browse and edit |
236 |
XXX focus+context |
the network of items. When the user is looking at an item, |
237 |
|
this visualization must show the related items nearby; |
238 |
|
if the user has to scroll or click through menus first, |
239 |
|
the network of items loses its usefulness. |
240 |
|
|
241 |
|
With `Nelson (1999b)`_, we propose to use hyperstructure |
242 |
|
not only for the network of user-relevant items, but also |
243 |
|
for the data the system needs to store internally. |
244 |
|
|
245 |
|
For example, when placing items onto a map, these items' |
246 |
|
x/y coordinates are normally not relevant to the user, |
247 |
|
and therefore not items. Still, they can be stored in the |
248 |
|
hyperstructure, available for the user to look at if they |
249 |
|
want to [#unix-command-line]_. |
250 |
|
|
251 |
|
By making the internals of the system work the same way |
252 |
|
as the network of items that users use daily, they can |
253 |
|
be more easily understood even by a non-advanced user, |
254 |
|
making them less arcane. "Look under the world, find a turtle," |
255 |
|
in Nelson's terms (private communication, 2001). |
256 |
|
|
257 |
We use the term hyperstructure to **denote** a **storage model** |
We use the term hyperstructure to **denote a storage model** |
258 |
that allows different data structures to overlap, but to |
that allows different data structures to overlap, but to |
259 |
**connote** being used as the basis of an **item-based hypermedia system**. |
**connote** being used as the basis of an **item-based hypermedia system**. |
260 |
This is the sense of the word in which it was used in the title |
This is the sense of the word in which it was used in the title |
362 |
4.2.1 RDF Focus+Context views |
4.2.1 RDF Focus+Context views |
363 |
""""""""""""""""""""""""""""" |
""""""""""""""""""""""""""""" |
364 |
|
|
365 |
|
In this section, we describe our visualizations of RDF XXX |
366 |
|
|
367 |
- our 'basic hyperstructure' visualization of rdf |
- our 'basic hyperstructure' visualization of rdf |
368 |
|
|
369 |
- wheel: f+c (see fig.1) |
- wheel: f+c (see fig.1) |
424 |
Figure XXX: a diagram of buoy animation (`larger image`__). |
Figure XXX: a diagram of buoy animation (`larger image`__). |
425 |
The "screenshots" with black edges represent |
The "screenshots" with black edges represent |
426 |
keyframes, and the others the animation. |
keyframes, and the others the animation. |
427 |
|
|
428 |
The first keyframe shows the user viewing the orange-colored |
The first keyframe shows the user viewing the orange-colored |
429 |
document; the user clicks on the light-blue buoy |
document; the user clicks on the light-blue buoy |
430 |
and the animation to the second keyframe ensues. |
and the animation to the second keyframe ensues. |
431 |
There, the user clicks on the green buoy |
There, the user clicks on the green buoy |
432 |
and the animation to the third keyframe follows. |
and the animation to the third keyframe follows. |
433 |
There are no disruptive changes to what the user |
|
434 |
sees - going back from the second keyframe |
**There are no disruptive changes to what the user |
435 |
|
sees** - going back from the second keyframe |
436 |
to the orange document is trivial without |
to the orange document is trivial without |
437 |
an explicit "back button". |
an explicit "back button". |
438 |
|
|
971 |
about them, in this case the idea about how to develop |
about them, in this case the idea about how to develop |
972 |
one of them. |
one of them. |
973 |
|
|
974 |
|
.. [#unix-command-line] Hyperstructure would have an analogous |
975 |
|
role to text files on the UNIX command line: It would store both |
976 |
|
the user's information and, unified in the same model, the data |
977 |
|
used internally by the system, and be processable by |
978 |
|
a lot of generic commands. |
979 |
|
|
980 |
.. [#zzstructure-rdf] RDF and zzStructure are actually closely |
.. [#zzstructure-rdf] RDF and zzStructure are actually closely |
981 |
related: zzStructure is obtained if a RDF graph is constrained |
related: zzStructure is obtained if a RDF graph is constrained |
982 |
by two uniqueness conditions: for all x, y, there can be |
by two uniqueness conditions: for all x, y, there can be |