Closed holfordm closed 2 years ago
I've noticed works.xml in medieval-mss contains note
elements of type "shelfmark" in each bibl
. Do those accurately reflect the manuscripts in which each work is found, and do you plan to continue to maintain them? If so, I could only create a link in the HTML for works which contain multiple of those notes (and/or other information, such as editions.)
I've noticed there are about a dozen title
elements containing space-separated keys. For example:
<msItem xml:id="MS_Canon_Bibl_Lat_76-item1" n="1" class="#biblia #liturgica">
<title rend="roman" key="work_14122 work_13443">Psalter and New Testament</title>
Is that intended or a mistake?
Intended - the work entries are respectively for "psalter" and "new testament". If entries like these can be tokenized by whitespace, that would be great, otherwise I can change the data.
They could be tokenized and the individual work IDs recognized. But the XSL wouldn't know how to divide up the title in order to create two links (in this case there is an 'and' but pattern matching for that wouldn't be a very safe or extensible solution.)
Of course - didn't think about the links. I'll fix the data: I have a list of the files in the SOLR log from work indexing.
I've implement title links on QA (the changes are on the processing-overhaul branch so they will disappear if you re-index using the master branch.)
It does mean a lot more things are displayed in blue, which maybe makes it a little more difficult to distinguish authors from work titles in some cases. Most titles are differentiated by being italicized but not if they have a @type
attribute. It would be better if a list of which type values not to italicized could be established. Presumably 'desc' title shouldn't be italic, because it is the cataloguer's description. But what about 'sub' and 'supplied'?
One possible way of distinguishing authors (author
, persName @role=author
) would be to render them in small capitals, this is quite a common convention in more recent medieval catalogues.
So, like this mockup?
If so, I'd need to give a class to the persNames with author roles before @IgnatG could do the CSS.
The italicization of titles was something spotted during the Fihrist event last week, so I'm moving that to medieval-mss's convert2HTML.xsl so I can vary it for each catalogue.
yes indeed, although i suppose for consistency we should include role="translator"
in this class.
reminder to @holfordm to look into @type
of title
Every persName
with a @role
now gets a span
with a corresponding @class
in the HTML on QA. All author
elements get a class of "author". That will include authors in bibl
elements.
So the next step is for @IgnatG to add CSS to make the following classes display in small caps:
.author .translator
//done - I've added small caps for .author and .translator. - it's on develop branch
Now deployed to QA. Here are some examples:
http://medieval-qa.bodleian.ox.ac.uk/catalog/manuscript_9025 http://medieval-qa.bodleian.ox.ac.uk/catalog/manuscript_1083
Can we close this one?
It will be closed by a merge request I'll submit for @holfordm's approval at the start of next week.
A special case is when a person's name is part of a descriptive title, such here:
http://medieval-qa.bodleian.ox.ac.uk/catalog/manuscript_141
Should the entire title be one link, to work_15291 in the above case? But the author name displayed in small-caps?
There are 617 instances of persName
elements inside title
elements in msItem
elements. Of those, 184 have a role of "author".
I suppose that for the sake of consistency across records the author's names should be in small capitals, yes
Detailed Description
As with persons and places at the moment, work titles with
@key
should generate a link to the works index.Link to Page
Context
The advantage of this for cataloguers and users is that it allows information about editions, bibliography etc. to be stored in the central authority file and not duplicated across several records. For that reason, though, it's not worth implementing this until issue #34 has been addressed
Possible Implementation