[mei-catalog-ig] <physLoc> and <provenance>

Tue Nov 10 14:58:10 CET 2015

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>