#69 Need provenance @type to handle "first seen" events

guidelines (65)

In RIB, there are frequent occurrences of inscriptions which are first recorded as "first seen" in locations which are clearly not their original findspots (e.g., Roman inscription first seen in an Anglo Saxon church in the 16th c.). While these would seem to be best characterized as an "observed" events, they still have "found"-like qualities, and for purposes of generating HTML editions, need to be treated as surrogates for the "found" event. It would be great to have a way of encoding these sorts of events that will allow convenient XSLT matching rules to treat these "first seen" events as "found" events.


  • Tom Elliott

    Tom Elliott - 2013-05-30

    accepting and changing milestone to "future"

  • Tom Elliott

    Tom Elliott - 2014-05-29

    Ticket moved from /p/epidoc/bugs/117/

  • Tom Elliott

    Tom Elliott - 2014-05-29

    The @type attribute is not constrained in the schema, so you can use whatever value(s) you want therein. Suggest we refactor this ticket to be about putting a recommended value into the guidelines and maybe supporting it in some way in the xslt?

  • Tom Elliott

    Tom Elliott - 2014-06-24

    Recommend the introduction into the guidelines of an additional @type value of "observed-first" for cases where the place of finding is unknown/unrecorded but the recording history of the inscription is sufficiently well-known to permit the assertion that it was first seen by a modern scholar or reporter at a particular location.

  • BODARD Gabriel

    BODARD Gabriel - 2014-06-25

    I seem to recall that Scott and Jonathan were going to put together a candidate list of useful provenance/@types for consideration by Markup and possible inclusion in the Guidelines.

    My instinct (for what it's worth, and not to pre-empt this discussion) is to keep the recommended list of @type values as short as possible. Is "observed-first" really meaningfully distinct from both "found" and the "observed" with the earliest @when? If so, can we perhaps record this distinction using @subtype instead? (In IRCyr I think we would have used a subtype on type=found to represent a first recorded finding that is not necessarily the original findspot, because we want to group the two together consistently, whereas type=observed is a superset of autopsy and current/last-recorded locations.)

    Do we need top-level values (i.e. @type) other than "found" and "observed"? Are there any useful values that could not be a subtype of one or other of those? (I suppose "not-found" and "moved" in principle.)

  • Scott Vanderbilt

    Here is the list of provenance events I proposed to MARKUP back in 2011:

    Drawn from RIB Vol. 1, the following is a list of what I believe are each distinct type of provenance event contained therein. I then tried to break down these events into the smallest number of categories possible, and try as I might, I couldn't get it down to any fewer than six.

    They are: Discovery, Observation, Negative Observation, Loss, Transfer, and Copy. I'm not really happy with the name of the category "Negative Observations". Perhaps you can devise a more felicitous term.

    A couple of notes:
    "First seen/first recorded" versus "seen/recorded". It seems to me that while the first sighting or recording of an object is technically an "Observation" event, it hews more closely to a "Discovery" event inasmuch as it marks the first time the object enters the historical record. Perhaps that is a false distinction, but it does make sense to me in an ontological sense. Please feel free to disagree.

    "Now lost" versus "lost" - the distinction I am making here is between those provenance events where the "loss" is an event without time or place, only noting that it can no longer be found. These are distinguished from those sorts of events where the circumstance surrounding the loss are more or less known (more frequent in the cases of destruction or theft, but it does happen).


    first seen
    first recorded


    squeeze taken
    now in...
    once in ...
    later at....
    thereafter at ....
    built into...

    Negative Observation

    sought in vain
    now lost
    no longer at...

    Loss (circumstances more or less certain)

    destroyed by fire


    loaned to...
    taken to...



  • BODARD Gabriel

    BODARD Gabriel - 2014-06-26

    This is a great list, Scott, thanks. (And sorry for not having commented on this when you sent it to Markup all those years ago.)

    Just to push back to my original proposal of having only a few recommended @types and unconstrained (but perhaps suggested) @subtypes, do you think we should propose in the guidelines:

    • @type='found' to include all your "discovery" categories, including the "first-seen" requested in this ticket;
    • @type='observed' to include your "observation" subcategories, and perhaps also "copy", since I see those as analogous to photographed, squeezed, drawn, RTIed, etc.;
    • @type='not-found' to include both your "negative observation" and "loss" categories;
    • @type='transfer' to include all your categories under that heading.

    Is that a gross over-simplication of your typology? What would everyone else think? (The values above would of course be recommended and not exhaustive or imposed.)

  • Tom Elliott

    Tom Elliott - 2014-07-02

    HGV data editor in papyri.info supports the following provenance types: already supports many types of geographic assocation: found, :observed, :destroyed, :'not-found', :reused, :moved, :acquired, :sold, :composed, :sent, :executed, :received, :located

    • BODARD Gabriel

      BODARD Gabriel - 2014-07-02

      Great. I think most of these can be grouped under the top-level categories suggested by Scott and myself above (with the possible exception of "composed" and "executed", which I would argue is a type of <origin>, not a type of <provenance>: provenance begins with the [usually modern] finding of an object).

      I would recommend that the Guidelines suggest these are @subtypes therefore, which of course does not force HGV or Papyri.info to change their practice (nor IOSPE, which currently uses @type='autopsy' for that matter) but they might like to eventually for future goodness.

  • Tom Elliott

    Tom Elliott - 2014-07-31

    I will try to have brought this issue to an actionable conclusion by the end of August 2014.

  • Tom Elliott

    Tom Elliott - 2014-08-01
    • BODARD Gabriel

      BODARD Gabriel - 2014-08-04

      Thanks for all this work, Tom, which is excellent!

      I have one small suggestion... Under provenance, I would be inclined not to use "standard" to describe the use of @subtype, but something like "common values of @subtype" or similar.

      (We have been in the habit, in other parts of the guidelines, of recommending a [more or less] strict set of values for @type, but considering @subtype to be complete free-text, with values in use by other projects suggested for convenience/compatibility, but in no way standardized. Seem fair?)

  • Tom Elliott

    Tom Elliott - 2014-08-01
    • status: accepted --> needs-feedback
    • Priority: 1(low) --> 6
  • Scott Vanderbilt

    Looks complete to me. Thanks, Tom!

  • BODARD Gabriel

    BODARD Gabriel - 2014-08-28
    • status: needs-feedback --> done
  • Tom Elliott

    Tom Elliott - 2015-05-01
    • Group: future --> previous

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks