- From: Svensson, Lars <l.svensson@d-nb.de>
- Date: Tue, 14 Sep 2010 10:55:12 +0200
- To: "public-lld" <public-lld@w3.org>
Karen: > > Jon Phipps: > > > On Mon, Sep 13, 2010 at 9:28 PM, Jon Phipps <jonp@jesandco.org> > wrote: > >> Karen, > >> > >> This might be a bit radical, but what would happen to your model if, > >> rather than thinking of the FRBR entities as 'entities', you thought > of > >> them as simply classifications/groupings of the properties > describing a > >> single bibliographic resource -- an item > > > > Quoting Dan Brickley <danbri@danbri.org> > > > I've been tempted by this kind of design too. > > > I tend to see FRBR as a source of functional requirements, rather > than > > of a direct OO class model to use in RDF. Yes, and particulary in RDF (open world) we don't _have_ to have manifestation-to-expression relation. > Me, three, I have thought about it this way, but I can't figure out > how to make it work on a real bibliographic system. > Essentially, this > is what we have today with MARC21 records (and ISBD records, I > believe). All of the data describing either an item or a manifestation > is created as a single set. Then say that you want to present a view > to your users that shows them works, and all of the expressions of > those works. I agree in general, too. Would a possible solution for the expression level be to create an ad hoc-expression for each manifestation, just in order to have one? That way you cannot build a good user interface _at once_ but eventually you could (intellectually) merge the "records" describing the same expression. That would definitely be a human task (crowdsourcing?). All the best, Lars
Received on Tuesday, 14 September 2010 08:55:47 UTC