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

[Axel Teich Geertinger]

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