Closed TEITechnicalCouncil closed 7 years ago
This issue was originally assigned to SF user: louburnard Current user is: lb42
Another example from: Kaur J, Lamb MM, Ogden CL. "The Association between Food Insecurity and Obesity in Children-The National Health and Nutrition Examination Survey."
which could be encoded as:
<profileDesc>
<abstract>
<div>
<head> BACKGROUND:</head>
<p>Food insecurity can put children at greater risk of obesity because of altered food choices and nonuniform consumption patterns.</p>
</div>
<div>
<head> OBJECTIVE:</head>
<p>We examined the association between obesity and both child-level food insecurity and personal food insecurity in US children.</p>
</div>
<div>
<head> DESIGN:</head>
<p>Data from 9,701 participants in the National Health and Nutrition Examination Survey, 2001-2010, aged 2 to 11 years were analyzed. Child-level food insecurity was assessed with the US Department of Agriculture's Food Security Survey Module based on eight child-specific questions. Personal food insecurity was assessed with five additional questions. Obesity was defined, using physical measurements, as body mass index (calculated as kg/m2) greater than or equal to the age- and sex-specific 95th percentile of the Centers for Disease Control and Prevention growth charts. Logistic regressions adjusted for sex, race/ethnic group, poverty level, and survey year were conducted to describe associations between obesity and food insecurity.</p>
</div>
<div>
<head> RESULTS:</head>
<p>Obesity was significantly associated with personal food insecurity for children aged 6 to 11 years (odds ratio=1.81; 95% CI 1.33 to 2.48), but not in children aged 2 to 5 years (odds ratio=0.88; 95% CI 0.51 to 1.51). Child-level food insecurity was not associated with obesity among 2- to 5-year-olds or 6- to 11-year-olds.</p>
</div>
<div>
<head> CONCLUSIONS:</head>
<p>Personal food insecurity is associated with an increased risk of obesity only in children aged 6 to 11 years. Personal food-insecurity measures may give different results than aggregate food-insecurity measures in children.</p>
</div>
</abstract>
</profileDesc>
Original comment by: @laurentromary
Note that this usage is reflected in most publishers' formats (from which we derive the TEI pivot format): Elsevier (with an abstract-sec element), Spinger (AbstractSection), and of course JATS, as shown in the example below:
<abstract abstract-type="executive-summary">
<sec id="st1">
<title>Background</title>
<p>Important controversies exist about the extent to which people's health status as adults is shaped by their living conditions in early life compared to adulthood. These debates have important policy implications, and one obstacle to resolving them is the relative lack of sufficient high-quality data on childhood and adult socioeconomic position and adult health status. We accordingly compared the health status among monozygotic and dizygotic women twin pairs who lived together through childhood (until at least age 14) and subsequently were discordant or concordant on adult socioeconomic position. This comparison permitted us to ascertain the additional impact of adult experiences on adult health in a population matched on early life experiences.</p>
</sec>
<sec id="st2">
<title>Methods and Findings</title>
<p>Our study employed data from a cross-sectional survey and physical examinations of twins in a population-based twin registry, the Kaiser Permanente Women Twins Study Examination II, conducted in 1989 to 1990 in Oakland, California, United States. The study population was composed of 308 women twin pairs (58% monozygotic, 42% dizygotic); data were obtained on childhood and adult socioeconomic position and on blood pressure, cholesterol, post-load glucose, body mass index, waist-to-hip ratio, physical activity, and self-rated health. Health outcomes among adult women twin pairs who lived together through childhood varied by their subsequent adult occupational class. Cardiovascular factors overall differed more among monozygotic twin pairs that were discordant compared to concordant on occupational class. Moreover, among the monozygotic twins discordant on adult occupational class, the working class twin fared worse and, compared to her professional twin, on average had significantly higher systolic blood pressure (mean matched difference = 4.54 mm Hg; 95% confidence interval [CI], 0.10–8.97), diastolic blood pressure (mean matched difference = 3.80 mm Hg; 95% CI, 0.44–7.17), and low-density lipoprotein cholesterol (mean matched difference = 7.82 mg/dl; 95% CI, 1.07–14.57). By contrast, no such differences were evident for analyses based on educational attainment, which does not capture post-education socioeconomic position.</p>
</sec>
<sec id="st3">
<title>Conclusion</title>
<p>These results provide novel evidence that lifetime socioeconomic position influences adult health and highlight the utility of studying social plus biological aspects of twinship.</p>
</sec>
</abstract>
Original comment by: @laurentromary
Permitting <div> elements within the header is quite a major change. I can think of at least two other less transgressive ways of meeting this use case (a) if the abstract is long enough to be subdivided, shouldn't it be a <div type="abstract"> within the <front>? (b) why not structure these examples using <list> <label> and <item>?
Original comment by: @lb42
These abstracts with formatting in look as if they belong in the <text>
. It strikes me as a very undesirable change to allow the structural elements in the header. I would note that the ref page for <abstract>
is quite specific: "The abstract for a born digital document should be located within the <front>
".
Original comment by: @sebastianrahtz
The problem is that the header is the right place for an abstract relating to primary source text (which of course may have its own <front>
). Since a primary source text can be a large volume, it's unrealistic to think that an abstract of it can be constrained to a single section. Therefore the <abstract>
element in the header must be able to handle multi-section abstracts. How that's best achieved is another matter. Is there a principled objection to the use of <div>
anywhere in the header? I've never heard one.
The rule that says "The abstract for a born digital document should be located within the <front>
is, IMHO, completely wrong. An abstract written by the authors of the original document should presumably be in the <front>
; if I come along later (as an editor, publisher or whatever) and add an abstract for my own purposes, that's metadata, and it belongs in the header.
Original comment by: @martindholmes
And the abstracts adduced by Laurent are all of the <front>
flavour, aren't they.
<p>
s, by analogy to the project description and other potentially wordy sections of the header?<div>
s are introduced for the sake of handling merely a sequence of paragraphs in a metadata-kind of abstract, encoders will try to (mis?)use that for the purpose of including <front>
-type abstracts.Original comment by: @bansp
Using the metadata header to contain what looks like a <floatingText>
of the abstract just seems, well, weird. How is the header now any different from the front matter? might as well go straight down the road to JATS and have no distinct metadata at all.
Is this really needed? Laurent's examples should plainly use <front>
, since he's using TEI to simulate JATS in a controlled environment (cf earlier TEI/ISO work), and Martin's example doesn't actually exist yet of a new structured abstract being written by a 3rd party for a born-digital doc. I'd say let sleeping dogs lie until you have to wake them up.
Original comment by: @sebastianrahtz
@Piotr
: One possible example of an abstract we will need to write is for John Stow's Survey of London, for which we're producing digital versions of several editions. If you look at the already-online BHO version of [the 1908 version of] the 1603 text:
http://www.british-history.ac.uk/no-series/survey-of-london-stow/1603
you'll see that the text is divided into several distinct sections with different purposes, including a series of individual chapters about the wards of the city, chapters on the municipal government system, sections on hospitals, parish churches, and various other curiousities. It's difficult to imagine constructing a worthwhile abstract for this text without dividing the abstract into headed sections; and only some sort of kludge would enable the use of headings interspersed inside a series of paragraphs.
The important thing here is that front matter is from the original text; you shouldn't really put modern editorial content into the <front>
alongside Stow's own front matter, which includes a dedicatory epistle. This, oddly enough, is what the BHO edition does: it has modern introductory material in its front matter, which then transitions (inside the same roman-numbered page sequence) into Stow's dedication. But this is because they're actually doing an edition of the Kingsford 1908 edition, and that's what Kingsford did, if I understand correctly.
But I take the point that we haven't written this abstract yet. It may turn itself into a critical introduction, which would itself be a born-digital text external to the Stow.
I also see the point about Laurent's cases, but I maintain there is a difference between an editor-supplied abstract (of which the author may know nothing at all) and an authorial abstract (such as an author would supply for an article they submit to a journal). The former belongs in the header; the latter in <front>
.
I worry about Piotr's point #2: this amounts to saying "if we provide this feature, people may abuse it for something it wasn't intended for." That's always true of every feature.
Original comment by: @martindholmes
I think Laurent's examples could all be handled by using a list inside the existing abstract element, with label to indicate the types. Alternatively, if there really is an agreed typology for these pseudo-divs within an abstract, typed ab elements could be used.
Original comment by: @lb42
I am completely in line with Martin. These are editorial abstracts which are maintained by publishers or, within publication repositories, by librarians as part of the metadata attached to whatever document. Finding arguments about why not to use the existing abstract element in such cases is weird. What is clear to me is that a) abstract contains a very poor number of possible children and b) div would ideally cover observed usages. I do not see the kind of ancestral fear generated by the idea of having div's there. This is a very localized use within a very specific element.
Original comment by: @laurentromary
Just seeing Lou's last comment: we are speaking here of a huge corpus of documents across all possible scientific domains where local practices have induced a wide variety of forms for abstracts. And yes, they do look like "small" documents at times. Hacking lists to this purpose would definitely not be generalizable.
Original comment by: @laurentromary
Discussion suggests we may need to define a different kind of <div> for the header (<section>)
Original comment by: @lb42
Original comment by: @lb42
Makes sense. Something simpler as div, I guess.
Original comment by: @laurentromary
Original comment by: @hcayless
Reassigning to Lou to produce non-transcriptional divs and ps.
Original comment by: @hcayless
Council reviewed this and also question of what belongs inside <front> Agreed that <front> can contain <div>s of any provenance i.e. both from original source and from elsewhere, irrespective of whether source is born digital. Not agreed how to handle structure, or lack of it, within <abstract> We could introduce new metadata-only division-like and block-level elements ("section", "para") with content models of (head?, (para|division)* ) and (model.restricted.phrase)* respectively. If it wasn;t for mixed-content problems, we could do without <para> We could add schematron rules to minimize impact of introducing <div, or <section. We did not reach a firm conclusion.
Hello all.
In that case i'd suggest adding abstracts to the exemples of the guidelines' description for <front>
element :
(front matter) contains any prefatory matter (headers, ++abstracts++, title page, prefaces, dedications, etc.) found at the start of a document, before the main body"
More controversial suggestion: also perhaps consider renaming renaming the element "<abstract>
" to "<metadescription>
" or something like this.
Motivation: when i was trying to encode a scientific paper's abstract in TEI i naturally tried to type "TEI abstract" in the search engine (which is a perhaps dumb but probably very common guidelines browsing strategy)... of course it sent me directly to the <abstract>
's element's page, and not <front>
's...
Reading this issue's history I now understand the explained difference between the <abstract>
tag as an encoder's addition in TEI council's perspective and "abstract" as a common sense word. It makes sense :+1: but because of the tag's denomination it is (once again) slightly cryptic when coming from the librarian's world with a search engine query like "how to encode my abstract in TEI". Hence the suggested changes.
To answer Lou's comment, I like the idea of controlling the presence of div, p etc. in abstract by means of schematron rules. Since we have no other means to implement polymorphism, it looks like a reasonable choice.
The suggestion that we should make more explicit the idea that an abstract might appear in <front> is helpful and worth following. The problem with how to help those who persist in wanting to put their highly structured abstract in the header remains: on the whole we would prefer to avoid polymorphism...
Have added an example of structured abstract to the front element spec, and revised wording of abstract spec in line with these suggestions. Schematron rules to be further considered, so leaving ticket open for now.
Just to answer @lb42 's previous comment. It is not a matte row persistence, but one of data pouring in from third party providers as part of their meta-data. If we want to acknowledge that the scientific article scenario is an important one, that's the way to proceed. Thanks for working on the schematron rules for controlling <div>
and <p>
.
Reviewed at FTF, and agreed to close for now.
The abstract element is particularly important for representing meta-data associated to scholarly works. Still, many disciplines have developed a tradition of reflecting the argument of a paper within a structured abstract.
For instance see the attached screen shot where the abstract has two subsections with corresponding headings.
We suggest to allow abstract to contain divs so that the preceding example could be represented as: