Print

Print


FRBR says that the WEMI analysis can be applied to integral, aggregate, and
component entities, not that WEMI itself is an aggregation.  I'm not sure
the metaphor of "container" works well for the primary relationships
between the WEMI entities (W is realized through E is embodied in M is
exemplified by I).  Maybe a better model for the Norton Critical Edition
(with apologies for any notation errors) would be:

FRBR_Graph_ED = {W_Graph, E_Graph, M_Graph, I_Graph}
FRBR_Graph_ED_M *contains* {FRBRGraph_01_E,  FRBRGraph_02_E,
 FRBRGraph_03_E,  FRBRGraph_04_E …}


The first line defines the aggregate in WEMI terms; the second line states
that the aggregate's Manifestation has a container relationship with other
FRBR Expression graphs.  That would follow the recommendation of the IFLA
Working Group on Aggregates (
http://www.ifla.org/files/assets/cataloguing/frbrrg/AggregatesFinalReport.pdf
):

This is the only many-to-many relationship between the group 1 entities: an
expression can only realize a single work, an item can only exemplify a
single manifestation but a manifestation can embody multiple
expressions. Based on the many-to-many relationship between expressions and
manifestations, an aggregate can be defined as a manifestation embodying
two or more expressions.


Stephen

On Wed, Feb 4, 2015 at 10:04 AM, Murray, Ronald <[log in to unmask]> wrote:

> Sorry:
> .
> When I said “describe," I meant in any conveyable form (ideally pre
> implementation) that does the job. So combining a natural language *plus*
> mathematical notation would be fine – if not obligatory. For example, If we
> allow that FRBR W|E|M|I descriptions each constitute graphs in their own
> right, then a description for a single physical/digital resource looks like
> this:
>
> FRBR_Graph = {W_Graph, E_Graph, M_Graph, I_Graph}
>
> Note that FRBR_Graph serves as a *container* for other graphs. This gives
> us what the 1998 FRBR report called "Aggregate and Component Entities:”
>
> *The structure of the model … permits us to represent aggregate and
> component entities in the same way w would represent entities that are
> viewed as integral units.”*
>
> (FRBR 1998, Section 1-3.3).
>
>
> The notation clarifies the prose very nicely, and opens one’s thinking to
> graph-friendly properties and measurements.
>
> And its also relevant to implementation thinking. If at implementation
> time FRBR_Graph or its subgraphs happen to be composed of familiar TARGET
> RELATIONSHIP VALUE triples, and the target value is that graphs's unique
> ID, then links can be constructed between the FRBR subgraphs, from *other*
> FRBR_Graphs, to this one, and from other data objects to to this FRBR_Graph
> or its subgraphs. This can be shown in the notation of course.
>
> Consider this:
>
> FRBR_Graph_ED = {FRBRGraph_01,  FRBRGraph_02,  FRBRGraph_03,  FRBRGraph_04
> …}
>
> This indicates a FRBR graph whose subgraphs are complete FRBR descriptions
> – each of which expand into a form like the example above. This is the
> general form for a Norton Critical Edition. Except that there also exist
> systems of relationships that bind an edition’s stories, plays, reviews,
> etc. into groups according to editorial discretion. Some of an edition’s
> content are there for context at the edition level, and have no specified
> relationship to included content. The *Backgrounds and Criticism* section
> of the Norton Critical Edition:
>
> http://books.wwnorton.com/books/detail-contents.aspx?ID=11299
>
> Fall into that category. With your minds more attuned to graph/subgraph
> thinking, note the *sub/subgraph *structure of the Norton publication,
> where each of the the eight plays have associated with them their own texts.
>
> Ron Murray
>
>
> From: <Young>, "Jeff (OR)" <[log in to unmask]>
> Reply-To: Bibliographic Forum <[log in to unmask]>
> Date: Tuesday, February 3, 2015 at 11:12 PM
> To: Bibliographic Forum <[log in to unmask]>
> Subject: Re: [BIBFRAME] Have your MARC and link it too (was 2-tier
> BIBFRAME)
>
> BTW, I didn't necessarily mean to imply that Ron's examples CAN'T be
> described in natural language. They certainly can be and they can even can
> be (partially) described *formally*. They can't be *completely* described
> by any single POV, though, formal or otherwise, and it's in our best
> interests to accommodate that fact.
>
> Ron can correct me if I'm wrong. :-)
>
> Jeff
>
> On Feb 3, 2015, at 9:54 PM, Young,Jeff (OR) <[log in to unmask]> wrote:
>
> I understood Ron to be saying that we can’t possibly formalize the rules
> if nobody can even describe his examples in natural language.
>
>
>
> Jeff
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Karen Coyle
> *Sent:* Tuesday, February 03, 2015 9:15 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Have your MARC and link it too (was 2-tier
> BIBFRAME)
>
>
>
>
>
> On 2/3/15 12:31 PM, Murray, Ronald wrote:
>
> Thomas Kuhn used the term *exemplars* to mean problem-solution sets whose
> understanding and solution demonstrated mastery of a given scientific area.
> Note that this does *not* refer to the software engineering concept of a
> *use-case*. So: given any of the contending resource description
> technologies, describe these exemplars:
>
>
> There are at least two aspects to this: 1) what cataloging rules to use
> and 2) what data format to use. I don't know how different the results
> would be from using different cataloging rules, but if we don't know which
> rules are used then we don't know if we're comparing apples or oranges.
> Something has to be held constant for a comparison to make sense.
>
> kc
>
> --
>
> Karen Coyle
>
> [log in to unmask] http://kcoyle.net
>
> m: +1-510-435-8234
>
> skype: kcoylenet/+1-510-984-3600
>
>


-- 
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID:  0000-0002-3590-1242