-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I may second:
Ross Singer schrieb:
> On Wed, Jun 23, 2010 at 8:01 AM, Ashley Sanders
> <a.sanders_at_manchester.ac.uk> wrote:
>
> Actually, I'll be completely honest here, this looks like a horrible
> idea. If you've ever had to try to parse and deal with formats that
> do stuff like this (EAD, for example), they're excruciatingly
> difficult to work with, simply because of all of the possible
> variables that can appear when you're just, in this example, trying to
> get the title string.
"tagging" within traditional elements is exactly what one needs
sometimes, not only when one was able to identify personal or
corporate names from words or initials in titles like here
>> <title><name type="corporate">Birmingham and Derby Junction Railway</name>
>> Time Tables.</title>
but also with respect to works and language escapes like here:
Diderot's shade : the discussion on "Ut pictura poesis" and expression in French
art criticism
Pictura loquens - poesis tacens : Studien zu Titelbildern und
Rahmenkompositionen der erzählenden Literatur des 17. Jahrhunderts von Sidneys
"Arcadia" bis Ziglers "Banise"
as for
>> <note>In : <name type="corporate">Midland Counties’ Railway</name>. <work
>> relation="In"><title>The <name type="corporate">Midland Counties’
>> Railway</name> Companion</title>, etc. <dateIssued>1840</dateIssued>.
>> <format>12º</format></work>.</note>
Here I'm not quite sure: If I recall correctly, MODS via <relatedItem> already
allows more general cross-referencing between titles than MARC, i.e.
you are allowed to include a full MODS citation and not restricted to encode
the gist of the MARC description of the target record into the constricted
area of subfields of one given field of the source record.
The <note> in the above example might be considered as the special case
of a citation / cross reference cum initial wording. In a more general
vein, when it comes to citations in notes (for indicating sources etc.)
it has always stunned me that librarians were all about scientists not doing
their citations properly but in their own data formats never even had
provisions for but the simplest form of citations...
Thus having the means of substructuring contents as needed and when needed
(BTW for me it is the "X" not the "M") is desirable.
> I'm also not entirely sure what this level of granularity buys you or
> any reasonable way you would actually add data like this.
>
> Trying to write applications to logically pull this data would be make
> me want yank my hair out. We're not confined to 99,999 bytes in XML
> -- it makes more sense to model things properly and explicitly and
> consistently (the last being possibly the most important).
Applications come to mind, which would very happily and easily
operate on this kind of data: Extract all (bibliographic or textual)
citations, all personal names, all works mentioned and do something
with them (present, match, verify, ...). These applications would
be much too stupid to understand the full bibliographic record,
but exactly know where to look for to fulfil their specific tasks.
They would benefit from the additional consistency introduced by
the kind of "orthogonal" markup in the examples above.
Of course, this kind of finer granularity will never be universal:
Neither mandatory for everyone to perform on data entry nor is there
any processing expectation for general systems as to gracefully
fall back to "processing as simple textual data field".
As for "model[ing] things explicitly": I personally do not like
the redundancy enforced by traditonal data formats: "Capture the
parallel title in this 3xx field for indexing and if the rules
furthermore mandate a note, then repeat the same information again
in the appropriate note field 5xx" (at least this is the situation
here with MAB).
Greetings
Thomas Berger
>
> -Ross.
>
>> <mods>
>> <originInfo>
>> <dateIssued encoding="marc">1840</dateIssued>
>> </originInfo>
>> <titleInfo>
>> <title>Birmingham and Derby Junction Railway Time Tables.</title>
>> </titleInfo>
>> <name type="corporate">
>> <namePart>BIRMINGHAM AND DERBY JUNCTION RAILWAY COMPANY.</namePart>
>> <role>
>> <roleTerm type="text">creator</roleTerm>
>> </role>
>> </name>
>> <note>In : Midland Counties’ Railway. The Midland Counties’ Railway
>> Companion, etc. 1840. 12º.</note>
>> </mods>
>>
>> What would be nice is to be able to encode it something like this:
>>
>> <mods>
>> <originInfo>
>> <dateIssued encoding="marc">1840</dateIssued>
>> </originInfo>
>> <title><name type="corporate">Birmingham and Derby Junction Railway</name>
>> Time Tables.</title>
>> <name type="corporate">
>> BIRMINGHAM AND DERBY JUNCTION RAILWAY COMPANY.
>> <role type="text">creator</role>
>> </name>
>> <note>In : <name type="corporate">Midland Counties’ Railway</name>. <work
>> relation="In"><title>The <name type="corporate">Midland Counties’
>> Railway</name> Companion</title>, etc. <dateIssued>1840</dateIssued>.
>> <format>12º</format></work>.</note>
>> </mods>
>>
>> Ie, if we have mixed content in the XML we can drop the need for
>> having a <titleInfo> tag as a parent for <title>. Likewise we can
>> get rid of the <namePart> tag inside the <name> tag; and get
>> rid of <roleTerm> inside <role>. (Actually I'd prefer to get rid
>> <role> and replace it with an attribute of <name>.)
>>
>> We would be able to mark-up names, titles and other interesting info
>> inside notes -- in fact, inside any other element.
>>
>> I think what we would end up with is the potential for much richer
>> records, while simplifying the tag structure.
>>
>> Regards,
>>
>> Ashley.
>> --
>> Ashley Sanders a.sanders_at_manchester.ac.uk
>> Copac http://copac.ac.uk A Mimas service funded by JISC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iJwEAQECAAYFAkwiDfQACgkQYhMlmJ6W47O0xwP/Yw0SID53LB6svAdCzC7IUd90
ANwBA5EDoaUK0p0Rki7etfuv2jbf0nQFrRRHFJ50A3fkaFWtLnijUhAE+MkAK3Fz
eWGuqXorBnleTCqn+/qL2zsKmfNCWO66am1M0c1uzSECuF1a0bFRTak+YGjuN7TA
Qjg/Bsk1cLIgl54GvZQ=
=nhNn
-----END PGP SIGNATURE-----
Received on Wed Jun 23 2010 - 09:38:21 EDT