[MEI-L] revision of <bibl>
Benjamin Wolff Bohl
bohl at edirom.de
Wed Oct 24 09:26:43 CEST 2012
Hi all,
great thing this is being discussed on MEI-L .
[1] A more strict version of mei:bibl is a good idea to support encpding
structured data and I suppose Axel is the one to best estimate the
degree of strictness currently needed.
[2] As for the new elements I agree with Peter that we should remodel
existing schemata and only "reinvent the wheel" if we see they are
lacking some specific feature or are problematic in any other way.
[another two cents]Consequently a first thing already problematic in the
concept is mei:series and mei:seriesStmt vs.
mei:relatedItem[@rel='series'] as this implements two different ways. I
know this is a devloping thing and for that reson things become
implemnted step by step, nonetheless I would opt for allowing
mei:relatedItem[@rel='series'] in order to allow either encoding with a
small amount of relation in the first case and a relation-based encoding
in the latter. It's a similar case with mei:respStmt/mei:persName[@role]
vs. mei:creator mei:editor etc.
I know allowing multiple ways of encoding the same thing makes files
more ambiguous and harder to process. a new mei:biblStrict on the other
hand could allow for only one way of encoding these phenomena.
Best wihes,
Benjamin
Benjamin Wolff Bohl
***********************************************************
Edirom - Projekt "Digitale Musikedition"
Musikwissenschaftliches Seminar Detmold/Paderborn
Gartenstraße 20
D – 32756 Detmold
Tel. +49 (0) 5231 / 975-669
Fax: +49 (0) 5231 / 975-668
http://www.edirom.de
***********************************************************
Am 23.10.2012 15:04, schrieb Roland, Perry (pdr4h):
> Hi, Axel,
>
> I think you've summed it up very well -- <mei:biblStrict> provides a middle-ground between <bibl> and <tei:biblStruct> -- and I'm glad you agree it's sufficient for the kind of bibliographic description you're doing, which is to say that it will most likely fit others' needs too, since you're doing fairly advanced things.
>
> As for your question about @rel on <relatedItem>, the values for @rel are taken from those used by @type on <relatedItem> in MODS (see http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#relateditem). The value "series" has been left out because we're providing <series> and <seriesStmt> as substitutes for <relatedItem rel="series">. Also, the value "references" has been provided, which was added in version 3.4 (see http://www.loc.gov/standards/mods/mods-changes-3-4.html), but isn't reflected in the MODS User Guide.
>
> While I agree that "host" is probably not the best terminology, I think it's a reasonable label for the relationship between a manuscript letter and its printed counterpart since the letter is contained within the printed edition. Perhaps a better choice would've been "isConstituentOf", which makes a nice pairing with its opposite "constituent". At any rate, in order to maximize interoperability, we should stick with the MODS values.
>
> 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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
> Sent: Tuesday, October 23, 2012 7:08 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] revision of <bibl>
>
> 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
>
> _______________________________________________
> 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