From atge at kb.dk  Tue Nov  3 09:35:45 2015
From: atge at kb.dk (Axel Teich Geertinger)
Date: Tue, 3 Nov 2015 08:35:45 +0000
Subject: [mei-catalog-ig] Catalog IG mail archive now active
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE9082@EXCHANGE-02.kb.dk>

Dear list

I just realized that the Catalog IG's mail archive hadn't been activated yet. It is now. Any postings to this group from now should be automatically archived at https://lists.uni-paderborn.de/pipermail/mei-catalog-ig/ for future reference.

Best,
Axel

Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Axel Teich Geertinger
Sendt: 2. november 2015 21:19
Til: mei-catalog-ig at lists.uni-paderborn.de
Emne: [mei-catalog-ig] <physLoc> and <provenance>


Dear Metadata IG

As you know, a new version of the MEI schema is in preparation which will break backwards compatibility in a few instances. I think we should take the opportunity to make a recommendation regarding an issue that has been raised a few times but never resolved.
In late 2012, the content model of the MEI header was revised. Until then, both <physLoc> (holding information about the physical location of a source) and <provenance> had both been children of the source's <physDesc> (physical description). With the revision, <physLoc> was moved out of <physDesc> to become its sibling, while <provenance> stayed within <physDesc>.
Please see the discussion from December 2012 below. Since then, the FRBR module has become an optional part of the MEI schema, but that doesn't solve the problem regarding the <provenance> element's place. The issue was brought up again in early April 2014 on MEI-L. You may find it in the archives: https://lists.uni-paderborn.de/pipermail/mei-l/2014/date.html (look for the 'history of sources / items' discussion).

My first problem with the current state is that I cannot understand the account of an item's provenance as part of its physical description. Provenance is part of an item's history, and it cannot be described from the item's physical appearance (even if, of course, the provenance may have left a few physical trails, such as library stamps or written shelf marks).
The second problem is how to use the current model. When using MEI without the FRBR module, the <item> element is not available and therefore all item-related information must be encoded at source level. That means: if there is more than one copy of a particular source, all the copies' physical locations and their provenance must be recorded within the same <source> element. But with <physLoc> and <provenance> separated, how can we tell which provenance corresponds to which current location (see the discussion below)?

There are a number of possible solutions that I can imagine. All of them imply moving <provenance> out of <physDesc>:
1. <provenance> could become a child of <physLoc>. This way, <provenance> would be regarded as supplementary information to the item's current location - or <physLoc>'s historical record, so to speak. Something like this:
<physLoc>
    <repository/>
    <identifier/>
    <provenance>
        <eventList/>
        ...
    </provenance>
</physLoc>

2. The other way around: <physLoc> could be a child of <provenance> (which in turn would become a sibling of <physDesc>). This would make <physLoc> more like the end point of a provenance time line:
<provenance>
    <physLoc>
        <repository/>
        <identifier/>
    </physLoc>
    <eventList/>
    ...
</provenance>

3. A new container for both could be introduced to group them as siblings (I can't think of a suitable name for such a container, though)

4. <provenance> could simply become a sibling of <physLoc> and a direct descendant of <source> (and <item>, of course, when using the FRBR module):
<source>
    ...
    <physDesc/>
    <physLoc>
        <repository/>
        <identifier/>
    </physLoc>
    <provenance>
        </eventList/>
        ...
    </provenance>
    ...
</source>



5. All the solutions I haven't thought of...



Any opinions? It would be nice to have consensus in this group as much as possible before making any suggestions to MEI-L and filing an issue for the next release.



Best,

Axel



________________________________
Fra: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu]
Sendt: 8. december 2012 15:25
Til: Music Encoding Initiative
Emne: Re: [MEI-L] physLoc

Axel,



To describe the provenance of two copies in different locations, I would leave your example exactly as it is.  Or I might even compress the two <provenance> elements into one --


<source>
  <physDesc>
    <provenance>This relates to one location. This relates to the other location.</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive</repository>
  </physLoc>
  <physLoc>
    <repository>some other archive</repository>
  </physLoc>
</source>



The text in <provenance> explains its relationship to the items in the different locations.



@sameas is incorrect, but I would not attempt to connect the <provenance> element to the <physLoc> elements.  That's a level of detail that is not required using this "text-based" approach.  Going to the FRBR approach is a better option for that level of detail.



In order to make the distinction between the two approaches more clear, it might be worth considering allowing only one <physLoc> in <source>.  The example then would be


<source>
  <physDesc>
    <provenance>This relates to one location. This relates to the other location.</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive. some other archive</repository>
  </physLoc>
</source>



--

p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Saturday, December 08, 2012 5:59 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] physLoc
Hi Perry,

to get back to the physLoc question: you wrote

does the provenance information pertain to only the copy in the first physical location or to both?  If it pertains to both, then the <provenance> elemement shouldn't be a child of the first <physLoc>, but should exist outside it.  Assuming <provenance> is permitted only within <physLoc>, if I want to say that both copies have always been kept together, then information will have to be repeated.  For example,

<source>
  <physDesc/>
  <physLoc>
    <provenance>Always together</provenance>
  </physLoc>
  <physLoc>
    <provenance>Always together</provenance>
  </physLoc>
</source>
I see that this would require information to be repeated. However, I think usually the situation would rather be that items in different physical locations (typically copies kept in different archives) would have different provenance. How would you describe that? You would have something like:

<source>
  <physDesc>
    <provenance>This relates to one location</provenance>
    <provenance>This relates to the other location</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive</repository>
  </physLoc>
  <physLoc>
    <repository>some other archive</repository>
  </physLoc>
</source>

With <physLoc> and <provenance> separated, you would have to use IDREFs to clarify which provenance is related to which location (or item), right? Is that better than repeating information or using someting like @sameas in those (rare, I would say) cases, where several items in _different_ locations (or with different shelf marks) share the same provenance?

Have a nice weekend,
Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151103/bd2753e2/attachment.html>

From pdr4h at eservices.virginia.edu  Mon Nov  9 20:53:44 2015
From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h))
Date: Mon, 9 Nov 2015 19:53:44 +0000
Subject: [mei-catalog-ig] <physLoc> and <provenance>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D7C72251D@reagan.eservices.virginia.edu>


Hello all,

Since <physLoc> can occur more than once within <source> (necessary because <item> isn't available when MEI.frbr is turned off), it seems to me that the best option is #1.  It involves the least amount of change to the content models of <item> and <source>; that is, only a move of <provenance> from <physDesc> to <physLoc>.

Because it's a pretty simple change, it's easy to implement quickly.  There's no fixed deadline for changes to the next release of MEI, but I'd rather make the change sooner than later.  While we're in "metadata revising" mode, I'd also like to discuss a couple more modifications to the header, but I'll post separate messages about those soon.

--
p.

________________________________
Perry Roland
University of Virginia
P. O. Box 400874
Charlottesville, VA, 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151109/ac858855/attachment.html>

From pdr4h at eservices.virginia.edu  Mon Nov  9 21:46:06 2015
From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h))
Date: Mon, 9 Nov 2015 20:46:06 +0000
Subject: [mei-catalog-ig] changes to <eventList> and <event>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D7C722585@reagan.eservices.virginia.edu>


I know we've had a few rounds of discussion about the content models of <eventList> and <event> in the past.  I think there are basically 2 issues currently facing us:


*       eventList contains a bug that doesn't allow grouping events that share the same date

*       the model of event is too vague

I propose to remedy the first problem by using the following content model for <eventList>:

eventList   (head*, listHead?, (date, (event | eventGrp))*, biblList*)

By placing <date> outside the model of <event>, the main content of <eventList> can be constrained to be any number of pairs of <date> and <event> elements, like so -

<eventList>
  <date><!-- when "it" happened --></date>
  <event><!-- what happened -->
  <date><!-- another happening --></date>
  <event><!-- another description -->
<!-- and so on -->
</eventList>

Or, when multiple events share the same date, like so --
<eventList>
  <date><!-- the date --></date>
  <eventGrp>  <!-- the events occurring on the date -->
    <event>Event 1</event>
   <event> Event 2</event>
   <!-- and so on -->
  </eventGrp>
</eventList>

The new model also introduces listHead, a new formatting element.  <listHead> contains a pair of <head> elements, one for each column in the eventList date-event pair.  This makes it possible to treat the list of events as though it were a table with a column heading for the dates and a heading for the descriptions.  Of course, eventList/head continues to contain a heading for the entire list --

<eventList>
  <head>My List o' Special Events</head>
  <listHead>
    <head>When</head>
  <head>What</head>
  </listHead>
  <event/>
  <event/>
</eventList>

I plan to investigate how this might work for other lists as well, such as <biblList>, <castList>, and <list>.  Any list that allows a label preceding its "items" could benefit from this treatment, I think.

One more change -- <eventList> is now a member of model.listLike, meaning it can occur not just in the header but anywhere a "regular" list can happen.

The <event> element now has the following model (switching to RNG as it's somewhat clearer than DTD syntax) --

<content>
  <rng:optional>
    <rng:ref name="model.labelLike"/>
  </rng:optional>
  <rng:choice>
    <!-- data-like organization -->
    <rng:zeroOrMore>
      <rng:choice>
        <rng:ref name="model.eventPart"/>
        <rng:ref name="eventList"/>
      </rng:choice>
    </rng:zeroOrMore>
    <!-- free-form organization -->
    <rng:zeroOrMore>
      <rng:choice>
        <!-- model.listLike is expanded here in order to disallow biblList -->
        <rng:ref name="model.pLike"/>
        <rng:ref name="model.tableLike"/>
        <rng:ref name="castList"/>
        <rng:ref name="eventList"/>
        <rng:ref name="list"/>
      </rng:choice>
    </rng:zeroOrMore>
  </rng:choice>
  <rng:zeroOrMore>
    <rng:ref name="biblList"/>
  </rng:zeroOrMore>
</content>

English translation is "an optional label, followed by EITHER some data-like elements or nested eventLists OR any number of paragraphs, tables, castLists, eventLists, or lists, followed by any number of lists of bibliographic citations."

The central choice (a data-centric organization OR a free-form text one) is the important factor here.  In purely practical terms, any file that formerly used a group of data elements followed by a paragraph will have to be translated into --

<event>
  <label><!-- former paragraph content -->
  <geogName/><persName/> <!-- etc. -->
</event>

This element re-naming and re-ordering is not a difficult task and can be made part of the 2013 -> 2015 XSLT transformation.  If the re-ordering poses a significant issue (that is, you *must* have the data elements followed by the label), I think it's not a problem to allow that, but please let me know.

As always, I apologize for the length of the message and the XML "gobbledy-gook".  I just don't know of any other way to communicate.  ;-)

--
p.

________________________________
Perry Roland
University of Virginia
P. O. Box 400874
Charlottesville, VA, 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151109/78aeaa6b/attachment.html>

From pdr4h at eservices.virginia.edu  Mon Nov  9 22:47:24 2015
From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h))
Date: Mon, 9 Nov 2015 21:47:24 +0000
Subject: [mei-catalog-ig] non-MEI metadata
Message-ID: <BBCC497C40D85642B90E9F94FC30343D7C7226A2@reagan.eservices.virginia.edu>


Following up on a multiple requests and recent TEI activity, I'd like to suggest the addition of a <extMeta> element within the header that can contain any non-MEI markup.

<elementSpec ident="extMeta" module="MEI.header" mode="add">
  <desc>(external metadata) - provides a container element into which metadata in non-MEI
    formats may be placed.</desc>
  <classes>
    <memberOf key="att.common"/>
    <memberOf key="att.whitespace"/>
  </classes>
  <content>
    <rng:zeroOrMore>
      <rng:group>
        <rng:choice>
          <rng:text/>
          <rng:ref name="macro.anyXML"/>
        </rng:choice>
      </rng:group>
    </rng:zeroOrMore>
  </content>
</elementSpec>
<macroSpec ident="macro.anyXML" module="MEI.shared" type="pe" mode="add">
  <desc>Permits any XML elements except those from the MEI and SVG namespaces.</desc>
  <content>
    <rng:element>
      <rng:anyName>
        <rng:except>
          <rng:nsName ns="http://www.music-encoding.org/ns/mei"/>
          <rng:nsName ns="http://www.w3.org/2000/svg"/>
        </rng:except>
      </rng:anyName>
      <rng:zeroOrMore>
        <rng:attribute>
          <rng:anyName/>
        </rng:attribute>
      </rng:zeroOrMore>
      <rng:zeroOrMore>
        <rng:choice>
          <rng:text/>
          <rng:ref name="macro.anyXML"/>
        </rng:choice>
      </rng:zeroOrMore>
    </rng:element>
  </content>
</macroSpec>

Of course, any metadata placed here won't be "interoperable"; that is, it can't be guaranteed to have any use or meaning to anyone other than the one who placed it there.  In fact, I think <extMeta> should never be allowed to "connect" with any data or metadata in the file, for example, via @decls or @data attributes.  Nevertheless, it could be helpful to some users to permit non-MEI metadata "blobs".  I'm not sure if it's a good thing, but this could help turn the MEI header toward becoming a more general-purpose metadata wrapper.

--
p.

________________________________
Perry Roland
University of Virginia
P. O. Box 400874
Charlottesville, VA, 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151109/10f2584d/attachment.html>

From atge at kb.dk  Tue Nov 10 13:24:36 2015
From: atge at kb.dk (Axel Teich Geertinger)
Date: Tue, 10 Nov 2015 12:24:36 +0000
Subject: [mei-catalog-ig] <physLoc> and <provenance>
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D7C72251D@reagan.eservices.virginia.edu>
References: <BBCC497C40D85642B90E9F94FC30343D7C72251D@reagan.eservices.virginia.edu>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC194@EXCHANGE-02.kb.dk>

Hi Perry

I agree (I guess that's why I listed it as no. 1). Furthermore, having <provenance> as a child of <physLoc> would also nicely fit the assumption that the latest provenance event refers to the source's current location.

/axel

Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 9. november 2015 20:54
Til: mei-catalog-ig at lists.uni-paderborn.de
Emne: Re: [mei-catalog-ig] <physLoc> and <provenance>


Hello all,

Since <physLoc> can occur more than once within <source> (necessary because <item> isn't available when MEI.frbr is turned off), it seems to me that the best option is #1.  It involves the least amount of change to the content models of <item> and <source>; that is, only a move of <provenance> from <physDesc> to <physLoc>.

Because it's a pretty simple change, it's easy to implement quickly.  There's no fixed deadline for changes to the next release of MEI, but I'd rather make the change sooner than later.  While we're in "metadata revising" mode, I'd also like to discuss a couple more modifications to the header, but I'll post separate messages about those soon.

--
p.

________________________________
Perry Roland
University of Virginia
P. O. Box 400874
Charlottesville, VA, 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu



________________________________
Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Axel Teich Geertinger
Sendt: 2. november 2015 21:19
Til: mei-catalog-ig at lists.uni-paderborn.de
Emne: [mei-catalog-ig] <physLoc> and <provenance>

Dear Metadata IG

As you know, a new version of the MEI schema is in preparation which will break backwards compatibility in a few instances. I think we should take the opportunity to make a recommendation regarding an issue that has been raised a few times but never resolved.
In late 2012, the content model of the MEI header was revised. Until then, both <physLoc> (holding information about the physical location of a source) and <provenance> had both been children of the source's <physDesc> (physical description). With the revision, <physLoc> was moved out of <physDesc> to become its sibling, while <provenance> stayed within <physDesc>.
Please see the discussion from December 2012 below. Since then, the FRBR module has become an optional part of the MEI schema, but that doesn't solve the problem regarding the <provenance> element's place. The issue was brought up again in early April 2014 on MEI-L. You may find it in the archives: https://lists.uni-paderborn.de/pipermail/mei-l/2014/date.html (look for the 'history of sources / items' discussion).

My first problem with the current state is that I cannot understand the account of an item's provenance as part of its physical description. Provenance is part of an item's history, and it cannot be described from the item's physical appearance (even if, of course, the provenance may have left a few physical trails, such as library stamps or written shelf marks).
The second problem is how to use the current model. When using MEI without the FRBR module, the <item> element is not available and therefore all item-related information must be encoded at source level. That means: if there is more than one copy of a particular source, all the copies' physical locations and their provenance must be recorded within the same <source> element. But with <physLoc> and <provenance> separated, how can we tell which provenance corresponds to which current location (see the discussion below)?

There are a number of possible solutions that I can imagine. All of them imply moving <provenance> out of <physDesc>:
1. <provenance> could become a child of <physLoc>. This way, <provenance> would be regarded as supplementary information to the item's current location - or <physLoc>'s historical record, so to speak. Something like this:
<physLoc>
    <repository/>
    <identifier/>
    <provenance>
        <eventList/>
        ...
    </provenance>
</physLoc>

2. The other way around: <physLoc> could be a child of <provenance> (which in turn would become a sibling of <physDesc>). This would make <physLoc> more like the end point of a provenance time line:
<provenance>
    <physLoc>
        <repository/>
        <identifier/>
    </physLoc>
    <eventList/>
    ...
</provenance>

3. A new container for both could be introduced to group them as siblings (I can't think of a suitable name for such a container, though)

4. <provenance> could simply become a sibling of <physLoc> and a direct descendant of <source> (and <item>, of course, when using the FRBR module):
<source>
    ...
    <physDesc/>
    <physLoc>
        <repository/>
        <identifier/>
    </physLoc>
    <provenance>
        </eventList/>
        ...
    </provenance>
    ...
</source>



5. All the solutions I haven't thought of...



Any opinions? It would be nice to have consensus in this group as much as possible before making any suggestions to MEI-L and filing an issue for the next release.



Best,

Axel



________________________________
Fra: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu]
Sendt: 8. december 2012 15:25
Til: Music Encoding Initiative
Emne: Re: [MEI-L] physLoc

Axel,



To describe the provenance of two copies in different locations, I would leave your example exactly as it is.  Or I might even compress the two <provenance> elements into one --


<source>
  <physDesc>
    <provenance>This relates to one location. This relates to the other location.</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive</repository>
  </physLoc>
  <physLoc>
    <repository>some other archive</repository>
  </physLoc>
</source>



The text in <provenance> explains its relationship to the items in the different locations.



@sameas is incorrect, but I would not attempt to connect the <provenance> element to the <physLoc> elements.  That's a level of detail that is not required using this "text-based" approach.  Going to the FRBR approach is a better option for that level of detail.



In order to make the distinction between the two approaches more clear, it might be worth considering allowing only one <physLoc> in <source>.  The example then would be


<source>
  <physDesc>
    <provenance>This relates to one location. This relates to the other location.</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive. some other archive</repository>
  </physLoc>
</source>



--

p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Saturday, December 08, 2012 5:59 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] physLoc
Hi Perry,

to get back to the physLoc question: you wrote

does the provenance information pertain to only the copy in the first physical location or to both?  If it pertains to both, then the <provenance> elemement shouldn't be a child of the first <physLoc>, but should exist outside it.  Assuming <provenance> is permitted only within <physLoc>, if I want to say that both copies have always been kept together, then information will have to be repeated.  For example,

<source>
  <physDesc/>
  <physLoc>
    <provenance>Always together</provenance>
  </physLoc>
  <physLoc>
    <provenance>Always together</provenance>
  </physLoc>
</source>
I see that this would require information to be repeated. However, I think usually the situation would rather be that items in different physical locations (typically copies kept in different archives) would have different provenance. How would you describe that? You would have something like:

<source>
  <physDesc>
    <provenance>This relates to one location</provenance>
    <provenance>This relates to the other location</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive</repository>
  </physLoc>
  <physLoc>
    <repository>some other archive</repository>
  </physLoc>
</source>

With <physLoc> and <provenance> separated, you would have to use IDREFs to clarify which provenance is related to which location (or item), right? Is that better than repeating information or using someting like @sameas in those (rare, I would say) cases, where several items in _different_ locations (or with different shelf marks) share the same provenance?

Have a nice weekend,
Axel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/8b1dc14d/attachment.html>

From K.McAulay at rcs.ac.uk  Tue Nov 10 13:41:25 2015
From: K.McAulay at rcs.ac.uk (Karen McAulay)
Date: Tue, 10 Nov 2015 12:41:25 +0000
Subject: [mei-catalog-ig] Unsubscribe? How do I ...
Message-ID: <DB3PR03MB04259F6A0B8C1685ECE975DAF140@DB3PR03MB042.eurprd03.prod.outlook.com>

Dear MEI list

How do I unsubscribe from your list, please?  Nothing personal, but the discussions, whilst fascinating, are too technical for me!

Many thanks

Karen McAulay

Dr. Karen McAulay
Music and Academic Services Librarian
+44 (0)141 270 8267 (direct)
K.McAulay at rcs.ac.uk
[cid:image001.jpg at 01D11BB5.191D82D0]<http://www.rcs.ac.uk/>
     [cid:image002.gif at 01D11BB5.191D82D0] <http://www.facebook.com/rcsofficial>     [cid:image003.gif at 01D11BB5.191D82D0] <http://twitter.com/rcstweets>     [cid:image004.jpg at 01D11BB5.191D82D0] <http://www.rcs.ac.uk/hub/>
[cid:image005.jpg at 01D11BB5.191D82D0]<http://www.isme2016glasgow.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/62fb6825/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6657 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/62fb6825/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1280 bytes
Desc: image002.gif
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/62fb6825/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 1279 bytes
Desc: image003.gif
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/62fb6825/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 17868 bytes
Desc: image004.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/62fb6825/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 584415 bytes
Desc: image005.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/62fb6825/attachment-0002.jpg>

From atge at kb.dk  Tue Nov 10 14:09:17 2015
From: atge at kb.dk (Axel Teich Geertinger)
Date: Tue, 10 Nov 2015 13:09:17 +0000
Subject: [mei-catalog-ig] [MEI-L] FW: changes to <eventList> and <event>
In-Reply-To: <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de>
References: <BBCC497C40D85642B90E9F94FC30343D7C722600@reagan.eservices.virginia.edu>
 <A348F6E5-1E8B-40FB-BA7A-6372EF374912@edirom.de>
 <BBCC497C40D85642B90E9F94FC30343D7C722651@reagan.eservices.virginia.edu>
 <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de>
 <BBCC497C40D85642B90E9F94FC30343D7C72276F@reagan.eservices.virginia.edu>
 <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC20D@EXCHANGE-02.kb.dk>

Hi Johannes & Perry 

This discussion is started on both MEI-L and MEI-Catalog-IG; I'm posting my reply to both lists, but in order not to exclude anyone now I suggest we continue the discussion on MEI-L only.

I agree with Johannes that an alternating sequence of date and event elements would be a way of looking for trouble. If I want to delete an event or change the order of events, I would have to make sure always to do the same with the preceding date sibling. If there is any. I would definitely prefer being able to address an event or group of events as a single element without having to care about any siblings. Also, Perry's model (if I read your suggestion correctly) implies that it would not be possible to have an <event> without a preceding <date>. But we are not always able to date events. Even if <date> could be left empty, the construct would seem somehow awkward to me.  
Finally, from a purely practical perspective, the way we handle elements would make it a pain to maintain and edit such a list of alternating elements. 

If we are introducing <eventGrp>, we have a clear way of distinguishing a list of events (that is, a possibly unordered, non-grouped <eventList>) from a group of events that have something in common. Let's not mix them up. If we want to group events by date, we could do so by allowing <date> or any eventPart element within <eventGrp> (but not in <eventList>):

<eventList>
  <event><!-- some single event --></event>
  <eventGrp>
    <!-- a group of events -->
    <date><!-- the grouping parameter - could also be geogName etc. instead --></date>
    <event><!-- event 1 --></event>
    <event><!-- event 2 etc. --></event>
  </eventGrp>
</eventList>

Alternatively, the @isodate approach could be used on <eventGrp>.

/axel

-----Oprindelig meddelelse-----
Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Johannes Kepper
Sendt: 10. november 2015 00:20
Til: Music Encoding Initiative
Emne: Re: [MEI-L] FW: changes to <eventList> and <event>

Hi Perry,

I understand (and fully support) your motivation to clean up events. However, could you please refresh my memory and indicate the current / planned content of event? Maybe I understand your proposal to move all these things out of events better with that model in mind. As you know, we use even annots in a data-like way, and while I agree that both annots and events are perfectly valid to take free-form content, I'm still in love with structured things - maybe just a couple of attributes. Or would it be an alternative to provide separate elements for free-form and structured content, like <annot> and <annotStruct> or <event> and <eventStruct>?

Just guessing.
jo


Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:

> 
> Our current handling of <eventList> is a mess, which reduces its 
> effectiveness for data interchange and interoperability.  Clarifying 
> its possible content can counteract this tendency.  It's relatively 
> easy to provide alternative grouping mechanisms.  For instance, a 
> content model for <eventList> like --
> 
> <content>
>  <rng:zeroOrMore>
>    <rng:ref name="model.headLike"/>
>  </rng:zeroOrMore>
>  <rng:optional>
>    <rng:ref name="listHead"/>
>  </rng:optional>
>  <rng:zeroOrMore>
>    <rng:group>
>      <rng:choice>
>        <rng:ref name="model.eventPart"/>
>      </rng:choice>
>      <rng:choice>
>        <rng:ref name="event"/>
>        <rng:ref name="eventGrp"/>
>      </rng:choice>
>    </rng:group>
>  </rng:zeroOrMore>
>  <rng:zeroOrMore>
>    <rng:ref name="biblList"/>
>  </rng:zeroOrMore>
> </content>
> 
> would allow any member of model.eventPart to act as the organizing 
> "term".  For instance,
> 
> <eventList>
>  <date><!-- date of event --></date>
>  <event><!-- event description --></event>
>  <!-- and so on -->
> </eventList>
> 
> or
> 
> <eventList>
>  <geogName><!-- place of event --></geogName>
>  <event><!-- event description --></event>
>  <!-- and so on -->
> </eventList>
> 
> or
> 
> <eventList>
>  <persName><!-- personal name, of conductor for example --></persName>
>  <event><!-- event description --></event>
>  <!-- and so on -->
> </eventList>
> 
> are all possible.  This is the essentially the model used by HTML for <dl>, by EAD for <chronlist>, and by TEI for <list> of @type "gloss".  The difficulty, of course, is ensuring that each event in a list is preceded by the same kind of element.  I'm not sure if this is possible using RNG alone, but it can certainly be enforced using Schematron.
> 
> --
> p.
> 
> 
>> -----Original Message-----
>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf 
>> Of Johannes Kepper
>> Sent: Monday, November 09, 2015 4:40 PM
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event>
>> 
>> 
>> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h)
>> <pdr4h at eservices.virginia.edu>:
>> 
>>> 
>>> An <eventGrp> element containing <event> with the current model 
>>> makes
>> no sense as there's no indication of the grouping criterion.  The 
>> <date> followed by <eventGrp> construct makes it clear that the 
>> events are grouped by date.  In fact, that's the only way to group them using this model.
>> 
>> Ok, what constitutes a group of events? What does it mean to have 
>> events grouped? Is there any other grouping mechanism other than by 
>> date? Does it make sense to have events grouped by place? If so, why 
>> don't we factor in groups (by date, for instance) and subgroups (by 
>> place)? Or is it maybe better to let the grouping be done by 
>> applications, based on structured markup like @isodate, @resp, @type and similar options?
>> 
>>> 
>>> It is nothing like the concept of chords that you raise.
>> 
>> I need to look into the preceding sibling to fully understand the 
>> current element...
>> 
>>> Order is a good thing here as it makes the structure of the data clear.
>>> 
>> 
>> jo
>> 
>>> --
>>> p.
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf 
>>>> Of Johannes Kepper
>>>> Sent: Monday, November 09, 2015 4:20 PM
>>>> To: Music Encoding Initiative
>>>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event>
>>>> 
>>>> I'm sorry to say, but I'm not convinced by this one either. I see 
>>>> the point to have an eventGroup element, but everything else seems 
>>>> rather dubious to me. By all means, I would like to keep the date 
>>>> inside events, even for free- form text-driven events (in contrast 
>>>> to data-driven events). Also, I hate the idea to have an 
>>>> alternation of events and something, and have to rely on document 
>>>> order to understand the meaning of something - this gets pretty 
>>>> close to MusicXML's concept of chords, doesn't it? Are there any 
>>>> real-world limitations that motivate this proposal? If so, could we 
>>>> discuss it with
>> those examples on the table?
>>>> 
>>>> jo
>>>> 
>>>> 
>>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h)
>>>> <pdr4h at eservices.virginia.edu>:
>>>> 
>>>>> 
>>>>> I sent this message to the cataloging interest group list earlier.
>>>>> I apologize if
>>>> you receive it twice, but I thought it would be a good idea to post 
>>>> to this list as well in the interest of generating as much 
>>>> discussion as
>> possible.
>>>>> 
>>>>> BTW, this is not a new feature, but rather a remedy for an 
>>>>> existing bug. But
>>>> I think it's finally squashed this time.
>>>>> 
>>>>> --
>>>>> p.
>>>>> 
>>>>> 
>>>>> From: Roland, Perry D. (pdr4h)
>>>>> Sent: Monday, November 09, 2015 3:46 PM
>>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de'
>>>>> Subject: changes to <eventList> and <event>
>>>>> 
>>>>> 
>>>>> I know we've had a few rounds of discussion about the content 
>>>>> models of
>>>> <eventList> and <event> in the past.  I think there are basically 2 
>>>> issues currently facing us:
>>>>> 
>>>>> *       eventList contains a bug that doesn't allow grouping events that
>> share
>>>> the same date
>>>>> *       the model of event is too vague
>>>>> 
>>>>> I propose to remedy the first problem by using the following 
>>>>> content model
>>>> for <eventList>:
>>>>> 
>>>>> eventList   (head*, listHead?, (date, (event | eventGrp))*, biblList*)
>>>>> 
>>>>> By placing <date> outside the model of <event>, the main content 
>>>>> of <eventList> can be constrained to be any number of pairs of 
>>>>> <date> and <event> elements, like so -
>>>>> 
>>>>> <eventList>
>>>>> <date><!-- when "it" happened --></date>
>>>>> <event><!-- what happened -->
>>>>> <date><!-- another happening --></date>
>>>>> <event><!-- another description -->
>>>>> <!-- and so on -->
>>>>> </eventList>
>>>>> 
>>>>> Or, when multiple events share the same date, like so --
>>>>> 
>>>>> <eventList>
>>>>> <date><!-- the date --></date>
>>>>> <eventGrp>  <!-- the events occurring on the date -->
>>>>>   <event>Event 1</event>
>>>>>  <event> Event 2</event>
>>>>>  <!-- and so on -->
>>>>> </eventGrp>
>>>>> </eventList>
>>>>> 
>>>>> The new model also introduces listHead, a new formatting element.
>>>>> <listHead> contains a pair of <head> elements, one for each column 
>>>>> in the eventList date-event pair.  This makes it possible to treat 
>>>>> the list of events as though it were a table with a column heading 
>>>>> for the dates and a heading for the descriptions.  Of course, 
>>>>> eventList/head continues to contain a heading for the entire list 
>>>>> --
>>>>> 
>>>>> <eventList>
>>>>> <head>My List o' Special Events</head>  <listHead>
>>>>>   <head>When</head>
>>>>> <head>What</head>
>>>>> </listHead>
>>>>> <event/>
>>>>> <event/>
>>>>> </eventList>
>>>>> 
>>>>> I plan to investigate how this might work for other lists as well, 
>>>>> such as
>>>> <biblList>, <castList>, and <list>.  Any list that allows a label 
>>>> preceding its "items" could benefit from this treatment, I think.
>>>>> 
>>>>> One more change -- <eventList> is now a member of model.listLike,
>>>> meaning it can occur not just in the header but anywhere a "regular"
>>>> list can happen.
>>>>> 
>>>>> The <event> element now has the following model (switching to RNG 
>>>>> as it's somewhat clearer than DTD syntax) --
>>>>> 
>>>>> <content>
>>>>> <rng:optional>
>>>>>   <rng:ref name="model.labelLike"/>  </rng:optional>  <rng:choice>
>>>>>   <!-- data-like organization -->
>>>>>   <rng:zeroOrMore>
>>>>>     <rng:choice>
>>>>>       <rng:ref name="model.eventPart"/>
>>>>>       <rng:ref name="eventList"/>
>>>>>     </rng:choice>
>>>>>   </rng:zeroOrMore>
>>>>>   <!-- free-form organization -->
>>>>>   <rng:zeroOrMore>
>>>>>     <rng:choice>
>>>>>       <!-- model.listLike is expanded here in order to disallow biblList -->
>>>>>       <rng:ref name="model.pLike"/>
>>>>>       <rng:ref name="model.tableLike"/>
>>>>>       <rng:ref name="castList"/>
>>>>>       <rng:ref name="eventList"/>
>>>>>       <rng:ref name="list"/>
>>>>>     </rng:choice>
>>>>>   </rng:zeroOrMore>
>>>>> </rng:choice>
>>>>> <rng:zeroOrMore>
>>>>>   <rng:ref name="biblList"/>
>>>>> </rng:zeroOrMore>
>>>>> </content>
>>>>> 
>>>>> English translation is "an optional label, followed by EITHER some 
>>>>> data-like
>>>> elements or nested eventLists OR any number of paragraphs, tables, 
>>>> castLists, eventLists, or lists, followed by any number of lists of 
>>>> bibliographic citations."
>>>>> 
>>>>> The central choice (a data-centric organization OR a free-form 
>>>>> text
>>>>> one) is the important factor here.  In purely practical terms, any 
>>>>> file that formerly used a group of data elements followed by a 
>>>>> paragraph will have to be translated into --
>>>>> 
>>>>> <event>
>>>>> <label><!-- former paragraph content -->  <geogName/><persName/>
>>>>> <!-- etc. --> </event>
>>>>> 
>>>>> This element re-naming and re-ordering is not a difficult task and 
>>>>> can be
>>>> made part of the 2013 -> 2015 XSLT transformation.  If the 
>>>> re-ordering poses a significant issue (that is, you *must* have the 
>>>> data elements followed by the label), I think it's not a problem to 
>>>> allow
>> that, but please let me know.
>>>>> 
>>>>> As always, I apologize for the length of the message and the XML 
>>>>> "gobbledy-gook".  I just don't know of any other way to communicate.
>>>>> ;-)
>>>>> 
>>>>> --
>>>>> p.
>>>>> 
>>>>> ________________________________
>>>>> Perry Roland
>>>>> University of Virginia
>>>>> P. O. Box 400874
>>>>> Charlottesville, VA, 22904
>>>>> 434-982-2702 (w)
>>>>> pdr4h (at) virginia (dot) edu
>>>>> 
>>>>> _______________________________________________
>>>>> 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
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From atge at kb.dk  Tue Nov 10 14:32:23 2015
From: atge at kb.dk (Axel Teich Geertinger)
Date: Tue, 10 Nov 2015 13:32:23 +0000
Subject: [mei-catalog-ig] Unsubscribe? How do I ...
In-Reply-To: <DB3PR03MB04259F6A0B8C1685ECE975DAF140@DB3PR03MB042.eurprd03.prod.outlook.com>
References: <DB3PR03MB04259F6A0B8C1685ECE975DAF140@DB3PR03MB042.eurprd03.prod.outlook.com>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC282@EXCHANGE-02.kb.dk>

Dear Karen (and list)

I'd be sorry to see you leave the list. Discussions here don't always have to be so technical - also news about upcoming events, new online resources or just general questions about cataloging and metadata (primarily MEI-related, though) may be posted here.
If you do want to unsubscribe, please visit https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig and look for the "Unsubscribe" button at the bottom of the page.

Best wishes,
Axel


Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Karen McAulay
Sendt: 10. november 2015 13:41
Til: 'mei-catalog-ig at lists.uni-paderborn.de'
Emne: [mei-catalog-ig] Unsubscribe? How do I ...

Dear MEI list

How do I unsubscribe from your list, please?  Nothing personal, but the discussions, whilst fascinating, are too technical for me!

Many thanks

Karen McAulay

Dr. Karen McAulay
Music and Academic Services Librarian
+44 (0)141 270 8267 (direct)
K.McAulay at rcs.ac.uk<mailto:K.McAulay at rcs.ac.uk>
[cid:image001.jpg at 01D11BC4.9CA257C0]<http://www.rcs.ac.uk/>
     [cid:image002.gif at 01D11BC4.9CA257C0] <http://www.facebook.com/rcsofficial>     [cid:image003.gif at 01D11BC4.9CA257C0] <http://twitter.com/rcstweets>     [cid:image004.jpg at 01D11BC4.9CA257C0] <http://www.rcs.ac.uk/hub/>
[cid:image005.jpg at 01D11BC4.9CA257C0]<http://www.isme2016glasgow.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/879169c8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6657 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/879169c8/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 1280 bytes
Desc: image002.gif
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/879169c8/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 1279 bytes
Desc: image003.gif
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/879169c8/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 17868 bytes
Desc: image004.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/879169c8/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 584415 bytes
Desc: image005.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/879169c8/attachment-0002.jpg>

From atge at kb.dk  Tue Nov 10 14:58:10 2015
From: atge at kb.dk (Axel Teich Geertinger)
Date: Tue, 10 Nov 2015 13:58:10 +0000
Subject: [mei-catalog-ig] <physLoc> and <provenance>
In-Reply-To: <1447159534.5942.1@smtp.gmail.com>
References: <BBCC497C40D85642B90E9F94FC30343D7C72251D@reagan.eservices.virginia.edu>
 <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC194@EXCHANGE-02.kb.dk>
 <1447159534.5942.1@smtp.gmail.com>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC2FD@EXCHANGE-02.kb.dk>

Hi Klaus

I see your point. But if we are talking about the source’s history in more general terms, the <history> perhaps shouldn’t be located inside <physLoc>. Having <history> inside <physLoc> would suggest something like the archive’s history to me rather than the source’s. Within <physLoc>, I think it should be restricted to actually describe the provenance only and therefore keep the name.
Using a <history> element located outside of <physLoc> to describe provenance, on the other hand, would leave us with the problem we have now (and as in my suggestion #4, by the way) that it is difficult to tell which history-like elements relate to which <physLoc>.

That doesn’t mean that <history> is out of place in <source>. Especially with printed sources it would make a good place to describe the publishing process, for instance. <provenance> can only relate to items (even if it is allowed in <source>, if you don’t use FRBR), so having a more general <history> element at source level may be a good idea.

/axel

Fra: Klaus Rettinghaus [mailto:klaus.rettinghaus at gmail.com]
Sendt: 10. november 2015 13:46
Til: Axel Teich Geertinger
Emne: Re: [mei-catalog-ig] <physLoc> and <provenance>

Hello Perry,

this is most likely the move that makes most sense.
But I was asking myself if <provenance> (as it provides some 'historical' information) tells us only something about the location of a source or more of the source itself?
Personally I would assume the latter.
So why not drop <provenance> completely and replace it with <history> as in <work>. In either place <history> should provide information about events (with persons, dates, and places all along) or more of unstructered data in a simple <p>. That approach would clear up and simplify some things. Or am I missing something there?

Klaus


Am Di, 10. Nov, 2015 um 1:24 schrieb Axel Teich Geertinger <atge at kb.dk<mailto:atge at kb.dk>>:

Hi Perry

I agree (I guess that’s why I listed it as no. 1). Furthermore, having <provenance> as a child of <physLoc> would also nicely fit the assumption that the latest provenance event refers to the source’s current location.

/axel

Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 9. november 2015 20:54
Til: mei-catalog-ig at lists.uni-paderborn.de<mailto:mei-catalog-ig at lists.uni-paderborn.de>
Emne: Re: [mei-catalog-ig] <physLoc> and <provenance>


Hello all,

Since <physLoc> can occur more than once within <source> (necessary because <item> isn’t available when MEI.frbr is turned off), it seems to me that the best option is #1.  It involves the least amount of change to the content models of <item> and <source>; that is, only a move of <provenance> from <physDesc> to <physLoc>.

Because it’s a pretty simple change, it’s easy to implement quickly.  There’s no fixed deadline for changes to the next release of MEI, but I’d rather make the change sooner than later.  While we’re in “metadata revising” mode, I’d also like to discuss a couple more modifications to the header, but I’ll post separate messages about those soon.

--
p.

________________________________
Perry Roland
University of Virginia
P. O. Box 400874
Charlottesville, VA, 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu



________________________________
Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Axel Teich Geertinger
Sendt: 2. november 2015 21:19
Til: mei-catalog-ig at lists.uni-paderborn.de<mailto:mei-catalog-ig at lists.uni-paderborn.de>
Emne: [mei-catalog-ig] <physLoc> and <provenance>

Dear Metadata IG

As you know, a new version of the MEI schema is in preparation which will break backwards compatibility in a few instances. I think we should take the opportunity to make a recommendation regarding an issue that has been raised a few times but never resolved.
In late 2012, the content model of the MEI header was revised. Until then, both <physLoc> (holding information about the physical location of a source) and <provenance> had both been children of the source's <physDesc> (physical description). With the revision, <physLoc> was moved out of <physDesc> to become its sibling, while <provenance> stayed within <physDesc>.
Please see the discussion from December 2012 below. Since then, the FRBR module has become an optional part of the MEI schema, but that doesn't solve the problem regarding the <provenance> element's place. The issue was brought up again in early April 2014 on MEI-L. You may find it in the archives: https://lists.uni-paderborn.de/pipermail/mei-l/2014/date.html (look for the 'history of sources / items' discussion).

My first problem with the current state is that I cannot understand the account of an item's provenance as part of its physical description. Provenance is part of an item's history, and it cannot be described from the item's physical appearance (even if, of course, the provenance may have left a few physical trails, such as library stamps or written shelf marks).
The second problem is how to use the current model. When using MEI without the FRBR module, the <item> element is not available and therefore all item-related information must be encoded at source level. That means: if there is more than one copy of a particular source, all the copies' physical locations and their provenance must be recorded within the same <source> element. But with <physLoc> and <provenance> separated, how can we tell which provenance corresponds to which current location (see the discussion below)?

There are a number of possible solutions that I can imagine. All of them imply moving <provenance> out of <physDesc>:
1. <provenance> could become a child of <physLoc>. This way, <provenance> would be regarded as supplementary information to the item's current location - or <physLoc>'s historical record, so to speak. Something like this:
<physLoc>
    <repository/>
    <identifier/>
    <provenance>
        <eventList/>
        ...
    </provenance>
</physLoc>

2. The other way around: <physLoc> could be a child of <provenance> (which in turn would become a sibling of <physDesc>). This would make <physLoc> more like the end point of a provenance time line:
<provenance>
    <physLoc>
        <repository/>
        <identifier/>
    </physLoc>
    <eventList/>
    ...
</provenance>

3. A new container for both could be introduced to group them as siblings (I can't think of a suitable name for such a container, though)

4. <provenance> could simply become a sibling of <physLoc> and a direct descendant of <source> (and <item>, of course, when using the FRBR module):
<source>
    ...
    <physDesc/>
    <physLoc>
        <repository/>
        <identifier/>
    </physLoc>
    <provenance>
        </eventList/>
        ...
    </provenance>
    ...
</source>



5. All the solutions I haven't thought of...



Any opinions? It would be nice to have consensus in this group as much as possible before making any suggestions to MEI-L and filing an issue for the next release.



Best,

Axel



________________________________
Fra: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu]
Sendt: 8. december 2012 15:25
Til: Music Encoding Initiative
Emne: Re: [MEI-L] physLoc

Axel,



To describe the provenance of two copies in different locations, I would leave your example exactly as it is.  Or I might even compress the two <provenance> elements into one --


<source>
  <physDesc>
    <provenance>This relates to one location. This relates to the other location.</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive</repository>
  </physLoc>
  <physLoc>
    <repository>some other archive</repository>
  </physLoc>
</source>



The text in <provenance> explains its relationship to the items in the different locations.



@sameas is incorrect, but I would not attempt to connect the <provenance> element to the <physLoc> elements.  That's a level of detail that is not required using this "text-based" approach.  Going to the FRBR approach is a better option for that level of detail.



In order to make the distinction between the two approaches more clear, it might be worth considering allowing only one <physLoc> in <source>.  The example then would be


<source>
  <physDesc>
    <provenance>This relates to one location. This relates to the other location.</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive. some other archive</repository>
  </physLoc>
</source>



--

p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Saturday, December 08, 2012 5:59 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] physLoc
Hi Perry,

to get back to the physLoc question: you wrote

does the provenance information pertain to only the copy in the first physical location or to both?  If it pertains to both, then the <provenance> elemement shouldn't be a child of the first <physLoc>, but should exist outside it.  Assuming <provenance> is permitted only within <physLoc>, if I want to say that both copies have always been kept together, then information will have to be repeated.  For example,

<source>
  <physDesc/>
  <physLoc>
    <provenance>Always together</provenance>
  </physLoc>
  <physLoc>
    <provenance>Always together</provenance>
  </physLoc>
</source>
I see that this would require information to be repeated. However, I think usually the situation would rather be that items in different physical locations (typically copies kept in different archives) would have different provenance. How would you describe that? You would have something like:

<source>
  <physDesc>
    <provenance>This relates to one location</provenance>
    <provenance>This relates to the other location</provenance>
  </physDesc>
  <physLoc>
    <repository>some archive</repository>
  </physLoc>
  <physLoc>
    <repository>some other archive</repository>
  </physLoc>
</source>

With <physLoc> and <provenance> separated, you would have to use IDREFs to clarify which provenance is related to which location (or item), right? Is that better than repeating information or using someting like @sameas in those (rare, I would say) cases, where several items in _different_ locations (or with different shelf marks) share the same provenance?

Have a nice weekend,
Axel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20151110/146c135b/attachment.html>

From klaus.rettinghaus at gmail.com  Thu Nov 12 13:39:47 2015
From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus)
Date: Thu, 12 Nov 2015 13:39:47 +0100
Subject: [mei-catalog-ig] <physLoc> and <provenance>
Message-ID: <1447331987.3364.0@smtp.gmail.com>

Hi Axel,



sorry I didn't make myself totally clear here:

I didn't mean to put a <history> inside a <physLoc> but more like 
replacing <provenance> with <history> *and* making <physDesc>, 
<physLoc>, and <history> all alike siblings and childred of <source>.

And as you know there are and always will be situations you can't 
encode information straight forward. So IDREFs can't be avoided in 
*every* case.



Klaus



From pdr4h at eservices.virginia.edu  Thu Nov 12 21:46:16 2015
From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h))
Date: Thu, 12 Nov 2015 20:46:16 +0000
Subject: [mei-catalog-ig] <physLoc> and <provenance>
In-Reply-To: <1447331987.3364.0@smtp.gmail.com>
References: <1447331987.3364.0@smtp.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D8D33C162@grant1.eservices.virginia.edu>


Hi Klaus, 

I see where you're going with this, but "provenance" (in library parlance) and "history" are different things.  The distinction is subtle, but real nonetheless.  "History" is a more general term than "provenance", the latter being a only record of possession or ownership.  As it deals with physical location historically, it makes sense to me for <provenance> to be located inside <physLoc>.

I have no objection to adding <history> as a child of <source> (and as a sibling of <physDesc> and <physLoc>) other than the fact that I'm afraid other users will also be confused about the difference between "history" and "provenance".  On the other hand, many will know the difference (and use the elements appropriately), while the rest can be guided by well-written documentation.  :-)

--
p.


> -----Original Message-----
> From: mei-catalog-ig [mailto:mei-catalog-ig-
> bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Klaus
> Rettinghaus
> Sent: Thursday, November 12, 2015 7:40 AM
> To: 'mei-catalog-ig at lists.uni-paderborn.de'
> Subject: [mei-catalog-ig] <physLoc> and <provenance>
> 
> Hi Axel,
> 
> 
> 
> sorry I didn't make myself totally clear here:
> 
> I didn't mean to put a <history> inside a <physLoc> but more like replacing
> <provenance> with <history> *and* making <physDesc>, <physLoc>, and
> <history> all alike siblings and childred of <source>.
> 
> And as you know there are and always will be situations you can't encode
> information straight forward. So IDREFs can't be avoided in
> *every* case.
> 
> 
> 
> Klaus
> 
> 
> _______________________________________________
> mei-catalog-ig mailing list
> mei-catalog-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig

From atge at kb.dk  Fri Nov 13 09:18:57 2015
From: atge at kb.dk (Axel Teich Geertinger)
Date: Fri, 13 Nov 2015 08:18:57 +0000
Subject: [mei-catalog-ig] <physLoc> and <provenance>
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D8D33C162@grant1.eservices.virginia.edu>
References: <1447331987.3364.0@smtp.gmail.com>
 <BBCC497C40D85642B90E9F94FC30343D8D33C162@grant1.eservices.virginia.edu>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEED352@EXCHANGE-02.kb.dk>

Hi Perry & Klaus

That was exactly what I was about to suggest: allowing <history> in <source>, not to substitute <provenance> but as a more general supplement. I suggest adding it to <item> as well, though. Then it would be available at all four FRBR levels. Seems to make sense (to me at least).

Best,
Axel

-----Oprindelig meddelelse-----
Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 12. november 2015 21:46
Til: MEI Metadata and Cataloging Interest Group
Emne: Re: [mei-catalog-ig] <physLoc> and <provenance>


Hi Klaus, 

I see where you're going with this, but "provenance" (in library parlance) and "history" are different things.  The distinction is subtle, but real nonetheless.  "History" is a more general term than "provenance", the latter being a only record of possession or ownership.  As it deals with physical location historically, it makes sense to me for <provenance> to be located inside <physLoc>.

I have no objection to adding <history> as a child of <source> (and as a sibling of <physDesc> and <physLoc>) other than the fact that I'm afraid other users will also be confused about the difference between "history" and "provenance".  On the other hand, many will know the difference (and use the elements appropriately), while the rest can be guided by well-written documentation.  :-)

--
p.


> -----Original Message-----
> From: mei-catalog-ig [mailto:mei-catalog-ig-
> bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Klaus
> Rettinghaus
> Sent: Thursday, November 12, 2015 7:40 AM
> To: 'mei-catalog-ig at lists.uni-paderborn.de'
> Subject: [mei-catalog-ig] <physLoc> and <provenance>
> 
> Hi Axel,
> 
> 
> 
> sorry I didn't make myself totally clear here:
> 
> I didn't mean to put a <history> inside a <physLoc> but more like 
> replacing <provenance> with <history> *and* making <physDesc>, 
> <physLoc>, and <history> all alike siblings and childred of <source>.
> 
> And as you know there are and always will be situations you can't 
> encode information straight forward. So IDREFs can't be avoided in
> *every* case.
> 
> 
> 
> Klaus
> 
> 
> _______________________________________________
> mei-catalog-ig mailing list
> mei-catalog-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig
_______________________________________________
mei-catalog-ig mailing list
mei-catalog-ig at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig