[MEI-L] physLoc

[Sigfrid Lundberg]

Hi

I do, naturally agree with Axel. After all we share office. But when I read this I felt that a physLoc is a property or result of an acquisition, which is an event in the history of an object. I.e., somewhat like this

<provenance>
<physLoc>
<repository/>
    <identifier/>
</physLoc>
<physLoc>
<repository/>
    <identifier/>
</physLoc>
</provenance>

Might be that this is a chicken and egg discussion

Sigfrid
________________________________________
Fra: Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu]
Sendt: 6. december 2012 19:57
Til: mei-l at lists.uni-paderborn.de
Emne: RE: physLoc

Hi, everyone,

I'm moving the discussion Axel and I have been having off-line to MEI-L as I think it may be of interest to others.

Regarding the bibliographic customization posted earlier, Axel said:

> I see that <physLoc> is moved out of <physDesc>, but <provenance> is not. Shouldn’t <physLoc> and <provenance> go along?

[...]

> I see <provenance> as something like the history of <physLoc>, and as such I would expect their close relationship to be reflected by the schema. It’s a great improvement that <physLoc> is moved out of <physDesc>. But <physLoc> being a sibling of <physDesc>, while <provenance> is still a child of <physDesc> does not make much sense to me. How about making <provenance> a child of <physLoc> instead? That wouldn’t further increase the number of immediate children of <item>, and it would keep <physLoc> and <provenance> together in a way that would make sense to me:

<item>
  ...
  <physDesc>
    ...
  </physDesc>
  <physLoc>
    ...
    <provenance/>
  </physLoc>
  ...
</item>

I agree that <provenance> can be a history of physical location(s), but it doesn't make sense as a child of <physLoc> when multiple <physLoc> elements are allowed, as is the case of <source> or when an <item> has component parts.

In the following case

<source>
  <physDesc/>
  <physLoc>
    <repository/>
    <identifier/>
    <provenance>...</provenance>
  </physLoc>
  <physLoc>...</physLoc>
</source>

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>

The same is true for

<item>
  <componentGrp>
    <item>
      <physLoc>
        <provenance>...</provenance>
      </physLoc>
    </item>
    <item>
      <physLoc>
        <provenance>...</provenance>
      </physLoc>
    </item>
  </componentGrp>
</item>

The phrase "exist outside it" above, however, doesn't mean that it has to be a sibling of <physLoc> -- it can reside inside <physDesc>, which is a sibling of <physLoc>.  Taking the first case above, <physDesc> can be moved outside either of the <physLoc> elements so that it can apply to both locations.

<source>
  <physDesc>
    <provenance>...</provenance>
  </physDesc>
  <physLoc>
    <repository/>
    <identifier/>
  </physLoc>
  <physLoc>...</physLoc>
</source>

As part of <physDesc>, <provenance> can be associated with either <source> or <item>.  This permits a description of provenance independent of the number of locations.  If, however, one item's history is somehow different from its fellows, then this can be accommodated in the text as well.

Making <provenance> siblings of <physDesc> and <physLoc> (and probably by extension <exhibHist>, <treatHist>, and <treatSched> as well) instead of children of <physDesc> will break backward compatibility as will allowing them only within <item>, and not <source>.  If they're allowed in both places (that is, in <physDesc> and as siblings of <physDesc>, then that will increase the complexity of the schema and therefore decrease the likelihood it will be used properly.  So, I'm inclined to leave well enough alone on this one.

Best wishes,

--
p.


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