Re: Non- and Partial-FRBR Metadata

On 9/27/10 8:35 PM, Ross Singer wrote:
> I *think* you're either saying:
> 1) You cannot create a WEMI like graph structure because the source
> data you would be modeling from contains elements from various parts
> of the W-E-M chain and therefore your resource isn't any specific one
> of those (that is, you have multiple, discrete resources in your
> 'record')
>   - or -
> 2) You cannot create a WEMI like graph because the source data you
> would be modeling from contains elements from various parts of the
> W-E-M chain and it's unpredictable and unparsable from the source data
> to ascertain what goes where.

I'm having trouble with what you mean by 'discrete resources' in #1, but 
#2 is a pretty good description of the case. The bottom line is that I 
probably cannot accurately create either an Expression or a 
Manifestation entity, as defined by FRBR, and I'm not sure what I would 
gain by forcing my data (and my identifiers) into that model. I can 
export an explicit Work entity, because OL has one and it's fairly 
accurate in its FRBR-ness, but there are Work properties that remain in 
the bibliographic "record" that is OL's "edition" entity. In other 
words, I am not working from fully FRBR-ized data.

What I want is 1) to be able to say: This is bibliographic data, and 2) 
to link that bibliographic data to a Work entity even though it is *not* 
either an Expression nor a Manifestation. Ideally I would also like to 
make use of other relationships: like translationOf, versionOf. But 
those would be relationships between instances of karensBibData, not 
between karensBibData and the Work, in most cases. This would allow us 
to do things like link MARC records to wikipedia entries for a Work, as 
an example, and perhaps to even create interesting relationships between 
standard citations and library data without having to fully FRBR-ize 
everything. (This is sounding better and better to me.)
> This sort of model will probably have to be pretty prevalent for
> legacy data.  It certainly calls into question, though, what an LCCN
> or oclcnumber is identifying.  I had, until this thread, basically
> considered it an identifier for a manifestation, but now I'm starting
> to think what it identifies might actually be the record (this
> ambiguous WEM jumble that you've pointed out) and just the record.  I
> mean, that is what it identifies in MARC; I just feel this sort of
> thing is still sort of up for grabs in RDF since the intention (I
> think!) is not to carry the literal notion of the record over into
> linked data (that is, it's not MARC-RDF), but, instead, its meaning.

yes, LCCN and OCLC number are identifiers for the record, or at least 
I've always considered them so. They are good clues to finding other 
instances of the same published "thing" but they represent the library 
record. The ISBN represents a publisher's product, and that product 
contains the whole WEM (but not Item, since ISBNs are not 
item-specific). Anything that is published is by definition a 
Manifestation of an Expression of a Work. It is unfortunate that in RDA, 
the publisher identifiers are defined as "identifier for the 
manifestation" -- which I think will be confusing.  (cf. Chapter 2 of 
RDA) This is where I just have a brain meltdown around FRBR, because in 
essence you cannot speak about, much less hold in your hand, any of the 
Group 1 entities by itself except at a very abstract level. Even the 
item, although it is concrete, cannot be separated from its co-entities. 
So to say "identifier for the Manifestation" is nonsensical unless you 
are referring to a URI that is associated with only the properties that 
FRBR defines as having the range frbr:Manifestation. In real life, it's 
only the whole bibliographic description that makes any sense.


> Definitely something we'd need to figure out given the scarcity of
> common identifiers and how important they'll be in linking data
> together.
> -Ross.

Karen Coyle
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Tuesday, 28 September 2010 20:02:52 UTC