Is there a need for a dedicated (scientific) article editor?

[michael]

Hi there, great effort!

I just thought our projects could be complimentary...

http://substance.io/texture/

We are solely focused on building an editor that stores content in a self-contained archive (e.g. a folder on the disk, using JATS-XML for storing the article data).

Based on that same architecture we are also working on reproducible web-publications, see:

http://builds.stenci.la/stencila/reproducible-publication-example-2018-04-16-dcf17f9/example.html?archive=repro-pub

[csarven]

@michael Thanks for raising this. Indeed complimentary. Just to be absolutely clear, it is not dokieli's intention (at least so far and in the foreseeable future) to have its own editor. The idea was to reuse a library that's already available - smart folks are doing great things in that space as you well know, so we reuse, and focus on other aspects of dokieli. The general plan was to allow different editors to work, but so far we've only worked with https://github.com/yabwe/medium-editor (ME).

Up to now, ME worked well enough with one of dokieli's design goals in that it had a relatively small footprint in the DOM eg. when adding a node, it didn't include any information that's specific to the library.. say a p would be just that, and no specialised attributes. I acknowledge that there are reasons why some editors do this and maybe there are ways to mute them, and just get the basic HTML out. Any way, that was one of the reasons to use ME. Having said that, there are other issues with ME which I won't delve into here.

The other aspect of the "editor" is I think perhaps closer to what you are getting at, ie. extensibility to do various interactions so to speak. I'd love to incorporate something like that, eg. executable blocks, rerendering based on some data.

Having any sort of a markup schema that may be imposed by the editor library is not particularly of interest. For example, dars/JATS-XML wouldn't be the reasons for dokieli to use Substance. I suppose I need to understand Substance better any way..

My question to you: is it possible to maintain the basic editor (content input) behaviour that we have with ME, but use Substance? If so, we can look into that, and then get more out of all the other cool things that Substance offers.

Happy to discuss this further in real-time if you'd like to share notes. Ping at https://gitter.im/linkeddata/dokieli , or we can audio/video if you like.

[michael]

Hi @csarven! I'd love to sync up. Maybe we can find a date/time in about 2-3 weeks?

Some quick thoughts:

If I understand correctly, you are building on top of HTML and enrich it with semantical information (RDF-style). That's a valid approach, and a lot of projects are following it. Especially when coming from the author's side.

We are following a different approach, which puts data (=pure content) first. With the Dar project we acknowledge that there's a difference between source and presentation. We model all data (content + metadata) in XML/JSON and don't use RDF ontologies at that "source" stage. On the presentation stage, we can use any HTML markup and enhance with RDFa etc. Another reason why we decided to go XML-first (in particular JATS), is that we want to support workflows at publishers. The long-term goal for Dar is to be a shared format for authors and publishers. Which means, you can make a submission (.dar file) to a journal, and they can perform review + production workflows on that same archive, without extra conversion. Authors and Publishers would each use specialised versions of Texture/Stencila for manipulating the archive.

Regarding your question: Yes it is possible to use Substance independently and based on a pure HTML model. That would mean though that another scientific editor would need to be maintained by someone. Would love to learn more about your requirements and if there was a chance that Texture could (at some point) serve as the editor component in the dokieli P2P system.

[michael]

Here's a related thread helping explain Dar workflows (with reproducibility in mind): https://github.com/substance/dar/issues/4