Re: FRBR and classes ('frbr:Works in the age of mechanical reproduction'...)

(thanks everyone for their replies, and sorry again for the length of
my original post; I'm in catchup mode between trips so no danger of
lengthy reply here at least)

On 21 March 2011 15:19, Tillett, Barbara <btil@loc.gov> wrote:
> Thinking of FRBR as "over-engineered" perhaps mistakenly focuses on casual readers and on inventory management issues.
>
> If our *Cultural Heritage* mission (as opposed to a marketing, entertainment, or advertisement mission) is to "collect the dots and then connect the dots" through our resource descriptions, we require the ability to create resource descriptions that serve the needs of  -> and incorporate the more sophisticated resource descriptions created by <- scholarly and educational users.
>
> We should keep the above point focus, and recall that our main job is user needs and not making IT people's jobs easier. IT is supposed to respond to requirements and *not* assume that their limits and system predilections are ours. RDF is primarily an IT-level invention that *assumes* things about high-level resource description. We are demonstrating that some of their assumptions are insufficient to what we can demonstrate to be the case.
>
> Ron Murray (via Barbara Tillett)

Perhaps I can suggest a halfway position. I personally don't consider
FRBR over-engineered, but I have found the direct 1:1 mapping of
FRBR's usecase-driven concepts into classes of pseudo-thing difficult
to work with. My suggestion was that an emphasis on the tangible,
countable, measurable end of the FRBR spectrum might make things
easier for users as well as for the engineers that serve them. By
looking at the ways in which these mass-produced artifacts might be
described "in bulk", I don't mean to belittle the importance of
describing the higher level - and typically Work-level - cultural
threads that tie things together. Rather I'm saying "FRBR: the clue is
in the name" -- let's not lose touch with the "Functional
Requirements" nature of FRBR. My fear is that RDF folk have looked at
FRBR, seen four capitalised noun-phrase concepts and run straight into
the natural conclusion that we should treat each as an RDF class that
can be instantiated, and that therefore the appropriate way to *meet*
FRBR's functional requirements is to exchange data using RDF classes
called 'Work', 'Manifestation' etc. In other words we jump too quickly
from FRBR as requirements, to FRBR as modeling solution.

 FRBR helps us understand if we've done a good job meeting user needs,
looking beyond entertainment to the greater needs of society,
government, learning, science. It gives us terminology for talking
about increasingly broad collections of items that share deeper
commonality than their outer mass-produced packaging. But to my mind
it shouldn't dictate the way we set out to meet those needs, and in
many cases I think we can agree there is a need to talk about higher
level groupings without having to buy into the assumption that the
FRBR entities are the last word in higher level grouping.

It should be possible to emphasise the value of information model that
is grounded in tangible items, without being mistaken for an advocate
of the view that it is useless to express more abstract
generalisations about collections of items and their common
characteristics. If I've been unclear on that, my apologies.

cheers,

Dan

Received on Monday, 21 March 2011 15:38:51 UTC