Functional Requirements? Really?
What I don't get is why FRBR actually goes by the name "Functional Requirements for Bibliographic Records"? (I don't understand much about functional requirements in software engineering or about requirements engineering. Maybe that's my problem...) Shouldn't it be called something like CMBU ("Conceptual Model of the Bibliographic Universe"). When I hear "functional requirements" in the context of bibliographic data, I think of the functionalities a bibliographic database should offer its users.[2] Unfortunately, FRBR is only indirectly talking about functional requirements in this sense as FRBR is focused on creating a data model. One just has to take a look at the FRBR paper by IFLA, Barbara Tillett's text "What is FRBR?" or the "FRBR" wikipedia entry. All of them describe FRBR as a "conceptual model"or "entity-relationship model".
And that is where I see a problem. I am highly in favour of creating functional requirements for bibliographic data covering different use cases. It really is important to do this if you want to develop a good conceptual model for bibliographic data. But one shouldn't confuse "functional requirements" with "conceptual model" as one data model can serve functional requirements from different users, use cases and contexts and as a data model can be created to only satisfy a small number of functional requirements.
Do we need new terminology to describe functional requirements?
Why develop a new language to talk about bibliographic resources if you can describe functional requirements in everday language that is used to talk about bibliographic resources? Users don't want to "select an expression of a work" nobody will tell you that he needs this function. They want to "find a French translation of Moby Dick", an "annotated version of Shakespeare's Julius Caesar", "get an overview over the œuvre of John Dewey" etc. So why doesn't FRBR use common language to show what these functions are users want? Instead, with FRBR, a data model is designed and a new language to talk about bibliographic resources and this language is then - in a circular move - used to formulate requirements for bibliographic data like
- Find all manifestations embodying the works for which a given person or corporate body is responsible
- Identify an expression of a work
- Obtain a manifestation
Requirements are always attached to use cases
Functional requirements, for what purpose anyway? - For tasks with which the libraries' users see themselves confronted. But there are so many other purposes one can use bibliographic data for, e.g. building public domain calculators or creating bibliographies and reference lists for research or lectures. And you definitely curtail your opportunities to re-use data for other purposes by adopting a model based on functional requirements that are quite narrowly tailored in the light of specific usage. For example, identifying a work in a FRBR sense doesn't help in a legal context where e.g. a translation is a work in its own right.
Am I just ignorant? Does FRBR actually provide what its name says? I would like to be disabused in my opinion. So please, requirement engineers and bibliographs, explain it to me.
[1] I don't believe these points are very novel but I only could follow some FRBR discussions during the last three years. And they might be wrong. I am happy about any feedback.
[2] Actually, I also think the second part of the lable isn't appropriate as well. It doesn't make much sense to speak of Functional Requirements for Bibliographic Records but for bibliographic databases. It is a database as a whole that has to fulfil specific function in the first place and not individual records.
[2] Actually, I also think the second part of the lable isn't appropriate as well. It doesn't make much sense to speak of Functional Requirements for Bibliographic Records but for bibliographic databases. It is a database as a whole that has to fulfil specific function in the first place and not individual records.
3 Kommentare:
Adrian,
Some good points, but you also miss the point now and then I think. FRBR wasn't written by system designers I guess. The term ‘Functional Requirements’ has puzzled me from the beginning too. Having said that, FRBR is defined in relation to ‘generic tasks that are performed by users when searching and making use of national bibliographies and library catalogues’ (find, identify, select, obtain, and also navigate). I think that’s what the ‘functional requirements’ refer too. It’s just mixing up data model and services built on that model.
But at the same time the user tasks have been grossly neglected in the FRBR modelling world. Cataloguers are dealing with creating metadata, not with creating user services. That’s where Public Services and System Librarians/developers come in.
It’s true that customers/users/patrons do not think in Work, Expression, Manifestation, Item concepts. But some of them actually are interested in specific editions, adaptations, and even comparisons between them. Not the ordinary public library customer who is looking for “The Da Vinci Code” in a language that suits her or him best. They might want to know about the movie though, or about Da Vinci, secret societies in general etc.
Anyway, the terminology of the infrastructural FRBR model are not aimed at being used by end users of systems based on the model. Nothing different from system development in all other areas. But the same applies to current cataloguing OPACs that present the user with incomprehensible and useless information based on AACR2/MARC (dimensions, ‘[s.l]’, subject headings that only lead to other publications with tha heading, etc).
In my view FRBR is a valuable model for building traditional library cataloguing systems, but has serious flaws: it’s still focuased on traditional publications/physical entities (even ebooks and ejournals), not on content.
Same goes to some extent for RDA, which uses text instead of actual links for implementing FRBR.
FRBR is necessary for connecting old style cataloguing entities with the new LOD world, but it is not enough to provide people with all information they should have access to in the networked online world.
See my recent presentation for the Dutch RDA seminar (audience of cataloguers!) http://www.slideshare.net/lukask/linking-books-rdafrbrlod
Adrian,
Hopefully by now you will have read our paper on FRBR – placed within a larger theoretical framework – in the December 2011 (ALA) LITA:
http://ejournals.bc.edu/ojs/index.php/ital/article/view/1868
Many problems people have with FRBR have to do with its "logical" data modeling origins. Much of what one encounters takes the FRBR Report and jumps straight into database, etc., design. Or objects to the data modeling technique and jumps into another one (FRBRoo).
We thought there was more work to be done than that. In our paper, we took the IFLA data modeling results (expressed as E-R modeling concepts) and formed them into a "resource description theory" that can coexist with other theories in the Cultural Heritage realm.
Along the way, we made a connection to an observational and theoretical science (Physics) – libraries make observations on the resources in their custody – and followed up on the implications.
Have a look and respond if you would like to my Library of Congress address.
Ron Murray
Thanks for the pointer, Ron. I didn't know of this paper before. I will definitely take a deeper look at it.
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.