Prism 3 Release – September 2010
We’re pleased to announce that the recent Prism 3 release preview has been released to the live Prism 3 environment. For further details on what has changed, please refer to the release preview blog post.
We’ve released this a little earlier than we normally would to ensure that certain features were out in time for our academic customers entering the start of a new semester.
Keep up with the latest Talis Prism 3 news and developments on the Talis Prism 3 website and blog.
September 14th, 2010 at 4:06 pm
Phil,
Is the Semantic Data Model work finished, or is more being done this month?
I’m asking in connection with the point I raised with you at the User Group meeting last week, about the display of 245 subfield c. I logged a job about this a month ago (68541), and it was immediately closed on the grounds that the issue would be addressed in the next stage of SDM work.
One of our Subject Librarians has just become aware of this problem and strongly agrees that the catalogue of an academic library ought to display the correct bibliographic description of a book. I note the point you made about making Prism 3 look like Amazon, but I have since tried looking up Shakespeare plays in Amazon and find that it treats the editor as a joint author. Surely a university library catalogue should enable the user to distinguish at a glance between different editions of a standard work?
September 15th, 2010 at 10:40 am
Hi Kate,
This release is just the first part of our Semantic Data Model work, we’re still working on other elements, including Author.
Part of the Author work has been properly attributing contributions to people listed in the 100’s and 700’s, and some of this is derived from the 245 $c (editor/illustrator etc.). The problem with 245 $c is twofold:
* Lots of different pieces of information can be present there (such as edition if it comes at the end of a title)
* Since we get a lot the same information from other fields you would end up with huge amounts of duplicated content
The 2nd point is the most difficult one, by repeating content on the page it makes it difficult for users to scan quickly and pushes the availability information further down the page.
We’re getting very good results with parsing nature of contribution out of the 245 $c, so we’re pretty confident that we can go some way to solving the issues that your Subject Librarians have encountered. It’s also worth mentioning that if your cataloguers have made use of the 100/700 subfield $e (relator terms) then we get even better results.
Kind regards,
Phil John
Prism 3 Technical Lead.
September 16th, 2010 at 2:29 pm
Thanks for your reply, Phil.
I’m the only full-time cataloguer here (University of Derby) and I have never used $e or heard/read any suggestion that we should use it!
Kate
September 20th, 2010 at 1:09 pm
Now, this is interesting, because someone raised with me last week why all the “authors” associated with a work were listed under the title with no indication of their relationship to the work, and it struck me that $e might be the answer – but (although it is a standard M21 field) we don’t use it and don’t see it in records we import from TalisBase, except for video records (where we consistently strip it out), so I’m guessing that most bibliographic utilities, and therefore most libraries, in the UK don’t use it. I’d be interested to hear from someone at Talis (Terry?) whether we are recommended to use it from now on, or whether an alternative (Semantic Data Model) solution will be available to us. Using $e may be possible, but unless we all use it, it will involve editing almost all records as we import them. If we are to make most efficient use of TalisBase it helps if we are all marching to the same drum. (Hope this makes sense – sorry, in haste!)
September 20th, 2010 at 1:48 pm
Hi Heather,
I’ll get Terry to answer as well, but from the SDM point of view, the $e would be the best bit of data for us to have; in its absence we have to fall back to parsing the natural language in the 245 $c and, while we’ve seen good results, it’s not 100% perfect.
Kind regards,
Phil John
Prism 3 Technical Lead
September 20th, 2010 at 3:43 pm
The relator term in $e is not used generally because it is not required by AACR2, but it will be required by RDA (assuming it gets implemented), as RDA aims to make much more of data relationships. Explicit information such as this is highly valuable, not least because it is relatively easy to manipulate by machine. So where it already exists, such as in BDS Video records, please don’t remove it.
We realise that it is not practical for libraries to add $e now because it would require too much editing. as Phil has said, we are seeking to make relationship information explicit in the data model as much as possible, so that we can provide more effective discovery and displays. This work includes parsing 245 $c but, given the variety of free text data there, a number of issues remain, and we are still considering how best to resolve them.
Best wishes
Terry
September 21st, 2010 at 8:01 am
This may not be the place to ask, but what effect does $e have in Authority? (I guess we’ll find out soon as we are beta-testing Alto 5.1).
September 22nd, 2010 at 12:46 pm
OK, thanks. Will $e work OK with Authority?
Gosh, it’s a funny old world. Here we be, reverting to what I think of as old printed BNB practice from the late 50’s/early 60’s, and with RDA promising to provide something like the even older BM printed catalogue. What goes around, comes around with a vengeance!
September 22nd, 2010 at 3:40 pm
It appears that, with default settings, $e in bibliographic name heading fields would be included in matching against authority headings, which may be why you’re removing it. I need to do some more checks to get a complete picture before advising further.
Use of $e will only be sustainable if major cataloguing agencies use it. I assumed they would, given that two key principles of RDA are identify and relate. However, in the LC training materials for the RDA tests (Module 3 slide 74), I find this:
‘Whether to include such a relationship designator in subfield $e is cataloger’s judgment. Do not use subfield $4. Also, do not include appendix I relationship designators in access points in authority records.’
Hopefully they will make more policy decisions and reduce ‘cataloguer’s judgement’ before they implement RDA. The point about authority records clarifies that $e should not be included for authorisation.
September 28th, 2010 at 1:55 pm
Another even more important implication of the non-display of 245 $c has come to light. Another colleague complained that it is not possible to distinguish between the three volumes of a Government report. This is because the volume no. and title are placed at the end of Field 245 without any subfield codes. The LC’s own MARC 21 website states –
In records formulated according to ISBD principles, subfield $c contains all data following the first slash (/). Once a subfield $c has been recorded, no further subfield coding of field 245 is possible.
We have re-opened my case mentioned above. Can Terry please advise?
September 30th, 2010 at 4:49 pm
Hi Kate, Yes we are aware that part number and title information sometimes occurs in 245 $c, and that it is critical information. We’re seeking an optimal way of dealing with it in the context of other elements that are being parsed out of that subfield, and with a view to providing good displays, as Phil mentioned above.
An update on the use of $e in headings – it is currently included in matching against authority headings. We’ll add it to the configured list of excluded subfields as part of the release of Talis Alto 5.1, so that it does not get authorised, thus allowing you to keep it.
October 7th, 2010 at 12:59 pm
I shall start using $e in $7xx then, and I’m looking forward to excluded subfields in authorisation!
Esther
October 8th, 2010 at 4:21 pm
And another thing… Having got a few examples of $e into our Prism 3, and seen what they look like, I am a bit anxious about the clarity of what we are presenting to our users. If there is a heading with $e, such as, Kilmer, Val, actor – then if you select “Find more by…” it will match on the whole string and find only occurrences of the name with the same $e.
I can see the logic of that – if what someone wants is only those works where Kilmer is an actor (as opposed to those where he is a director, or whatever).
But I can also see a user thinking, yes, Val-Kilmer-the-actor, that’s who I’m interested in – and I want everything he’s been involved with.
How is Prism going to explain the difference between (in M21 terms) $c and $e?
October 11th, 2010 at 1:03 pm
Hi Heather,
In the Semantic Data Model work we’re not storing the relator code as text, rather using it for linking between entities, so you may have:
Bright Young Things -> directed by -> Stephen Fry
Wilde -> actor -> Stephen Fry
The Liar -> written by -> Stephen Fry
Depending on the context of the link, it could be displayed in different ways (e.g. finding all films a person has acted in vs films they have directed).
Kind regards,
Phil John
Prism 3 Technical Lead.