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

Byrd, Donald A. donbyrd at indiana.edu
Tue May 18 14:05:10 CEST 2010 

What you say makes perfect sense to me, Eleanor. Actually, to a 
mathematician, probability doesn't exclude certainty! A probability 
_density_ function can describe any situation, including very specific 
known dates. It can say P(12 Feb. 1744, NS) = 1.0, P(any other date) = 
0.0. Or that any date between 14 Jan. 1743 and 26 Dec. 1744 is equally 
likely, and no earlier or later date is possible -- or that situation 
except that 12 Feb. 1743 and 1 Nov. 1744 are twice as likely as the 
other possible dates. Or literally anything else.

There are other limitations of MEI's proposed time representation. For 
example, I really don't think "15th cent." means quite the same thing as

  <date notbefore="1400" notafter="1499">12th cent.</date>

If a composer was described as "15th century" and it turned out that 
they were born in 1399, would that be a mistake? Surely not. How about 
if they were born in 1385, so they might have started composing in the 
late 1300's Still probably not.

But I don't think we should try for a perfect representation of time -- 
and specifically, I don't think MEI should offer probability density 
functions.

--DAB


On Mon, 17 May 2010 18:47:47 -0700 (PDT), Eleanor Selfridge-Field 
<esfield at stanford.edu> wrote:

> 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
>
>>>>>
>>>>
>>>> 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
>



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

More information about the mei-l mailing list