- From: Alf Eaton <eaton.alf@gmail.com>
- Date: Mon, 21 Mar 2016 19:28:54 +0000
- To: W3C Scholarly HTML CG <public-scholarlyhtml@w3.org>
- Cc: Robin Berjon <robin@berjon.com>
On 21 March 2016 at 14:15, Robin Berjon <robin@berjon.com> wrote: > My current thinking is that when you process an SH document, you > actually get two tree. One is the article tree, that is basically little > more than title/hunks/sections with sections containing that > recursively. The other is a metadata tree, which is basically the > JSON-LD tree rooted at the article resource (in JSON-LD terms, the graph > of the article is framed into the article resource). > > Both trees have identifiers that make it possible (even relatively easy) > to merge them back together. What we do is that we store both separately > (largely so that the metadata can be edited and enriched on its own) and > then we have a React component that just merges them back together. I agree (in JATS the separation is into <front> and <body> elements). The "Paper Now" tool I made works a similar way: the metadata is all in a YAML file[1], and the sections, figures, etc are all entirely separate[2]. When they're combined, though, the whole graph can be extracted[3]. [1] https://github.com/PeerJ/paper-now/blob/gh-pages/_data/article.yml [2] https://github.com/PeerJ/paper-now/tree/gh-pages/_sections [3] https://developers.google.com/structured-data/testing-tool?url=https%253A%252F%252Fpeerj.github.io%252Fpaper-now%252F
Received on Monday, 21 March 2016 19:29:43 UTC