[MEI-L] [Time uncertainty; WAS] feature request list (long)

Tue May 18 03:47:47 CEST 2010

As a music historian, I would prefer the outer limits for a date over a
probability function. Some dates are vague at the outset and eventually
are pinned down to something very specific. Yet there are other cases
where a received opinion has held a very consistent date for a long time
and it turns out to be wrong.

All the same can be said of composer attributions. If a manuscript is
unsigned by any composer, that needs to be indicated. References shelves
are full of sources that (especially in the computer era) forced certainty
where none existed previously. Coders need to respect uncertainty, so as
not to preclude later discovery and appropriate clarification.

Eleanor

-----Original Message-----
From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A.
Sent: Monday, May 17, 2010 5:58 PM
To: Music Encoding Initiative; Roland, Perry (pdr4h)
Subject: Re: [MEI-L] [Time uncertainty; WAS] feature request list (long)

I took the liberty of incorporating your correction to the "12th
century" example below :-) ... Yes, what you say makes a lot of sense,
and answers almost all my doubts! One exception: I don't think any of
what you mention addresses the "known wrong" concept.

FWIW, I tend to agree that "@cert is only useful if it uses coded
values". For my General Temporal Workbench thing, I've been trying to
come up with the most flexible possible representation of time. What if
you know -- say, because of damage to a manuscript -- that an event was
on Feb. 12 of some year in the 1740's, or the 12th of some month in
1743 or 1744? I think the _most_ flexibility possible requires
descriptions in terms of probability density functions, but I seriously
doubt if MEI should go that far!

--DAB

On Mon, 17 May 2010 14:16:18 -0400, "Roland, Perry (pdr4h)"
<pdr4h at eservices.virginia.edu> wrote:
> Hi, Don,
>
> In MEI <date> can be used for either a single date or a date range.
>
> <date> may also contain other <date> elements.  This is useful when
> the start and end dates of the range have different amounts of
> uncertainty.  "1836 or 7-1896" indicates an uncertain start date, but
> a certain end point --
>
> <date>
>  <date notbefore="1836" notafter="1837>1836 or 7</date> -
>  <date>1896</date>
> </date>
>
> It might also be useful to add @startdate to the first and @enddate
> to the second date sub-elements.
>
> "12th cent." is just a range where both end points are questionable --
>
> <date notbefore="1100" notafter="1199">12th cent.</date>
>
> A single date element is used because the attributes apply to the
> entire range and there's only a single string to wrap the <date>
> around.
>
> "fl. 1893-1940" introduces a different wrinkle.  As I read it, the
> "fl." indicates the *function* of the date, not its (un)certainty --
>
> <date n="fl">fl. 1893-1940</date>
>
> There is no controlled vocabulary for @n because I don't think
> there's any way to anticipate all the various ways a date can be used.
>
> If the entire range is questionable, then @cert can be used to
> indicate this --
>
> <date n="fl" cert="medium">fl. 1893-1940</date>
>
> I think @cert is only useful if it uses coded values.  In MEI, the
> permitted values are high, low, medium, and unknown.
>
> If the start and end dates are differently uncertain, they can be
> handled as described above.
>
> For multiple dates that are not part of a date range as in your
> Cowell example, multiple date elements are required --
>
> <date>1912</date>
> <date>1917</date>
>
> The context for the dates is provided by the parent element --
>
> <pubstmt>
>  <date>1912</date>
>  <date>1917</date>
> </pubstmt>
>
> Decisions about which date(s) should be diplayed, indexed, etc. must
> be based on the context and the attributes of the date(s).
>
> Make sense?
>
> --
> p.
>
> __________________________
> Perry Roland
> Digital Curation Services
> University of Virginia Library
> P. O. Box 400155
> Charlottesville, VA 22904-4155
> 434-982-2702 (w)
> pdr4h at virginia.edu
> ________________________________________
> From: mei-l-bounces at lists.uni-paderborn.de
> [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd,  Donald A.
> [donbyrd at indiana.edu]
> Sent: Monday, May 17, 2010 11:55 AM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] [Time uncertainty; WAS] feature request list (long)
>
> All--
>
> I have a question about the proposed description of historical
> information. Forgive me for this _very_ belated response; I hope it's
> still useful... I wonder if we need more ways to describe uncertainty.
> Other than including the "natural language" version of a date, it looks
> like the only ways to describe uncertainty in the current plans are the
> @notBefore and @notAfter attributes. But other ways are already widely
> used. Sec. 22.17A, "rules and approximation methods for dates", of
> AACR2R (the Anglo-American Cataloguing Rules, 2nd ed. revised) includes
> examples like "1836 or 7-1896", "fl. 1893-1940", and "12th cent."
> (meaning -- AACR2R says -- years of birth and death unknown, years of
> activity unknown, century known). And what about cases where there's
> evidence for two dates that aren't adjacent? For example, Henry
> Cowell's The Tides of Manaunaun, was one of the first pieces to employ
> large tone clusters, was probably written in 1917, but Cowell claimed
> he'd written it in 1912 (perhaps to make it seem even more original).
> This suggests either attributes to represent specific alternative
> dates, or perhaps "known wrong" dates. Also, some existing time formats
> -- I forget which -- allow replacing one or more trailing digits of the
> year with a question mark: for example, "17??" means some year in the
> 1700's. And so on. But, Daniel, I'm quite sure you thought about all of
> this when you were designing the EAC format, so I suspect there's less
> need for additional methods than I think!
>
> --Don
>
>
> On Thu, 1 Apr 2010 10:12:01 +0200, Daniel Röwenstrunk
> <roewenstrunk at edirom.de> wrote:
>
>> Hi all,
>>
>> just one short comment to the history discussion. I would like to
>> have a text explaining that event, but with all features a paragraph
>> offers (using date, persname, geogname, etc. for encoding everything
>> you like). And I would like to have a defined structure for the most
>> basic information of an event: the date, time or date range. This
>> information could be certain (@when (or any other name for that
>> thing), @from and @to) or uncertain (@notBefore and @notAfter). From
>> my point of view I would like to use attributes more than a date
>> element because it handles the same information (except the human
>> readable, language specific form like "1. April im Jahre 2010", but
>> this could be part of the text inside event) and don't force you to
>> have a eventdesc element inside event.
>>
>> Daniel
>>
>> PS: the @when attribute could be named to @date
>>
>>
>>
>> Am 31.03.2010 um 20:45 schrieb Johannes Kepper:
>>
>>> Hi all,
>>>
>>> my comments are spread over Daniel's and Daniel's replies?
>>>
>>>
>>> Am 31.03.2010 um 18:47 schrieb Daniel Pitti:
>>>
>>>> In my view it is either too structured or insufficiently structure.
It
>>>> depends on what you intend to do with the information: indexing,
>>>> rendering (just as a list; or perhaps as a timeline; or perhaps as a
>>>> timeline/map combination) or analysis.
>>>>
>>>> Dates, for example, can be quite complex: single or range? Certain or
>>>> uncertain? And to make the data "operational," one would want it
>>>> constrained using some union of W3C datatypes. If you want a
timeline/
>>>> map combination, then you would probably want the date and geographic
>>>> name independent of the event. You probably also want to be able to
>>>> give dates in natural language as well as machine-readable form.
>>>>
>>>> On the other hand, if all you want to do is display a list, then you
>>>> do not need <persname> and <geogname>.
>>>
>>> I don't think that we should worry too much about
>>> application-specific implementations of this feature. It should
>>> cover everything necessary for more or less simple eventlists, but
>>> it is not intended to lay the foundations for a highly sophisticated
>>> eventlist encoding XML standard. If a project needs more than what
>>> MEI offers, it has to use a different approach (METS or whatever).
>>> But we should take care that this situation is only an edge case,
>>> not the standard way for every project. I think it's good to have a
>>> compromise like this (although I'm not married with this particular
>>> solution).
>>>
>>>>
>>>> For a very structured timeline, see <chronItem> (component of
>>>> <chronList>) in the EAC-CPF schema:
>>>>
http://www3.iath.virginia.edu/eac/cpf/tagLibrary/cpfTagLibrary.html#d1e163
0
>>>>
>>>
>>> Our reason not to use <chronList> / <chronItem> / <chron*> was that
>>> it implies a chronological order (surprise!), but we wanted a more
>>> unspecific kind of event list that could cover simultaneous events
>>> as well as events of unknown order or dating.
>>>
>>>> (The examples unfortunately do not have one with a <placeEntry>, but
I
>>>> think you will get the idea).
>>>>
>>>> Daniel
>>>>
>>>>
>>>> On Mar 31, 2010, at 11:27 AM, Daniel Röwenstrunk wrote:
>>>>
>>>>> Hi all,
>>>>> to keep things simple and short what about a structure like that
>>>>> (concerning item 8):
>>>>>
>>>>> <eventlist type="composition">
>>>>>
>>>>> <event when="1812-03-25" type="composition">
>>>>>  Completed sketch in <geogname>My Little Town</geogname>
>>>>> </event>
>>>>>
>>>>> <event when="1812-06-26" type="dedication">
>>>>>  Dedicated to <persname>his wife</persname> on <date>June 26,
>>>>> 1812</date>
>>>>> </event>
>>>>> </eventlist>
>>>
>>> I see what you're getting at. First: I wasn't sure if we really need
>>> a defined element to encode place information for events. (@Perry: I
>>> know, it was suggested by me ;-). I see arguments for having it as
>>> well as not having it, but as it is optional in our proposal, I
>>> guess it won't hurt too much.
>>> Regarding the dating mechanism: As Daniel P. pointed out, dates are
>>> complicated things. We already have an element dedicated to date
>>> encoding in MEI, and I prefer to use that one also on eventlists
>>> over the simplicity of copying it's functionality to the event
>>> itself. By using the separate element, we may encode the "natural
>>> language" version of the date mentioned by Daniel P. as the
>>> element's content. If we use only attributes, we don't have this
>>> opportunity. I don't know if we really need it, but I would prefer a
>>> separate date.
>>>
>>>
>>> Johannes
>>>
>>>
>>>>>
>>>>>
>>>>> We would need the following elements and attributes:
>>>>>
>>>>> eventlist (with @type, @n) contains event*
>>>>> event (with @type, @n, @when, @notBefore, @notAfter, @from, @to)
>>>>> contains everything a p-element could contain
>>>>>
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>>
>>>>> Am 30.03.2010 um 20:26 schrieb Roland, Perry (pdr4h):
>>>>>
>>>>>> Finally, item 8.  Johannes and I propose adding eventlist, event,
>>>>>> and eventdesc elements.  From the attached .odt file:
>>>>>>
>>>>>> "Eventlist contains historical information given as a sequence of
>>>>>> significant past events. <eventlist> contains <event> elements that
>>>>>> pair a date or date range with a brief description of the
>>>>>> associated event and locations where the event took place. An
>>>>>> <eventlist> describes events associated with a work when it appears
>>>>>> in the <profiledesc> element or events associated with the
>>>>>> custodial history of a given copy of a source for the encoding when
>>>>>> it appears within the <source> element.
>>>>>>
>>>>>> Event groups a date, a description of the event related to the
>>>>>> date, and optionally, any number of places where the event took
>>>>>> place.
>>>>>>
>>>>>> Eventdesc describes or names something that happened."
>>>>>>
>>>>>> Usage examples:
>>>>>>
>>>>>> <profiledesc>
>>>>>> <eventlist type="composition">
>>>>>> <event>
>>>>>>   <date reg="1812-03-25"/>
>>>>>>   <geogname>My Little Town</geogname>
>>>>>>   <eventdesc n="composition">
>>>>>>     Completed sketch
>>>>>>   </eventdesc>
>>>>>> </event>
>>>>>> <event>
>>>>>>   <date reg="1812-06-26"/>
>>>>>>   <eventdesc n="dedication">Dedicated to <persname>his wife</
>>>>>> persname>.</eventdesc>
>>>>>> </event>
>>>>>> <event>
>>>>>>   <date reg="1813"/>
>>>>>>   <eventdesc>Published</eventdesc>
>>>>>> </event>
>>>>>> </eventlist>
>>>>>> <eventlist type="reception">
>>>>>> <event>
>>>>>>   <date reg="1814-04-01"/>
>>>>>>   <geogname>The State Theater</geogname>
>>>>>>   <eventdesc>1st performance</eventdesc>
>>>>>> </event>
>>>>>> <event>
>>>>>>   <date reg="1814-04-01"/>
>>>>>>   <eventdesc>1st bad review</eventdesc>
>>>>>> </event>
>>>>>> </eventlist>
>>>>>> </profiledesc>
>>>>>>
>>>>>> <provenance>
>>>>>> <eventlist>
>>>>>> <event>
>>>>>>   <date notafter="1985">until 1986</date>
>>>>>>   <eventdesc>Weber family </eventdesc>
>>>>>> </event>
>>>>>> <event>
>>>>>>   <date notbefore="1986">1986-</date>
>>>>>>     <eventdesc>owned by the <repository>Berlin State Library</
>>>>>> repository></eventdesc>
>>>>>> </event>
>>>>>> </eventlist>
>>>>>> </provenance>
>>>>>>
>>>>>> <profiledesc> allows multiple lists, hence the need for @type to
>>>>>> distinguish them.  <provenance> on the other hand only allows a
>>>>>> single list.
>>>>>>
>>>>>> Within profiledesc, creation permits a "text-y" description of the
>>>>>> creation of the work, while eventlist offers a more structured,
>>>>>> more easily machine-processed approach.  Either or both are
>>>>>> permitted.  In provenance, however, one method must be selected.
>>>>>>
>>>>>> Notice that event permits only a single date element.  This can
>>>>>> contain a single date or a date range.  However, an event cannot
>>>>>> have multiple, discontinuous dates.  In our estimation, this
>>>>>> situation implies multiple events.
>>>>>
>>
>>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>

--
Donald Byrd
Senior Scientist
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l