Re: [Orga-semantics-2018] Reply to Semantics Proceedings Inquiry

On 2018-02-06 09:46, Sebastian Hellmann wrote:
> On 06.02.2018 04:39, Sarven Capadisli wrote:

>> 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.

A generalisation.

> 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:
> HTML5 leaves out trailing </p> tags, etc. Many small diverse things.

Please provide a study for the claim "HTML is more difficult to produce".

Handcoding in LaTeX will give you the same class of issues.

Have a look at why Tim chose HTML for the Web:

LaTeX/PDF is a non-starter on the Web. If you have an error, you get
nothing/junk - not even useful on a desktop. HTML in the browser has
decent error-handling. You get something. That's an important difference
to keep in mind.

That validator shows 3 errors related to `meta`. Nothing to do with `p`.
It is clearly confused about RDFa on `meta`, hence the errors. Have a
look at the source! Verify.

Years of HTMLing thought me one thing. Don't blindly trust the tools
(validators, parsers) to implement specs flawlessly, nor maintained at
the level that one would like.

The RDF Ruby Distiller sees no (X)HTML issues:

119 triples are fine.

rapper will give you 138 triples.

I can't tell how many OpenLink Structured Data Sniffer gives right now
but it seems to have no issues.

All three detect the statement with `doap:maintainer` (express through
that `meta`) just fine. Even if the whole thing fell through the cracks
- either on my part of handcoding or the specs for whatever reason, it
is a trivial issue to resolve. Given everything else that's going on,
pointing that out is rather pedantic don't you think?

Not all HTML/RDF tooling do the same thing for day to day operations.
You'll have to go back and forth, and sometimes even overrule what the
tool says about your data (re spec, and many other reasons).

> 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.

As I've mentioned, the proceedings document which points to the article
(at least at is more or less a solved problem space. Some
of my colleagues can give you more information on the UI side of
generating CEUR-WS proceedings.

Authors should handle preparing their own HTML. That's how they want to
express the content, and so goes everything else eg CSS, JS. Organisers
shouldn't have to invest more energy into than they are already.

I'm going to side-step the issue on best tooling for adoption. People
have different preferences, accessibility requirements, familiarity,
environments that they work in. And again, I would rather not see people
being prematurely forced into using a particular tool or format.

> 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.

Yes, with you on fully supporting Hence stuff like:

See also:

CEUR-WS has provided a lot for this community, and I suggest we help
them more.

> PS: is a 404
Thanks. There is a typo.


Received on Tuesday, 6 February 2018 09:39:04 UTC