Re: AW: Non- and Partial-FRBR Metadata

Interesting discussion!

On 14 Sep 2010, at 19:50, Karen Coyle wrote:
> 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.
...
> 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)

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

....

> Identifiers would be very useful for making statements like "Expression456 is a translation of FreebaseWork123."

Yes, and I'd like to be able to make such assertions.

...

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

That's a problem. But can there be an identifier? If so, why chain from Manifestation to Expression to Work?

> 
> 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),

The ability to chunk it is useful -- because "book" (or "bibliographic resource") can be one of several things. So I don't know...

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

I think there's a difference between the *logical* structure and the optimized "engineer's" structure.

-Jodi

Received on Tuesday, 14 September 2010 19:06:38 UTC