Karen:
Reading Kelley's response reminds me of the discussions that happened in
MARBI many years ago about 'bound with' relationships. As I recall, the
MARBI proposal went down because it was attempting to conflate
'bibliographic relationships' and 'physical relationships' (bound-withs),
and the use cases discussed around that proposal made the problems quite
clear.
I think the same concerns apply here, and your response gives some good
examples of where those distinctions are important.
Diane
On Fri, Jan 25, 2013 at 11:31 AM, Karen Coyle <[log in to unmask]> wrote:
> Thanks, Nancy, for the examples. However, I believe that all of your Works
> are ones that would be separate works in FRBR -- they aren't the same work,
> they are adaptations. And I think Kelley's question had to do with
> instances of the same work. (?)
>
> Here's the way I imagine that multiple descriptions of the same work would
> go: in some single set of descriptions (e.g. one library's catalog), with
> of course a few errors and omissions, all of the data for the same work
> would have the same identifier. Your database may or may not store these as
> a single set of data, but you needn't worry about that -- that's a database
> function. When it is time for a user display, your display software could
> display the identified work only once, if that's what you want. The reality
> will be, however, as it is today, that cataloging descriptions will be done
> in a variety of environments and each of these will assign its identifiers.
> So we will always have the "de-duplication" problem in union catalogs and
> out on the web. There is a solution to that, just as we de-duplicate today,
> but I'm afraid that the "one work identifier for all the world" won't be in
> our future. But the issue is not whether the work is one-to-one with the
> instance, but how it is identified.
>
> Also, I would be interested to know if there are any music specialists
> experimenting, since the "bound with" case is almost the norm in that area.
> I don't think that FRBR covers that, and yet it might solve some of the
> issues with aggregates. I noticed that the Xquery code turns out a
> "hasComponent" for music. http://kcoyle.net/bibframe/**LCsr.html<http://kcoyle.net/bibframe/LCsr.html>.
> It's not quite "bound with" because sometimes these compilations have a
> name of their own. (I'm actually beginning to think of all manifestations
> as aggregates since they aggregate what the creator created plus what the
> publisher has added, which may be as little as cover art but may be front
> matter, indexes, etc. So the creator's work is *in* the publisher's
> package, and it does more than simple "manifest" the work. FRBRoo takes
> this into account, although in a very complex way.)
>
> kc
>
>
>
> On 1/24/13 4:42 PM, Fallgren, Nancy (NIH/NLM) [E] wrote:
>
>> Hi Kelley,
>>
>> I'm a member of the Early Experimenters representing the National Library
>> of Medicine. Your posts have been greatly appreciated as they are
>> thoughtful and constructive -- and have generated discussion among the EE's
>> internally. Perhaps sharing some of that discussion more broadly here will
>> be helpful to everyone.
>>
>> I think it's fair to say that the model as published in the Draft
>> proposal is exactly that, a draft. As a group, the EE's are collaborating
>> to refine that draft, evaluating its merits and deficiencies and exploring
>> changes. Your post is timely in that we're still reviewing and looking for
>> use cases to validate (or not) the statement that "Each BIBFRAME Instance
>> is an instance of one and only one BIBFRAME Work." Use cases like your
>> Dracula films are helpful toward that end.
>>
>> I'd like to offer up my own attempt at modeling the Dracula use case and
>> confess that I did cheat a little and do some research on the 1931 Dracula
>> films on IMdb. It turns out that these are actually two distinct films:
>> the Spanish language film has a different director and cast, but they were
>> both filmed on the same set and at the same time. From IMdb: "This
>> Spanish-language version was filmed on the same sets and at the same time
>> as the English-language, Bela Lugosi version of Dracula. The
>> English-language version was filmed during the day, and the
>> Spanish-language version was filmed at night." For more on the differences
>> see http://www.imdb.com/title/**tt0021815/faq#.2.1.2<http://www.imdb.com/title/tt0021815/faq#.2.1.2>.
>> In addition, the writing credits at IMdb infer that both films were
>> adaptations of the play by Deane and Balderston. So, more than just
>> language distinguishes these two films, which was not initially clear to me
>> from your email.
>>
>> Based on this additional info, I think that packaging the two films
>> together is no different than binding copies of two distinct books
>> together. i.e., these films happen to have a "boundwith" relationship in
>> this packaging, but that may not always be true ("the English and Spanish
>> language version of Dracula from 1931 are often packaged together"). Each
>> book in a boundwith volume is a single item belonging to a distinct
>> instance/manifestation (so they have distinct MARC records) but not every
>> copy of that book is "boundwith" other books. I would treat the two
>> Dracula films the same way I'd treat a print boundwith.
>>
>> As Jackie Shieh pointed out, each of the EE's approached the model from a
>> slightly different perspective. So, using a fuller RDA/FRBR definition of
>> a work than stated in the BIBFRAME draft (i.e., defining a work as "... a
>> distinct intellectual or artistic creation. A work is an abstract entity;
>> there is no single material object one can point to as the work."), I might
>> model your Dracula example like this:
>>
>> (Please forgive the loose and abbreviated labeling of properties - these
>> are not necessarily "official" BIBFRAME property labels, they are just used
>> for expediency)
>>
>> Work0 (w0)
>> Title: Dracula
>> Author: Bram Stoker
>>
>> Work1 (w1):
>> Title: Dracula
>> Author: Hamilton Deane
>> Author: John L. Balderston
>> Relationship: Is an adaptation of w0
>>
>> Work2 (w2):
>> Title: Dracula
>> Director: Tod Browning
>> Relationship: Is an adaptation of w1
>>
>> Instance1 (w2i1):
>> Produced: 1931
>> Producer: Universal Pictures
>> Language: English
>> Format: 16mm film?
>> Relationship: Is an instance of w2
>>
>> Instance2 (w2i2):
>> Original production: 1931
>> Date distributed: 1999
>> Distributor: Universal
>> Format: DVD
>> Language soundtrack: English
>> Language captions: French
>> Relationship: Is a reformatted version of w2i1
>> Relationship: Is an instance of w2
>>
>> Item1 (w2i2#1):
>> Barcode: 12345
>> Relationship: Is packaged with w3i2#1
>>
>> Item2 (w2i2#2):
>> Barcode: 22345
>> [a copy of the same instance but not packaged with the Spanish version of
>> the film]
>>
>> Work3 (w3):
>> Title: Dracula
>> Director: George Melford
>> Relationship: Is an adaptation of w1
>>
>> Instance1 (w3i1):
>> Produced: 1931
>> Producer: Universal Pictures
>> Language: Spanish
>> Format: 16mm film?
>> Relationship: is an instance of w3
>>
>> Instance2 (w3i2):
>> Original production: 1931
>> Date distributed: 1999
>> Distributor: Universal
>> Format: DVD
>> Language soundtrack: Spanish
>> Language captions: French
>> Language captions: English
>> Relationship: Is a reformatted version of w3i1
>> Relationship: Is an instance of w3
>>
>> Item1 (w3i2#1):
>> Barcode: 12345
>> Relationship: is packaged with w2i2#1
>>
>> Modeled this way, each instance is an instance of just one work. I'm not
>> necessarily saying that the statement "Each BIBFRAME Instance is an
>> instance of one and only one BIBFRAME Work" is always valid, just that I
>> don't think this example necessarily demonstrates that the statement is not
>> valid. It would be great to have additional use cases that might prove the
>> statement either way.
>>
>> In regard to your FRBR dilemma, the above Dracula model includes
>> expression data as part of the instance record (on the assumption that, if
>> modeled well, it can be programmatically surfaced as needed) and leaves the
>> work record free of data that would associate it with a single material
>> object. I've also taken liberties with the addition of "items" although
>> the modeling of items and holdings is currently being explored by a
>> subgroup of EE's.
>>
>> I hope you find this response both helpful and thought provoking.
>>
>> -Nancy
>>
>>
>> Nancy J. Fallgren
>> Metadata Specialist Librarian
>> Cataloging Section
>> National Library of Medicine
>> 8600 Rockville Pike
>> Bethesda, MD 20894-3823
>>
>> ------------------------------
>>
>> Date: Wed, 23 Jan 2013 05:28:18 +0000
>> From: Kelley McGrath <[log in to unmask]>
>> Subject: Re: Bibframe, flexibility and FRBR
>>
>> Hi Eric,=0A=
>> =0A=
>> Belated thanks for your reply (and the incongruent image of a
>> Cockney-imbue=
>> d version of Arrietty)=0A=
>> =0A=
>> I am glad to hear Bibframe is intended to be so flexible. However, I
>> wonder=
>> if you could say more about how you plan to reconcile all this
>> flexibility=
>> with the interoperability needed in a communication format? Those two
>> thin=
>> gs often seem to be at odds.=0A=
>> =0A=
>> I also have a follow up question about the statement in the November
>> report=
>> "Each BIBFRAME Instance is an instance of one and only one BIBFRAME
>> Work."=
>> In the FRBR model manifestations can be linked to many expressions so
>> how =
>> do you represent a manifestation (instance) embodying multiple
>> expressions =
>> (works) in Bibframe? In situations like the Dracula DVD described below
>> in =
>> my original post, I don't see a practical way to do what I want to do
>> with =
>> the data without linking the instance/manifestation/**publication to
>> separate=
>> expressions for the two movies. Of course, aggregate works are thorny
>> and =
>> the FRBR working group took years to get to their final report:
>> http://www.=
>> ifla.org/files/assets/**cataloguing/frbrrg/**AggregatesFinalReport.pdf<http://ifla.org/files/assets/cataloguing/frbrrg/AggregatesFinalReport.pdf>.
>> It migh=
>> t in some cases also be useful to have what the FRBR working group is
>> calli=
>> ng an aggregating work, but I don't think it can take the place of
>> describi=
>> ng the separate expressions/works. And yet, this seems more like the
>> option=
>> that Bibframe is supplying. Is this a place where Bibframe consciously
>> div=
>> erged from FRBR and does it mean that FRBR can't be fully implemented in
>> Bi=
>> bframe?=0A=
>> =0A=
>> Kelley=0A=
>> =0A=
>>
>>> For example, the English and Spanish language version of Dracula from
>>> 193=
>>>
>> 1 are often packaged together.=0A=
>>
>>> =0A=
>>> Work 1 Expression 1 Manifestation=
>>>
>> =0A=
>>
>>> Dracula (1931) English soundtrack DVD (1999)=0A=
>>> English French subtitles 1 disc=0A=
>>>
>>> ISBN =
>>>
>> 0783227450=0A=
>>
>>> Work 2 Expression 2 OCLC# 46829789=
>>>
>> =0A=
>>
>>> Dracula (1931) Spanish soundtrack=0A=
>>> Spanish English and French subtitles=0A=
>>> =0A=
>>> Without a separate expression level, it is unclear how to prevent the
>>> wro=
>>>
>> ng connections from being made (work 1 has English subtitles or work 2
>> has =
>> an English soundtrack)=0A=
>>
>>> =0A=
>>> Work 1 Version=0A=
>>> Dracula (1931) DVD (1999)=0A=
>>> English 1 disc=0A=
>>> ISBN 0783227450=0A=
>>> Work 2 OCLC# 46829789=0A=
>>> Dracula (1931) English soundtrack=0A=
>>> Spanish French subtitles=0A=
>>> Spanish soundtrack=0A=
>>> English and French subtitles=0A=
>>>
>> =0A=
>> The fact you're separating these out as 2 separate "things" (wether you
>> cal=
>> l it Work or Expression) is a critical step in supporting such
>> disambiguati=
>> on. MARC / AACR* conflates this and over time, various conventions have
>> bee=
>> n introduced to try and minimize this ambiguity but, as you've pointed in
>> t=
>> he case of moving pictures, audio, etc. this is still a huge issue.=0A=
>> =0A=
>> Separating these Works out as first class resources is a first step.
>> While =
>> the granularity of descriptive practices will be an issue, it should be
>> not=
>> ed that not everything need be described at once. If these Works are
>> packa=
>> ged together (and one wants to describe the package), we might think
>> about =
>> this package as its own Work with its specific characteristics. The key
>> her=
>> e is to allow a model to evolve and allow contextual relationships that
>> rel=
>> ate these Works together be introduced as needed.=0A=
>> =0A=
>> ______________________________**__________=0A=
>> From: Bibliographic Framework Transition Initiative Forum
>> [BIBFRAME@LISTSER=
>> V.LOC.GOV] on behalf of Eric Miller [[log in to unmask]]=0A=
>> Sent: Wednesday, January 09, 2013 12:26 PM=0A=
>> To: [log in to unmask]
>> Subject: Re: [BIBFRAME] Bibframe, flexibility and FRBR=0A=
>> =0A=
>> On Jan 6, 2013, at 8:06 PM, Kelley McGrath <[log in to unmask]>
>> wrote:=0A=
>> =0A=
>>
>>> I would also like to get a sense of the flexibility of Bibframe,
>>> especial=
>>>
>> ly as it relates to FRBR. It makes sense to me that Bibframe is not
>> explici=
>> tly tied to the FBRB model. It needs to be hospitable to many types of
>> data=
>> , all of which will not be modeled on or necessarily compatible with
>> FRBR.=
>> =0A=
>> =0A=
>> Correct.=0A=
>> =0A=
>>
>>> My (and at least some other people's) initial impression of the mapping
>>> o=
>>>
>> f FRBR group 1 entities to Bibframe was that it would be something
>> like=0A=
>>
>>> =0A=
>>> Work =3D work + expression=0A=
>>> Instance =3D manifestation=0A=
>>> =0A=
>>> It appears from the actual examples, that the mapping is more like=0A=
>>> =0A=
>>> Work =3D work=0A=
>>> Instance =3D expression + manifestation=0A=
>>> Holdings (annotation) sort of =3D item=0A=
>>> =0A=
>>> Interestingly, this essentially two-level mapping is very similar to
>>> what=
>>>
>> OLAC did for our prototype interface for moving images (
>> https://blazing-su=
>> nset-24.heroku.com/).=0A=
>> =0A=
>> It's surprisingly more common than one might think.=0A=
>> =0A=
>>
>>> Movie =3D work + primary (usually original) expression=0A=
>>> Version =3D current expression + manifestation=0A=
>>> =0A=
>>> We had a table for libraries and items were modeled as a relationship
>>> bet=
>>>
>> ween libraries and versions (manifestations), which I think is
>> essentially =
>> similar to Bibframe's holdings. The attributes of the items could then be
>> h=
>> ung off the relationship.=0A=
>> =0A=
>> I would be interested in any additional details you might be able to
>> share =
>> on this point.=0A=
>> =0A=
>>
>>> The reasons we took this approach were practical. Most of the
>>> attributes=
>>>
>> of expressions for commercial videos are what I think of as independent
>> va=
>> riables. That is, the fact that this DVD has a French subtitle track has
>> no=
>> necessary connection to the fact that it has a full screen expression
>> or t=
>> o what other language options are available. For every new manifestation,
>> t=
>> he individual values for these types of expression have to be verified
>> anew=
>> and linking up to some sort of existing expression record would save no
>> ti=
>> me over just adding them to the manifestation record. This two-level
>> approa=
>> ch (we presented item location as a version attribute) also worked well
>> for=
>> display to the public.=0A=
>> =0A=
>> How to display BIBFRAME data to patrons / users has yet to be fully
>> explore=
>> d but we've balanced the user centered search + discovery process in from
>> t=
>> he start. As part of the python MARC2bibframe codebase available on
>> github,=
>> for example, we've included a simple end user interface to show one
>> exampl=
>> e of how this might look.=0A=
>> =0A=
>> - https://github.com/lcnetdev/**marc2bibframe/blob/master/**
>> python/html/exhibit=<https://github.com/lcnetdev/marc2bibframe/blob/master/python/html/exhibit=>
>> .html=0A=
>> =0A=
>> We're using this interface this over several 1000+ MARC->BIBFRAME record
>> ex=
>> amples from various collections donated by the Early Experiments to
>> explore=
>> their data. It's been quite a useful exercise and one I hope that will
>> be =
>> made public shortly. FYI, the list of the various Early Experimenters who
>> h=
>> ave contributed their sample collections are listed here=0A=
>> =0A=
>> - http://www.loc.gov/marc/**transition/news/bibframe-**112312.html=0A=<http://www.loc.gov/marc/transition/news/bibframe-112312.html=0A=>
>> =0A=
>>
>>> However, it turned out that there were a couple situations in which this
>>> =
>>>
>> model did not work so well.=0A=
>>
>>> =0A=
>>> One is when there are multiple works on a manifestation and the
>>> expressio=
>>>
>> n values (such as language) related to each work vary. There was no easy
>> wa=
>> y in our model to represent this.=0A=
>>
>>> =0A=
>>>
>> =0A=
>> =0A=
>>
>>> The second case is when the expression isn't really a single independent
>>> =
>>>
>> variable (or couple of closely related ones such as French Dolby surround
>> s=
>> oundtrack), but rather a cluster of attributes that are inherently
>> related =
>> and need to be reused together. For commercial videos, these are usually
>> di=
>> stinct intellectual or artistic versions (rather than things like dubbed
>> so=
>> undtracks that are meant to be substitutions for accessibility). For
>> exampl=
>> e, a director's cut would usually have a duration associated with it and
>> we=
>> might also know of a date or an editor. It might also need its own
>> summary=
>> and would be connected to its own reviews or other annotations.=0A=
>>
>>> =0A=
>>> Work Expression
>>> M=
>>>
>> anifestation=0A=
>>
>>> Blade runner (1982) Final cut (2007) DVD (2007)=
>>>
>> =0A=
>>
>>> 117 min.
>>> =
>>>
>> 2 discs=0A=
>>
>>> Review:
>>> =
>>>
>> ISBN 9781419850028=0A=
>>
>>> http://goo.gl/UgMQe
>>> OCLC#=
>>>
>> 173522015=0A=
>> =0A=
>> Again an alternative interpretation of this is that Blade runner (the
>> theat=
>> rical release) and Blade Runner (the extended / much better directors
>> cut) =
>> are simply 2 different Works each of which share contextual relationships
>> t=
>> o common resources (actors, directors, etc. etc.). In the Work
>> associated =
>> with the theatrical release, I would expect to see that Editor you
>> mentione=
>> d.=0A=
>> =0A=
>> In this case, the separation into different Works is important for
>> several =
>> reasons, but one is simply they have very different Instances associated
>> wi=
>> th them. The theatrical release came out in VHS, Beta, LaserDisc, etc.
>> whil=
>> e the Directors cut was released later in DVD, BluRay, etc. I'm a bit
>> emba=
>> rrassed to say I have just about all of these ;)=0A=
>> =0A=
>>
>>> There are also rare cases where even for information that we would
>>> normal=
>>>
>> ly consider as an isolated, independent variable, there is additional
>> infor=
>> mation that one would want to keep together. For example, many of
>> Miyazaki'=
>> s animated films have been dubbed into English with big name voice casts.
>> I=
>> once came across a Criterion Collection DVD of a Japanese film that
>> offere=
>> d for comparison two different English subtitle tracks translated by two
>> di=
>> fferent scholars.=0A=
>> =0A=
>> Ha! It may be a rare case, but the fact there are 2 *different* dubbed
>> into=
>> English versions of Miyazaki's "The Secret World of Arrietty" has
>> caused =
>> all sorts of problems for my kids. The en-uk dubbed version (with slight
>> co=
>> ckney accent) is included in the Miyazaki collection that played over and
>> o=
>> ver this holiday break. My children found this version to be a very
>> differe=
>> nt experience from the other US based / big name voice cast we have.
>> ;)=0A=
>> =0A=
>> - http://www.amazon.com/2012-**Studio-Ghibli-Collection-**
>> Titles/dp/B0081UEWI2/=<http://www.amazon.com/2012-Studio-Ghibli-Collection-Titles/dp/B0081UEWI2/=>
>> ref=3Dsr_1_3?ie=3DUTF8&qid=**3D1357745050&sr=3D8-3&**
>> keywords=3DMiyazaki=0A=
>> =0A=
>> In this case, I'd assert there are 3 separate Works (the original in
>> japane=
>> se, the one dubbed into en-uk and the one dubbed into en-us which include
>> t=
>> he voices of various famous actors, etc.).=0A=
>> =0A=
>>
>>> Expressions that consist of a cluster of related attributes are
>>> particula=
>>>
>> rly important for musical expressions (performers, conductor, location,
>> dat=
>> e, arrangement) and also some literary works.=0A=
>>
>>> =0A=
>>> It is also unclear to me whether it is possible to realize the full
>>> poten=
>>>
>> tial of RDA without the ability to encode all the FRBR group 1 entities
>> sep=
>> arately.=0A=
>>
>>> =0A=
>>> I can see why the focus on translation from MARC led to the existing
>>> mode=
>>>
>> l. It is clearly the most practical approach for legacy data. Although
>> many=
>> researchers have tried, no one has found an effective way to automate
>> the =
>> identification of expressions in legacy data. It is not always possible
>> eve=
>> n with manual review.=0A=
>> =0A=
>> Agreed. And that is why the translation from MARC is only one of several
>> of=
>> the factors that went into the BIBFRAME design. For BIBFRAME we tried
>> to b=
>> alance the following:=0A=
>> =0A=
>> [[=0A=
>> * Flexibility to accommodate future cataloguing domains, and entirely new
>> u=
>> se scenarios and sources of information=0A=
>> * The Web as an architectural model for expressing and connecting
>> decentral=
>> ized information=0A=
>> * Social and technical adoption outside the Library community=0A=
>> * Social and technical deployment within the Library community=0A=
>> * Previous efforts in expressing bibliographic material as Linked Data=0A=
>> * Application of machine technology for mechanical tasks while amply
>> accomm=
>> odating the subject matter expert (the librarian) as the explicit brain
>> beh=
>> ind the mechanics.=0A=
>> * Previous efforts for modeling bibliographic information in the library,
>> p=
>> ublishing, archival and museum communities=0A=
>> * The robust and beneficial history and aspects of a common method of
>> bibli=
>> ographic information transfer=0A=
>> ]]=0A=
>> - http://www.loc.gov/marc/**transition/pdf/marcld-report-**
>> 11-21-2012.pdf=0A=<http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf=0A=>
>> =0A=
>> The current BIBFRAME list discussion as focused on the translation to
>> MARC =
>> (i believe) simply because sample translation code has been made
>> available.=
>> As cataloging use-cases, end-user scenarios (very important),
>> vocabulary b=
>> rowsers, more tools, more examples, etc. are made available i anticipate
>> a =
>> shift in the dialog.=0A=
>> =0A=
>>
>>> However, it seems to me that Bibframe does need to support the
>>> separatio=
>>>
>> n of all the WEMI entities, as well as the best possible environment for
>> en=
>> tering new data going forward. Perhaps there could be some parallel way
>> to =
>> allow the creation of a Bibframe work record for an expression with an
>> inst=
>> ance record that only describes the manifestation and that is linked as
>> fol=
>> lows:=0A=
>>
>>> =0A=
>>> Bibframe Work (FRBR work) --> Bibframe Work (FRBR expression) -->
>>> Bibfram=
>>>
>> e Instance (FRBR manifestation)=0A=
>> =0A=
>> The above model is certainly accomplishable from a BIBFRAME perspective.
>> Th=
>> e named relationships e.g "-->" however are critical. What we call these
>> Cl=
>> asses is important, but more so are the relationships that contextualize
>> th=
>> em.=0A=
>> =0A=
>> (Thing -- hasExpression --> Thing) conveys some meaning. But if
>> hasExpress=
>> ion is a high level, general relationship that is a surrogate for more
>> usef=
>> ul detail, I'd encourage the use of richer relationships.=0A=
>> =0A=
>> (Thing -- hasTranslation | hasVariant | hasPart | isBasisFor, etc. -->
>> Thin=
>> g) conveys more useful and actionable context. In a Linked Data / Web
>> envir=
>> onment, theses contextual relationships are key.=0A=
>> =0A=
>>
>>> I also wonder how hardcoded the mapping of attributes to Bibframe
>>> classes=
>>>
>> is going to be.=0A=
>> =0A=
>> The initial code bases build their mappings from declarative mapping
>> tables=
>> . Quick changes to these tables change the results. I would like to see
>> thi=
>> s be abstracted away in place of a more configurable, end user interface
>> to=
>> allow more customized, collection-specific mappings to be performed.
>> Unfor=
>> tunately, we're just not there yet.=0A=
>> =0A=
>>
>>> For example, there was a post that suggested that actors would probably
>>> b=
>>>
>> e mapped to instances.=0A=
>> =0A=
>> While different groups are exploring different ways of modeling this, In
>> th=
>> e current BIBFRAME model (and from my perspective) that would be
>> incorrect.=
>> Actors (1xx, 7xx) would be defined as relationships contextualizing
>> Works =
>> and People.=0A=
>> =0A=
>>
>>> For film actors, this is counter to the approach that makes sense to the
>>> =
>>>
>> moving image cataloging community. The majority of film actors should be
>> as=
>> sociated with the work. This also makes sense from the point of view of
>> eff=
>> icient data modeling since we want to reuse the list of actors from the
>> wor=
>> k record in all instances rather than recording them redundantly at the
>> ins=
>> tance level. Will there be any mechanism in Bibframe to accommodate
>> differi=
>> ng viewpoints such as these?=0A=
>> =0A=
>> Yes (but in this particular case I think there is a shared viewpoint).=0A=
>> =0A=
>> Thanks for your insightful email. I hope this response helps.=0A=
>> =0A=
>> --=0A=
>> Eric Miller=0A=
>> President, Zepheira "The Art of Data"=0A=
>> http://zepheira.com/ tel:+1.617.395.0229=0A=
>>
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
