About (FRBR) Data Modeling: Conceptual Data Modeling In Cultural - - PowerPoint PPT Presentation

Conceptual Data Modeling In Cultural Heritage Institutions

Ronald J. Murray Library of Congress Washington DC USA

Workshop on FRBR in the European Library Lisboa, Portugal October 9, 2008

About (FRBR) Data Modeling:

Data Modeling in General

• Definitions
• About data modeling
• Data models as “Paper Tools”
• Data modeling examples
• What to do now

Data Modeling in General

• Definitions

– Conceptual Data Model: A description of a portion of an enterprise in terms of the fundamental things of interest to it. They are fundamental in that most things seen by business owners are examples of these. – Logical Data Model: The organization of data for use with a particular data management technology. For relational databases, these are tables and columns; for object-oriented databases, object classes and attributes.

• The MARC bibliographic standard specifies a logical data model that uses tags

and delimiters to structure bibliographic data. In practice, the bibliographic conceptual data model is tangled up in the logical data model

– Physical Data Model: The organization of data used to place it on specific storage media. This level refers to “tablespaces” and “cylinders.” – General Definition: The specification of a final conceptual data model and an initial logical data model that together meet business requirements, prior to any performance tuning.

About Data Modeling

• Why a Data Model is Important
• What Makes a Good Data Model?
• What Makes a Good Data Modeler?
• What is the Description/Design

Question?

About Data Modeling

• Why a Data Model is Important

– Leverage: Small changes in the data model have major effects on the system design and final implementation – Conciseness: The relatively compact data model takes less time to review that the functional specification, and in-depth understanding easier to achieve – Data Quality: Data quality problems are often traceable to inconsistent data definition, interpretation, and enforcement mechanisms

About Data Modeling

• Why a Data Model is Important

– It serves as a necessary complement to a function and process model

• The database system design and implementation process described

here can involve three types of modeling

• A data model describes the information an enterprise must have on

hand to execute its functions

• A function model describes what an enterprise must do
• A process model describes how an enterprise must do it.

– Function and process models are regularly combined during the database system design process

– It can function as a “Paper Tool” in service of theoretical and practical ends

About Data Modeling

• What Makes a Good Data Model?

– Completeness – Nonredundancy – Enforcement of Business Rules – Data Reusability – Stability & Flexibility – Elegance – Communication – Integration

About Data Modeling

• What is the Description/Design Question?

– Is data modeling best characterized as a descriptive activity, the

• bjective of which is to document some aspect of the real

world? – Is data modeling best characterized as a design activity, the

• bjective of which is to create data structures to meet a set of

requirements? – Does the history of the development and implementation of the FRBR model reflect aspects of this controversy?

Portions quoted from Simsion, Graeme (2007). Data Modeling: Theory and Practice. p.3.

About Data Modeling

• How is the Description/Design Issue Manifest?

– Explicit arguments among practitioners and academics, as to whether the description or design paradigm was correct. – Clashes between practitioners who subscribed to the descriptive paradigm, but had produced different models that were difficult to reconcile. – Disagreement over the appropriateness of data modelers introducing new concepts and terminology rather than simply documenting an established view of business entities.

Quoted from Simsion, Graeme (2007). Data Modeling: Theory and Practice. p.10.

About Data Modeling

• How is the Description/Design Issue Manifest (cont.)?

– Difficulty in teaching data modeling using texts and teaching materials which treated it as a descriptive process. – Experienced data modeling practitioners struggling to develop models, and observing that data modeling in practice was much more difficult than it should be if it was essentially concerned with describing data requirements. – Antipathy towards data modelers, who were frequently seen as pursuing an ideal description of reality rather than contributing in the most productive way to an information system design.

Quoted from Simsion, Graeme (2007). Data Modeling: Theory and Practice. p.10.

About Data Modeling

• Description/Design Issue Findings

– The description/design issue is considered an important one by data modeling practitioners

• Evenly divided on opinion

– Data modeling extends into the implementation-

• riented Logical Data Model stage

– Database design methods used in practice support the design paradigm – Data modeling product variation supports a design paradigm with many possible models, plus there are effects of training and personal modeling stylees

From Simsion, Graeme (2007). Data Modeling: Theory and Practice. p.326-3xxx.

About Data Modeling

• Description/Design Issue Implications for FRBR

– Expect FRBR data modeling efforts to encounter similar issues – In compensation, develop an approach that allows theory to guide (but not dictate) FRBR design efforts

• Design data structures that meet requirements
• Test data models - as Paper Tools - in theory-driven

scenarios, and allow each to mutually inform and creatively correct one another – Employ multiple sources for theory – Employ data modeling conventions and patterns

From Simsion, Graeme (2007). Data Modeling: Theory and Practice. p.326-3xxx.

FRBR Data Modeling Using Paper Tools

• What are paper tools?
• Who uses them?
• Why should we use a paper tool for reasoning about

bibliographic relationships?

• How do we use them?

• Paper Tool† - A collection of symbolic elements (diagrams,

characters, etc.), whose construction and manipulation follow rules and constraints of one or more guiding theories

– Paper tool manipulation permits rapid, flexible, and creative exploration of phenomena of interest – Paper tool/user dialogs can generate unprecedented manipulations, and change the interests and goals of a modeling effort – One can reason theoretically as well as practically with a paper tool

• Examples abound in the Sciences
• Can use for FRBR theory formation and testing
• Clears the way for specification of data structures that meet user

requirements

† Klein, Ursula (2001) ‘Paper Tools in Experimental Cultures’, Studies in History and Philosophy of Science 32: 265–302.

The Data Model As Paper Tool

A Paper Tool For Modeling Physics

Feynman Diagrams & Diagramming Rules†

† http://www2.slac.stanford.edu/vvc/theory/feynman.html. Kaiser, David. Drawing Theories Apart: The Dispersion

• f Feynman Diagrams in Postwar Physics. Chicago, IL: University of Chicago Press. 2005.

Data Modeling With Paper Tools

• Why use a paper tool for reasoning about bibliographic (or

any other) relationships?

– Efficient presentation of entities, attributes, relationships, and business rules – Can validate obvious and non-obvious aspects of the data model by creating and validating simple and complex model diagrams

• Diagram construction can be heavily constrained by (FRBR)

theory

• Example – Modeling a collection of resources and resource

descriptions

– Simple to complex resource structuring – Addition of resource relationships – “Factoring out” hierarchical structures from a more complex whole

Expression Manifestation Item Work

FRBR Paper Tool Example

Expression Manifestation Item Work

FRBR Paper Tool Example

The basic diagram element represents a resource and the

• verall description of that

resource

Expression Manifestation Item Work

FRBR Paper Tool Example

A black-filled circle means that a resource and a resource description are both present. A clear circle means that no resource is present

Expression Manifestation Item Work

FRBR Paper Tool Example

The color squares designate different descriptions of the

• resource. In this case, they reflect

FRBR rules for resource description.

Expression Manifestation Item Work

FRBR Paper Tool Example

Connections between descriptions are made according to the rules for the point of view being represented.

Expression Manifestation Item Work

FRBR Paper Tool Example

Squares placed next to one another are linked together by the appropriate relationship. No lines are visible.

Expression Manifestation Item Work

FRBR Paper Tool Example

If a color square is solid, that means that a full resource description is present.

Expression Manifestation Item Work

FRBR Paper Tool Example

If a color square is hollow, that means that this description points to

• ne or more descriptions of the

same type. It acts as a container.

Expression Manifestation Item Work

FRBR Paper Tool Example

Has Part Has Part

A container description must be linked to

• ne or more descriptions of the same Type.

(This is a Business Rule at work.) In this example, an Item (acting as a container) is composed of two other Items.

Expression Manifestation Item Work

FRBR Paper Tool Example

Has Part Has Part

In Item can act as a container because it is a type of Resource. Recall that in this data model, a Resource is defined so as to allow it to be composed of other Resources. Resource subtypes like Item may inherit this ability, depending on business rules.

Expression Manifestation Item Work

FRBR Paper Tool Example

A Mildly Complex Example A serial publication consists of a number of articles (one is two-part) gathered into issues under a single journal title. Some author, publisher, and other role-based information is

• known. Only two subject headings have been assigned so far.

In addition to routine issue publication, a number of articles have been selected by the editors for a special issue on Cosmology, as well as for an ongoing “Best Of” collection of articles.

Work

FRBR Paper Tool Example

A Mildly Complex Example The diagram of the serial publication will be presented in segments that relate the content and structure of such publications.

Found on your bookshelf or your hard drive

Some Resources are not described as completely as others

Same as before, but with a serial number/ID and your own name for the Resource of interest

What publishers can do: group their publications by date

What publishers can do: group &

• rder

publications by editorial choice What publishers can do: group their publications by date

What libraries can do: group related but editorially distinct publications by publisher

What libraries can do: supply a subject term for an article

What libraries can do: supply a controlled name for a person, corporation, etc. mentioned in or having to do with an article What libraries can do: supply a subject term for an article

The subject portion of this network of bibliographic entities and relationships may seem hierarchical when viewed in isolation

As does the name portion

• f the

network of bibliographic entities and relationships

When the entities and realtionships are taken all together, the network structure of this mildly complex conceptual data model of a serial publication is readily apparent.

The ability to represent this serial publication diagrammatically is dependent on FRBR theory’s ability to prescribe diagram elements and construction rules in a conceptually valid fashion. If significant aspects of the publication’s structure and content cannot be expressed in the diagram, it is an indication that the theory needs work. Just as in architectural or engineering design, management of complex data model diagrams may require computerized assistance.

The ability to accept and use diagrammatic representations of FRBR theoretical elements may be dependent on that party’s position on the Description/Design Issue. Catalogers may already be accustomed to a descriptive stance due to personal inclination reinforced by professional training. Software developers must take a design stance towards their work, and are already conversant with diagrammatic representation. Whether either group will be able to reason theoretically using diagrams (á la Feynman) is an open question.

The FRBR Data Model In A Widening Context

• What kinds of “things of interest” are FRBR

entities?

– Of what types or subtypes are they?

• Who else is out there creating information about

things that are of interest to us

– Where do our paths cross?

• Design Decisions

– Model FRBR entities as subtypes of a larger, more familiar type of entity, as Resources – Descriptions of resources can themselves be resources – Business Rules constrain a more flexible data structure

• Model Presentation

– Data model to be presented from FRBR “up” – Model elements are introduced one at a time, in an

• rder that promotes assimilation of new element

function and relationship to existing elements – Statements about the model should take the form

• f “Business Assertions” that employ:
• Entity Names
• Entity Attributes
• Relationships
• Business Rules - Constraints applied to the model

The Conceptual Data Model

Institutionally Managed Named Resource

Expressed As Expression Of Exemplified By Example Of Work Expression Manifestation Item Manifestation Of Manifest As

The Conceptual Data Model

Institutionally Managed Named Resource

Expressed As Expression Of Manifest As Manifestation Of Exemplified By Example Of Work Expression Manifestation Item C D C D C D C D

The Conceptual Data Model

Institutionally Managed Named Resource

Expressed As Expression Of Manifest As Manifestation Of Exemplified By Example Of Work Expression Manifestation Item C D C D C D C D

The Conceptual Data Model

IFLA’s FRBR theory asserts that a Resource may be viewed and described from one up to to four levels of abstraction: Work, Expression, Manifestation, or Item. The FRBR specification (will) indicate which Institutionally Managed Named Resource attributes and relationships (plus others specific to that level of abstraction) constitute each of these levels of description.

Institutionally Managed Named Resource

Expressed As Expression Of Manifest As Manifestation Of Exemplified By Example Of Work Expression Manifestation Item C D C D C D C D

The Conceptual Data Model

Institutionally Managed Named Resource

Institutionally Managed Named Resource Description

The Conceptual Data Model

Institutionally Managed Named Resource

Institutionally Managed Named Resource Description

The Conceptual Data Model

An Institutionally Managed Named Resource Description is (ultimately) a Type

• f Resource. This entity makes it possible to describe an Institutionally Managed

Named Resource by associating it with one or more of an institution’s customary views of that Resource. No customary view has a privileged or compulsory relationship with the Institutionally Managed Named Resource. Incremental or incomplete resource (set) descriptions can be created.

The Conceptual Data Model

The Conceptual Data Model

While the more abstract combinations of attributes and relationships that define an institution’s customary view on a Resource may not be shareable with another institution’s, overlaps at less abstract levels are possible. A set of ISAD(G) archival Resource views has been added to the bibliographic views in the model, along with a general Annotation view, and an Other View.

The Conceptual Data Model

The Conceptual Data Model

Institutionally Managed Find & Navigate Resource Descriptions aid in Resource discovery by providing identifiers, assigning standardized names, subjects, and resource relationships.

The Conceptual Data Model

An Identifying Authority Resource Description consists of a name or an identifier. One or more of these must be assigned to a Named Resource.

The Conceptual Data Model

A Resource Aboutness Resource Description provides a subject term for a Named Resource. The term must be a Concept, an Event, an Object, a Place, or another Resource.

The Conceptual Data Model

A Responsible Party Resource Description identifies parties (Persons, Families, Corporate Bodies, etc.) who may (a.) play one or more roles with respect to a Named Resource, or be the subject of a Named Resource.

The Conceptual Data Model

An Other Relationship Resource Description consists of any “other” Type

• f relationship that one Named Resource

may have with another Named Resource. At least one relationship (“Creator”) is required for a Named Resource.

The Conceptual Data Model

The Conceptual Data Model

The Conceptual Data Model

A Managed Named Resource is a Named Resource that is managed (ID’d, named, described, etc.) by one or more Responsible Parties playing

• ne or more Roles such as “Creator,” “Cataloger,”

“Curator,” “Repository,” etc.

The Conceptual Data Model

This Resource assignment grouping collects all of the link information made possible by institutionally managed reference data.

The Conceptual Data Model

Grouping Resource assignments like this makes it possible to refer to (i.e., create, update and delete) ID’s, names, parties- in-roles, and relationships without changing the content

• f any Resource.

The Conceptual Data Model

Notice that two of these Institutionally Managed Named Resource Assignments are applied to an even simpler type of resource than the Managed Named Resource.

The Conceptual Data Model

This indicates that identifier, subject heading, responsible party, and relationship lists are created and maintained by institutions but are useable by any non-institutional party.

Types of Types are here A Named Resource is a Resource that must be of one or more Types. A Named Resource may be composed of one or more other Named Resources. A Type may be differentiated into one or more Subtypes.

Identifier, names and creator information are the most basic Resource characteristics that can be assigned, and appear at this very general level. Assigning an identifier to a Resource makes it uniquely distinguishable from other Resources. Assigning an name to a Resource renders it discoverable (but not necessarily uniquely) with a text-based search. Business Rules for this data model deliberately limit Responsible Party-in- role assignments for a Named Resource to a “Creator” role only. This follows from a design assertion that “someone” who assigns more than a “Creator” role to a Resource is either managing that Resource or knows someone who is. Additional roles can be assigned, from the Managed Named Resources level on down.

Finally(!), allowing a Named Resource to be composed of one or more Named Resources follows a conceptual data modeling convention for entities that may be composed of parts (that may be composed of parts...). Business Rules limit its use to theoretically relevant situations.

The Role of Conceptual Data Modeling In Cultural Heritage Institutions

• Definitions

– Conceptual, Logical, Physical, General

• About data modeling

– Modeling process, model, modeler

• Data models as “Paper Tools”

– Efficient reasoning about simple and complex models

• Data modeling examples

– FRBR entities are defined in the context of a Resource

• What to do now

– Revisit current modeling efforts; secure professional involvement in the modeling process; build, lease, buy modeling tools, training, education, taking leadership

Conceptual Data Modeling In Cultural Heritage Institutions

Acknowledgments:

Barbara B. Tillett JoAnne O’Brien-Levin James Hodson Workshop on FRBR in the European Library Lisboa, Portugal October 9, 2008

About (FRBR) Data Modeling: