MARC 520

[kiegel]

Conversion of field 520 (Summary, Etc.) seems problematic in two ways.

1) The text of the summary now appears in bf:note in the instance. First, summarization of content is a FRBR work/expression attribute, so it should be associated with bf:Work. Second, summary information is important enough to receive its own property and should not be mixed with other notes.

2) The generation of a summary link is not done consistently or well. It now happens when there is a 520 $c. It lacks the actual summary text and a link from the Work to the summary.

For example,

520 __ |a "It was the year I broke a bone in my leg, the year I got my first kiss, and the year Jesus got himself shot. One dead Japanese pearl-diver who is starting to smell. A big, slow Filipino crewman. A beautiful girl called Amy O'Rourke. And Sam, who gets mixed up with them all, and maybe shouldn't have. Sam is a skinny layabout, working at the Sun Picture Stadium for his dad, and dreaming of being a hero, a cowboy, a legend. It's Broome, the year is 1926, and the heat is on"-- |c Container.

generates:

bf:note "\"It was the year I broke a bone in my leg, the year I got my first kiss, and the year Jesus got himself shot. One dead Japanese pearl-diver who is starting to smell. A big, slow Filipino crewman. A beautiful girl called Amy O'Rourke. And Sam, who gets mixed up with them all, and maybe shouldn't have. Sam is a skinny layabout, working at the Sun Picture Stadium for his dad, and dreaming of being a hero, a cowboy, a legend. It's Broome, the year is 1926, and the heat is on\"--" ; [Instance]

<http://example.org/99161769137201452summary10> a bf:Summary ;
    bf:annotationAssertedBy "Container." ;
    bf:label "Summary" ;
    bf:summaryOf <http://example.org/99161769137201452> .

One problem is that the summary link does not contain the text of the summary itself. Having got to the summary link, one expects to find the summary; the bf:note in the instance cannot be retrieved from there. Perhaps bf:summary could be added, but it is not clear that this works because its range is rdfs:Resource, not rdfs:Literal. bf:summary may need to be redefined or a new property created.

Second, while it is good that the summary points to the work summarized, there is no reverse link, which is expected. It is more likely that users will discover a work and want to move to its summary than discover a summary and want to move to the work. There is no property in BF with the appropriate domain and range for a reverse link. We need something like bf:hasSummary, with domain of bf:Work and range of bf:Summary.

Finally, we think a summary link should be generated for every 520, regardless of whether subfield c is present. This would result in a more consistent treatment of summary information and code it explicitly as a summary.

As noted in #138, the text of the summary should contain both $a and $b.

A revision along these lines would look like:

    bf:hasSummary <http://example.org/99161769137201452summary10> ; [Work]

<http://example.org/99161769137201452summary10> a bf:Summary ;
    bf:annotationAssertedBy "Container." ;
    bf:label "Summary" ;
    bf:summary "\"It was the year I broke a bone in my leg, the year I got my first kiss, and the year Jesus got himself shot. One dead Japanese pearl-diver who is starting to smell. A big, slow Filipino crewman. A beautiful girl called Amy O'Rourke. And Sam, who gets mixed up with them all, and maybe shouldn't have. Sam is a skinny layabout, working at the Sun Picture Stadium for his dad, and dreaming of being a hero, a cowboy, a legend. It's Broome, the year is 1926, and the heat is on\"--" ;
    bf:summaryOf <http://example.org/99161769137201452> .

(OCLC # 881182936)

[ntra00]

I am putting 520 $ab into the annotation body, but the links will still go only from the annotation to the work. This is not a problem in RDF, since you can query for "things that annotate this work" and find all summaries.