oops, typo - that's: "if it works best for catalogers..." not "catalogs".
On 11/28/12 7:22 AM, Karen Coyle wrote:
> If we're going with a one-to-one model between Work and Instance, why
> not a "one" model? Admittedly I am a "unitarian" when in comes to FRBR
> group1 and have long argued for a "whole" rather than a set of parts.
> Remember, bibframe is the data structure, not the cataloging concepts
> and FRBR is a conceptual model. If it works best for catalogs to think
> in terms of WEMI I'm all for it. But that doesn't mean that the data
> structure has to be divided into four parts -- the purpose of the data
> structure is to store the data in a way that you can do a whole
> variety of interesting things with it.
> Even more than unitarian, I espouse the heresy that not all
> communities and applications will define WEMI in the same way (two
> parts, six parts, a gradation?), so pre-defining it in the library
> data could be a barrier to interoperability. Call a "work title" a
> "work title" and let others decide how that fits into their
> bibliographic view. Also, limiting relationships to a particular group
> 1 entity is, IMO, a great danger to our ability to interact with
> non-library data. In other words, we can define our data elements to
> mean what we want them to mean, but we shouldn't try to control how
> others will use them or what they can link them to.
> On 11/27/12 11:51 AM, Eric Miller wrote:
>> Hi Diane, Philippe,
>> In this draft model, the aggregation would be done at the (BIBFRAME)
>> Work level. A set of collected stories, for example, would in fact be
>> a Collection (Work) of other Works. Works are typed and a Collection
>> is just one kind of Work. What connects these Works together are a
>> set of defined relationships that create a Web of Works. The
>> paperback (or hardback, or …) version of this collected Work would be
>> instances of this Collection (but there may be other instances
>> associated with the individual Works as well).
>> Whats missing from this primer are more detailed use cases and
>> example applications which help demonstrate more concretely this
>> approach. I'm hopeful these will be made available soon. Nothing
>> helps ground any model (and serialization, vocabulary, constraint
>> layer, HTTP services, etc.) like practical examples.
>> Diane, as you know no good idea goes unpunished ;), if there are
>> specific examples that you would be willing to suggest that would be
>> extremely helpful. I can't claim a quick turn around, but I'd be
>> happy to give a go at representing these via BIBFRAME.
>> On Nov 26, 2012, at 10:34 AM, Diane Hillmann
>> <[log in to unmask]> wrote:
>>> I had the same response, immediately thinking of things like
>>> collected stories (single or multiple authors) and serial issues.
>>> These are certainly fairly common in bibliographic metadata, and
>>> were not well handled in MARC or MODS. The FRBR model, though
>>> admittedly a complex beast, accommodated these materials, and gave
>>> some hope that there could be ways of handling those kinds of
>>> materials in ways that a machine could understand, rather than (as
>>> usual) depending on the human user to figure it out.
>>> Diane Hillmann
>>> Sent from my iPad
>>> On Nov 26, 2012, at 9:13 AM, "LE PAPE, Philippe" <[log in to unmask]>
>>>> Dear Everybody,
>>>> Colleagues have already expressed their concern about the vanishing
>>>> of FRBR Expression entity in Zepheira's "BIBFRAME" model, but I was
>>>> rather puzzled by this:
>>>> "Each BIBFRAME Instance is an instance of one and,only one BIBFRAME
>>>> Work." P. 10.
>>>> What about (FRBR) Manifestations embodying more than one (FRBR)
>>>> Work then? Will there be something like compound (BIBFRAME)
>>>> instances? Or will the aggregation be done at the (BIBFRAME) Work
>>>> Philippe Le Pape
>>>> Mission Normalisation
>>>> 227 avenue Professeur-Jean-Louis-Viala
>>>> 34193 MONTPELLIER CEDEX 5
>>>> Tél. 33 (0)4 67 54 84 67
>>>> Fax 33 (0)4 67 54 84 14
[log in to unmask] http://kcoyle.net