Re: AW: Non- and Partial-FRBR Metadata

Quoting "Svensson, Lars" <l.svensson@d-nb.de>:


>
> 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?).

I think my situation brings up the dilemma: what is the nature of that  
expression "level"?

It seems to me that we have (at least) two options.
I need to draw this out in some detail, but in general it seems that  
these two sketch out as:

1. separate identification each of WEMI for a given bibliographic  
resource; each will have a URI, and properties will be associated only  
with one of the WEMI URIs (this is the RDA viewpoint)

Work123:
    Title of Work123
    Author of Work123

Expression456:
    Expression of Work123
    Language of Expression456

Manifestation789:
    Manifestation of Expression456
    Title of Manifestation789
    place of publication of Manifestation789
    Publication date of Manifestation789
    etc.

2. identification of a bibliographic resource as a whole; a URI for  
the resource; with interpretation of the "FRBR-ness" of properties by  
applications, probably based on an application profile. This would  
allow some views of the data that vary from the strict FRBR view.(Note  
that in RDA, the properties are all associated with a single FRBR  
entity, so there is no ambiguity between them in terms of FRBR  
association in an RDA environment.)

BibResourceABC:
    Work title of BibResourceABC
    Author of BibResourceABC
    Language of BibResourceABC
    Manifestation title of BibResourceABC
    Place of publication of BibResourceABC
    Publication date of BibResourceABC

Works, Expressions and Manifestations could be identified *somewhere*  
(e.g. Open Library, Freebase), and probably in more than one place.  
If, however, there were no identified entity, this model would still  
be functional. Some entities also have commonly known identifiers (and  
possibly more than one) that could help bring together data for the  
same entity but generated in a different environment. (This is  
actually how RDA defines identifiers for WEMI.

BibResourceABC:
    BibResourceABC represents FreebaseWork123
    BibResourceABC represents OLWorkXYZ
    BibResourceABC represents Expression456 (identified with ISTC ID)
    BibResourceABC represents Manifestation789 (identified with ISBN, LCCN...)
    Work title of BibResourceABC
    Author of BibResourceABC
    Language of BibResourceABC
    Manifestation title of BibResourceABC
    Place of publication of BibResourceABC
    Publication date of BibResourceABC

Identifiers would be very useful for making statements like  
"Expression456 is a translation of FreebaseWork123." But that does not  
mean, to me, that the Work or Expression are "records" in the sense  
that they appear to be in FRBR; that is, that the properties are  
related structurally to that identifier. (And note that in FRBR there  
is no identifier for the whole bibliographic description, something I  
find odd, and which creates difficulties if you cannot derive a full  
FRBR entity set from your data, such as my dilemma of having a  
Manifestation and a Work, but no Expression identified to bring them  
together.)

This #2 is a realistic version of the data that we have today,  
pre-FRBR. Remember, however, that FRBR is a new way to conceptualize  
the bibliographic data that we already create -- it is structurally  
new, but most properties are not new. Today's data is not organized in  
terms of FRBR entities, but most (all?) of the data in our records has  
a place in FRBR.

I realize that this looks like a re-writing of FRBR, but in fact FRBR,  
as Gordon reminds us, is a CONCEPTUAL model not a data model. To  
arrive at a data model we need to think about how we want to use the  
data and what services we wish to provide. I happen to think that in  
many if not most cases, the bibliographic resource will be treated as  
a whole for retrieval (searching), and often will be displayed as a  
whole. I appreciate the efficiencies that the one-to-many  
relationships may make for data creation, but the information  
discovery function may not be best served by that same structure.  
Different applications can use the many bibliographic properties  
differently.

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

Received on Tuesday, 14 September 2010 18:51:33 UTC