[MEI-L] relateditem and relations between mei elements

[Axel Teich Geertinger]

Hi Perry,

as <relateditem> is modelled after <source>, using it in <filedesc> would of course require some redefinition or probably even a different element (like <relatedWork>, as you suggest). I thought that was what was implied in your response. As it is, I am aware that <relateditem> is usable for bibliographic items only - hence my question about how to relate works. 
Using a uniform title to tie together different versions seems to me a bit too vague. The connection to other versions would be obscured until the entire collection is searched and a matching title in another file is found. Also the kind of relationship would not be clear from a matching title alone, and finally there is the risk of accidentally displaying as related versions two works which just happen to have the same uniform title. Or do I misunderstand the concept?
Using profiledesc/classification I guess would mean something like <keywords n="relatedWorks"><term n="otherVersion">some.id</term></keywords>. This may be somewhat misleading, as I am listing external references, not keywords.
With the existing elements I would prefer using <extptr> or <extref> with @targettype="otherVersion" or @xl:role to explicitly reference related works. In profiledesc/creation however I would have to wrap it in <p></p>, even though it has nothing to do with a paragraph of text.
I could use some of these solutions (preferably the last one), they just don't seem very convincing to me. 

/axel

-----Oprindelig meddelelse-----
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry (pdr4h)
Sendt: 6. januar 2011 00:09
Til: Music Encoding Initiative
Emne: Re: [MEI-L] relateditem and relations between mei elements

Axel,

I've given more thought to my statement earlier about adding <relateditem> to <filedesc> and to the use of <relateditem> in general.  We must be clear that the purpose of <relateditem> is to permit relationships between *bibliographic items*, not *works*.  

In the following example --

<relateditem xml:id="chanson01" rel="constituent">
  <!-- Title of the *chanson* -->
  <titlestmt>
    <title>Qui souhaitez</title>
    <!-- Composer -->
    <respstmt>
      <persname authority="lcnaf">
        <choice>
          <orig>Certon</orig>
          <reg><rend>Certon, Pierre, d. 1572</rend></reg>
        </choice>
      </persname>
    </respstmt>
  </titlestmt>
  <!-- Relateditem can also be used to point to other formats of this, e.g., the text/poetry and/or a Sibelius transcription located on the web -->
  <relateditem rel="otherFormat" n="Text">
    <extref xlink:href="pointer.to.text"/>
  </relateditem>
  <relateditem rel="otherFormat" n="Sibelius">
    <extref xlink:href="pointer.to.SibeliusFile"/>
  </relateditem>
</relateditem>

the top-level <relateditem> is used to enumerate the individual chansons within a composite work, hence rel="constituent".  The nested <relateditem> elements are pointing to *the same intellectual content* in a different *physical form*.  This is fine and dandy.

We begin to get into trouble, however, when <relateditem> is used to relate musical works. I think I didn't read your message carefully enough. Sorry :(

Currently, work-to-work relationships can be described in a couple of places.  One method is to use titlestmt/title type="uniform"; the other is to use profiledesc/creation or /classification.  The first is the traditional librarian-ish method, which is not generally known to or used by non-librarians.

The second is not exactly intuitive either. (<profiledesc> is the container for work-related info., but you'd never know it from the name. It's a lousy name, but it has historical precedent.)

Allowing <relateditem rel="otherVersion"> in <source> and <filedesc> I fear will only encourage users to (mis|ab)use it.

Perhaps what we need is a <relatedwork> element in <profiledesc>.  (And maybe even a name change from <profiledesc> to <workdesc>!)  But, before doing anything I'd like to hear how the current methods don't address your needs and I'd like to investigate work-to-work relationship approaches that others have used.  Of course, I'd like to hear comments from everyone else on the list, too!

Sorry for the back-pedalling,

--
p.

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