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

Quoting Dan Brickley <danbri@danbri.org>:

  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.

I would love to see some data that uses the conceptual model of FRBR  
but does not instantiate each entity as a class. I've actually called  
for that on a variety of lists and have had strong push-back. What  
would that look like?

In the lengthy discussion on the ol-tech list and the frbr list  
(neither of which has an archive!), we went round and round trying to  
figure out how to use general (non-FRBR-specific) elements defined in  
RDA [1] as RDF statements without separating the data into WEMI. We  
didn't come up with a way to do it, but perhaps we didn't have all the  
right folks in the discussions. (Ross, bless him, actually invented  
some properties for me out of sympathy for my plight.)

I have come to the conclusion that FRBR, as defined in the document  
and in particular in FRBRer [2] and RDA, will need to be generalized  
in order to allow FRBR to be viewed as conceptual rather than  
structural. I'm sure that there are those who greatly support FRBR as  
3 sets of entities/classes. This leads me to conclude that we need  
both, and that FRBRer needs to be able to be generalized *without*  
losing the ability to make relevant relationships between  
bibliographic "things."* (And, Dan, I really mean "bibliographic"  
things, not physical things. Although some physical things exist, they  
are only of minor interest, although I understand that working with  
concrete entities is superior to abstract ones. Concrete in library  
data \= physical things, however. I actually think the Work could be  
suitably concrete.) FRBRer could be a more detailed, and less  
flexible, view of the bibliographic universe, and FRBR(Open)[3] could  
be what FRBR becomes when it is shared beyond libraries and their  
systems.

kc

* That's a whole long discussion, but eventually some of us need to  
re-live it and document it. There are issues with relationships that  
are FRBR-entity specific, and how those can be generalized.

[1] http://metadataregistry.org/rdabrowse.htm
[2] http://metadataregistry.org/schema/show/id/5.html
[3] which Gordon began at  
http://metadataregistry.org/schema/show/id/27.html but I'm sure it's a  
huge job and may require more modification than just removing the  
class constraints (possibly why he didn't get far?)

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 21 March 2011 16:42:32 UTC