[MEI-L] physLoc

[Axel Teich Geertinger]

Hi all

I think this discussion illustrates a problem of the non-FRBR approach to encoding source information: Whithout the distinction between features common to all copies (items) and the individual items, we are in trouble when <source> is used to describe more than one copy (item). This is true not only for physLoc, but for physDesc as well, because there may be some shared features (number of pages, for instance) and indvidual ones (binding, for instance). How would that information be organized without the FRBR <item> level?

Perhaps <physLoc> should not even be allowed in <source> at all when using the bibl customization (and thus standard MEI, later?). Restricting it to <item> would make it clear that <physLoc> - and <provenance>, whether within or outside <physLoc> - refers to this particular item or item component. The schema actually allows only one <physLoc> per item (or item component). I think thats keeps us clear of all the ambiguities we have in <source> now. Actually, having multiple <physLoc> in <source> is really a sort of alternative implementation a FRBR <itemList>, but a very limited one, isn't it? I believe the FRBR approach is the more consistent and more useful one. 

Backwards compatibility... well, compatibility to MEI 2010 was severely broken already with v. 2.0.0, and I doubt anyone has adapted the 2012 <source> encoding yet. I don't think that should be the reason for not changing anything.

Best,
Axel

> -----Oprindelig meddelelse-----
> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-
> paderborn.de] På vegne af Sigfrid Lundberg
> Sendt: 7. december 2012 09:00
> Til: Roland, Perry (pdr4h); mei-l at lists.uni-paderborn.de
> Emne: Re: [MEI-L] physLoc
> 
> 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
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l