Our aim is to find a way to build new texts which is fully satisfying for authors/users/active readers and whose structure is clear, i.e. suitable for linguistic computation. These are the main ideas of Novelle.

1. Introduction Structure Architecture Conclusions
Novelle
A collaborative open source writing tool software
Federico Gobbo & Michele Chinosi
{federico.gobbo,michele.chinosi}@uninsubria.it
Universit` dell’Insubria
a
Varese, Italy

2. Introduction Structure Architecture Conclusions
What we learned from hypertexts
The digital revolution and the medium of writing
Since the Web Era (1991), new forms and techniques of writings
emerged, whose structural traits are still unclear, and the
role/distinction between authors and readers beging to collapse.
The optimists say: ‘hypertexts realize our postmodern and
decostructionist dream of an ‘opera aperta’ (open work)’.
On the contrary, the pessimists say: ‘authors have lost their power
in this openness’.

3. Introduction Structure Architecture Conclusions
What we learned from hypertexts
The main ideas behind Novelle
Our aim is to find a way to build new texts which is fully satisfying
for authors/users/active readers and whose structure is clear, i.e.
suitable for linguistic computation. These are the main ideas of
Novelle.
We feel that the problems faced by hypertexts are much more the
sames of blogs and wikis. We didn’t want to reinvent the wheel, so
we gave a lot of attention of the known literature, in particular on
hypertexts.

4. Introduction Structure Architecture Conclusions
What we learned from hypertexts
The analysis of terminology on hypertexts
The technical (Cunningham, McCloud) and philosophical (Nelson,
Bolter, Landow) description of the known problems faced by
hypertexts had helped us to design Novelle. We started from
terminology.
Terms as ‘chapter’, ‘page’ or ‘footnote’ become senseless in the
new texts, or they highly change their meaning. What seems to be
lost is the relations, the texture underpinning the text itself –
etimologically, ‘texture’ and ‘text’ both derive from the late Latin
term textum, coined by the Roman Rhetorician Quintilianus.

5. Introduction Structure Architecture Conclusions
What we learned from hypertexts
Terms we adopt
Some keywords we found useful for our analysis:
web canvas instead of ‘web page’, much more clear and not
dependent from printing, from web comics (McCloud);
lexias, i.e. autonomous units of a hypertext, form hypertexts in
education (Bolter).
transclusion, i.e. a kind of quotation, but with the ability to follow
the evolution of the original document (see later).

6. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collections
without loss of context information.

7. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collections
without loss of context information.
comparing complex alternatives, i.e. how to get parallel or
alternative versions of the same document.

8. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collections
without loss of context information.
comparing complex alternatives, i.e. how to get parallel or
alternative versions of the same document.
typology of links, i.e. how to order links avoiding confusion.

9. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Known problems as traced by Nelson, 1992
the framing problem, i.e. how to extract sub-collections
without loss of context information.
comparing complex alternatives, i.e. how to get parallel or
alternative versions of the same document.
typology of links, i.e. how to order links avoiding confusion.
version control, i.e. how to keep track of the history of every
document.

10. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved.

11. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.

12. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.
comparing complex alternatives is not solved.

13. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.
comparing complex alternatives is not solved. A cue is given
by the document history model by wikis, but it works only on
a chronological basis.

14. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.
comparing complex alternatives is not solved. A cue is given
by the document history model by wikis, but it works only on
a chronological basis.
typology of links is not solved.

15. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.
comparing complex alternatives is not solved. A cue is given
by the document history model by wikis, but it works only on
a chronological basis.
typology of links is not solved. The (X)HTML standard(s) of
the anchor tag is too generic to give a typology.

16. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.
comparing complex alternatives is not solved. A cue is given
by the document history model by wikis, but it works only on
a chronological basis.
typology of links is not solved. The (X)HTML standard(s) of
the anchor tag is too generic to give a typology.
version control is solved

17. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
Which problems are already solved?
the framing problem is not solved. We think the best
approximation is to let the users be able to extract
subcollection on-the-fly, i.e. extractions are not permanent,
they are view of lexias.
comparing complex alternatives is not solved. A cue is given
by the document history model by wikis, but it works only on
a chronological basis.
typology of links is not solved. The (X)HTML standard(s) of
the anchor tag is too generic to give a typology.
version control is solved by the wiki model of document
history, so we keep this solution.

18. Introduction Structure Architecture Conclusions
Known problems and proposed solutions
The wiki model of document history
a very old an old the current the last
version version version version
the document
creation destruction
history timeline
an edit a restore
sandbox

19. Introduction Structure Architecture Conclusions
Ownership and licencing
The problem of ownership
In order to address the remaining problems, we found that we had
to make a choice for the problem of ownership.

20. Introduction Structure Architecture Conclusions
Ownership and licencing
The problem of ownership
In order to address the remaining problems, we found that we had
to make a choice for the problem of ownership.
The Blog Way. Blogs follow the annotation model, where a single
lexia is central and the others are comments, sometimes organized
in threads (“write once, read many”). Advantage: suitable for a
lot of licences.

21. Introduction Structure Architecture Conclusions
Ownership and licencing
The problem of ownership
In order to address the remaining problems, we found that we had
to make a choice for the problem of ownership.
The Blog Way. Blogs follow the annotation model, where a single
lexia is central and the others are comments, sometimes organized
in threads (“write once, read many”). Advantage: suitable for a
lot of licences.
The Wiki Way. Wikis follow an free-to-edit model, where every
lexia is central: no authorship, no signature, no hierarchy (“write
many, read many”). Disadvantage: only GPL-like licences.

22. Introduction Structure Architecture Conclusions
Ownership and licencing
Solution: free licencing
We decided to let users/authors free to choose the licence of their
works, as in case or narrative or creative works ownership is treated
as authorship, even by fellows of free culture (Stallman, Lessig). In
other words, each user owns his own lexias (as blogs).

23. Introduction Structure Architecture Conclusions
Ownership and licencing
Solution: free licencing
We decided to let users/authors free to choose the licence of their
works, as in case or narrative or creative works ownership is treated
as authorship, even by fellows of free culture (Stallman, Lessig). In
other words, each user owns his own lexias (as blogs).
So, we decided to implement every standard Creative Commons
(cc) Licence version 2.0. Consequently, everybody is free to
comment everything, but freedom of everything may be denied
depending on the licence. This have to be chosen on lexia creation.

24. Introduction Structure Architecture Conclusions
Ownership and licencing
How to manage editing and create derivative works
an old the current
version version
the document
creation
history timeline
creation of a a new document
derivative work history timeline

25. Introduction Structure Architecture Conclusions
Ownership and licencing
For people who don’t like pictures
A user may let others edit his work, i.e. no No-Deriv option in the
CC licence. If so, he has the right to retain or refuse the attribution
after the edits – for comparison: wikis let only to restore
documents along history, you can’t “fork contents”; nor blogs.
In this case, a new history timeline start and a derivative link will
be put to mark the derivation from the original work.

26. Introduction Structure Architecture Conclusions
Ownership and licencing
Transclusion: beyond quotation
the current
version
the document
history timeline
transclusion
a freezed quotation
an other document
history timeline

27. Introduction Structure Architecture Conclusions
Ownership and licencing
Again, for people who don’t like pictures
Every user may comment and quote works by others – max. 10%
of the original document may be quoted, as in the Italian Law. We
call the quoted text transclusion, following Nelson. Unlike the
cut-and-paste text, a transclusion retains a link to recall the
original context (quotation link), so it never points to out-to-date
data.
Furthermore, a transclusion may let the author/user to be living,
i.e. to be kept up-to-date along the history timeline of the original
document.

28. Introduction Structure Architecture Conclusions
Ownership and licencing
An up-to-date transclusion example
an old the current
version version
the document
history timeline
transclusion
an up-to-date
quotation
an other document
history timeline

29. Introduction Structure Architecture Conclusions
Ownership and licencing
From transclusion to a typology of links
A quotation link is a special case of the deep links, i.e. every link
that let users change the context. A web page becomes a view of
lexias, where relations/differences/comparison between lexias are
rendered visually in a single canvas. The choice of the (CC) licence
may be a guide for the user.

30. Introduction Structure Architecture Conclusions
Ownership and licencing
From transclusion to a typology of links
A quotation link is a special case of the deep links, i.e. every link
that let users change the context. A web page becomes a view of
lexias, where relations/differences/comparison between lexias are
rendered visually in a single canvas. The choice of the (CC) licence
may be a guide for the user.
So, we distinguish between shallow links, i.e. links in a single view
of lexias, and deep links, i.e. links that let users change view or
context.

31. Introduction Structure Architecture Conclusions
Ownership and licencing
From transclusion to a typology of links
A quotation link is a special case of the deep links, i.e. every link
that let users change the context. A web page becomes a view of
lexias, where relations/differences/comparison between lexias are
rendered visually in a single canvas. The choice of the (CC) licence
may be a guide for the user.
So, we distinguish between shallow links, i.e. links in a single view
of lexias, and deep links, i.e. links that let users change view or
context.
Finally, links to web materials out of our system will be marked as
external links.

32. Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and web
canvas as views of lexias.

33. Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and web
canvas as views of lexias.
comparing complex alternatives should be solved by
transclusions and the document history model by wikis.

34. Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and web
canvas as views of lexias.
comparing complex alternatives should be solved by
transclusions and the document history model by wikis.
typology of links, i.e. shallow vs. deep (quotation, derivative)
and external links should avoid chaos.

35. Introduction Structure Architecture Conclusions
New solutions to classic hypertext’s problems
Our solutions of open problems of hypertexts
the framing problem should be solved by deep links and web
canvas as views of lexias.
comparing complex alternatives should be solved by
transclusions and the document history model by wikis.
typology of links, i.e. shallow vs. deep (quotation, derivative)
and external links should avoid chaos.
version control is already solved by wikis.

36. Introduction Structure Architecture Conclusions
A simple overview
The Architecture of Novelle
This is a basic scheme of Novelle multi-tier architecture
GUI
AJAX
Ruby on Rails
RDBMS
XML
DBMS / Filesystem

37. Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because we
want to be able to save messages with their meanings.

38. Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because we
want to be able to save messages with their meanings.
XML is a W3C standard.

39. Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because we
want to be able to save messages with their meanings.
XML is a W3C standard.
XML lets us extend and connect Novelle with other
applications.

40. Introduction Structure Architecture Conclusions
Why XML for data?
XML, eXtensible Markup Language
We choose XML as language and meta-language because we
want to be able to save messages with their meanings.
XML is a W3C standard.
XML lets us extend and connect Novelle with other
applications.
Storing separately data from their representations lets a
system run more efficiently and quickly.

41. Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,
messages and their meanings.

42. Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,
messages and their meanings.
We tried to use other more classical solutions such
commercial databases (e.g. Oracle) or open-source software
(e.g. PostgreSQL, MySQL).

43. Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,
messages and their meanings.
We tried to use other more classical solutions such
commercial databases (e.g. Oracle) or open-source software
(e.g. PostgreSQL, MySQL).
None of these solutions let us store efficiently our data
structure.

44. Introduction Structure Architecture Conclusions
Why XML for data?
XML suites our needs for the Repository
We use XML trees to store together data, metadata,
messages and their meanings.
We tried to use other more classical solutions such
commercial databases (e.g. Oracle) or open-source software
(e.g. PostgreSQL, MySQL).
None of these solutions let us store efficiently our data
structure.
An Entity-Relationship schema can’t map exactly Novelle’s
data architecture.

45. Introduction Structure Architecture Conclusions
Why XML for data?
Why RDBMS don’t fit our needs
The commercial solutions we tested haven’t native support for
XML data except an emulation layer that maps XML trees
into E-R model to store data into tables, losing most of the
expressive power. These products also introduce a cost for
purchase and use them.

46. Introduction Structure Architecture Conclusions
Why XML for data?
Why RDBMS don’t fit our needs
The commercial solutions we tested haven’t native support for
XML data except an emulation layer that maps XML trees
into E-R model to store data into tables, losing most of the
expressive power. These products also introduce a cost for
purchase and use them.
Other free RDBMS, such as the most famous MySQL or
PostgreSQL, are compatible with XML data but they also
store XML trees in a relational schema or map the entire XML
tree as BLOB (Binary Large OBject) storing it in one large
table.

47. Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone as
native XML databases.

48. Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone as
native XML databases.
While Ozone, as an Object Oriented XML native database,
requires a large amount of memory for working on entire XML
trees, Xindice and eXist are two more interesting projects.

49. Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone as
native XML databases.
While Ozone, as an Object Oriented XML native database,
requires a large amount of memory for working on entire XML
trees, Xindice and eXist are two more interesting projects.
Xindice has not been developed since april 2004, so it is very
difficult to adopt it for a new project.

50. Introduction Structure Architecture Conclusions
Why XML for data?
Native XML databases
We tried using Xindice (by Apache Group), eXist, Ozone as
native XML databases.
While Ozone, as an Object Oriented XML native database,
requires a large amount of memory for working on entire XML
trees, Xindice and eXist are two more interesting projects.
Xindice has not been developed since april 2004, so it is very
difficult to adopt it for a new project.
eXist is more usable and stable, but it doesn’t implement full
XML standard and its performances are not so good (yet).

51. Introduction Structure Architecture Conclusions
Why XML for data?
XML Repository in the filesystem
Like most blogs and wikis, we choose to store Novelle XML
repository on time-based filesystem structure. Our representation is
a directory tree that reflects quite well our idea of history.

52. Introduction Structure Architecture Conclusions
Why XML for data?
XML Repository in the filesystem
Like most blogs and wikis, we choose to store Novelle XML
repository on time-based filesystem structure. Our representation is
a directory tree that reflects quite well our idea of history.
For every message Novelle stores three XML documents:
The message itself
Its past history
The filesystem directory tree

53. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick develop
cycle for web applications without the need to rewrite common
functions and classes (DRY - Don’t Repeat Yourself).

54. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick develop
cycle for web applications without the need to rewrite common
functions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. In
particular:

55. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick develop
cycle for web applications without the need to rewrite common
functions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. In
particular:
gdiff/gpatch creates a patch from two files.

56. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails: an open-source web framework
The Ruby on Rails (RoR) framework lets us a quick develop
cycle for web applications without the need to rewrite common
functions and classes (DRY - Don’t Repeat Yourself).
It provides XML builder and gdiff/gpatch libraries. In
particular:
gdiff/gpatch creates a patch from two files.
XML Builder offers a set of classes to menage XML files.

57. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails for the document history model
Using gdiff/gpatch we can implement our history model in an
easy way and saving space.

58. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails for the document history model
Using gdiff/gpatch we can implement our history model in an
easy way and saving space.
Moving across a history means to retrieve a fixed number of
subsequent patches.

59. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
Ruby on Rails for the document history model
Using gdiff/gpatch we can implement our history model in an
easy way and saving space.
Moving across a history means to retrieve a fixed number of
subsequent patches.
RoR doesn’t support XML native databases, so we temporarily
use a RDBMS only for RoR needs.

60. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
AJAX: Asyncronous Javascript And XML
AJAX is a web development tecnique for creating interactive
web applications. It uses a combination of XHTML,
Javascript, XML, CSS, DOM and the XMLHTTPRequest
object.

61. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
AJAX: Asyncronous Javascript And XML
AJAX is a web development tecnique for creating interactive
web applications. It uses a combination of XHTML,
Javascript, XML, CSS, DOM and the XMLHTTPRequest
object.
XMLHTTPRequest lets clients ask servers to give some
particular data using asyncronous handshake, while users can
still continue using the web application.

62. Introduction Structure Architecture Conclusions
Ruby on Rails and AJAX
AJAX: Asyncronous Javascript And XML
AJAX is a web development tecnique for creating interactive
web applications. It uses a combination of XHTML,
Javascript, XML, CSS, DOM and the XMLHTTPRequest
object.
XMLHTTPRequest lets clients ask servers to give some
particular data using asyncronous handshake, while users can
still continue using the web application.
Ruby on Rails fully supports AJAX.

63. Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simple
search engine.

64. Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simple
search engine.
The engine returns a list of meaning and a set of links
between them.

65. Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simple
search engine.
The engine returns a list of meaning and a set of links
between them.
These links are represented with clickable images. Every
image is itself a map that the user can surf and/or open to
increase details level.

66. Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simple
search engine.
The engine returns a list of meaning and a set of links
between them.
These links are represented with clickable images. Every
image is itself a map that the user can surf and/or open to
increase details level.
Users can create new typed links between lexias or
comment/modify every existing lexia if these actions are
granted by the author.

67. Introduction Structure Architecture Conclusions
Access Points
Access Points as a flexible model for navigation
In Novelle users can search through histories using a simple
search engine.
The engine returns a list of meaning and a set of links
between them.
These links are represented with clickable images. Every
image is itself a map that the user can surf and/or open to
increase details level.
Users can create new typed links between lexias or
comment/modify every existing lexia if these actions are
granted by the author.
These modifications are stored into the history of the
document.

68. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and common
terminology for the team – done.

69. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and common
terminology for the team – done.
Test technologies in order to find out what may fit our needs
– done.

70. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and common
terminology for the team – done.
Test technologies in order to find out what may fit our needs
– done.
Develop our first prototype with the basic data structure – in
progress.

71. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and common
terminology for the team – done.
Test technologies in order to find out what may fit our needs
– done.
Develop our first prototype with the basic data structure – in
progress.
Let users test our prototype with real data and real needs, in
order to have feedback about GUI and features – to do.

72. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and common
terminology for the team – done.
Test technologies in order to find out what may fit our needs
– done.
Develop our first prototype with the basic data structure – in
progress.
Let users test our prototype with real data and real needs, in
order to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-source
project – to do.

73. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Novelle’s milestones
Make a concept map to organize goals and common
terminology for the team – done.
Test technologies in order to find out what may fit our needs
– done.
Develop our first prototype with the basic data structure – in
progress.
Let users test our prototype with real data and real needs, in
order to have feedback about GUI and features – to do.
Adjust GUI and features. Publish Novelle as an open-source
project – to do.
Dig and extract sensible information automatically, thanks to
the well-structured context datas – to do.

74. Introduction Structure Architecture Conclusions
What is done, what’s still to do
Thanks
We wish to acknowledge Massimiliano Pepe for his collaboration.
Attribuzione - Non Commerciale - Condividi allo stesso modo 2.0 Italia
http://creativecommons.org/licenses/by-nc-sa/2.0/it/
You may have this file here: http://purl.org/net/fgobbo
Questions?