W3C home > Mailing lists > Public > public-scholarlyhtml@w3.org > September 2017

Re: html for scholarly communication: RASH, Scholarly HTML or Dokieli?

From: Sarven Capadisli <info@csarven.ca>
Date: Wed, 6 Sep 2017 12:08:05 +0200
To: public-scholarlyhtml@w3.org
Message-ID: <06a4fd34-2ec8-febe-71f2-8de83df1ce3d@csarven.ca>
On 2017-09-06 10:52, Johannes Wilm wrote:
> Hey,
> at Fidus Writer [1] we are about ready to convert from our basic HTML
> exporter to one of the standards. As I understand it, there are
> currently three standards out there that more or less aim to do the same
> thing: RASH [2], Scholarly HTML [3], and Dokieli [4]. We had thought we
> would go for Scholarly HTML, but now I am not sure if it is being
> maintained at all any more. Is there a reason why we have three
> different formats for this? Are we moving toward just one, or do they
> have different purposes? 
> 
> Also, I see that RASH and Dokieli allow metadata to be added in a
> variety of different formats. I wonder if one of the ways is the
> recommended way to ensure that other tools can work with the data later on?
> 
> [1] https://www.fiduswriter.org
> [2] https://github.com/essepuntato/rash
> [3] https://w3c.github.io/scholarly-html/
> [4] https://github.com/linkeddata/dokieli
> 
> -- 
> Johannes Wilm
> http://www.johanneswilm.org
> tel: +1 (520) 399 8880


dokieli's docs [1] explains its principles, architectural and design
patterns. Its decisions on HTML patterns for articles, annotations, and
notifications takes a holistic approach in that it can be (re)consumed
and interacted on by different applications (as much as one can aim it
to be). That is, its HTML tries to follow DRY principles across those
three documents, provided that different CSS (ACM, LNCS, etc) - similar
to CSS Zen Garden to some extent - can be effectively applied without
having to change the HTML, all meanwhile JavaScript can extract or
insert data via HTML(+RDFa), as well as other RDF serializations.

I think of dokieli's HTML patterns in terms of guidelines in the docs
because we haven't found a particular good reason to constrain HTML5
based on our scope and use cases. In contrast, formats and the tooling
specifically built around them are fine, but they come with a major
caveat that they tend to age (fast). Enforcing an HTML pattern leads to
a tooling lock-in - history shows this.

For the time being, I think dokieli's HTML patterns have already proven
to work well enough. See also [2] which lists self-published articles in
the wild.

There is still a lot of room for improvement as we discover and
integrate other functions of scholarly communication, with strong
emphasis on decentralisation and interoperability.

[1] https://dokie.li/docs
[2] https://github.com/linkeddata/dokieli/wiki#examples-in-the-wild

-Sarven
http://csarven.ca/#i
Received on Wednesday, 6 September 2017 10:13:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 September 2017 10:13:00 UTC