Print

Print


I hear echoes of a W3C LLD discussion:

 

http://lists.w3.org/Archives/Public/public-lld/2011Mar/0142.html

 

Jeff

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Wednesday, February 04, 2015 1:11 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Have your MARC and link it too (was 2-tier BIBFRAME)

 

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:

 

 

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