Research Articles in Simplified HTML: a Web-first format for HTML-based scholarly articles

HTML-based formats

One of the first documented contributions that proposed an HTML-based format for scholarly articles was Scholarly HTML (http://scholarlyhtml.org). It is not defined as a formal grammar, but as a set of descriptive rules which allows one to specify just a reduced amount of HTML tags for describing the metadata and content of a scholarly article. It is the main intermediate format used in ContentMine (http://contentmine.org) for describing the conversion of PDF content into HTML.

Along the same lines, PubCSS (https://github.com/thomaspark/pubcss/) is a project which aims at pushing the use of HTML+CSS for writing scholarly articles. It does not define a formal grammar for the HTML element set to use. Rather it provides some HTML templates according to four different CSS styles, which mimic four LaTeX styles for Computer Science articles, i.e., ACM SIG Proceedings, ACM SIGCHI Proceedings, ACM SIGCHI Extended Abstracts, and IEEE Conference Proceedings.

HTMLBooks (https://github.com/oreillymedia/HTMLBook/) is an O’Reilly’s specification for creating HTML documents (books, in particular) by using a subset of all the (X)HTML5 elements. This is one of the first public works by a publisher for pushing HTML-like publications, even if the status of its documentation (and, consequently, of its schema) is still “unofficial”.

Another project, which shares the same name of one of the previous ones, Scholarly HTML (https://github.com/scienceai/scholarly.vernacular.io), is a work by the science.ai (http://science.ai) company that aims at providing a domain-specific data format based on open standards (among which HTML5) for enabling “the interoperable exchange of scholarly articles in a manner that is compatible with off-the-shelf browsers” (Berjon & Ballesteros, 2015). While the format is not defined by any particular formal grammar, it has a well-described documentation (Berjon & Ballesteros, 2015) that teaches how to produce scholarly documents by using a quite large set of HTML tags, accompanied by schema.org (http://schema.org) annotations for describing specific structural roles of documents as well as basic metadata of the paper. The company also provides services that enable the conversion from Microsoft Word document into ScholarlyHTML format.

One of the authors of the previous work is also the chair of a W3C community group called “Scholarly HTML” (https://www.w3.org/community/scholarlyhtml/) which aims at developing a HTML vernacular (https://github.com/w3c/scholarly-html) for the creation of a Web-first format for scholarly articles. It involves several people from all the aforementioned specifications (including RASH), and the group work should result in the release of a community-proposed interchange HTML format. As of September 22, 2017, the online documentation (https://w3c.github.io/scholarly-html/) is mainly a fork of the Scholarly HTML specification proposed by science.ai discussed above.

HTML-oriented WYSIWYG editors

One of the most important and recent proposals, which is compliant with the principles introduced as part of the Linked Research (http://linkedresearch.org) project¹, is dokieli (https://dokie.li) (Capadisli et al., 2017). Dokieli is a web application (still under development) that allows the creation of HTML-based scholarly articles directly on the browser, and implements several features among which are annotations (in RDF) and a notification system. The application makes also available some HTML templates and a series of widgets for navigating, visualising (in different formats) and printing research documents easily by using common browsers.

Fidus Writer (https://www.fiduswriter.org/) is another Web-based application for creating HTML scholarly documents by means of a wordprocessor-like interface. While the particular format used is not explicitly specified, it allows the conversion of the HTML documents created within the application in two different formats, i.e., EPUB and LaTeX (alongside with HTML).

Authorea (https://www.authorea.com) is a Web service that allows users to write papers by means of a clear and effective interface. It enables the inclusion of the main components of scientific papers such as inline elements (emphasis, quotations, etc.), complex structures (figures, equations, etc.), and allows the use of Markdown and LaTeX for adding more sophisticated constructs. In addition, Authorea is able to export the document in four different formats (PDF, LaTeX, DOCX, and zipped archive with several HTML files) and according to a large number of stylesheets used in academic venues.

Theoretical foundations: structural patterns

While we have plenty of tools and languages for creating new markup languages (e.g., RelaxNG (Clark & Makoto, 2001) and XMLSchema Gao, Sperberg-McQueen & Thompson, 2012), these usually do not provide any particular guideline for fostering the development of robust and well-shaped document languages. In order to fill that gap, in the last decade we have experimented with the use of a theory of structural patterns for markup documents (Di Iorio et al., 2014), that has since been applied in several national and international standards, among which OASIS LegalDocumentML (https://www.oasis-open.org/committees/legaldocml/)³, a legal document standard for the specification of parliamentary, legislative and judicial documents, and for their interchange between institutions in different countries.

The basic idea behind this theory is that each element of a markup language should comply with one and only one structural pattern, depending on the fact that the element:

• can or cannot contain text (+t in the first case, −t otherwise);

• can or cannot contain other elements (+s in the first case, −s otherwise);

• is contained by another element that can or cannot contain text (+T in the first case, −T otherwise).

By combining all these possible values—i.e., ±t, ±s, and ±T—we basically obtain eight core structural patterns, namely (accompanied by a plausible example within the HTML elements):

1. inline [+t+s+T], e.g., the element em;

2. block [+t+s−T], e.g., the element p;

3. popup [−t+s+T], e.g., the element aside;

4. container [−t+s−T], e.g., the element section;

5. atom [+t−s+T], e.g., the element abbr;

6. field [+t−s−T], e.g., the element title;

7. milestone [−t−s+T], e.g., the element img;

8. meta [−t−s−T], e.g., the element link.

Instead of defining a large number of complex and diversified structures, the idea is that a small number of structural patterns are sufficient to express what most users need for defining the organisation of their documents. Therefore, the two main aspects related to such patterns are:

• orthogonality—each pattern has a specific goal and fits a specific context. It makes it possible to associate a single pattern to each of the most common situations in document design. Conversely, for every situation encountered in the creation of a new markup language, the corresponding pattern is immediately selectable and applicable;

• assemblability—each pattern can be used only in some contexts within other patterns. This strictness provides expressiveness and non-ambiguity in the patterns. By limiting the possible choices, patterns prevent the creation of uncontrolled and misleading content structures.

Such patterns allow authors to create unambiguous, manageable and well-structured markup languages and, consequently, documents, fostering increased reusability (e.g., inclusion, conversion, etc.) among different languages. Also, thanks to the regularity they provide, it is possible to perform easily complex operations on pattern-based documents even when knowing very little about their vocabulary (automatic visualisation of document, inferences on the document structure, etc.). In this way, designers can implement more reliable and efficient tools, can make a hypothesis regarding the meanings of the document fragments, can identify singularities and can study the global properties of a set of documents, as described in Di Iorio et al. (2012) and Di Iorio et al. (2013).

HTML does not use the aforementioned patterns in a systematic way, as it allows the creation of arbitrary and, sometimes, quite ambiguous structures. To apply the structural pattern guidelines for RASH, we restricted HTML by selecting a good subset of elements expressive enough to capture the typical components of a scholarly article while being also well-designed, easy to reuse and robust.

RASH: Research Article in Simplified HTML

The Research Articles in Simplified HTML (RASH) format is a markup language that restricts the use of HTML (http://www.w3.org/TR/html5/) elements to only 32 elements for writing academic research articles. It allows authors to use embedded RDF annotations. In addition, RASH strictly follows the Digital Publishing WAI-ARIA Module 1.0 (Garrish et al., 2016) for expressing structural semantics on various markup elements used.

All RASH documents begin as a simple HTML5 document⁴ (Hickson et al., 2014), by specifying the generic HTML DOCTYPE followed by the document element html with the usual namespace (“http://www.w3.org/1999/xhtml”) and with additional (and mandatory) prefix declarations through the attribute prefix ⁵. The element html contains the element head for defining metadata of the document according to the DCTERMS (http://dublincore.org/documents/dcmi-terms/) and PRISM (http://www.prismstandard.org/) standards and the element body for including the whole content of the document. The element head of a RASH document must include some information about the paper, i.e., the paper title (element title), at least one author, while other related information (i.e., affiliations, keywords and categories included using the elements meta and link) are optional. The element body mainly contains textual elements (e.g., paragraphs, emphases, links, and quotations) for describing the content of the paper, and other structural elements (e.g., abstract, sections, references, and footnotes) used to organise the paper in appropriate blocks and to present specific complex structures (e.g., figures, formulas, and tables).

In the following subsection, we provide a quick discussion about usage patterns in RASH, and introduce the tools used for developing its grammar.

 
 
<−− A paragraph  referring  to a footnote −−> 
< p > 
       In this  paragraph  there  is an  explicit  reference  to the 
     second  footnote<xref  rid="n2"></xref>. 
</p > 
 
<−− The  group  containing  all  the  footnotes −−> 
<fn−group> 
      <fn id="n1"> 
             < p >This is a paragraph  within a footnote.</p > 
      </fn> 
      <fn id="n2"> 
             < p >This is a paragraph  in  another  footnote.</p > 
             < p > 
                   All  the  footnotes  are  contained  in a group, so as 
               to  collect  them  together. 
          </p > 
      </fn> 
       ... 
</fn−group>    

 
 
<−− A paragraph  containing a footnote −−> 
< p > 
       In this  paragraph  the  footnote <fn id="n3"><p >That is 
     what we call  popup−based  behaviour!.</p></fn>  has  been 
     defined  directly  within  it. 
</p >    

 
 
<−− A paragraph  referring  to a footnote −−> 
< p > 
       In this  paragraph  there  is an  explicit  reference  to the 
     second  footnote< a href="#fn2"></a>. 
</p > 
 
<−− The  group  containing  all  the  footnotes −−> 
<section  role="doc−endnotes"> 
      <section  role="doc−endnote" id="fn1"> 
             < p >This is the  text of a footnote.</p > 
      </section> 
      <section  role="doc−endnote" id="fn2"> 
             < p >This is the  text of  another  footnote.</p > 
      </section> 
       ... 
</section>    

 
 
... 
<define  name="p"> 
      <element  name="p"> 
             <ref  name="attributes_html_element_no_role" /> 
             <ref  name="cm_inline" /> 
      </element> 
</define> 
... 
<define  name="aClass"> 
      <attribute  name="class"> 
             <data  type="NMTOKENS" /> 
      </attribute> 
</define> 
... 
<define  name="cm_inline"> 
      <zeroOrMore> 
             <choice> 
                   <text /> 
                   <ref  name="a" /> 
                   <ref  name="aRef" /> 
                   <ref  name="img" /> 
                   <ref  name="svg" /> 
                   <ref  name="math" /> 
                   <ref  name="img_math" /> 
                   <ref  name="span_latex" /> 
                   <ref  name="span" /> 
                   <ref  name="code" /> 
                   <ref  name="sub" /> 
                   <ref  name="sup" /> 
                   <ref  name="em" /> 
                   <ref  name="strong" /> 
                   <ref  name="q" /> 
             </choice> 
      </zeroOrMore> 
</define> 
... 
<define  name="attributes_html_element_no_role"> 
      <ref  name="attributes_html_generic" /> 
      <optional> 
             <ref  name="aClass" /> 
      </optional> 
      <ref  name="attributes_rdfa" /> 
</define> 
...    

 
 
<section  role="doc−bibliography"> 
      <h1>References</h1> 
      <ol> 
             <li id="Per2014" role="doc−biblioentry"> 
                   < p >Write  here  the  reference  entry.</p > 
             </li> 
             ... 
     </ol> 
</section>    

 
 
<math  xmlns="http://www.w3.org/1998/Math/MathML"> 
      <mi> π</mi> 
      <mo><!−− &InvisibleTimes; −−></mo> 
      <msup> 
             <mi> r</mi> 
             <mn>2</mn> 
      </msup> 
</math>    

 
 
<−− Specifying a formula  through  the  element  'img' −−> 
<img  role="math" src="formula.png" alt="r^2" /> 
 
<−− Specifying a formula  in  LaTeX  through  the  element  'span' −−> 
<span  role="math">∖pi r^2</span>    

 
 
<!−− MathJax  for multi−browser  support  of  LaTeX  formulas  and  MathML −−> 
<script  src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX− AMS−MML_HTMLorMML"> 
   </script>    

 
 
@prefix  cito: <http://purl.org/spar/cito/>  . 
<>  cito:credits <http://www.w3.org/TR/rdfa−syntax/>  .    

 
 
<html  prefix="cito: http://purl.org/spar/cito/"> 
       ... 
     < p > 
             RASH  has  been  developed  in  order  to  allow  anyone  to add 
         <span 
               property="cito:credits" 
               resource="http://www.w3.org/TR/rdfa−syntax/">RDFa</span> 
             annotations <a href="#rdfa"></a >  to any  element  of the  document. 
     </p > 
       ... 
</html>    

 
 
<script  type="text/turtle"> 
    @prefix  pro: &lt;http://purl.org/spar/pro/&gt; . 
    @prefix  foaf: &lt;http://xmlns.com/foaf/0.1/&gt; . 
    @prefix  sd: &lt;https://w3id.org/scholarlydata/person/&gt; . 
    sd:silvio−peroni a foaf:Person ; 
        foaf:givenName "Silvio" ; 
        foaf:familyName "Peroni" ; 
        foaf:homepage &lt;http://www.essepuntato.it&gt; ; 
        pro:holdsRoleInTime [ 
            a pro:RoleInTime ; 
            pro:withRole  pro:author ; 
            pro:relatesToDocument &lt;&gt; 
        ] . 
</script> 
 
<script type="application/ld+json"> 
    { 
        "@context": 
            { 
                "nick": "http://xmlns.com/foaf/0.1/nick", 
                "sd": "https://w3id.org/scholarlydata/person/" 
            }, 
        "@id": "sd:silvio−peroni", 
        "nick": ["S.", "essepuntato"] 
    } 
</script>    

Validating RASH documents

RASH has been developed as a RelaxNG grammar (Clark & Makoto, 2001), i.e., a well-known schema language for XML documents. All the markup items it defines are fully compatible with the HTML5 specifications (Hickson et al., 2014).

In order to check whether a document is compliant with RASH, we developed a script (https://github.com/essepuntato/rash/blob/master/tools/rash-check.sh) to enable RASH users to check their documents simultaneously both against the specific requirements in the RASH RelaxNG grammar and also against the HTML specification through W3C Nu HTML Checker (http://validator.w3.org/nu/). This will hopefully help RASH users to timely detect and fix any mistakes in their documents. This script also checks datatype microsyntaxes.

In addition to the aforementioned script, we developed a Python application (https://github.com/essepuntato/rash/tree/master/tools/rash-validator) that enables one to validate RASH documents against the RASH grammar. This application makes also available a Web interface for visualising all the validation issues retrieved in RASH documents.

Visualising RASH documents

The visualization of a RASH document is rendered by the browser by means of appropriate CSS3 (http://www.w3.org/Style/CSS/specs.en.html) stylesheets (Atkins Jr, Etemad & Rivoal, 2017) and Javascript developed for this purpose.

RASH adopts external libraries, such as Bootstrap (http://getbootstrap.com/) and JQuery (http://jquery.com/), in order to provide the current visualisation and include additional tools for the user. For instance, the footbar with statistics about the paper (i.e., number of words, figures, tables and formulas) and a menu to change the actual layout of the page⁸, the automatic reordering of footnotes and references, the visualisation of the metadata of the paper, etc.

Note that this kind of automatic rendering of paper items, such as references to a bibliographic entry or a figure, reduce the cognitive effort of an author when writing a RASH paper. For instance, a piece of text referencing a table, e.g., “as shown in Table 2”, is created without caring about the particular text to specify for that reference (“Table 2” in the example), since RASH prescribes to specify just an empty link to the object one wants to refer to, as shown in the following excerpt:

 
 
< p>... as  shown  in <a href="#table_patterns"></a >  ...</p >    

For these objects, the Javascript scripts decide which is the most suitable text to put there according to the type of the item referenced.

Converting RASH into LaTeX styles

We spent some effort in preparing XSLT 2.0 documents (Kay, 2007) for converting RASH documents into different LaTeX styles, such as ACM ICPS (http://www.acm.org/sigs/publications/proceedings-templates) and Springer LNCS (http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0), among the others. We believe this is essential to foster the use of RASH within international events and to easily publish RASH documents in the official LaTeX format currently required by the organisation committee of such events. Obviously, the full adoption of RASH or any other Web-first format would make these stylesheets not necessary but, currently, they are fundamental for the adoption of the overall approach.

Producing RASH from ODT and DOCX

We also developed two XSLT 2.0 documents to perform conversion from Apache OpenOffice documents (https://github.com/essepuntato/rash/blob/master/xslt/from-odt.xsl) and Microsoft Word documents (https://github.com/essepuntato/rash/blob/master/xslt/from-docx.xsl) into RASH documents. The RASH documentation provides a detailed description of how to use Apache OpenOffice (https://rawgit.com/essepuntato/rash/master/documentation/rash-in-odt.odt) and Microsoft Word (https://rawgit.com/essepuntato/rash/master/documentation/rash-in-docx.docx) for writing scientific documents that can be easily converted to the RASH format. The standard features of these two editors (e.g., styles, document properties, etc.), elements (e.g., lists, pictures, captions, footnotes, hyperlinks, etc.) and facilities (e.g., mathematical editor, cross-reference editor, etc.) can be used to produce fully compliant RASH documents. A web-based service, for converting documents online (presented in ‘ROCS’) and two Java applications for ODT (https://github.com/essepuntato/rash/tree/master/tools/odt2rash) and DOCX (https://github.com/essepuntato/rash/tree/master/tools/docx2rash) documents (that can be downloaded and used offline on the local machine) were developed to facilitate the conversion process of Apache OpenOffice and Microsoft Word documents into the RASH  format.

In the past few years, as sort of alpha-testing, we have used these conversion approaches with many internal projects in the Digital and Semantic Publishing Laboratory of the Department of Computer Science and Engineering at the University of Bologna. Moreover, also our co-authors and collaborators from different disciplines (e.g., business and management, humanities, medicine, etc.) have successfully used this approach for producing their documents, giving us a chance to have fruitful feedback, comments, and suggestions. In particular, we have been able to convert with discrete success several ODT and DOCX files of research papers, PhD theses, documentations, and project proposals and deliverables.

ROCS

We created an online conversion tool called ROCS (RASH Online Conversion Service) (http://dasplab.cs.unibo.it/rocs) (Di Iorio et al., 2016) for supporting authors in writing RASH documents and preparing submissions that could be easily processed by journals, workshops, and conferences. ROCS integrates the tools introduced in the previous sections.

The abstract architecture of the tool is shown in Fig. 2. ROCS allows converting either an ODT document or a DOCX document, written according to specific guidelines, into RASH and, then, into LaTeX according to the following layouts: Springer LNCS, ACM IPCS, ACM Journal Large, PeerJ. Such guidelines, introduced in ‘Producing RASH from ODT and DOCX’, are very simple and use only the basic features available in Apache OpenOffice Writer and in Microsoft Word, without any external tool or plug-in.

ROCS allows users to upload four kinds of file, i.e., an ODT document, a DOCX document, an HTML file compliant with RASH, and a ZIP archive which contains an HTML file compliant with RASH and related files (i.e., CSSs, javascript files, fonts, images). It returns a ZIP archive containing the original document plus all its converted versions, i.e., RASH, if an ODT/DOCX file was given, and the LaTeX file.

The main advantage of having the paper both in RASH and in LaTeX is that it is fairly easy for RASH to be adopted by workshops, conferences or journals. Since the program committee, the reviewers, and the editors have also access to a LaTeX or a PDF version of the paper, the RASH file is an addition that does not preclude any current workflows. Of course, the hope is that the inherent advantages of an HTML-based format such as RASH will eventually persuade stakeholders to adopt the HTML version whenever it is possible, keeping the alternatives as fall-back options.

Enriching RASH documents with structural semantics

Another development of the RASH Framework concerns the automatic enrichment of RASH documents with RDFa annotations defining the actual structure of such documents in terms of the FRBR-aligned Bibliographic Ontology (FaBIO) (http://purl.org/spar/fabio) and the Document Component Ontology (DoCO) (http://purl.org/spar/doco) (Constantin et al., 2016). More in detail, we developed a Java application called SPAR Xtractor suite⁹. SPAR Xtractor is designed as a one-click tool able to add automatically structural semantics to a RASH document. SPAR Xtractor takes a RASH document as input and returns a new RASH document where all its markup elements have been annotated with their actual structural semantics by means of RDFa. The tool associates a set of FaBIO or DoCO types with specific HTML elements. The set of HTML elements and their associations with FaBIO or DoCO types can be customised according to specific needs of expressivity. The default association provided by the current release of SPAR Xtractor is the following:

• the root html element is mapped to an individual of the class fabio:Expression (http://purl.org/spar/fabio/Expression). The class fabio:Expression identifies the specific intellectual or artistic form that a work takes each time it is realised;

• the body element is mapped to an individual of the class doco:BodyMatter (http://purl.org/spar/doco/BodyMatter). The class doco:BodyMatter is the central principle part of a document, it contains the real document content, and it is subdivided hierarchically by means of sections;

• p elements are represented as individuals of the class doco:Paragraph (http://purl.org/spar/doco/Paragraph), i.e., self-contained units of discourse that deal with a particular point or idea;

• figure elements containing the element img within a paragraph are represented as individuals of the class doco:FigureBox (http://purl.org/spar/doco/FigureBox), which is a space within a document that contains a figure and its caption;

• section elements are mapped to individuals of the class doco:Section (http://purl.org/spar/doco/Section), which represents a logical division of the text. Sections can be organised according to a variable level of nested sub-sections. Accordingly, SPAR Xtractor reflects this structural behaviour by representing the containment relation by means of the object property po:contains (http://www.essepuntato.it/2008/12/pattern#contains)¹⁰. For example, a certain section element with a nested section element produces two individuals of the class doco:Section (e.g., :section_outer a doco:Section and :section_inner a doco:Section) related by the property po:contains (e.g., section_outer po:contains :section_inner).

In addition to these semantic annotations, which come from the actual structure of a document, the tool is also able to automatically detect sentences and annotate them as individuals of the class doco:Sentence (http://purl.org/spar/doco/Sentence). A doco:Sentence denotes an expression in natural language forming a single grammatical unit. For the sentence detection task, SPAR Xtractor relies on the sentence detection module of the Apache OpenNLP project (https://opennlp.apache.org/), which provides a machine learning based toolkit for the processing of natural language text. By default, SPAR Xtractor is released to support English only. However, it is possible to extend it with new languages by adding their corresponding models for Apache OpenNLP, most of which are available with an open licence (http://opennlp.sourceforge.net/models-1.5/).

We remark that the object property po:contains is used for representing any kind of containment relation among the structural components that SPAR Xtractor deals with. Hence, the usage of such a property is not limited to the individuals of the class doco:Section only. In fact, the property po:contains can be used, for example, for expressing the containment relation between a doco:BodyMatter and a doco:Section or between a doco:Section and a doco:Sentence. For example, let us consider the following code snippets that provide a sample HTML document.

 
 
<html> 
  ... 
  <body> 
     ... 
     <section>< h1> A section</h1> 
       ... 
       < p >This is a sentence. This is  another  sentence  of this  paragraph.</p > 
       ... 
       <section>< h1> A sub−section</h1>  ... </section> 
       ... 
     </section> 
    ... 
  </body> 
</html>    

The HTML document in the snippet above is enriched by SPAR Xtractor resulting in the document reported in the snippet below.

 
 
<html 
  resource="expression" 
  typeof="http://purl.org/spar/fabio/Expression"> 
  ... 
  <body  resource="body" 
    typeof="http://purl.org/spar/doco/BodyMatter" 
    property="http://www.essepuntato.it/2008/12/pattern#contains"> 
    ... 
    <section  resource="section_outer" 
      typeof="http://purl.org/spar/doco/Section" 
      property="http://www.essepuntato.it/2008/12/pattern#contains"> 
      <h1  resource="section_outer/title" 
        typeof="http://purl.org/spar/doco/SectionTitle" > 
        <span  property="http://purl.org/spar/c4o/hasContent"> 
          A section 
        </span> 
      </h1> 
      ... 
      <p resource="section_outer/paragraph−1" 
        typeof="http://purl.org/spar/doco/Paragraph" 
        property="http://www.essepuntato.it/2008/12/pattern#contains" > 
        <span  property="http://www.essepuntato.it/2008/12/pattern#contains" 
          resource="section_outer/paragraph−1/sentence−1" 
          typeof="http://purl.org/spar/doco/Sentence"> 
          <span  property="http://purl.org/spar/c4o/hasContent"> 
            This is a sentence. 
          </span> 
        </span> 
        <span  property="http://www.essepuntato.it/2008/12/pattern#contains" 
          resource="section_outer/paragraph−1/sentence−2" 
          typeof="http://purl.org/spar/doco/Sentence"> 
          <span  property="http://purl.org/spar/c4o/hasContent"> 
            This is  another  sentence  of this  paragraph. 
          </span> 
        </span> 
      </p > 
      ... 
      <section  resource="section_inner" 
        typeof="http://purl.org/spar/doco/Section" 
        property="http://www.essepuntato.it/2008/12/pattern#contains"> 
        <h1  resource="section_inner/title" 
          typeof="http://purl.org/spar/doco/SectionTitle" "> 
        <span  property="http://purl.org/spar/c4o/hasContent"> 
          A sub−section 
        </span>  
      </h1> 
        ... 
      </section> 
      ... 
    </section> 
    ... 
  </body> 
</html>    

Writing RASH documents with a native editor

A recent development of RASH is the RASH Javascript Editor (RAJE) (https://github.com/essepuntato/rash/tools/RAJE) (Spinaci et al., 2017), a multiplatform What You See Is What You Get (WYSIWYG) word processor for writing scholarly articles in HTML, according to the RASH format. In particular RAJE allows authors to write research papers in HTML natively by means of a user-friendly interface, instead of writing raw markup with an IDE, a text editor or any external word processor

RAJE guarantees to its users the benefits of a word processor combined with those given by an HTML-based format, i.e., interactiveness, accessibility and easiness to be processed by machine. In addition, RAJE uses the GitHub API (https://api.github.com/) so as to allow authors to store their articles online, to keep track of changes by means of the GitHub services, and to share the articles with others.

SAVE-SD 2015 and 2016

SAVE-SD 2015 was organized by some of the authors of this paper with the aim of bringing together publishers, companies, and researchers in order to bridge the gap between the theoretical/academic and practical/industrial aspects in regard to scholarly data. It was thus a multifaceted workshop which drew researchers from a number of heterogeneous fields, such as Document and Knowledge Engineering, Semantic Web, Natural Language Processing, Scholarly Communication, Bibliometrics and Human–Computer Interaction. Since many of the interested researchers were keen on experimenting with novel technologies regarding semantic publishing, it was a natural choice for the debut of RASH. For this reason, SAVE-SD 2015 allowed authors to submit papers using either RASH or PDF, explicitly encouraging authors to test the new format. To this end, the organisers introduced a special award for the best submission in RASH, according to the quality of the markup, the number of RDF statements defined in RDFa, and the number of RDF links to LOD datasets. The possibility of submitting in RASH was also advertised on social media (e.g., Twitter (https://twitter.com/savesdworkshop)), Facebook (https://www.facebook.com/savesdworkshop)) and during various international events (e.g., DL 2014 (http://www.city.ac.uk/digital-libraries-2014), EKAW 2014 (http://www.ida.liu.se/conferences/EKAW14/home.html), FORCE 2015 (https://www.force11.org/meetings/force2015)).

The initiative had a substantial success: the workshop received six out of 23 submissions in RASH and after the review process an additional author chose to prepare the camera-ready paper in RASH. Out of these seven final submissions, three were research papers, one was a position paper, and three posters/demo. These papers were submitted by 16 authors from Switzerland, Italy, Germany, Netherlands, United Kingdom, Ireland, and the USA.

At the time of the workshop submission deadline, there were no public tools available for converting other formats into RASH. However, the authors were able to self-learn it by simply referring to the documentation page, confirming that computer scientists have no particular problem in handling it directly. The conversion of the RASH submissions into the ACM format requested by the Sheridan publisher (responsible for the publications of all WWW proceedings) was handled by the organisers through a semi-automatic process. In particular, they used the XSLT files introduced in ‘Converting RASH into LaTeX styles’ and had to fix only a few layout misalignments.

Six authors and four reviewers involved in SAVE-SD 2015 participated in our evaluation.

SAVE-SD 2016 had the same characteristics and goals of the predecessor. In order to give authors full freedom, the organizer decided to accept not only RASH, but any kind of HTML-based format. Since it was not possible to handle the conversion of all possible HTML-based format to the publisher layout, the authors of alternative formats were asked to prepare a PDF of the camera-ready version according to the publisher needs.

SAVE-SD 2016 received 6 out of 16 submissions in RASH from 14 authors from Italy, Sweden, Greece, Germany, Belgium, and the USA. In total, five out of the 14 accepted papers were in RASH, including two full papers, two demos, and one position paper. Even if no author chose to submit in other HTML-based formats, this possibility will be kept open in future editions. Differently from the previous edition, the proceedings were published as a dedicated LNCS volume. The conversions of RASH papers to the PDF documents in Springer LNCS layout was automatically handled by ROCS.

As in the previous workshop, we evaluated RASH by conducting the same study (with the same exact questions) on ten people. Seven authors of RASH papers and three reviewers participated in the survey.

User background

It is useful to first assess the background of RASH pioneer users in term of their knowledge of relevant technologies and software. For this reason, the first section of the survey included a number of statements about the user expertize (e.g., “I have extensive experience in writing academic papers with LaTeX”) and allowed five response options, from “Strongly Agree” to “Strongly Disagree”. Table 3 shows the percentage of users who claimed to be familiar with a range of technologies (by selecting “Agree” or “Strongly Agree”).

In 2015, the authors were mainly from the Semantic Web community and therefore familiar with technologies such as RDFa and Turtle. Most of them knew how to correctly annotate an HTML file and understood the advantages of including semantic relationships in the paper. They also commonly used LaTeX rather than Microsoft Word or OpenOffice Writer. This suggests that they were acquainted with WYSIWYG editors and had experience with complex formats. A qualitative analysis of the survey answers confirms this intuition; for example, an author remarked: “I am used to writing papers in LaTeX so I do not want to bother with formatting and in that sense RASH is similar”.

In 2016 the situation changed and only 57% of the users were familiar with semantic technologies. In addition, even if most of them knew how to use LaTex, the majority of them had experience also with Microsoft Word. It seems thus that RASH started to interest also less technical users with different research backgrounds.

User survey

We assessed the strengths and weaknesses of RASH by means of six open questions. We summarize here the answers of both authors and reviewers for the 2015 and 2016 workshops. The reviewers answered only questions 2, 3, 4 and 5. Note that the questions were exactly the same in both editions and none of the users partecipated in both the surveys.

RASH usability

We also performed a quantitative analysis of the usability of RASH, using the System Usability Scale (SUS) questionnaire (Brooke, 1996). The scores are acceptable, though not very high, especially if we consider that all authors but one edited RASH files directly with text/XML editors. Users perceived even a ‘vanilla RASH’ as acceptable, though they need more sophisticated converters as remarked in the open questions of the survey.

RASH yielded a mean score of 62.7 ± 11.9, slightly lower than the average SUS score (68). However, SUS scores varied dramatically according to the person’s background. Figure 3 shows the results of different categories of expertize¹¹ in HTML, LateX, and Semantic Web Technologies (SWT), which appear correlated with the average SUS scores (respectively r = 0.78, 0.97, 0.99). Users with a strong expertize in LaTeX and SWT yielded significantly better SUS scores than the other authors, while authors with HTML expertize yielded only slightly better scores. For this reason, authors from 2015, who as previously discussed had a higher expertize in these categories obtained an average SUS score of 69.6 ± 11.9, while the authors from 2016 yielded 57.1 ± 9.7. However, the difference is not statistically significant because the two samples are small and the test power is low.

These results further confirm that most users with limited expertize in non-WYSIWYG editors and semantic technologies find it unfeasible to write HTML directly, even in a simplified form.

Analysis of RDF annotations in RASH documents

To complete the previous analysis, we also studied the nature of the semantic annotations in RASH papers. We focused on a sample of 1,751 annotations obtained from 11 papers published in SAVE-SD 2015 and 2016. The number of statements in a single paper was found to range from 24 to 903, yielding a median value of 46 (25th percentile 34, 75th percentile 175). We extracted all the RDF statements by running the W3C RDFa 1.1 Distiller service (https://www.w3.org/2012/pyRdfa/) on each article. We then considered only the statements that used http-based entities as predicates, or their objects if used for typing resources. The data are organised in several CSV files and have been obtained by running a Python script we developed for gathering the data used in this evaluation. The script and all the aforementioned data have been made available at Osborne & Peroni (2016).

The first goal of the study was to determine the prevalent vocabularies and how much they were used in the average paper. The left panel of Fig. 4A shows the common vocabularies. Schema.org and PRISM are actually enforced by RASH: the first is used for standard metadata such as emails, affiliations and organization names and the second for keywords. In addition, a quantity of RDF statements was automatically extracted when processing DPUB-ARIA roles (Garrish et al., 2016). Thus we will not consider such vocabularies in the rest of the evaluation. The other common vocabularies are Dublin Core, which appears in 82% of the papers, FOAF (27%) and the SPAR ontologies (Peroni, 2014a), such as FABIO (36%) and CITO (27%) (Peroni & Shotton, 2012). The right panel of Fig. 4B illustrates the average number of statement for each of these vocabularies. Dublin Core characterizes the highest number of annotation (9.4), followed by FOAF (7.4) and FABIO (6.4).

We also performed a more fine-grained analysis considering the amount of entities of these vocabularies within the various RDF statements. The goal was to understand the percentage of contribution that the various entities provide (on average) to the statements of the document analysed. As expected, the entities that contribute to about 60% of the statements are either those that are obliged by RASH (prism:keyword 6.9%, schema:affiliation 5.7%, schema:name 5.3%, and schema:email 4.7%) or those automatically extracted by processing the DPUB roles included, mandatorily, in the documents (xhtml:role 38%). Excluding these, the following top ten entities, shown in Fig. 5, cover about 20% of the statements.

Among these entities, there are three classes describing three diverse but interlinked kinds of objects, i.e., people (foaf:Person) authoring a research work (fabio:ResearchPaper) and the sentences (doco:Sentence) therein contained. The other seven entities are three object properties—two of them (pav:authoredBy and pattern:contains) provide the links between the three aforementioned classes, while the other, i.e., cito:cites, describes citation links between papers—and four data properties—used for providing additional metadata about the entities (dcterms:title, dcterms:bibliographicCitation, foaf:name) and for describing bunches of textual content of the sentences (c4o:hasContent).

Discussion

The evaluation study confirmed that RASH is ready to be adopted in workshops, conferences, and journals and can be quickly learnt by researchers who are already familiar with HTML. However, it also highlighted some issues in the adoption of HTML formats, especially by less technically savvy users.

Interestingly, the 2016 survey showed that RASH is being tried also by users unfamiliar with semantic web technology. While the expansion of the user base represents a positive development, it also yields a number of challenges. The mass of authors accustomed to WYSIWYG editors such as Microsoft Word or OpenOffice Writer, tend to have difficulties with HTML editors. In addition, since research papers are often written by multiple authors, it is usually simpler to use the most well-known solutions. For these reasons, we need to offer the authors who currently cannot or do not want to change their workflow the tools for converting their favourite format in to RASH and annotate the resulting paper. While ODT was a first step in this direction, it is imperative to be also able to process DOCX (which has been already implemented) and LaTeX. A second important issue is that authors who are not expert in semantic technologies can find it hard to correctly annotate their papers. Hence, we also need to use and/or develop simple tools for helping authors in this phase—such as the OpenLink Structured Data Editor (http://osde.openlinksw.com/). The introduction of these solutions will be critical for motivating users to adopt HTML-based approaches and for creating a robust framework that can be used by expert and common users alike.

As far as the analysis of the RDF annotations in RASH documents is concerned, the outcomes highlighted that the users decided to adopt a few well-known standard vocabularies, rather than using a multiplicity of different solutions. The most used vocabularies other than Schema.org and PRISM (used by default by RASH), are Dublin Core, FOAF, and the SPAR ontologies. However, the outcomes of our evaluation generally show a quite low number of statements specified by the authors. This behaviour could derive from the lack of appropriate support for the annotation of RASH papers with RDF data. In addition, this low number seems not to be related to the research community the authors work in. For instance, several of the papers written by Semantic Web experts do not include any RDF statements other than those enforced by RASH.