- From: Sebastian Hellmann <kurzum@googlemail.com>
- Date: Tue, 6 Feb 2018 09:46:29 +0100
- To: Sarven Capadisli <info@csarven.ca>, Sebastian Hellmann <kurzum@googlemail.com>, Pellegrini Tassilo <Tassilo.Pellegrini@fhstp.ac.at>
- Cc: "orga-semantics-2018@lists.informatik.uni-leipzig.de" <orga-semantics-2018@lists.informatik.uni-leipzig.de>, "semantic-web@w3.org" <semantic-web@w3.org>
Hi Sarven, On 06.02.2018 04:39, Sarven Capadisli wrote: > On 2018-02-06 01:34, Sebastian Hellmann wrote: >> Hi Sarven, >> >> >> On 05.02.2018 23:29, Pellegrini Tassilo wrote: >>> * Why are contributors forced to communicate using print-centric medium >>> as opposed to Web? >> We did the exercise to publish HTML-only proceedings at CEUR for the >> posters last year: https://github.com/webdata/SEMANTiCS2017-posters/ >> >> This is complemented with a full RDF version in NIF and HDT, also >> Spotlight annotations. We are currently finishing it and submitting it >> to CEUR. Should only be another week now. >> >> As lessons learned, we can say, that http://dokie.li/ was not really >> recommendable, because the HTML editing lacked usability > > Classic straw man. I'm not even going to bother. > > Based on past conversations, I'm fairly certain that there is a giant > gap between what you think dokieli does or intended to do, and the > reality. Seems to be well documented. The main criteria here was the ease of doing the basics, i.e. getting the content in HTML to make it more accessible for machine-reading and NLP and also doing uniform proceedings. The other great intentions were more of a nice-to-have, but not essential. > But don't let me get in the way, please send the results of the > usability study. We (well Javier did most of it) tried to reformat an existing paper with each tool available and on this we based the decision. So it was very subjective, but this is probably what all users would base their decision on. You could debrief the authors of the proceedings what the main pain points were. We just want to finish the proceedings, not study it too much. My main point here is that HTML is more difficult to produce. Each paper had small different errors and our colleague Marvin was working on each of these individually. See e.g. here: https://validator.w3.org/nu/?doc=https%3A%2F%2Fdokie.li%2F HTML5 leaves out trailing </p> tags, etc. Many small diverse things. Google Docs Export or Latex2HTML would really help with adoption. I would really like to see more HTML in research, but doing the exercise I would say that it is still quite a chunk of work. Proceedings are still necessary in my opinion. On the other hand, if there were better tools, I am sure more people would switch, similar to how everybody switched to sharelatex and google docs. CEUR-WS is also a really good platform to publish. All the best, Sebastian PS: http://csarven.ca/dokeili-rww is a 404 > > >> We tried >> Google Docs, which is a very good HTML editor underneath, but it was >> hard to export it in a good way. Overall, we stuck with the tools of >> Silvio Peroni: https://github.com/essepuntato/rash They were quite >> good, but there was some conversion and post editing involved. We had to >> remove Javascript and there were some really difficult and specific >> issues found by the NU validator for HTML. >> >> So my answer to your question: while there are approaches, nobody solved >> the engineering problems involved. Latex2Rash export would be sweet and >> doesn't seem to hard. As far as I see from your publication list, you >> also did not manage to produce any proceedings according to the >> standards you request. Where is the proof of concept? >> >> For the other questions, you can also ask Elsevier. I am sure they will >> explain you all the different details of their offers. We are just >> users, so we rely on good tools and organisations to publish. > > You need to be more precise on a number of things up there. Which > engineering problems are you referring to exactly? I think you are > conflating articles and proceedings. > > CEUR-WS's proceedings template uses a subset of dokieli's HTML patterns. > Tooling at: > > https://github.com/ceurws/ceur-make/tree/dev/dokieli > > Here is one: > > http://ceur-ws.org/Vol-1809/ > > > dokieli was *never* advertised to do any print-centric stuff. What > "proof of concept" are you are referring to? My own articles? > > http://csarven.ca/dokeili-rww > > What do you think that I didn't "eat my own dogfood" on exactly? ;) > > > I was approached about dokieli and your posters session. So I explained > what dokieli does, its approach, intentions, and differences from other > tooling etc. I've asked you numerous times to define the > criteria/requirements for what you seek. I'm not here to sell you a tool > or try to force you to use one. > > I've been a strong proponent for not forcing a particular tool / format > on article/review contributions, and to strive for interopable > solutions. You've decided to do otherwise for the posters. Forcing a > particular toolchain is a crystal clear case of what's widely accepted > to lead to "vendor lock-in" solutions. Anyone that puts in an honest 10 > seconds into my work or initiatives can tell you that. > > > -Sarven > http://csarven.ca/#i
Received on Tuesday, 6 February 2018 08:47:47 UTC