- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 1 Dec 2015 11:56:18 -0500
- To: Ivan Herman <ivan@w3.org>
- Cc: W3C Scholarly HTML CG <public-scholarlyhtml@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Ivan, On 01/12/2015 03:59 , Ivan Herman wrote: > 1. The sad reality is that academic publishing is very > conservative (because people's livelihood depends on playing by the > rules), which also means that, at the end of the day, their > publication must end up by reputable(?) journals. And, at least in > 2015, most of those journals are still bound by formatting rules > that are, though antiquated, nevertheless prevalent (the ACM or > Springer formats are probably the best known examples in computer > science or mathematics). This means that any environment based on > SH can be successful only if it is possible to produce, through > some clever software, HTML *as well as* PDF formats that abide to > those rules. Similarly, authors still use Microsoft Word, mostly, > to author their articles and tools must exist to convert those into > SH. These formats are indeed arbitrary and, as I said, antiquated > and often motivated by the not-invented-here syndrome (a good > example is the absolutely crazy proliferation of various formal > reference formats in the bibliography). But I believe that we have > to be pragmatic and not forget their existence. > > Whether these considerations will affect the final definition of > SH: I do not know. Mostly not, but maybe yes in some places (eg, > the reference format and vocabulary we use). But I think keeping > this in our back of our mind all the time is important. Silvio's > RASH format is a good example for such a full(er) environment, but > I let him comment on the details I think that there are at least two primary areas in which these constraints influence SH: – Semantics: whatever SH supports needs to be reasonably compatible with the data model used by publishers. This, of course, varies; but we should also expect notable similarities at a high level. Having written a tool to convert between bibliographic formats I'll attest that we can't perfectly map to everything just in that area; but I am confident that we can get "close enough". — Styling: the format needs to have sufficient markup backbone that it can be styled for both online and print PDFs (assuming reasonably recent tooling). I think that's largely achievable with today's tools. > (A good example from my own experience: I am part of the steering > committee for the WWW201X conferences. Our 'proceedings' has also > been published by the ACM, in their digital library, for many > years, although we also maintain the proceedings, free of charge > for everybody, on the Web. We would like to have a purely HTML > based proceedings eventually, and we are seriously considering > doing that for WWW2017. But it is clear for us that having a copy > of the articles in the ACM DL is important for our constituency.) Your use case is the use case of a *lot* of people, certainly of a lot of societies, journals, and conferences. That's why having a pivot format is useful: either the ACM will start accepting it, or someone will have written a tool to convert to whatever they accept. > 2. We should not look at SH in isolation, but should also consider > the environment they would be in. Of course, SH is an interchange > format but, on long term, we would also like to see academic > journals that are fully Web based using SH at their core. As an > example, I am co-author of a paper at PeerJ CS[1]: as an author, > the advantage is not (only) that it is in HTML, but also the whole > process of getting there which was offered (superbly, I must add) > by PeerJ: the reviewing, the commenting, etc. SH should make that > easy and smooth. Obviously, it is *not* our goal to come up with a > standard environment like PeerJ. But, again, design consideration > should keep that in the back of our mind. Well, our goals are certainly about the full environment :) But given a sane model, a lot of the specifics more or less Just Work™ (the "more or less" part being important). To give an example, we made https://github.com/scienceai/web-verse to support annotation models, notably for peer review, but it should work perfectly fine with any reasonable HTML vernacular. > B.t.w., it would be good to have people from places like PeerJ, > PLOS, arXiv, etc, in our midst… If you look closely you'll see that we have a few already ;) (But yes, we can always have more input.) > 3. The issue of archiving came up. I think we should also > seriously consider, from the start, that an SH, more exactly the SH > plus the surrounding information, should also be storable, for > offline usage *and* archiving, in EPUB of some version. Doing that > means we can provide a proper offline usage for the paper (and > forget about PDF in that respect) as well as ensure a certain level > of defense against link-rot. > > EPUB 3 definitely has some restrictions on what can or cannot be > included and what format can be used; we should know that. Note > also that the W3C DPUB IG is working on a more general vision, a > *draft* called Portable Web Publications[2] that may be the right > environment to consider in the future. Again: we should keep that > approach for archiving in mind... Yes, interop with EPUB 3/PWP/E0 is certainly very important. - -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing • -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWXdEyAAoJECyUfoUUVwDb1h4P/3qGH9bOJgmyOdBxbME3ub8Y mT9U/t6o/rnh8+X0oiniWtuXt/mAzNDlPjFLXz0sPawGOBZted4pwL1fDsSrKJNz 1ZIGcc0LMM6NX0Mf15eNmLkYM2mrX6JFmzSuLpnmAIx54rDAMggccOFm6G+9mzBs bcf3IGuYZcD30FFc4s3zU/5QYNZcOC1l9izagh5zuCE8zWDMcFw8499vl7XvORjP TQoxSWV5CQsus/1/2E4mithCl/HZLnQKULsxtfzCgLzCKbjteUFvL99mG+OxI0JJ M06Lu/XGNk7e1ugWrENahzBiIhYmQSmRL6i7w+95Xc+RY3D+yfEBvA8Ad1So0u3U TGeKau4rGYTvhf2KtT3NQdTqPBN13OvbgFkZpUuxU0tV9Gc+wR32qyij42KVQ9Vq bwLSZKAIZ1AwfAMSz7E76rrgRie1i0bNKtF3DGOJSVB7ddQYOwfrCBpESR42WJvu HGONIXFdTHrRO9RSz2RBm8rLgAbehhtPR/206E3FVH9JmOile9AUUdjkOUhPd7+y +jy67V/ch6XD7v7hl8Vbd6kE6hdasnsa8RFwX18xRwkplKTYehqjdJQ2CZvz0pah I96lLNHMVlDse0IIj9V6g0a/SohnaTK64xdevPrqtGqGn/pWj2t+uQettj3f99yk IUS8vtRK5s1bJzp3I9BP =uurV -----END PGP SIGNATURE-----
Received on Tuesday, 1 December 2015 16:56:43 UTC