Ross,
> Actually, I'll be completely honest here, this looks like a horrible
> idea.
I thought people would hate it :-)
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.
But it's easy to get the title string -- it's a simple XPATH:
/mods/title. It is irrelevant that title contains other tags.
> I'm also not entirely sure what this level of granularity buys you or
> any reasonable way you would actually add data like this.
a) It is more truthfully encoding the information in the record.
b) You don't loose sight of the fact that the title contains
a name -- important information I'd have thought. When displaying
the record you can provide links from the name within the title.
Links that take the viewer onto other resource about that name, etc.
> 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).
I'm not advocating a completely random tag soup. We need structure,
but I think we also need more flexibility within that structure.
Bernard wrote:
> Do you have software to facilitate the input and editing of
structures like this?
No. But I would envisage a workflow like this. The cataloguer is
viewing the title on screen. Sees it contains a name, highlights
the name with the mouse, right clicks and a context sensitive menu
pops up. The system has seen that text before as a name, so
the first choice on the menu is to tag the highlighted text as a
name. Other less likely options would occur further down the popup
menu.
> And could it be handled with XSLT
Yes.
> (BTW, is it XMSL 1 or 2 you are using?)
This goes back to SGML. XML 1 has always had mixed content.
Ashley.
>
> -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
>>
--
Ashley Sanders a.sanders_at_manchester.ac.uk
Copac http://copac.ac.uk A Mimas service funded by JISC
Received on Wed Jun 23 2010 - 09:41:42 EDT