Menu

#304 <provenance> examples and definition are inconsistent

GREEN
closed
nobody
5
2011-11-05
2011-09-20
Lou Burnard
No

According to its description, <provenance> should describe "a single identifiable episode during the history of a manuscript". However, several of the examples show it as containing a sequence of paragraphs each of which describes some different episode between the ms origins and its entry into the repository. This is inconsistent. I believe the description is right and the examples are wrong: otherwise why is <provenance> repeatable within <history> -- it is also datable, which suggests the intent was to provide multiple dated <provenance>s for multiple events in the ms history.

Discussion

  • Laurent Romary

    Laurent Romary - 2011-09-21

    I have had exactly this comment from a colleague working on a manuscript project. +1

     
  • BODARD Gabriel

    BODARD Gabriel - 2011-09-21

    Interesting. I had been interpreting in the other direction: tei:provenance can contain tei:eventList, which suggests that multiple discoveries, movements, sales, autopsies etc. might happen to the same object. (This is how I've been using it, and how it's about to be codified in EpiDoc Guidelines, so if we're going to clarify that this is wrong, let's have that conversation asap!)

    The only time I can imagine wanting multiple tei:provenance elements--according to my usage--would be if a single manuscript is made up of multiple objects (not uncommon), which have a different series of events related to their lifetime. How would you make this clear if each object had multiple provenances? Multiple tei:msDescs? (But the relationship of "document" to "object" is many-to-many, so I'm not sure how that would work either.)

     
  • Lou Burnard

    Lou Burnard - 2011-09-21

    I think the text of the description is quite clear that a <provenance> element contains one "episode". Of course an episode might be decomposed into several events in which case listEvent might be useful but this is is a fairly untypical case I think. It is repeatable so that several episodes can be listed. Each <provenance> also is datable independently.

    The case where you have a single object composed of different parts each with its own cdistinct history is handled by <msPart> surely.

    Laurent, I don't know who (or your unnamed colleague) you are agreeing with!

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2011-09-21

    I would say that the inclusion of <listEvent> as a child of <provenance> is accidental, and that the prose description stands: "a single identifiable episode". It is not impossible that an episode contains multiple events, mind. The "episode" where the MS was bought by a museum _might_ be broken up into 1. first approach 2. haggle over price. 3. withdrawal. 4. re-offered. 5. lent and then taken back 6. finally handed over for good. In a mad world.

    But its hard to know what to say when the description and the examples are at such odds.

    If you ask me, its typical of the mixed history of the MS module, which can never make its up mind between paragraphs of woolly prose and proper data.

     
  • Laurent Romary

    Laurent Romary - 2011-09-22

    To answer Lou. I would mend the examples.

     
  • BODARD Gabriel

    BODARD Gabriel - 2011-09-23

    Okay, on reflection I could just about live with doing away with the use of tei:eventList in EpiDoc, and repeating tei:provenance in its stead. However, we've been coming up with a controlled list of event/@types and @subtypes for purposes of typologising such stages in an object's (modern) history. I would strongly argue that if we get rid of the misleading examples as Lou suggestions, we also suggest to Council adding tei:provenance to att.typed. Any objections?

     
  • BODARD Gabriel

    BODARD Gabriel - 2011-09-27

    As per discussion in TEI Council mailing list this week, I have added (at rev 9404) provenance to att.typed and att.responsibiltiy, to allow the expressiveness that was previous captured on attributes on individual events within provenance.

    (This ticket remains open because examples and guidelines need changing to reflect the clarification reached here.)

     
  • BODARD Gabriel

    BODARD Gabriel - 2011-09-27
    • milestone: 871214 --> GREEN
     
  • Kevin Hawkins

    Kevin Hawkins - 2011-11-03

    Lou's 2011-11-02 email to Council proposed close this without further discussion, but I agree with Gabby that we need to update the examples and prose of the Guidelines.

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-11-04

    (update the examples and prose of the Guidelines BEFORE closing the ticket, lest we forget about it)

     
  • James Cummings

    James Cummings - 2011-11-04

    I agree, make guidelines, prose, examples consistent. I agree that provenance is right to be repeatable, each for a distinct episode in its history up to acquisition.

     
  • Lou Burnard

    Lou Burnard - 2011-11-05

    Example and discussion in MS modified accordingly at rev 9607

     
  • Lou Burnard

    Lou Burnard - 2011-11-05
    • status: open --> closed