<-prev [Thread] next-> <-prev [Date] next->
Month Index | List Home

RE: [jats-list] How/When do you produce a JATS-XML version of you publication within your publication workflow

Subject: RE: [jats-list] How/When do you produce a JATS-XML version of you publication within your publication workflow
From: "Kelly, Laura (NIH/NLM/NCBI) [E]" <kelly@xxxxxxxxxxxxxxxx>
Date: Tue, 23 Oct 2012 12:25:07 -0400
>A big question, though, is whether PubMed Central would be willing to
>archive content when the body of the document is in a format other
>than JATS XML (possibly in a separate, accompanying file).

No, we aren't.

There have been cases where we've accepted metadata plus PDF for filling in
back content of data that has committed to sending us full-text XML for
current articles, but we won't accept non-XML or non-SGML (we do accept
non-JATS XML and even SGML) content for current data.

Laura

________________________________________
From: eaton.alf@xxxxxxxxx [eaton.alf@xxxxxxxxx] On Behalf Of Alf Eaton
[lists@xxxxxxxxxx]
Sent: Tuesday, October 23, 2012 10:10 AM
To: jats-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [jats-list] How/When do you produce a JATS-XML version of you
publication within your publication workflow

On 21 October 2012 17:26, Kevin Hawkins
<kevin.s.hawkins@xxxxxxxxxxxxxxxxxx> wrote:
> You clearly understand the problems here, and there are many points to
respond to.  Let me make an attempt at this.  I'm sure others will have things
to add.
>
> You've already decided to use OJS, so the first question is whether to
bother producing XML at all.

This raises an interesting question, which I was thinking about during
JATS-CON. If an article is authored in HTML, it's not entirely
straightforward to convert the body of the article to JATS markup. In
that case, is it possible to use JATS for the metadata (front and
back) of the article, but maintain the body of the article in the
original source format?

The source format might be HTML (in this case), PDF (as in the J-STAGE
converter <http://www.ncbi.nlm.nih.gov/books/NBK100490/> which only
extracts metadata so far), an image (from OCR), or even something
else.

An analogous element is Atom's "content" element, which has a "type"
attribute[1] containing the MIME type of the content within the
element.

The JATS "body" element only has a "specific-use" attribute, and the
element definition would have to be extended to allow non-JATS
content, so, instead, maybe a solution is to provide the main content
of the article in a separate file, and link to it within the body
element, like this?:

<article>
  <front>[...]</front>
  <body>
    <media mimetype="text" mime-subtype="html" xlink:href="index.html"
xlink:actuate="onLoad"/>
  </body>
  <back>[...]</back>
</article>

A big question, though, is whether PubMed Central would be willing to
archive content when the body of the document is in a format other
than JATS XML (possibly in a separate, accompanying file).

Alf

[1] http://tools.ietf.org/html/rfc4287.html#section-4.1.3.1
Current Thread
<- PreviousIndexNext ->
Re: [jats-list] How/When do you pro, Alf Eaton Thread Re: [jats-list] How/When do you pro, Alf Eaton
Re: [jats-list] How/When do you pro, Alf Eaton Date Re: [jats-list] How/When do you pro, Alf Eaton
Month