W3C home > Mailing lists > Public > public-lld@w3.org > March 2011

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

From: William Waites <ww@styx.org>
Date: Sat, 19 Mar 2011 17:51:19 +0100
To: Dan Brickley <danbri@danbri.org>
Cc: public-lld <public-lld@w3.org>
Message-ID: <20110319165119.GB1320@styx.org>
Dan, very much appreciate your thoughts. I have to say that
in my experience trying to describe books in RDF, and not
being a librarian, this seems the right approach.

We tried using FRBR and basically found it over-engineered.
Trying to make an application where people take books and
annotate them and organise them into reading lists and 
collections, FRBR just introduces too much irrelevant
abstraction and gets in the way. This is why we use bibo,
which has "book in the usual sense" and could be understood
in terms of what you have described with owl classes and
punning (if you imagine an implied :ficciones a owl:Class).

I also agree with Karen that this is much closer conceptually
to MARC then WEMI. Perhaps that is as it should be. To me,
again as a non-librarian, the rules for when something is 
a new work or expression or manifestation seem at best 
arbitrary or at worst simply wrong on a philosophical or
artistic level. MARC might be ambiguous in some ways and
libraries might have a bad habit of shoehorning data into
fields where it doesn't really belong but it does make 
sense intuitively.

So given that we have enormous amounts of data floating 
around in MARC or similar related formats probably the
most directly useful thing that could be done with these
data is to transform them into a simple, relatively flat
RDF format (not unlike bibo) without introducing dubious
abstraction. The data would then be directly reuseable
and could be understood "in the usual sense" (hand wave,
hand wave).

William Waites                <mailto:ww@styx.org>
http://river.styx.org/ww/        <sip:ww@styx.org>
F4B3 39BF E775 CF42 0BAB  3DF0 BE40 A6DF B06F FD45
Received on Saturday, 19 March 2011 16:51:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:19:01 UTC