Novelle

  • 892 views
Uploaded on

Presented by me and Michele Chinosi at EACL2006

Presented by me and Michele Chinosi at EACL2006

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
892
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
29
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 a new document creation of a history timeline derivative work
  • 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?