Alex

The FRBRer model at http://metadataregistry.org/schema/show/id/5.html will eventually be the official IFLA version. It is not safe to use it at the moment, as all elements are unapproved and subject to change. There are a number of issues requiring resolution by the FRBR Review Group, and they are currently under discussion.

The work on FRBRer and the RDA elements indicated that it would be useful to identify similar issues in developing an RDF version of FRAD, and also start to uncover issues that arise when FRAD and FRBRer are cross-related in RDF, which they have to be because FRAD makes direct references to FRBRer elements. The FRAD model at http://metadataregistry.org/schema/show/id/24.html is only half-completed - I've done the <easy> bits, but there are some interesting semantic modelling issues to tackle now.

The FRBR Review Group is charged with consolidating the three-and-a-half FR models (FRBRer/oo, FRAD, and FRSAD when it is published), but has no plans to replace the individual models. We are developing the RDF versions one-by-one, and trying to be as strict as possible (that is, ignoring external requirements and dependencies, including RDA). That is, even though we have the benefit of hindsight, we want to treat FRBRer and FRAD on their own merits. We think this will improve our understanding of the processes of developing RDF ontologies from entity-relationship models, and expose semantic amibiguities (in an RDF sense) which will help with the consolidation work in the future.

The RDA work is, nonetheless, informing the FR work, but I also expect the FR work to inform the RDA work. The <FRBR entities for RDA> registration is, of course, still provisional and unapproved. Depending on various factors, including the availability of approved FR classes, RDA might have a choice of not using the <FRBR entities for RDA> elements at all, and just use the FRBRer and FRAD URIs instead, OR declare equivalences with sameAs, (OR determine sub-class relationships - there may be differences in semantics which only become apparent with the FR work), etc. I guess the main factors are semantics/definitions and the timing/sequencing of approved versions of the various ontologies. The D-Lib article assumes that the RDA URIs will be approved and published first, in which case equivalence properties will have to be declared (or not, if there are semantic ambiguities or inconsistencies) with the subsequent FRBRer and FRAD URIs.

I think all of this has wider implications. IFLA and <RDA> are separate organisations with a mutual interest in each other's <standards> (models, vocabularies, etc.). A common goal is bibliographic control. But the methods of human discourse (cross-membership, liaison arrangements, seminars, etc.) which work well for mutual benefit are not necessarily sufficient for ensuring machine discourse (if I can put it that way). For example, version control presumably needs to be much tighter in the semantic web - only the final, approved version can be made available to the machine, whereas humans can exchange draft versions and still make safe decisions. And I guess there must be intrinsic tensions between <control> and <anyone can say anything ...> approaches to RDF. This is new territory for most of us, as much in organisational (administration, policy) terms as technical. So I don't think there will be immediate answers to your questions ;-)

Family is a FRAD class. The FRBR Review Group discussed whether to declare it in the FRBRer namespace, but decided not too for the reasons given above. So RDA would have to link to FRAD with a sameAs relationship, or just use the FRAD URI, etc. as discussed above.

I think we would have to decide whether apparent duplicate relationships actually have the same semantic; that is, really are duplicates. It is possible that some RDA properties are actually sub-properties of FRBRer and FRAD ones (this is pure speculation on my part - I haven't looked at this at all). It is more certain that there are properties duplicated between RDA and FRBRer/FRAD, in which case they can be linked using equivalence relationships, or substituted (again, as discussed above).

You are right that the additional entities in FRBRer can be represented using the basic classes and properties, and the element Sound Recording Manifestation inferred from one of the relevant properties. I chose to start with an explicit and strict approach to interpreting the FRBR source document (i.e. <entities> and <entity sub-types) are usually classes and sub-classes, <relationships> and <attributes> are usually properties), and have applied domains and ranges as much as possible. <Sound recording> is defined as a sub-type of Manifestation, so I have <naively> represented it as a sub-class of Manifestation. This is a deliberately heavy, over-engineered and restrictive approach (or is it just more controlled?;-) and is subject to radical surgery by the FRBR Review Group, if it so chooses. The source document does not, for example, offer any further definition of Sound Recording, which suggests that it is inferred to be <a Manifestation with at least one attribute associated with sound recordings>. That association of an attribute with a sub-type would, of course, have to be asserted to allow this inference to be made.

The RDA approach uses super-properties such as soundCharacteristic and soundCharacteristicManifestation to represent these associations, which reflects the way that RDA groups its rules above the single attribute/rule level. But I'm not sure that the RDA <model> can, or is intended to, be applied to the situation where a manifestation is known to be a sound recording but no specific sound recording attributes are known (that is, the item is not <in hand>, but historical metadata indicates the general manifestation type); I'm slightly unsure that the FRBRer model is intended to cover this, and will ask the Review Group for guidance.

Perhaps this is exposing some interesting differences in the application contexts of FRBR and RDA :-(or perhaps I've just misintepreted some things) - you've raised the need for more discussion. And any advice on better ways of representing FRBRer is most welcome.

Cheers

Gordon

Gordon Dunsire
Head
Centre for Digital Library Research
University of Strathclyde

The University of Strathclyde is a charitable body, registered in Scotland, with registration number SC015263
________________________________________
From: List for discussion on Resource Description and Access (RDA) [[log in to unmask]] On Behalf Of Haffner, Alexander [[log in to unmask]]
Sent: 23 February 2010 10:56
To: [log in to unmask]
Subject: [DC-RDA] FRBRer & FRAD in Registry

Hello

I've spotted the element sets for FRBRer and FRAD registered by Gordon:
FRBRer: http://metadataregistry.org/schema/show/id/5.html
FRAD: http://metadataregistry.org/schema/show/id/24.html

In your paper "RDA Vocabularies: Process, Outcome, Use" you said:
Once the RDF version of FRBR is officially available from IFLA,
relationships between the same classes in the RDA-defined version of
FRBR and IFLA version of FRBR will be made to indicate that these are
actually the same entities.

I suppose this FRBRer registration represents the official IFLA
ontology, doesn't it? Accordingly, I'd like to make sure about some
details to understand things right...
-       So does this mean you link the already registered "FRBR entities
for RDA" to the corresponding FRBRer entities (i.e. by
sameAs-relationships)?
-       How do you deal with the entity "family"? Do you link to FRAD?
-       How do you handle all the duplicated RDA relationships specified
in FRBRer? Will those be linked too or replaced?
-       Furthermore, I am not sure if I got the idea behind specifying
additional types of entities beyond the classical ones (i.e. Sound
Recording Manifestation). I think all the additional entities in FRBRer
can be represented by the classical ones applying the corresponding
attributes. However, do these new entities influence the specified RDA
element sets?

Thanks in advance for your reply!
Best, alex