[MEI-L] revision of <bibl>
Axel Teich Geertinger
atge at kb.dk
Tue Oct 23 13:08:09 CEST 2012
Hi Perry & all
>From my rather pragmatic point of view, the <biblStrict> element you suggest seems to accommodate very well the information we want to capture in MerMEId. From a more purist point of view, however, one could say that it falls between two stools, neither being as freely structured as <bibl>, nor as strict as <tei:biblStruct>. On the other hand, I also doubt there will be a great need within bibliographic references in MEI for such detailed descriptions as provided by, for instance, <tei:msDesc>, but I may be wrong. I think the <biblStrict> solution is completely satisfying and sufficiently flexible to reference different types of material without lots of unused elements.
I have one question to your original <bibl> example below: You suggest <relatedItem rel="host"> to hold references to editions or transcriptions of (in this case:) letters. "Host" seems to me to be a somewhat vague description of that relation. Is that a standard and sufficiently unambiguous label for an edition or transcription of a manuscript?
All the 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 Roland, Perry (pdr4h)
Sendt: 22. oktober 2012 21:01
Til: Music Encoding Initiative
Emne: Re: [MEI-L] revision of <bibl>
Hi, Peter,
Thanks for your comments. I appreciate your well-thought-out arguments.
I've arrived at the same conclusion as you; that is, that MEI needs a method for capturing structured as well as unstructured bibliographic citations. We already have <bibl> for the unstructured citations, but need to work on a mechanism for more structured ones.
I also agree whole-heartedly that wheel-reinvention is undesirable. But, maintaining backward compatibility at the expense of sensible markup is not a reasonable path either.
I'm not quite yet convinced of the need to adopt a model as highly-structured as TEI's <biblStruct> or the other schemas you pointed to. Looking at Axel's examples and trying to envision future requirements, I don't see a need *at this time* for the level of detail that <biblStruct> provides. So, I've been working toward an element I call <biblStrict>. If we determine that an even more-structured way of handling bibliographic citations/descriptions than <biblStrict> is necessary, we can look at emulating/adopting <biblStruct>, bibtexml, or Zotero.
Whereas, <bibl> allows all inline text elements, <biblStrict> will permit only <title> and the members of a new class, model.biblPart, which has the members: biblScope, contributor, creation, creator, distributor, edition, editor, funder, genre, imprint, physLoc, pubPlace, publisher, recipient, relatedItem, series, and sponsor. This is very similar to the TEI model of <bibl> with inline text elements removed.
There are, however, some useful changes in the MEI model of <biblStrict>, compared with TEI, such as the substitution of <creator> and <contributor> for <author>, which I think you'll agree is not completely satisfying for music. These elements, as well as the other "responsibility-like" elements -- editor, funder, sponsor, and recipient -- are simply syntactic sugar for the <name> element with a role attribute of "editor", "funder", etc. Therefore, I see no harm in adding them to the current MEI model of <bibl> and <titleSmt> -- it makes the MEI model more TEI-like, reduces the markup needed to accurately identify the parts of the citation, and makes the markup more consistent and more processable by removing a number of competing markup possibilities. The <creation>, <genre>, <physLoc>, and <recipient> elements permit the citation of correspondence and other manuscript material without taking on the burden of TEI's <msDesc>.
As all of these elements will be optional, they will not break existing MEI instances. The break in backwards compatibility is limited to the re-definition of <physLoc> and its placement in the class hierarchy. This is necessary to correct a defect in MEI, not to create "castles in the sky".
While it's not as strict as TEI's <biblStruct> element, which requires all its elements in a predetermined order, <biblStrict> accommodates what I would call the "semi-structured" nature of MerMEId's bibliographic citations. And the changes to <physLoc> improve MEI's handling of bibliographic metadata not only in bibliographic citations within text, but in the header as well.
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
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de]
Sent: Saturday, October 20, 2012 4:59 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] revision of <bibl>
Dear Perry,
thank you for disseminating this issue.
I have been discussing mei:bibl with Axel in the last weeks so I feel free to repeat my comments publicly:
First, TEI has the nice separation between tei:bibl and tei: biblStruct where the former is a "loosely-structured bibliographic citation" [1] and the latter a "structured bibliographic citation, in which only bibliographic sub-elements appear and in a specified order. "[2] If your use case is *creating* bibliographical citations, than the plain bibl can be used to store your citations already in the desired style (i.e. with punctuation etc.) which makes e.g. a later html output much easier.
So, my proposal would be to add a mei:biblStruct for at least three reasons:
1. MerMEId is using bibliographic citations in a highly structured way (cf. your examples) 2. It would not break backwards compatibility 3. a clear separation of structured and loosely-structured data which makes processing much easier since the processor knows what to expect. (Of course, the mei:biblStruct would need a clear structure with mandatory elements in a mandatory order)
Second, I don't understand the need for reinventing the wheel. There are a lot of schemata out there for bibliographic data which could be used, since it makes developing much easier as well as interchange. Here I'm not saying to use a different namespace (one could argue so, though) but to adopt the appropriate schemata from e.g. BibtexML[3], Zotero[4] or TEI[2]. For example I'd like to see the possibility to assign keywords/tags -- on the other hand I'm reluctant to introduce those special elements recipient and creation (the latter could go into mei:annot).
All the best
Peter
PS: By the way, mei:bibl is currently described as "Provides a citation for a published work." which should be amended to cover unpublished material as well.
[1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-bibl.html
[2] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-biblStruct.html
[3] http://bibtexml.sourceforge.net
[4] http://www.zotero.org/support/dev/data_model
Am 15.10.2012 um 20:50 schrieb "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>:
> Hello,
>
> Those of you subscribed to the developers list may have already seen a version of this message. My apologies for cross-posting, but I think this is important enough to warrant soliciting a wide range of opinions, since some of the changes proposed will break backwards compatibility.
>
> In order to better support bibliographic applications, such as MerMEId, the content model of <bibl> needs to be revised/expanded. The example below contains several new elements -- creator, editor, contributor, biblScope, genre, imprint, pubPlace, and publisher. These might also be useful at other points in addition to within <bibl>, say in the header, but that is not under consideration at the moment. A new <recipient> element may also be added for correspondence. <distributor> will also be allowed in <imprint>.
>
> In addition, some existing elements, such as <creation>, should also be permitted within <bibl>. This will allow the capture of non-bibliographic details of creation, such as the location where an item was created.
>
> Also, some existing elements, such as <physLoc> and <relatedItem>, should be allowed after re-definition; that is, <physLoc> will no longer function as the call number/shelf location. It will function as the wrapper for <repository> and <identifier>. In this context, <identifier> will hold the shelf number. With the FRBR changes, <relatedItem> will be replaced by <relation>, allowing <relatedItem> to be used as illustrated here.
>
> The new element <biblList> will be a member of model.listLike, allowing it to be used wherever <list> is currently allowed. Other places where it might occur include <work>, <source> (will be called <item> after FRBR implementation, <event>, <eventList>, etc.
>
> <biblList>
> <bibl>
> <!-- genre is preferred over @type on bibl so that authorizing info about the material designation can be captured. -->
> <genre authority="marcgt"
> authURI="http://www.loc.gov/standards/valuelist/marcgt.html">article</genre>
> <creator>Daniel Grimley</creator>
> <title level="a">Modernism and Closure: Nielsen's Fifth Symphony</title>
> <title level="j">The Musical Quarterly</title>
> <!-- The bibliographic unit values below can be added to the unit attribute defined in att.measurement. -->
> <biblScope unit="vol">86</biblScope>
> <biblScope unit="issue">1</biblScope>
> <biblScope unit="pp">149-173</biblScope>
> <imprint>
> <pubPlace>London</pubPlace>
> <date isodate="2002">2002</date>
> </imprint>
> </bibl>
> <bibl>
> <creator>Carl Nielsen</creator>
> <recipient>William Behrend</recipient>
>
> <!-- Name with @role will still be possible, but the specific elements above are preferred. -->
> <name role="author">Carl Nielsen</name>
> <name role="recipient">William Behrend</name>
>
> <date isodate="1904-04-13">1904-04-13</date>
> <genre>letter</genre>
> <creation>
> <geogName>Copenhagen</geogName>
> </creation>
> <physLoc>
> <repository>DK-Kk</repository>
> <identifier>NKS 5155 4°</identifier>
> </physLoc>
> <relatedItem rel="host">
> <bibl>
> <title>CNB</title>
> <biblScope>II/333</biblScope>
> </bibl>
> </relatedItem>
> </bibl>
> </biblList>
>
> Comments are greatly appreciated, especially if this will break anything you're currently doing.
>
> --
> 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
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list