This document has been superceded.

The latest version is available at entity1.html.

ALEG

Data Model - Entities

Everything is vague to a degree you do not realize
till you have tried to make it precise.
Bertrand Russell
Introduction

This document looks at breaking down some of the large entities described in the data model inventory with more specific descriptions. For example, the work entity covers all types of works, from serials to poems to letters.

The point of this exercise to to resolve issues which get raised when we try to look deeper at what the things we are storing really are - what they consist of and how they interract with other elements. It does not imply a 'physical' implementation strategy, but hopefully progresses us along that path with more confidence.

Work


Fig 1: Work

[MLA: "Main" rather than "Other"?
"Multiwork volume" rather than "Collection" (KF: but a serial Issue is also "multiwork")]

The Work entity is used in ALEG to record information about written work. The above diagram attempts to show that the Work entity is subclassed by (or has specialisations of) various entities that build on the general abstract concept of a Work to define concrete entities representing the various types of works dealt with by ALEG. (That funny grey triangle should be interpreted as saying "the entity at the pointing end of the triangle is the base (also known as super-class) of the entity(ies) connected to the blunt end.) Most works fall into the sadly named other category (novels, reviews, letters, essays, plays...) because they are single, stand-alone works.

These attributes are common to all works (described in the data model inventory):

Serial

A Serial entity contains information about a serial title, eg Westerly.

Serial adds the following attributes to those of work:

Notes and Issues:

SerialIssue

A SerialIssue entity contains information about a specific issue of a serial.

SerialIssue adds the following attributes to those of work:

Notes and Issues

Sequence

A sequence entity just defines a sequence, which is just a name for a group of works related because they are part of the sequence.

Sequence adds the following attributes to those of work:

Notes and Issues

Collection

A collection entity just defines a work which sets out to combine other works within a single new work. Collections are differentiated as "anthology" and "collected works" and "selected works".

Collection adds the following attributes to those of work:

Notes and Issues

Other

The Other sub-class of Work is just the place to classify what is left over - the vast majority of works stored in ALEG.

Other doesn't add any attributes to those of work.

Notes and Issues

Poetry

The poetry entity subclasses Other to hold poetry-specific attributes.

poetry adds the following attributes to those of work:

What about serialised works?

This doesn't really belong here, but somewhere we need to decide how to deal with works (such as a novel) which are serialised. For example, imagine an abridged version of Peter Carey's Oscar and Lucinda was serialized over 3 weekends in The Age.

Firstly, is the abridged version recorded as a new work (who did the abridging - Peter Carey or someone else, and does it matter?) or would abridged versions usually be treated as instantiations annoted appropriately? (I've assumed below it is a separate work, albeit linked to the 'original' by a versionOf relationship.)

Secondly, how best to record exactly how this abridged version has been instantiated? There are at least three possibilities:

  1. Create 3 new works, each representing a part of the abridged Oscar and Lucinda. Link each of them to the abridged version with a special "segmentOf" relationship (why not "partOf" - I don't know, maybe, but "partOf" is used elsewhere to group far more unrelated works, such as the individual works which just happen to appear together in a serial Issue). Each of these works is then linked (using "instantiatedAsPartOf") to one of the three instantiations of The Age:

  2. Link the abridged Oscar and Lucinda (using perhaps "partlyInstantiatedAsPartOf") to one of the three instantiations of The Age. The obvious problem here (although it also occurs in the first approach) is that there is probably a need to link these three partially instantiated links together with yet another relationship so that the fact that it was instantiated in three parts can be easily grasped by the user. Maybe this inter-instantiation relationship could be called "coInstantiation", or something wierd:

  3. As above, but create a new entity: InstantiationSet specifically to handle this case. The abridged Oscar and Lucinda is instantiated as this one of these InstantiationSets which itself is linked to the three instantiations of The Age:

It probably doesn't matter much, but we just have to do something to represent this common case.

KF: For the current thinking on how best to represent this, see the Work Types section of the Relationship Inventory

Creator


Fig 2: Creator

7 June 2000 - what about 'cultural groups' (A.L.M.), eg the Aranda Tribe? another division of Creator, or shoe-horn into 'Organisation'?

The Creator entity is used in ALEG to record information about each creator of works. The above diagram attempts to show that the Creator entity is subclassed by human and organisation.

This isn't a particularly significant dichotomy, but maybe it will help later provide templates or rules for the data maintenance of these entities. For example, the familial relationships of which an organisation could partake are pretty limited!

These attributes are common to all creators (described in the data model inventory):

Human

A Human entity contains information specific to human creators.

Human adds the following attributes to those of creator:

Notes and Issues:

KF: For the current thinking on how best to represent names, see the Names, alternate names, pseudonyms document.

Organisation

An Organisation entity contains information specific to non-human creators.

Organisation adds the following attributes to those of creator:

Notes and Issues:


Home > Data Model
Kent Fitch
k.fitch@adfa.edu.au
6 June 2000
revised: 27 June 2000