Re: Content vs. Carrier (was: RE: [open-bibliography] MARC Codes for Forms of Musical Composition)

All
 
Some enlightenment (or fog ;-):
 
The FRBR groups are not intended to be super-classes; that is the view of the
FRBR Review Group, which is responsible for maintaining the FR "family" of
models. Functional Requirements for Authority Data (FRAD) and Functional
Requirements for Subject Authority Data (FRSAD) are the other two family
members. They will not, therefore, be declared as classes in the FRBRer
namespace which is under development (FRBRer refers to the original FRBR
entity-relationship model, to distinguish it from its subsequent extension to
the CIDOC CRM, known as FRBRoo (object-oriented)).
 
(Note: the preferred qname will be frbrer, which will handily distinguish it
from the existing frbr namespace that you are all referencing.)
 
FRBRer is incomplete (this is stated in the documentation), as it does not
address the detail (particularly attributes) of the Group 2 or 3 entities. FRAD
is focussed on Group 2, and FRSAD on Group 3. FRAD and FRSAD (in the final
stages of development) therefore refer to FRBRer, and some of the classes and
relationships declared in the FRBRer namespace will be re-used in the FRAD and
FRSAD namespaces. Separate namespaces are being used because of the significant
gap in publication between FRBRer and FRAD (11 years) and re-definition of some
of the earlier entities. The Review Group has started work on consolidating all
three models, and it is the consolidated model that is likely to be most useful
in the future. The consolidation process is being informed by the namespace
developments.
 
One complication to note about the FRBRer groups is that all the Group 1 and 2
entities can be subjects of a work as well as the entities in Group 3.
 
An impact of not declaring the groups as super-classes is that multiple
properties are required to relate entities. For example, there are 10
has-as-subject properties with domain Work and a range for each of the 10 Group
1, 2 and 3 entities.
 
It has been suggested that the RDA namespace should declare the FRBRer groups as
super-classes, to reduce the need for multiple parallel properties. The FRBR
Review Group view is that RDA is free to do this (AAA), but it will weaken the
link between RDA and the FR family (bits of RDA are also based on FRAD, and
there are placeholders for some stuff associated with FRSAD). Currently, RDA has
provisionally declared the FRBRer entities it needs in its own namespace. In
time, RDA will have to decide if it wants to retain these classes, or re-use the
classes from the FRBRer namespace; that decision will presumably be influenced
by how closely RDA wishes to be associated with the FR family. In particular,
what will the consequences be if frbrer:Work owl:sameAs frbrentitiesrda:Work,
with frbrentitiesrda:Work rdfs:subClassOf frbrentitiesrda:Subject, for an
instance triple myWork frbrer:has-as-subject-work yourWork (domain and range are
frbrer:Work)? (Note that the FR URIs are all opaque, and these examples are
using the labels for readability.) The same remarks apply to the existing frbr
namespace ...
 
As an added complication, IFLA's International Standard Bibliographic
Description (ISBD) consolidated edition is also being represented in RDF. ISBD
has only one class, provisionally labelled "Resource". ISBD is aligned with
FRBRer, although an up-to-date mapping needs to be developed to confirm how
close that alignment is. ISBD is the basis of UNIMARC ... Some of this is
discussed in my paper UNIMARC, RDA and the Semantic Web
(http://www.ifla.org/files/hq/papers/ifla75/135-dunsire-en.pdf).
 
I will be discussing some of these issues in a presentation to next week's
Cologne Conference on Interoperability
(http://linux2.fbi.fh-koeln.de/cisko2010/programme.html), and will post a link
to it in due course.
 
Also, note that most of this will be discussed at the IFLA conference in August,
and I welcome any feedback that informs those discussions.
 
Cheers
 
Gordon
 

On 13 July 2010 at 23:56 Karen Coyle <kcoyle@kcoyle.net> wrote:

> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
>
>
> > That’s a better name, but it’s still far from being useful for the   
> > masses. Even less usefully, RDA appears to ignore the “Group N   
> > Entity” abstractions completely:
> >
> >
> >
> > http://metadataregistry.org/schemaprop/list/schema_id/14.html
>
> I don't think that it is RDA that ignores the "group" level in FRBR -- 
> I believe that it is FRBR that does so. (And Gordon should be able to 
> enlighten us on this since he is the one defining FRBR in RDF for 
> IFLA.)[1] Quite honestly,if it was intended that that 3 FRBR groups be 
> part of the model, I suspect they would have been given better names 
> than "group 1, group 2, and group 3." The metadata registry caught 
> "heck" for adding "Agent" as a generalization of Group 2, even though 
> the purpose was to bring together a number of properties that are 
> repeated for each group 2 entity type. (e.g. cataloger note about the 
> person, cataloger note about the corporate body...).
>
> [1] http://metadataregistry.org/schemaprop/list/schema_id/5.html
>
> >
> >
> >
> > FRBR is a technical model and at the risk of repeating old arguments 
> >  I believe classes and individuals should to be linked to/from other 
> >  models rather than conflating their identities.  To illustrate, I   
> > don’t think that “CatalogingRecord” is a bad class to start creating 
> >  Linked Data from. We don’t need to redesign cataloging databases 
> > and  systems to produce Linked Data. Imagine a lightweight “library” 
> >  ontology to help back up these examples involving 2 legitimate   
> > CatalogingRecords (eng, ger) that describe a “single”   
> > Work/Expression/Manifestation/Book:
>
> I'm unclear here why you are creating records. It seems that you are 
> using the catalog document as your focus rather than the object of the 
> catalog document. Can you explain better your use case for this kind 
> of approach?
>
> Thanks,
> kc
>
>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>