WO1999066425A1 - Data management system - Google Patents

Abstract

A data management system is provided in which a publishable story is comprised of one or more content items and one or more insertions. For publication, each insertion includes data fields which, among other things, direct at least one content item to a specified output destination. The output destination may include print, broadcast, Internet or other medium, and may be further broken down by publication, publication zone, publication date and/or publication edition. The insertions and content of a particular story are logically associated on the database, to permit users to track or edit the story, insertions or content while viewing and/or editing any or all associated insertions and content of a story. In one embodiment, content may be linked across insertions so that any change in the content will be updated to all linked versions. In another embodiment, common pages are defined in which insertions and content are to appear identically on a page across multiple media, editions or zones, in which case, insertions subject to common page rules are linked.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a data management system that permits users to view and/or edit a single copy of data under unified relationship criteria. More particularly, the present invention relates to an editorial and/or advertising data management system having enforced relationships between individual components and rules of the components, where the component data is maintained in a single, unified format that can be viewed/edited in overall manner, or by component, or rule. The present invention has particular utility in the field of editorial and advertisement data management systems that permit users to edit/augment and track publishable stories, by way of insertions (and based on a priori knowledge), with various components, while maintaining a unified data structure applied globally to the insertions and components, and will be described in connection with such utility, although other utilities are contemplated. 2. Description of Related Art Editorial and Advertising Data Management Processing and storage of editorial and advertising data has involved a substantial, and ever increasing amount of complexity. The nature of newspaper publishing has radically altered during the past decade. What was once a relatively straightforward process of producing one or two print editions - all on paper - during a production cycle has swollen to myriad publications, zones, editions and media that must be produced in the same amount of time. One major metropolitan newspaper that used to create two zones in two editions on difficult nights now routinely creates up o zone vers ons an ve e ons n a s ng e even ng w concurren publications to the Internet. Competition is, of course, the driving force behind this increased diversity. The market share previously enjoyed by metropolitan publications is now under assault from a variety of sources, particularly suburban publications, which are often perceived as better serving markets outside downtown areas, and local broadcast outlets. Also, newspapers feel compelled to have a strong presence on the Internet now that it has gained widespread acceptance as an information and commerce conduit In a separate trend, the weakening of FCC cross-ownership regulations has resulted in an increase in the number of media companies that own print, broadcast, cable and on-line publishing media within a single market. With these multiple outlets, it's understandable that owners would want to reuse content created for one medium in another. It is becoming increasingly common for a reporter to simultaneously create content for distribution on the Web, report via broadcast and create a "traditional" story for the local newspaper. Fundamentally, editors and reporters are expected to produce a considerably greater amount of content for more media in the same amount of time it took to previously create a much smaller amount of content for a single medium. The editorial systems used by these publications have remained relatively unchanged in the way they manage content since the 1970s and 80s. Editors and reporters generate individual news stories with virtually no system-maintained knowledge of a newspaper's zoning and edition requirements. All information regarding where a story is to be run is maintained either in editors' heads or "cheat sheets." If a story is to be run in multiple media, editions and/or zones, it is either up ca e or pu s e unmo e . e s ory s cop e , an a ona se o con en management problems arise, particularly when changes must be made in each autonomous version of a file. Minor, but critical modifications to content often result in "fishing expeditions" in the database to ensure that all copies of a story are properly updated. Eventual output of the finished product to archive systems is also problematic, as libraries are forced to cull through different stories to determine which ones should be "morgued." For example, referring to Figure 1, a conventional editorial management system is depicted in block diagram form. In this example, a story 1 may be created which may comprise a complete publishable story. Naturally, the story 1 contains content 2, which may include body text, headlines, pictures, etc. The content is typically associated with the story in traditional, folder/file database storage. Story 1, with its associated content 2, is used to generate a publication instance 3. Publication instance 3 may be, for example, a complete story on page 3 of a newspaper (which may include the above-noted content). If , however, the same (or different) user seeks to use the same content 2' for the same story 1 ', but wishes to create another publishable instance 3' (for example, the same story run in a different zone/edition, or an entirely different medium (e.g., Internet, etc.)), the user must recreate (e.g. copy) the content and edit it for the additional publishable instance 3 ' . In other words, publishable instances 1 and 1 ' have no link between each other, and thus, each must be created as separate, independent (autonomous) versions on the database. Thus, the same content must be duplicated for each publishable instance, and each copy resides separately and independently on the database (by way of separate folders, etc.). Additionally, since no link is established between the publishable instances 1 and 1', this system can give no information to another user about where other identical con en may ex s on e a a ase, or w e er e con en was cop e an use or another publishable instance. Since, as noted above, it is preferable (and, indeed, required) that the same information (content) is reused for different publishable instances, this system cannot accomplish this goal, since each instance must be created separately and independently from all other instances, which can quickly produce a vast and unmanageable database. Anther example of a conventional editorial management system is shown in Figure 2. In this example, a master version of a single story 4 (which typically includes content, as noted above) is stored on a database, and users are permitted to access the "master" copy, make a subordinate copy, and save any revisions separately on the database. Thus, for a given story 4, the database of this system may also include subordinate versions 5, 6 and 7 of the "master", where each version is created and/or edited independently of any other versions. As shown in the figure, no link is established between each version, and thus, each version is created and/or edited as a separate entity from all other versions. Thus, like the example shown in Figure 1, each version must be maintained separately on the database, since the content must be created and edited separately from a "master" version. To help resolve some of these story management issues, existing editorial system usually rely on a highly-serialized form of file management. Publication of content must occur in a well-defined set of steps or the entire process may collapse. For example, most publications rely on a system whereby content destined for publication on the World Wide Web (Internet) is gleaned from listings of stories that have been previously typeset. The immediacy and potential benefits of simultaneous (or pre-print) publication of content are lost due to limitations in existing products. ne a emp o so ve e a oremen one s o com ngs n conven ona editorial systems can be found in U.S Patent No. 5,181,162. This patent discloses an object-oriented document management and production system in which documents are represented a collections of logical components, or "objects", that may be combined and physically mapped onto a page-by-page layout. This patent discloses objects as "content" - text, images, audio, or graphics. These objects may contain attributes specifying a relationship to other objects or content, or other criteria. However, this patent does not provide a mechanism by which content can be reused across multiple mediums, editions, zones or dates, without the need for making a copy of the content for each instance. Advertising systems have obviously been expected to accommodate the same zoning, edition and medium challenges faced by newsrooms; it is, of course, publishers' desire to better target audiences that is pushing much of the need for the increased workload. The Atex ® Media Solutions Enterprise™ Configuration Manager is one example of an application that allows for the modeling of how a publications products are scheduled and structured. As a corollary to their modeling capabilities, advertising systems are able to manage enormously complex advertisement scheduling requirements using simple user interface techniques that prevent users from scheduling advertising material in an invalid publication, publication date or physical location within the published product. Finally, advertising systems have done a better job than their editorial brethren in monitoring the production status of each of the components that makes up an advertisement. Whereas an editorial story may consist of only a few text-based components almost preferably produced by the newspaper staff or a wire service, comp ex sp ay a ve semen s may ave ozens o components genera e y a variety of sources both internal and external to the newspaper. An additional problem arises because most existing editorial system databases are capable of storing only textual material. Audio, video, graphics, photographs and other "multimedia" content must be maintained on separate systems, each with its own user interface and functionality. Failure of any of these subsystems can result in fairly spectacular problems with the entire production process. Simultaneous creation of content for broadcast, Internet and print media is virtually impossible with existing advertising and editorial products. Additionally, like existing editorial products, advertising products have not been designed to handle multimedia content (e.g., audio/video data, etc.), nor do current advertising products have the ability to define content to destinations beyond print or Internet, i.e., defining content to appear in broadcast mediums/media. At the heart of the system is a story management paradigm not contemplated in the prior art. Rather than thinking of stories as being entities unto themselves which must be either reused unmodified in multiple editions and/or zones (Figure 1) or duplicated in order to accommodate modifications specific to a particular medium, zone or edition (Figure 2), the present invention uses an editorial "insertion" model that has not been attempted in the editorial and advertising field. A single story is preferably not duplicated when it is to be run in more than once. Instead, a new insertion is created. There is no presumption that the publication of one medium is superior to any other. With the present invention, a story may start life destined for broadcast, but concurrently be produced in print, broadcast and on-line; the output medium is irrelevant. a user s scre on, a new nser on can e rec e o m rror an ex s ng one: When a user changes on insertion, the content of another is automatically updated, eliminating the need to make modifications for each. Alternatively, each insertion can be independent modifiers of contents, each linked to the same (or different) content. Since content is defined for a particular destination by way of an insertion, there is no need to create multiple copies of the same content for each publishable instance or event, quite unlike prior art advertising and editorial products known in the art. In other words, the present invention does not manage data using conventional "file-folder" data structures, rather the insertion can be used to direct a single copy of content to multiple destinations. The database of the present invention, like the database of the existing Atex Media Solutions DewarView® editorial product (and some other systems), is capable of storing a virtually unlimited array of information. However, it may also serve as a conduit to conventional subsystems, if desired. Textual material, graphics, photographs, audio and video are accommodated. Indeed, the present invention need not predict what types of material newspapers will be expected to produce in the years to come; the system makes no presumptions about the type of material it will be expected to manage. Additionally, the present invention provides an interface to permit users to interact with this myriad of data via a single user interface. Importantly, insertions are created based on publication configuration and scheduling information maintained in the database, and referred to herein as "a priori knowledge". The same rules applied to the creation of advertising content will be used in the generation of editorial content; it will be impossible to schedule an editorial story for publication in an invalid publication, nor will it be possible to ass gn an nva ype o con en o a pa cu ar pu ca on as n e case o an au o snippet being assigned to a print publication). Additionally, the present invention goes a step further, dividing a particular insertion into components, which generally represent blocks of content (e.g., headline, body text, photo, photo caption, graphic, audio clip, video clip, etc.). Each of these components may be edited, paginated and tracked separately from any other component assigned to an insertion, much the way the individual components of an advertisement are produced autonomously, then brought together near the end of the production process. SUMMARY OF THE INVENTION In one aspect, the system of the present invention is designed to improve existing editorial and advertisement systems by permitting a single copy of content data to be defined by a plurality of insertions to be destined for a plurality of different publications, publication mediums, zone, editions, dates, etc, and which can be updated and/or edited by one or more users. In accordance with the present invention, a central database stores a unified logical data structure representative of a publishable story. To accommodate modifications, the central database permits a user (or users) to create insertions for that data which describes the form that the data will take. Each insertion can contain one or more components which include content data, e.g., headlines, photos, photo caption, logos, advertisement text, etc. Likewise, each component (i.e., data content) can be associated with several insertions, thereby "directing" that component to several publications, zones/editions, or into a different medium, without the need for multiple copies of the same content. Moreover, each insertion applies a local set of formatting rules to be applied to the components of that insertion. In addition, the central database tracks each insertion (and each component) create y one or more users, an can g o a y up ate any c ange n one n v ua component to all other like-components in other insertions, thereby saving the time and effort of making multiple copies of data and allowing all users to view/edit any and all insertions and components. The system also stores all publishable stories, insertions and components as a single, logical data structure that can be globally viewed and edited from an insertion, component or story perspective basis, by associating all components and insertions of a publishable story under a logically unified data structure. In one embodiment, the present invention provides a data management and editorial system, comprising a central database for storing at least one publishable story. The story comprises data content and at least one insertion related to the data content. The insertion includes one or more attributes related to the data content. At least one attribute defines a destination for the content. The central database is adapted to relate the content and insertions of the story in a single, unified data structure to permit said all the insertions and/or content of said story to be viewed and/or edited. In another embodiment, the present invention provides a data management and editorial system for the production and management of publishable events, comprising: a central database for storing at least one publishable story. The story comprises data content and at least one insertion related to the data content. The insertion includes one or more attributes related to the data content wherein at least one attribute defines a destination for the content. In this embodiment, content is to appear in multiple insertions. Accordingly, content is defined by separate insertions to appear in a plurality of separate publishable events, wherein the database links all ns ances o e con en an up a es any c anges n e con en o a ns ances o e content. In yet another embodiment, the present invention provides a data management and editorial system to link content to common pages across multiple publications, zones, dates and/or editions. In this embodiment, an editorial system is provided for the production and management of publishable events, comprising: a central database for storing at least one publishable story. The story comprises data content and a plurality of insertions related to the content. Each of the insertions including one or more attributes related to the data content wherein at least one attribute defines a destination for the content. The central database also for storing common page data which defines content that is to appear substantially the same on a given page in multiple destinations. The central database links all the insertions that define a destination that is part of a common page, and updates any changes in any one linked insertion with all other linked insertions. Common pages, as defined herein, logically extend to other non-print media as well. In method form, the present invention provides method of creating a publishable story, comprising the steps of: creating one or more content items related to a publishable event; creating at least one insertion for the content items, the insertion including attribute data including destination data to direct the content to a specified destination; associating all the content items and said insertions related to said publishable story to form a single, unified data structure; and storing the content items, insertions and associations on a database. The present invention also provides a method of creating a publishable story, comprising the steps of: creating one or more content items related to a publishable event; creating at least one insertion for the content items, the insertion including on e creating separate instances of a single copy of the content item and linking all instances of the single copy of the content item defined by the insertions; updating any changes in the single copy of the content item to all other linked instances of the content item; associating all the content items and the insertions related to the publishable story to form a single, unified data structure; and storing the content items, insertions and associations on a database. Additionally, the present invention provides a method of creating a publishable story, comprising the steps of: creating one or more content items related to a publishable event; creating at least one insertion for the content items, the insertion including attribute data including destination data to direct the content to a specified destination; determining if common page rules exist and linking all insertions whose content appears on common pages, associating all the content items and the insertions related to the publishable story to form a single, unified data structure; and storing the content items, insertions and associations on a database. In another aspect, the present invention also provides workflow management system to configure the workflow of publishable stories, insertions and/or components. In addition, the system of the present invention permits any user to obtain the status (e.g., pre-press, finalized, etc.) and view/edit any publishable story, insertion and/or component. The workflow management system, as provided herein, is media independent and applies equally to any publishable story in any medium, and applies routing and constraining procedures to a given publishable story, so that story can be tracked from its conception to its final disposition. It will be appreciated by those skilled in the art that although the following Detailed Description, Appendix A and Appendix B will proceed with reference being ma e to pre erre em o ments, t e present nvent on s not nten e to e m te to these preferred embodiments. Other features and advantages of the present invention will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and wherein: BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of an editorial data management system of the prior art; Figure 2 is a block diagram of another editorial data management system of the prior art; Figure 3 is a logical relationship diagram of one embodiment of the present invention; Figure 4 is a story- view logical diagram of the data management system of the present invention; Figure 5 is an insertion- view logical diagram of the data management system of the present invention; Figure 6 is a component- view logical diagram of the data management system of the present invention; Figure 7 is a functional block diagram of the data management system of the present invention; Figures 8 A and 8B depict flowchart diagrams of the preferred creation/editing of the preferred a priori database of the present invention; Figure 9 is a logical relationship diagram of the story, insertions and components of the present invention where the components remain unlinked; Figure 10 is a logical relationship diagram of the story, insertions and components of the present invention where the components are linked; gure s a og ca re a ons p agram o t e story, nser ons an components of the present invention where the insertions are linked; and Figure 12 is a flowchart depicting the preferred creation/editing of stories, insertions and components of the of the present invention. Detailed Description of the Invention While not wishing to be bound by example, the following description will detail the various components and functionality of the data management system of the present invention in relation to creating a publishable story. A publishable story is made up of multiple components in the form of headlines, pictures, text, bylines, etc. All, or some subset, of the components can be collectively published in various publications, zones, editions, or other media (e.g., magazines, Internet, newsletters, broadcast, etc.). Advertisements have the same relationship (i.e., insertion-component relationship), as do other material published in a newspaper. Collectively and individually, stories, advertisements, folios, banners, indexes, graphics, rules, etc are referred to herein as "publishable stories". As used herein, the terms "publishable story" and "story" should be viewed broadly as media-independent publishable events that can be viewed and/or printed and/or broadcast simultaneously or independently in a plurality of different mediums. Accordingly, publishable stories can encompass editorial events (e.g., news stories, etc.) and/or advertisement events (e.g., classified advertisements, retail advertisements, etc.) for a given medium. A publishable story can be formatted for print media and the Internet, while being simultaneously formatted for broadcast television and radio. A story will also have associated header data fields that can be user-supplied, or automatically assigned or derived by the system. (Exhibit A) As used herein, the term "insertion" should be viewed quite broadly as encompassing ru es an or nstruc ons as to t e orm an est nat on o a part cu ar component or set of components. Collectively, an insertion and it's components define a publishable event. For example, an insertion contains attributes (e.g., formatting instructions, style, font, length, etc.) about the form of a particular component for a particular medium (e.g., print media, Internet, broadcast, etc.) and/or edition (e.g., morning news print edition, etc) and/or geographic zone and/or other criteria. Print media can include newspapers, publications, magazines, periodicals, directories, catalogs, newsletters, inserts, etc. Broadcast should be viewed broadly as any modulated carrier frequency communications channel, including, but not limited to, cable broadcast communications, free-space broadcast communications (e.g., radio, UHF, VHF, etc.), satellite communications, digital communications, etc. The insertion as described herein preferably includes a plurality of data fields where each data field defines a particular attribute. At it's most atomic level, the insertion defines a destination for content. An insertion will have associated header data fields (attributes) that can be user-supplied, or automatically assigned or derived by the system. (Exhibit A). The attributes can be predefined, or may be provided by a user. Also, as used herein, the term "component" should be viewed broadly as the content of a particular insertion. Thus, for example, a given insertion can contain a subset of components, e.g., headlines, editorial text, picture, graphic, caption, audio, video, advertisement text, logos and/or other data that is computer-readable/transmittable and /or computer-controllable/reproducible. Likewise, the component includes the content and an associated header data fields that can be user-supplied, or automatically assigned or derived by the system. (Exhibit A). Collectively, a complete publication is a coherent collection of stories, related insertions and, in turn related components. a se o co permitting users to create/modify stories, insertion and components. Preferably, "application program" includes an appropriate program modules to permit users to create/modify content (components) in a variety of formats, for example, text, pictures, audio, video, or other publication content. This may include, for example, pagination software and directory management software that is appropriately adapted to interface to the system of the present invention to permit users to supply the appropriate data, as described below. Such software may include proprietary pagination and editing software tools (which preferably includes page layout and design software, as is understood in the art) and directory management software, or may include conventional pagination/editing and/or directory management software tools. Additionally, the preferred application program includes a "database program" which permits users to store content information on the database. "Database program", in turn, preferably includes an appropriate interface to permit users to query the database (e.g., using SQL translators), and to define relational data associated with stories, insertions and components. As the following detailed description proceeds, it is important to note that components (content) cannot be created for use in a publishable event without being assigned to an insertion (at some stage of the publication process). (However, content can exist on the database that has yet to be defined in an insertion). In other words, the insertion, as set forth herein, provides identity to the content or groups of content data by logically associating all content under that insertion's control. Accordingly, it will be assumed herein that all content, as defined above and herein, has at least one associated insertion, and that the insertion governs, at the very least, where that content will appear (destination). One feature of the present invention is e a y or perm ss ve or restr c ve ru es o e p ace on content, v a at r u es n insertions, so that the placement or destination of content cannot conflict with preset pagination and/or destination criteria. Referring to FIG. 3, the relationship between publishable stories 10, insertions 12 and components 14 is shown. As noted above, a component 14 is a subset of an insertion, and preferably comprises text, photos, video, audio, etc, i.e., content. An insertion 12 is defined by a user (or be partially or fully defined a priori, as discussed below), and operates as an instruction set for a given subset of components. Thus, for example, an insertion defines the particular form (e.g., format) that the components 14 will take for a given publication medium/zone/edition. In the present invention, the association between content, insertions and stories includes three preferable management structures: 1) the content remains independent across insertions, thus, each instance of the content can be edited separately, to accommodate, for example, physical size limitations of a particular medium; 2) the content is linked between insertions and thus, a given component can appear in multiple insertions, or, alternatively, between insertions, the form (e.g., length, font format, style, etc.) of the component can vary. Thus, while the content can remain the same, the form may vary between insertions. This does not mean that multiple copies of the content are required, just that multiple insertions define the destination of that content that is to appear substantially unchanged in each of those insertions. 3) Common pages are defined in which all insertions and content one page is to appear identically on another page in another medium, zone, data, or edition. As described more fully below, all insertions (and, accordingly, all components of each insertion) are stored by a central database in a single, unified data structure that can be accessed, edited and tracked by a plurality of users (e.g., editors). Of course, each of the above- men one managemen s ruc ures can e com ne or any g ven s ory an or publishable event. FIG. 4 is a logical diagram of one embodiment of the data structure of the present invention. By way of example, suppose that a certain publishable story 10 is being created on a "warehouse fire". As shown in the Figure, a user can create an insertion 12a for the "warehouse fire" for a specified date, zone (e.g., Boston Globe, NorthZone), edition (e.g., morning edition news print), and location (e.g., page 3). That insertion can contain components 14a-14d specific to that insertion 12a. The insertion 12a contains instructions, via editing software, as to the appropriate format and style of each of the components 14a- 14d, for that zone and/or edition. Component 14a is depicted as "headline 1" for that particular insertion, and is formatted accordingly, via insertion 12a, for the particular zone/edition. Component 14b represents the text of the warehouse fire, as created by, e.g., a reporter. Insertion 12a will dictate the format and style of component 14b for the particular zone/edition. Likewise, components 14c and 14d are under similar constraints, as dictated by insertion 12a. Insertion 12a' represent the same publishable story, but as it appears and is formatted for page 8 of the same medium as insertion 12a. Since insertion 12a' appears at a different physical location compared to insertion 12a, it contains a different subset of components 14a'-14c'. In this case, components 14a'-14c' are constrained by insertion 12a' in a similar manner as described above. In addition, a new insertion 12b can be created, by the same or different user, for the publishable story 10 that will be displayed on the internet. In this case, insertion 12b dictates the format of components 14e-14h for the Internet medium. Thus, for example, a video clip 14g may be included as a component of the warehouse fire story on the Internet. Of course, similar components, e.g., 14a, 14a' and 14e, can be exactly the same, or eren n o con en an orm. e a a ormat as s own n . s a en rom the perspective of the publishable story 10 (i.e., "story view"), and displays all information for that story in single logical data structure, i.e., the collection of insertions and components under that story, in a single logical data structure. Figures 5 and 6 are logical diagrams of other embodiments of the data structure of the present invention. The data structures depicted in Figures 5 and 6 are from the viewpoint of the insertion and component, respectively. It should be noted at the outset that the data structures of Figures 4-6 are not mutually exclusive, but rather, are different ways the data management system of the present invention can track publishable stories, insertions and components. As shown in FIG. 5, the present invention permits a user to view/edit any and all insertions at a particular physical location of the medium. Thus, for example, all insertions (and, all components thereof) present on page 3 of a newspaper can be displayed and edited. Similarly, from a component view (FIG. 6), all components for any given insertion or publishable story can be displayed and/or edited. As will be appreciated, an editorial story (story) is only one example of the data management system of the present invention. Most media publish stories in the form of advertisements as well. In other words, a given media has both an editorial component and advertisement component. Advertisements, for a given medium, come in various forms, e.g., printed, audio, video, graphical, etc, or some combination thereof. Advertisements can be further broken down into classified, retail, inserts and other advertisements. The data management system of present invention, as described above in reference to a news story, applies equally to advertisements. Thus, for example a given advertisement can contain certain components (e.g., text, banner, graphic, logos, etc.) specific for a given medium, and can be defined (i.e., constrained) or a me um y way o an nse on. e same a ve semen may a so compr se a different set of components (e.g., video, audio, etc.) for a different medium, and be defined for that medium by a separate insertion. In that regard, the logical structure of Figures 2-4 (i.e., insertion-component relationship), and indeed, the relationship between publishable story, insertion and component of Figure 3, extends to advertisements as well. For example, the publishable story 10 could represent a retail advertisement that will be run in a variety of newsprint media (including, for example, newspapers, magazines, periodicals, newsletters, professional association journals, etc.) and/or in the Internet. Accordingly, insertion 12a is defined as the local set of rules as to the form of components 14a-14d, as defined for a particular location of a particular medium. Of course, that same advertisement could be run on the Internet (by way of insertion 12b) and could comprise, e.g., video clips, audio clips, text, logos, and graphics as components thereof. The central database may comprise a stand-alone system, or can comprise one or more distributed computer program processes running on one or more networked personal (e.g., Apple Mclntosh™ or Intel Pentium™-based) and/or mainframe computers and include such additional computer, mass storage, and communications hardware and software as is appropriate to enable performance of their stated functions. For example, the computers may run the Microsoft Windows™, Windows NT™, or DOS™ operating systems, and may include database programs such as Oracle™, or other proprietary and or off-the-shelf database programs known in the art. Alternatively, the various functional components of the system present invention may be constructed solely out of custom, dedicated electronic hardware and software, without departing from the present invention. Further alternatively, rather than use the a oresa ypes o compu ers, t e sys em e presen nven on may ns ea u ze SUN™ and/or RISC-based workstations running Solaris™ and/or Unix™ operating systems, or an IBM RS/6000 running AIX operating system. Additionally, each user can track the status of and perform the various edits to the publishable stories either locally, or remotely over a network connection. To that end, the system can be adapted to permit users to download data, work offline to view/edit, and upload the data at a later time. The network may comprise a TCP/IP -based wide area network (e.g., an Internet-type of computer network). Of course, the present invention should not be viewed as being limited to the above-described types of computer/communications hardware, operating systems, and program processes, but rather, should be viewed expansively, as encompassing all types of computer/communications hardware, operating systems, and program processes so long as the stated functionality for the present invention may be carried out by same. It should also be noted that the system of the present invention can accommodate various software text, audio, video and other computer data editing tools known in the art. To that end, the system of the present invention can be appropriately modified with a dedicated software editing tool, or other editing packages known in the art. As will be described more fully below, the present invention includes database structure and management features and associated functionality. For example the database structures described hereinafter may comprise "relational" database technology is modeled such that all data is organized as though it is formatted into tables, with the table columns representing the table's fields or domains and the table rows representing the values of the table's fields or domains. Data is logically organized as tables but is not necessarily physically stored as such. The relational database user does not need to know how the database is physically constructed and can access an up a e a a v a a anguage n er ace or s ructure query anguage (SQL). The relational model described herein between stories, insertions and components assumes a certain stability in the number of columns of data associated with a table and that usually, data is present in most, if not all, fields within the table. However, those skilled in the art will recognize that other database structures and interfaces can be used without departing from the scope of the present invention. Figure 7 is a functional block diagram of the preferred embodiment of the data management system 30 of the present invention. Essentially, the system 30 of the present invention includes an administration system 32, an a priori database 38, a central database 34, an output manager 36, and an application program / database program 44. It should be noted that each of the functional components depicted in Figure 7 may include separate modular systems, or may be part of a unified database system. Each of these functional components is discussed more fully below. Administration system 32, which includes functionality to establish the a priori database 38, maintain the central database 34 and establish global rules applied to users 46A, 46b, 46C ...46N, preferably includes a configuration manager 40. Configuration manager 40 includes appropriate database functionality to permit a user (in this case, a system administrator, for example) to insert information (i.e., via data fields) related to the particular operating environment of the system. For example, a given publication will have a priori knowledge as to the scope of that publications' coverage, the different media in which publication events could occur, the different zones that publication may publish, times, dates, sections, editions, etc., and other knowledge specific to that publication. Additionally, the configuration manager 40 can include restriction and /or limiting data that can be placed globally on any data field within an insertion. For example, restriction data can be placed on a given pu ca on a e or e on suc a no con en components can e p ace on page 30 of that data or edition (for example, either because page 30 does not exist for that publication, or that other content is pre-reserved for that page). This list is only exemplary information, and other configuration data can be added to the system without departing from the scope of the present invention. Additionally, common page data can be defined for certain insertions (or, more particularly, attributes of certain insertions) to define common pages that may exist across several editions and/or zones of a given publication. For example, it is possible with the present invention to predefine content and insertions for a given page in a given publication zone/edition/medium to mirror another page in another zone/edition/medium. As part of the functionality associated with configuration manager, user's can define details related to preexisting content, shape, size and other dimensional characteristics specific to a particular publication and/or publication medium. For example, users are permitted to store recurrent data related to the overall dimensions of a given publication, specific dimension of a given page of a publication, etc. Additionally, certain content (components) recur from publication to publication, across zones, across editions, and across mediums. For example, logos, page number identifiers, templates, etc. may be common to all publications. Common page data can be defined for certain insertions (or, more particularly, attributes of certain insertions) to define common pages that may exist across several publications, editions, mediums and/or zones. For example, it is possible with the present invention to predefine content and insertions for a given page in a given publication zone/edition/medium to mirror another page in another zone/edition/medium. Common page data is one example of preset insertions that can be established a priori using configuration manager 40. a a genera e y t e con gura on manager s s ore n e a pr or database 38. As will be described below, the structure of the a priori database is preferably in the same (or equivalent) format as the insertion structure, since the insertion is checked against the database 38 for conflicting information. In other words, in the preferred system both the central database and the a priori database 38 are constructed using a "common currency" database language and structure. Alternatively, an appropriate database conversion system can be provided (not shown) to permit the system 30 to read and query both databases 38 and 34. In any event, administration system 32 preferably include an appropriate user-interface to permit entry of a priori data into the database 38. Of course, the interface may include, for example, prompt-type in which a user is prompted with a series of choices regarding the above-described particulars of a given environment, or field-type in which a user enters information into preset or user-definable data fields. Additionally, especially with respect to preexisting content, the system 32 may also include data filters and/or translators (not shown) to convert preexisting content into a preferred format. To that end, additional databases may be present which store preexisting data, which may be directly transferred to database 38 or logically stored in database 38 (using, e.g., pointer data). In addition to, or as part of, configuration manager 40, a module is also preferably provided which permits global (i.e., system-wide) control over user and content rights. Thus, for example, configuration manager 40 (or some subset module) can configure the system 30 to include a database of permitted user's of the system, and for those user's, provide what kind of access is granted (e.g., full edit rights, partial edit rights, view only, etc.) for specified content, or these preset rights may be defined globally for all content within the system. This may further include approp a e secu y measures e.g., passwor protect on, etc. t at can e app e on a per-user basis, and/or a per-content basis. Referring to Figures 8A and 8B, flowcharts are depicted which detail the construction of the a priori database 38, using the configuration manager 40 to configure the system and define particular characteristics of a publication. It should be noted that the process steps indicated in Figures 8 A and 8B are exemplary processes that may be associated with configuration manager 40, and are not intended to be an exhaustive list of their respective stated functionality. It should also be noted that unless otherwise specified, the sequence of steps listed in Figures 8 A and 8B need not be performed in the listed sequence, but may be performed in any sequence to accomplish the stated functionality. Also, for clarity, the system components numerically referenced in Figure 7 are omitted. An administrator (e.g., system administrator) opens configuration manager 50 to begin defining the particular operating environment of the system 30. The administrator creates and/or modifies a list of users 52 permitted to access/view/edit data on the system. The administrator can create/modify groups 54 by logically linking groups of users that share, for example, common roles in the publication process. Thus, for example, groups (of users) can be defined by department, title, etc. For each user and/or groups of users, parameters can be assigned 58. For example, access rights, password information, etc. can be assigned to users or groups of users. The administrator creates/modifies queues 56. A queue is that data related to workflow of a given story (including insertion and components), from conception to final publication. Thus, a queue can be assigned parameters 60 which may include, for example, the number of hours a story (including that story's insertions and components) lies "dormant' (i.e., period of time a story remains unaccessed) in the ata ase e ore mov ng t at story to na output or e ete , etc. A t ona y, user access to any particular queue or queues 62 can defined/modified. The administrator can define default parameters 64 such as: scope of a publications' coverage, the different zones that publication may publish in, times, dates, sections, editions, different media of publication (e.g., newspaper, Internet, periodical, broadcast, etc.), and other knowledge specific to that publication. The administrator also preferably creates/modifies restriction data 66 specific for a given publication, medium, time, zone, edition, etc. This data can include, for example, absolute page data, page count, etc. This data is stored in the a priori database 68, and is used in the publication production process, as described herein. Additionally, the administrator or other user can open the configuration manager 70 (Figure 8B), to define data related to preexisting content and/or shape, size and other dimensional and layout characteristics specific to a particular publication and/or publication medium. For example, the overall layout of a publication can be defined 72, which may include inputting data related to specific pages. Additionally, size, shape and other dimensional or layout characteristics related to components (content) can be defined/modified. Pre-existing content can be assigned and/or modified 74. This type of content, for example, may include preferred template arrangements for a given page, etc. In most publications, there is some content that appears constantly, for example, day-to-day in all editions and zones. Thus, an administrator can define this type of recurrent data 76 (content) and can further define, for example, that contents' placement on a particular page. As noted above, common page data can be defined, in which a plurality of preset insertions are defined 80. Of course, content related to those insertions can also be assigned to a page, which may be linked to other pages in common. Likewise, this a a s s ore n e a pr or a a ase , an s use n e pu cat on pro uc on process, as described herein. It should be noted that recurrent data, or indeed any content or rule structure provided by the present invention, need not reside on the database, but instead may be associated with the database via, for example, pointer data. Referring again to Figure 7, the central database 34 stores the story 10, insertion 12 and component 14 data. Application program and database program 44 permit users 46A, 46B, 46C...46N to access the database 34 and create/edit (if permitted) components, insertions and stories. Application program 44 may include pagination editing tools, management tools, database translating tools, and other tools as may be necessary. Such tools (programs) can be custom-made or off-the-shelf programs for editing, paginating and database file management, and other purposes. Output manager 36 is responsible for accumulating those stories that are common to a particular publication, zone, medium or edition and logically grouping those common story destined for a particular output. For example, output manager 36 will query the database 34 for all insertions that contain a data field for a particular edition in a particular zone of a newspaper in a particular medium. Output manager 36 includes appropriate systems to manage and/or translate and/or format a given collection of stories, insertion and components that are destined for a particular medium. For example, output manager 36 preferably includes a web-based publishing content manager to appropriately format those stories, insertion and components destined for the web. Other examples may include broadcast systems to manage those stories, insertion and components destined for broadcast (e.g., television, radio). The pagination rules supplied by the a priori database 38 and those created in the nsert ons w rect t e na output o a t e approp ate nsert ons or t at publication. Archival system 42 is provided to permit storage of any of the insertions, components (content) and/or stories herein defined for future access and retrieval. Thus, for example, a user may wish to archive a given publication event and define an insertion that directs the destination for the content of that event at some future time. Archival system 42 can also include such mass storage devices to store audio and/or video data (content) that can be defined by an insertion to be destined for broadcast or Internet mediums. Instead of having to recreate the content, the user can indicate in the insertion that the content exists as an archive in the archival system. Archival system preferably includes appropriately adapted mass-storage devices to accommodate the various type of content contemplated herein. Data from sources not shown in Figure 7 can also be stored in archival system, for example, external data, video, graphics, audio, and/or other data. Additionally, communications manager 48 is provided in the preferred system 30. Communications manager 48 essentially includes appropriate hardware and software to permit external wire service content data (e.g., AP/UPI) to be automatically translated into an appropriate format and assigned an insertion. In this instance, the insertion is preferably generated automatically by communications manager based upon data gathered from a priori database 38 (e.g., layout, style, etc.), and/or internal data associated with the content. Once the insertion(s) and component(s) are created and stored on the database 34, a user may edit or modify both, as if both were originally supplied by a user. As noted above, content cannot be published by the system unless it is associated with an insertion. Thus, insertion, content and story attributes in the preferred system 30 can be supplied by the app cat on program w c prov es a m xture o preset an user-spec e insertion data) and the communications manager 48, which automatically assigns attributes based on data from the a priori database. This automatic assignment may contain one or more data fields (attributes) that are assigned "TO BE DETERMINED" status, which may be supplied by a user of the applications program at a future time. Figures 9, 10 and 11 depict preferred embodiments of the logical association of stories, insertions and components when content differs between insertions, when content is linked between insertions, and when insertions and content are identical to multiple pages (herein referred to as "common pages"), respectively. Referring to Figure 9, a story is created under which insertions and content are provided and defined. In this example, the content BT1 (body text 1), BT2 and BT3 all differ from one another (e.g., each is not an exact content copy of the others) for insertion into a publication medium, via Insertion 1, 2 and 3, respectively. Since it is known that the content will differ between insertions (and hence, between each destined medium), the system permits existing content to be edited for another publication, zone, edition and/or medium, where each new instance of content is defined by another insertion. Likewise HI, H2, H3 (headlines) and AUDIO (audio clip) differ from each other, and are likewise unlinked. In Figure 10, the content BT1 and BT2 are identical. Accordingly, the content is linked together in the database. Any change in BT1 will automatically generate a like change in BT2. In this example, the link can be between content only, or between content and/or shape, and/or style, etc., where a change in one generates a like change in the other. Of course, multiple content can be linked across multiple insertions. Additionally, not all of the content in a given insertion need be linked to other content in another insertion. For example, although in this examp e = , nee not necessar y equa a t oug , o course, t s linkage among all content in an insertion could exist). In Figure 11 , common pages are established in which certain content and insertions of a page are to be mirrored on another page in another medium. In this case, the insertions are linked. Common pages can be defined a priori (using the a priori database construction processes, described above), or defined at any stage of the process. Common pages, as described herein, includes those media events for which all of the content and insertions are to be duplicated in another media event. One obvious example is defining a common page to exist across multiple publications, where the page will appear identical. Common pages applies equally to non-print mediums, for example, defining common pages for unique web sites, defining common pages for independent broadcast events, etc. Thus, common pages is not restricted to a printed page publications, but rather, for that set of components and insertions that are to be defined to be presented identically (or substantially identically) in any publication medium. Moreover, not all of the insertions for a given publishable event or story need be linked to the other insertions for that event or story. Linked changes in Figures 10 and 11 may be made not only to text but to other components (not all pictured). Figure 12 depicts the overall flow and decision flowchart 100 for the creation and/or editing of stories, insertions and components that are stored on the database 34, in accordance with the above described embodiments of Figure 9, 10 and 11. Appendix A, at the end of the Detailed Description, provides preferred component, insertion and story header (attribute) data. The data fields listed in Appendix A are provided as examples of the type of data that can be associated with the component, insertion and story, and are not intended to be an exhaustive, exclusive list. Those s e n e a w recogn ze a ce a n a a e s a u es or e componen s, insertions and stories may be user-supplied (via applications program, discussed above) or predefined (using, for example configuration manager, discussed above ). Additionally, it will be noted that certain attributes are preferably restricted (locked), and/or conditionally restricted from a user's perspective, so that a user is not permitted to edit (change) these attributes. Reference will be made in the following detailed description to certain attributes listed in Appendix A, but it should be recognized that similar processes described in Figures 12 may be implemented to define and/or edit a particular attribute. It should be noted that the process and decision steps described in Figure 12 do not necessarily need to take place in the order noted, rather Figure 12 is intended to depict the overall flow of the creation of insertions, stories and components at any point in the production process. A story is defined, or a pre- existing story is opened (if permitted) 102. The appropriate header data (Appendix A) is supplied for the story 104. For that story, content is created or modified (if permitted) 104, and a header for that content is created/modified 106. Once content is created, an insertion is defined for that content 110. As noted above, the insertion contains, at a minimum, data directing the output medium of the content. Accordingly, the destination (output medium) of that content is defined 112 for that insertion. Likewise, additional header data is preferably created/modified 114. The system looks at the header data in the story, insertion and component to determine if a preset (a priori) rule is violated 116. This can include, comparing the user supplied or automatically generated header data with preset header data to flag a conflict, or this may include a set of rules about what content can appear in a given medium. If a conflict exists, the system prompts the user 118 to correct the appropriate entry. The system queries the database to determine if the content is (or, is not) to be reused in ano er nser . no , e c n o o er con database, or future insertions to be created 122. (Figure 9). If yes, the content is linked. 124. (Figure 10). This is performed, for example, by matching header information in the content with content already on the system, or by a user defining that the content is to be reused by another insertion. An additional insertion is created for each instance (destination) of the linked content 126. Since the content is linked, the system will determine if this is new content, or pre-existing content that is being modified 128. If the content is pre-existing, the system will update all linked content with the modifications 130. It is important to note that linked content is not multiple copies of the same data, but rather, a single copy of data that is logically linked to different insertions, to be reused in those insertions. The system will also inquire as to whether common pages have been defined 132. The common page rules are preferably defined in the a priori database, but may also be defined at any stage of the publication process and stored in the central database. If yes, the system will create multiple insertions for the content, as indicated by rules defined by the common pages 134. Essentially, these rules indicate that a page is to be mirrored (i.e., exact replicas of the content and insertions) in two or more publications, zones, editions and/or mediums. This data is stored on the central database 136. Those skilled in the art will recognize that certain criteria, apart from the story/insertion/component model described herein, need to be defined in the publication production process. For example, it is often desirable to define page data which permits a given page on a particular media to be defined in terms of size, format, date, edition, zone, slug (shorthand name), and/or other criteria. Additionally, certain definitions may apply specifically to print media, for example, Double-Truck To field which contains the identification of a double-truck partner page (this en ica on s ou e trans ate to p ys ca an og ca pages epen ng on ow a user is referencing the component or page), Double-Truck Side field which indicates whether the page is the left or right side of a double-truck pair (the attributes of this field are assigned at the time the page is determined to be part of a double-truck), Logical Section field which displays the logical section in which the component is intended to be published (in addition to the logical section values specified in the Configuration Manager, the Logical Section field may be set to TBD — "To Be Determined." The Logical Section field is preferably protected; Logical Section information for a component may be changed either by altering the logical section field for the insertion to which it belongs, by "dragging and dropping" the component into another insertion or by invoking manual commands), Physical Section field displays the physical section in which the component is intended to be published In addition to the physical sections specified in the Configuration Manager, the Physical Section field may be set to TBD — "To Be Determined." The Physical Section field is preferably protected; Physical Section information for a component may be changed either by altering the physical section field for the insertion to which it belongs, by "dragging and dropping" the component into another insertion or by invoking manual commands), Double-Truck To field which contains the identification of a double- truck partner page (this identification should be translated to physical or logical page, depending on how a user is referencing the component or page. The Double-Truck To field is protected; it is preferably filled in by the system and preferably cannot be modified by users), Logical Section field which displays the logical section to which the insertion has been assigned (information in this field may be derived by default publication sizing information, gleaned from data maintained by the Configuration Manager, will be displayed. Modifications to the logical section field of the insertion necessar y mo y e og ca ec on e s o a componen s con a ns. e Logical Section field will be represented in the insertion header as a combo box with an associated editable entry field. The user will either type the name of a valid logical section or may select one from the combo box. The Logical Section field is linked to the Publication, Publication Date, Zone, Edition, Logical Page, Physical Section and Absolute Page fields in that a modification to the Logical Section field may result in the entries in the other fields to change to reflect valid publication information. In addition to the logical sections specified in the Configuration Manager, the Logical Section field may be set to TBD — "To Be Determined." The Logical Section field may be modified via the insertion header, by altering a displayed field in the system or by invoking manual commands), Physical Section field which displays the physical section to which the insertion has been assigned (Modifications to the Physical Section field of the insertion necessarily modify the Physical Section field of the components it contains. The Physical Section field is linked to the Publication, Publication Date, Zone, Edition, Logical Page, Logical Section and Absolute Page fields in that a modification to the Physical Section field may result in the entries in the other fields to change to reflect valid publication information. In addition to the physical sections specified in the Configuration Manager, the Physical Section field may be set to TBD — "To Be Determined." The Physical Section field is preferably protected; Physical Section information for an insertion may be changed by invoking manual commands), and or other page criteria. Essentially, page definitional data is where insertions are booked against, i.e., the manifestation of the insertions. Of course, those skilled in the art will recognize that additional and/or different parameters may be used to define a "page", as used herein. ona y, nser ons ayou a a can e e ne w c can nc u e g o a and/or local commands by which insertions are fundamentally defined. Insertion layout data includes the geometric boundaries for the content, and the relationship between the boundaries of content. Insertion layout data can include, for example, Fit Indication field used to indicate that the component fits in the available space (acceptable entries include "Short," "Fits" and "Overset." The Fit Indication field is protected; it is preferably filled in by the system and cannot be modified by users. Though the user will see running information indicating whether the component fits the assigned shape as he or she modifies the content, the Fit Indication field will be updated only when the user stores the associated component, not each time the story is edited. The Fit Indication fields of an insertion's components dictate how the Fit Indication field of the insertion will be set. If any component in an insertion has a fit indication other than "Fits," the Fit Indication field of the insertion will be set to "Components Don't Yet Fit." When all components of an insertion fit, the insertion's Fit Indication field will be set to "All Components Fit."), Shape field specifies the geometric properties to use when composing the component (initially, the Shape field contains a default specification which is tuned for the name of the component and the publication to which it has been assigned. Until the component is assigned a pagination status of placed, the Shape field is unprotected. Authorized users can change its contents by selecting from available shapes, displayed when the user pulls down a combo box associated with the field. Shapes can be a complex list of ordered polygons or a simple rectangle. The value inserted into the Shape field may include, for example, a named shape applied by the user, a shape name derived from the component type and the layout applied to the insertion, a default value inserted by the system, set to "drawn," which indicates the shape comes from a container drawn in.), y e e e spec es e compos on prope es o use w en compos ng a component (initially, the Style field contains a default specification tuned for the name of the component and the publication to which it has been assigned. Until the component is assigned a pagination status of placed, the Style field is unprotected. Authorized users can change its contents by selecting from available styles, displayed when the user pulls down a combo box associated with the field.), X Position field represents the position on the X axis of the upper left-hand corner of the component (for the insertion, it is the upper left-hand corner of the overall bounding box. This field is protected if the component or insertion is locked by the pagination editor or has a status of Placed or higher. When the story is locked by the pagination editor, only the session holding the lock may change the position. When the status is greater than Placed, the position may only be changed by the pagination editor), Y Position field represents the position on the Y axis of the upper left-hand corner of the component (for the insertion, it is the upper left-hand corner of the overall bounding box. This field is protected if the component or insertion is locked by the pagination editor or has a status of Placed or higher. When the story is locked by the pagination editor, only the session holding the lock may change the position. When the status is greater than Placed, the position may only be changed by the pagination editor), H&J (Hyphenation and Justification) Length. This field displays the composed depth of the component. The H&J field of newly-created user-generated stories is blank until the story is H&Jd and stored. The H&J length of existing material, though updated dynamically as the user modifies the content, is not updated in the H&J Length header field until the user stores the story. The unit of measurement used to display the composed depth is specified in the user's user pro-file. The H&J field is conditionally pro ec e ; canno e up a e w e e assoc a e ex s open or e . e con en of this field are preferably not modified by the user. . Of course, those skilled in the art will recognize that additional and/or different parameters may be used to define a "insertion layout", as used herein. In another aspect of the present invention, a workflow management system is provided to aid in the tracking and routing of publishable stories, insertions and components from conception (i.e., creation) to disposition (e.g., publication, archival, billing, cancellation, etc.) in either an automatic or user-defined manner. Preferably, the workflow management system applies routing and constraining instructions for a given publishable story, insertion and/or component. Workflow management is preferably included as part of the "applications program" discussed herein. Accordingly, the workflow management system of the present invention permits users to create a set of procedures, that can include adding steps for a given procedure so that a given publishable story can be routed and tracked according to a pre-defined set of rules that are user-configurable. Moreover, the status of any publishable story can also be rule-based and configurable by site according to their specific workflow needs and is continually updated and can be viewed/edited by one or more users. Routing decisions for a given publishable story can be based on sequencing, i.e., steps performed in a certain order, or based on other criteria, e.g., the evaluation of the attributes of the story or its components. In addition, steps can be linked together to form a sequence order, i.e., grouped together logically to form procedures. Thus, for example, a group can be constrained such that the steps are executed at once in a parallel-logical manner, or, the overall sequence of steps can be constrained such that all steps are executed in series. Routing decisions can include the parameters of where the publishable story is to be sent (e.g., physical location, such as the queue w ere e nex person s o wor on , or examp e, a sports w re s ory com ng n could be examined and the system determine that it should be sent directly to one of the queues of the sports desk. To that end, the workflow management system of the present invention can also include appropriate hardware/software to route publishable stories (using, for example, output manager, discussed above) between separate users, via, for example, the Internet or other network, or to different users via a set of queues that the users would have explicit access to. Routing decisions can also include logical instructions defining the overall flow from creation to fmalization. Preferably, the workflow management system is comprised of a graphical user interface to permit users graphically create and define the procedures and steps and to link together steps in a group for a given publishable story. Also preferably, the workflow management system comprises Visual Basic™ for Applications as the scripting tool for defining the workflow process as described above, and to provide other functional components, for example, notification that a story is ready for the next step or that it is running behind the scheduled deadline for insertion into the publication. For example, an advertisement (a publishable story) typically has several steps that must be tracked from creation to disposition. The present invention permits the creation of a set of procedures for defining the sequence of steps, and apply routing decisions for any given number of steps. An advertisement can include the steps of creation, editing, publication and billing (not necessarily in that order). In addition, a credit check for a given client might also be run before the advertisement is finalized and/or published. The present invention permits a user to define rules associated with these steps. The present invention also permits the creation of a set procedures for the sequence of steps to be followed. Thus, for example, a given advertisement can be appropriately constrained so that publication and/or editing of the advertisement cannot occur unt a cre t c ec s o ta ne . vantageous y, an w t part cu ar applicability to advertising, the workflow management system preferably provides billing and publication tracking for a given advertisements to permit users to obtain up-to-the-minute information regarding the status of an advertisement. The workflow management system of the present invention may be appropriately modified to permit customized procedures and capabilities, on an individualized basis, for both advertising and editorial applications. Traditionally, newsroom systems defined the progress of a story toward publication on the basis of the queue in which the story resided. To accomplish this functionality, the present invention provides the ability to define a system of automated statuses. These statuses are evaluated automatically when header fields change and are dynamically updated on all other user's systems that are currently viewing the same story or components. The evaluation of these statuses is also done using rule-based criteria, similar to the mechanism described previously for workflow steps. In addition to automated queue movement and status changes, the workflow also provides a mechanism to execute scripted actions based on an item being placed into a "worklisted" queue. These queues can be set up to perform extensive and extensible actions using site configurable Visual Basic for Applications scripting language. Alternatively, or in addition to, queues and/or status, the present invention provides "packages" to allows users to efficiently create stories in the database, assign their completion to other staff members and track their progress toward completion in terms of their relationship to users, not queues. Like other stories, packages have a header, but they differ in that they are assigned to users, not queues (discussed above). ac ages prov e a conven ent mec an sm or t e creat on of story and photo assignments, the tracking of layouts and paginated pages pertaining to a collection of stories and the "clustering" of stories destined for non-print publication. Appendix B, attached herewith at the end of the Detailed Description, provides some exemplary header information for packages, which include data fields to achieve the stated functionality. Preferably, the system provides an appropriate user interface (e.g., graphical user interface) to create and/or edit packages. By way of example, packages may be created and used as follows: Editor Larry has been assigned the task of organizing his newspaper's coverage of the upcoming theater season. To simplify his work, Larry creates a package, which will include all elements destined to be published as well as supporting material he might need from his sub-editors and reporters. Via mechanisms provided in the package (Exhibit B) user interface, he creates the individual stories to be included in the package, automatically placing them in the appropriate reporter queues. He also generates photo assignments as part of creating the package, doling out work to the picture desk. During the weeks (if not months) it takes to prepare the package, he adds layout shapes he thinks might be used in the package. As production nears, he also adds the pages where the theater stories have been placed. During the daily news "huddles," Larry's editor is able to provide accurate information about the progress of the theater package by simply building a list of the packages assigned to Larry. With his previous editorial system, Larry would have had to hunt around myriad queues to check the status of the theater season coverage. With the present invention, all that is required is to query the system for the status of all the packages for which he is respons e; t e system mme ate y u s a escr pt on o t e pro uct on status o a the package's components (and, necessarily, of the package itself). Before the present invention is installed, city editor Max organized his reporters' workload by culling through piles of paper on his desk. Though he had a fairly good idea what his staff was working on, he preferably not could be sure of exactly what his people were doing. Making matters more difficult, the news editor recently began asking Max for productivity reports on the city desk staff. During the daily news huddle, Max is able to utilize the present invention to immediately describe the workload his staff will contribute to the next day's paper. It's no longer necessary to print and distribute paper news schedule; the present invention provides a convenient mechanism for querying the database about what's happening on the city desk. Max "horse trades" stories with other editors during the news huddle, immediately shifting the assignment of certain files from one package (and consequently one responsible editor) to another. Based on what he learned in that day's news huddle, wire editor Rick knows what packages are being worked for the next day's paper. After the meeting, he returns to his desk and issues a query of all packages in process. Rick can see that Larry is working on a package regarding the upcoming theater season. He "offers" a story about a new play to Larry by automatically inserting it in Larry's package. Publications are free to generate editorial material without assigning it to a package and may conversely create packages that contain no links to material destined for publication. Modifications of the present invention are also possible. For example, the unified data structure as described herein applies equally to the broadcast medium e.g. e ev s on an or ra o roa cas . us, or examp e, componen s can nc u e video clips, audio/video presentations, audio sound bites, teleprompter text, commercial advertisements, or other data that is computer readable/transmittable or is otherwise computer controlled (e.g., analog video/audio equipment modified for computer control). In that regard, different insertions, as described above, can be applied for different geographic locations and/or different markets, while maintaining the single, unified data structure as described herein. Of course, the system of the present invention can be adapted for other media outlets as well. For example, the system can be adapted as an editorial/advertisement story data management system for use by catalogs, magazines, newsletters, books, professional publications, inserts, directories, and/or other print media. As described above, the data management system of the present invention can track publishable stories (e.g., editorial stories and advertisement stories) across media channels, while maintaining the single, unified data structure as described herein. The data management system of the present invention can further be appropriately modified for use by news, advertising and similar agencies, independent of any publication operated by such agencies. Further modifications are also possible. For example, the present invention can be appropriately modified to permit users to view/edit the publishable stories in multiple languages. To that end, the present invention can be adapted with language translation modules that permit any publishable story (and, accordingly, any insertions and components thereof) to be translated into a particular user's native language, edited, and then retranslated into the language as stored on the central database. In addition, the system of the present invention can be appropriately modified to incorporate exchange rates for multiple currencies, thereby permitting, for example, users n eren coun es o run a ve semen s an c arge t e appropr ate ee n e appropriate currency. Advantageously, the data management system of the present invention maintains a rigorous enforcement of the relationship between publishable stories, insertions and components. By permitting different viewpoints of the data relationships, a user can perform collective operations on logical subsets of components or insertions, while the logical relationships between publishable story, insertion and component is maintained. Thus, rather than creating a new data file for each new instance of a publishable story, the present invention permits insertions and components to be reused unmodified in a different publication/medium/zone/edition, or modified as desired to accommodate the particulars of yet a different publication/medium/zone/edition, while maintaining the structural relationship between this data in a single, unified data structure. Thus, there is no need to create a new file for the same publishable story that is to appear in a different publication/medium/zone/edition. Advantageously, the system of the present invention applies the same set of global rules for both editorial and advertisement, and other stories. Additionally, the present invention provides a system that permits a user to make changes in an insertion and the system can automatically update the content of other insertions, thereby eliminating the need to make modifications in each insertion, and/or linking content so that a change in one publishable instance of that content will appear in all other linked instances of that content. Component Attribute Information: In the present invention, components have an associated header, which essentially is a collection of data fields in which attributes can be user-defined or generated automatically. Some examples of preferred header data include: Author. This field displays the system login name of the user responsible for the creation of the first version of the component's content. Author differs from creator in that a story may be created by a user who will have nothing to do with the content, as in the case of pagination user creating components as part of the page layout process or of a desk editor creating story assignments prior to the creation of page layouts. The Author field is preferably protected; it is preferably filled in by the system and cannot be modified by users. Character Count. This field displays the number of characters contained in the component's text. This value is the sum of the non- white space characters in the component. The intent of this field is to provide a rough size estimate of the component but should not be considered a definitive measure of story size. The Character Count field is preferably conditionally locked; it cannot be updated while text with which it is associated is open for editing. In any event, the character count field is preferably protected from user modification. For non-textual components, this field will be left blank. Color. This field is used to indicate whether a component has full or spot color. The user is free to enter the name of a spot color to be assigned to the component, though the value of the field will often be filled in by a pagination editor. The user will select either of the two options by selecting the appropriate option from a combo box. The o or e s pre era y not protecte ; t may e mo ie y t e sys em or a user while another user has the content open for edit. Component Format. This field is used to represent the format of the associated component. Possible entries in this field include (but is not limited to): audio components ( WAV, etc.), textual components (ASCII, XML, SGML, RTF, HTML, etc.), graphic components, including Images, ( JPG, GIF, EPS, TIFF, etc.), video components ( AVI, MOV). The contents of the Component Format field are preferably protected; the value is entered by the system when the component is created. Component Type. This field is used to represent the type of information the component includes. Possible entries in this field include: audio, recurrent content, HTML, images, text, video, etc. The contents of the Component Type field are preferably protected; the value is entered by the system when the component is created. Copy Count. This field displays the number of times this component has been copied. It is acceptable for this field to read either "0" or be blank in the headers of components which have not been copied. The Copy Count field is protected; it is preferably filled in by the system and cannot be modified by users. Cost/Payment. This currency-formatted field is used to maintain dollar amounts for payment of free-lancers for a submission or the amount the newspaper will charge to publish the associated content. By default, this field will be left blank. The Cost Payment field is preferably not protected; it may be modified by the system or a user while another user has the content open for edit. Creator. This is the name of the user who created a component. Creator differs from Author in that the author is the first user to be responsible for a story's content — the rst user to mo y t e text, or examp e. e creator w o en e a pag nat on user designing a page or an editor assigning stories to his or her reporters. The Creator field is protected; it is preferably filled in by the system and cannot be modified by users. Deadline Date and Time. This unprotected date and time field displays when the component should have reached a specific point in the editing or pagination process. To streamline the entry of information into this field, a calendar combo box will be associated with this field as well as a streamlined mechanism for the entry of the time. By default, the Deadline Date and Time field will be blank. The Deadline Date and Time field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Editor. This protected field displays the login name of the last user to edit the component's content. In instances where a user creates, edits then stores a newly- created component, the same login name will appear in the Author, Creator and Editor fields. The Editor field is protected; it is preferably filled in by the system and preferably cannot be modified by users. Editorial Status. This field is used to specify the production status of a component from an editorial perspective. The Editorial Status field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. The Editorial Status field entries of each component in an insertion are used to derive the editorial production status of the insertion to which the components belong. Essentially, the adage that a chain is as strong as its weakest link applies to editorial status information; the status assigned to the insertion is equivalent to the lowest status assigned to one of its components. ea ure o er. s e s use o spec y n orma on genera e y e on- figuration Manager to indicate that the story must be position relative to another editorial or advertising story. The Feature Modifier field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Entries in the Feature Modifier field can be generated by via conventional and/or proprietary display advertisement placement programs. Internal Reference Number. Every story in the database will receive an internal reference number, distinguishing it from other stories. Though multiple versions of an element may share the same internal reference number (allowing the system to identify two modifications of a story as being related even though the other header information and text may differ considerably), no two different stories in the database may share the same internal reference number. The Internal Reference Number will be inserted into a field. The Internal Reference Number is protected; it is preferably filled in by the system and cannot be modified by users. Internet Status. This field is used to specify the production status of a component from an Internet publishing perspective. The Internet Status field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. The Internet Status field entries of each component in an insertion are used to derive the Web production status of the insertion to which the components belong. Essentially, the adage that a chain is as strong as its weakest link applies to Internet Status information; the status assigned to the insertion is equivalent to the lowest status assigned to one of its components. Jump From. This field contains the identification of the page that the component jumps from. This identification should be translated to physical or logical page depending on whether the user has configured the system to show insertion n orma on us ng e er p ys ca or og ca pages. s e s pro ec e once a component is placed on a page and preferably can only be changed within a pagination editor. Jump Head. This field contains the identification of the page on which a component's jump sequence begins. This identification should be translated to physical or logical page depending on how a user is referencing the component. This field is preferably protected. It is derived as the jump sequence is assigned. Jump Position. This field contains the component's ordinal position in a jump sequence. This field is preferably protected. It is derived as the jump sequence is assigned. Jump To. This field contains the identification of the page that the component jumps to. This identification should be translated to physical or logical page depending on how a user is referencing the component. This field is protected once a component is placed on a page and preferably can only be changed within the pagination software. Keywords. This field displays keywords assigned to the insertion. The Keywords field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Locked By. The name of the system user who currently has the content of the component locked. When a user locks the insertion, its associated components are also locked; the name of the user who locked the insertion is indicated in the component's Locked By field. Similarly, when a user locks the story, all components in all insertions are also locked. The Locked By field of all components and all insertions will be updated to reflect the login name of the user who has the story locked. In the event a user attempts to open for edit any story opened by another user (or the same user at another workstation), an error message will appear indicating the login name of t e user w o as t e story oc e , t e name o t e wor stat on w ere t e oc ex sts. The user will be given the option of opening the story for read-only or aborting the operation. If the user elects to open the story for read-only, it will automatically become editable when the user editing the story releases the lock. The Locked By field is protected; it is preferably filled in by the system and cannot be modified by users. Locked By Workstation ID. This field will be used for the storage of the workstation ID where the component is locked. If the component is not locked, the field will be blank. The Locked By Workstation ID field is protected; it is preferably filled in by the system and cannot be modified by users. Makeup Date. This unprotected date field displays the date in which the insertion should go into the production process. To streamline the entry of information, a calendar combo box will be associated with this field. The date is displayed using the date configuration specified on the workstation. The Makeup Date field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Next Queue. This unprotected field displays the name of the default next queue for the component. The name of the Next Queue is entered in the administrative utilities for the cur-rent queue and is displayed not only in the header for the component, but also when the user invokes the Move command. If an authorized user modifies the Next queue field entry, the revised queue name will appear when the user invokes the Move command. So, for example, if the default move queue of a component residing in queue A\B\C is XYYΛZ, but an editor changes the Next Queue field to be R\S\T, R\S\T will appear as the default destination if the story is subsequently moved. The Next Queue entry may also be overridden as part of the Move operation. The Next ueue e s pre era y no pro ec e ; may e mo e y e sys em or an authorized user while another user has the content open for edit. It is also possible for users to execute the move command to the Next Queue destination while another user has the content open for edit. A combo box with an editable entry field will be used for the selection of the next queue; all queues to which the user has write rights will be displayed when the combo box is activated. Assuming the user has the right to edit header information in the queue where the component resides, he or she may enter the name of a queue in the combo box entry field or select a queue from the list. Original Queue. This field is used to indicate the queue where the component was created. The Original Queue field is protected; it is preferably filled in by the system and is preferably not modified by users. Pagination Status. This field is used to specify the production status of a component from a pagination perspective. The Pagination Status field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. The Pagination Status field entries of each component in an insertion are used to derive the Pagination Status of the insertion to which the components belong. Essentially, the adage that a chain is as strong as its weakest link applies to Pagination Status information; the status assigned to the insertion is equivalent to the lowest status assigned to one of its components. Parent Internal ID. A unique ID of the parent story to allow a user to trace back from the child. In the case of components, the parent internal ID would refer to the internal ID of the component used as the source of the current component. The Parent Internal ID field is protected; it is preferably filled in by the system and is preferably not modified by users. No validation of the Parent Internal ID field will occur. Thus, if a component s parent as een remove om t e ata ase, t e Parent nterna e may include the ID of a story that no longer exists in the system database. Previous Editorial Status. This field is used to specify the previous editorial production status of a component from an editorial perspective. The Previous Editorial Status field is protected; it is preferably filled in by the system and is preferably not modified by users. Previous Internet Status. This field is used to specify the previous Internet Status of a component from an editorial perspective. The Previous Internet Status field is protected; it is preferably filled in by the system and is preferably not modified by users. Previous Pagination Status. This field is used to specify the previous Pagination Status of a component from an editorial perspective. The Production Status field is protected; it is preferably filled in by the system and is preferably not modified by users. Previous Queue. This protected field displays the name of the previous queue where the component resided. This field is initially blank until the component is moved from one queue to another. The Previous Queue field is protected; it is preferably filled in by the system and is preferably not modified by users. Priority. This field displays information obtained from the Priority field in the standard NAA wire service (AP/UPI) header for the component. The priority field is unique in that sorts of the field are not necessarily alphabetical. In the United States for example, the priority field would be sorted in the following order: F (flash), B (bulletin), U (urgent), R (regular), D (deferred), H (hold), S (Sunday). The Priority field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. The Priority field will be sp aye o e user as a com o ox w an e a e en ry e . e user may e er type the letter corresponding to the desired priority or select an entry from the resulting list. Queue. This field displays the queue in which the component currently resides. Components are the only type of stories which, from the user's perspective, appear to reside in queues. The Queue field may be modified by the user who has the content of a component locked, or via the user interface by an authorized user without first locking the content. It will not be possible for one user to modify the Queue field of a component if the content is locked by another user (or by the same user at a different workstation). The Queue field will be represented to the user as a combo box with an editable entry field. When selected, the box will display all the queues to which the user has at least the right to write content. Assuming the user has the right to edit header information, he or she will be free to enter any of the values "by hand" or select one of the user names from the combo box. This field would preferably only apply to editorial events, not advertising events, since advertising events typically are not associated with queues. Responsibility. This field displays the login name of the system user responsible for ensuring that the production of this component takes place successfully. The Responsibility field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. The Responsibility field will be represented to the user as a combo box with an editable entry field. When selected, the box will display all system users. The user will be free to enter any of the values "by hand" or select one of the user names from the combo box. Responsible Department or Desk. This field displays the name of the department or desk responsible for ensuring that the production of this component takes place success u y. e espons e epartmen or es e s pre era y no pro ec e ; may be modified by the system or an authorized user while another user has the content open for edit. The Responsible Department or Desk field will be represented to the user as a combo box with an editable entry field. When selected, the box will display all of the publication's departments. The user will be free to enter any of the values "by hand" or select one of the departments from the combo box. Slug. This field contains the name of the component. Component names roughly correspond to the name of NAA SGML tags for incoming wire material. The Slug field for components will be protected; possible names are configured upon system installation. To create a component slug, the user will select the type of component when creating the component. The system will automatically number the story type depending on how many similar stories are in the story; component names are unique across all insertions for a particular story. Time Arrived in Queue. This date field displays the time when a particular version of the component arrived in its current queue. The date and time are displayed using the date configuration specified on the workstation. The Time Arrived in Queue field is protected; it is preferably filled in by the system and is preferably not modified by users. This field would only apply to editorial events, not advertising events, since advertising events typically are not associated with queues. Time Created. This date field displays the time when a particular component was created. The date and time are displayed using the date configuration specified on the workstation. The Time Created field is protected; it is preferably filled in by the system and preferably not modified by users. Time Modified. This date field displays the time the component was created. The date and time are displayed using the date configuration specified on the workstation. e me o e e s protecte ; t s pre era y e n y t e system an preferably not modified by users. Version. This field displays the version number of the component. The Version field is protected; it is preferably filled in by the system and preferably not modified by users. Insertion Attribute Information: In the present invention, insertions have an associated header, which essentially is a collection of data fields in which attributes can be user-defined or generated automatically . Some examples of preferred header data include: Absolute Page. This field displays the absolute page to which the insertion has been assigned. The pagination software is capable of updating this field as stories are assigned to pages. In addition to the absolute page values specified in the Configuration Manager, the Absolute Page field may be set to TBD — "To Be Determined." The Absolute Page field will preferably be protected; Absolute Page information for a component may be changed either by altering the absolute page field for the insertion to which it belongs, by "dragging and dropping" the component into another insertion or by manual (user-supplied) commands. Author. This field displays the login name of the user first responsible for the creation of an insertion. Author differs from creator in that a story may be created by a user who will have nothing to do with the content, as in the case of a pagination user creating components as part of the page layout process or of a desk editor creating story assignments prior to the creation of page layouts. The name of the user who first modifies the content is the author. The Author field is protected; it is preferably filled in by the system and cannot be modified by users. oc oun . s e sp ays t e con ents o t e oc oun e as received from incoming wire services for a particular story. The block count field is not used on stories generated "in-house" (i.e., locally, as opposed to generated via wire service) — it will be empty in the headers of stories generated by users. The block count field is entered into the insertion header created as part of the reception of a story from a wire service; it is left blank in the insertion headers of stories created by copying the initial insertion. The Block Count field is protected; it is preferably filled in by the system and is preferably not modified by users. Category. This field displays information obtained from the Category field in the standard NAA wire service header for the story. Generally, the category field is left blank on stories generated in-house, though customers are free to use it. The category field is inserted into the headers of stories transmitted from the newspaper. The Category field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Copy Count. This protected field displays the number of times this insertion has been copied. It is acceptable for this field to read either "0" or be blank in the headers of insertions which have not been copied. The Copy Count field is protected; it is preferably filled in by the system and cannot be modified by users. Cost/Payment.1 This currency-formatted field is used to maintain dollar amounts for payment of free-lancers for a submission or the amount the newspaper will charge to publish the associated content. The information included in this field is the sum of the Cost/Payment fields of each of the components included in the insertion. The Cost Payment field is preferably not protected; it may be modified by the system or a user while another user has the content open for edit. rea or. s s name o t e user w o create an nsert on. reator ers om Author in that the author is the first user to be responsible for a story's content — the first user to modify the text, for example. The creator will often be a pagination user designing a page or an editor assigning stories to his or her reporters. The Creator field is protected; it is preferably filled in by the system and cannot be modified by users. Deadline Date and Time. This unprotected date and time field displays when the insertion should have reached a specific point in the editing or pagination process. To streamline the entry of information into this field, a calendar combo box will be used as well as a streamlined mechanism for the entry of time. By default, the Deadline Date and Time field will be blank. The Deadline Date and Time field is protected; it is preferably filled in by the system and cannot be modified by users. Though the components that make up an insertion may have information in their Deadline Date and Time field, there is no correlation between component deadlines and the deadline of the insertion. Edition. This protected field displays the edition in which the insertion is intended to be published. Default publication sizing information, gleaned from data maintained by the Configuration Manager, will be displayed. Modifications to the Edition field of the insertion necessarily modifies the Edition field of all components it contains. The Edition field will be represented in the insertion header as a combo box with an associated editable entry field. The user will either type the name of a valid edition or may select one from the combo box. The Edition field is linked to the Publication, Publication Date, Zone, Logical Page, Logical Section, Physical Page, Physical Section and Absolute Page fields in that a modification to the Edition field may result in the entries in the other fields to change to reflect valid publication information. In a on o t e e ons spec ie n e on igura on anager, e on e may be set to TBD — "To Be Determined." The Edition field may be modified via the insertion header, by altering a displayed field in the Directory Manager or by invoking manual commands. Editorial Status. This field is used to indicate the "lowest" Editorial Status of a component belonging to the insertion. Essentially, the adage that a chain is as strong as its weakest link applies to the Editorial Status information; the status assigned to the insertion is equivalent to the lowest status assigned to one of its components. The Editorial Status field is preferably protected; its contents are either derived from the production statuses of the components contained in the insertion or is set by pagination software. Feature Modifier. This field is used to specify information generated by the Configuration Manager to indicate that the story must be position relative to another editorial or advertising story. The Feature Modifier field is preferably not protected; it maybe modified by the system or an authorized user while another user has the content open for edit. It is anticipated that entries in the Feature Modifier field will be generated by display advertisement placement programs via the Page One third- party interface API. Internal Reference Number. Every story in the database will receive an internal reference number, distinguishing it from other stories. Though multiple versions of an element may share the same internal reference number (allowing the system to identify two modifications of a story as being Document Name: related even though the other header information and text may differ considerably), no two different stories in the database may share the same internal reference number. The Internal e erence um er w e nser e n o a e . e n erna e erence um er s protected; it is preferably filled in by the system and cannot be modified by users. Internet Status. This field is used to indicate the "lowest" Internet Status of a component belonging to the insertion. Essentially, the adage that a chain is as strong as its weakest link applies to the Internet Status information; the status assigned to the insertion is equivalent to the lowest status assigned to one of its components. The Internet Status field for insertions is preferably protected; its contents are either derived from the production statuses of the components contained in the insertion or is set by pagination software. Locked By. The name of the user who currently has the insertion locked — the user who has all components locked. In the event a user attempts to open for edit any story opened by another user (or the same user at another workstation), an error message will appear indicating the login name of the user who has the story locked and the name of the workstation where the lock exists. The user will be given the option of opening the story for read-only, "taking a number" for a cascading lock or aborting the operation. If the user elects to "take a number," it will automatically become editable when the user editing the story releases the lock. The Locked By field is protected; it is preferably filled in by the system and cannot be modified by users. Locked By Pagination Software. This field will contain the name of the user who has locked the last unlocked component. Once a story has been placed on a page, its position and geometry may not be modified outside of the pagination software until the lock is released. This field is protected and may only be modified by a pagination session or an authorized user. Locked By Workstation ID. This field will be used for the storage of the workstation ID of the user who has all components of the insertion locked. If any of the componen s are oc e y any o er user, s e w e set to oc e y u p e Users." If no components are locked, the field will be blank. The Locked By Workstation ID field is protected; it is preferably filled in by the system and cannot be modified by users. Logical Page. This field displays the logical page to which the insertion has been assigned. Default publication sizing information, gleaned from data maintained by the Configuration Manager, will be displayed. Modifications to the logical pages field of the insertion necessarily modify the Logical Page fields of all components it contains. The Logical Page field will be represented in the insertion header as a combo box with an associated editable entry field. The user will either type the name of a valid logical page or may select one from the combo box. The Logical Page field is linked to the Publication, Publication Date, Zone, Edition, Logical Section, Physical Page, Physical Section and Absolute Page fields in that a modification to the Logical Page field may result in the entries in the other fields to change to reflect valid publication information. In addition to the logical pages specified in the Configuration Manager, the Logical Page field may be set to TBD — "To Be Determined." The Logical Page field may be modified via the insertion header, by altering a displayed field in the Directory Manager or by invoking manual commands. Makeup Date. This unprotected date field displays the date in which the insertion should go into the production process. To streamline the entry of information into this field, a calendar combo box will be associated with this field. The date is displayed using the date configuration specified on the workstation. The system must be capable of evaluating the Makeup Date of the insertion in relation to the makeup date of its associated components. If the user enters a makeup date in the insertion that is before the makeup date for any of its corresponding components, an information dialog box w appear w e message e ma eup a e or t e nsert on w occur e ore e makeup date for the component slug component." This dialog box will appear for each component whose makeup date is later than the makeup date of the insertion. The Makeup Date field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Original Slug. This field displays the slug originally assigned to the insertion. The name of the insertion will be derived from its run information; users will not "manually" assign slugs to insertions. The Original Slug field is protected; it is preferably filled in my the system and is preferably not modified by users. Output Medium Type. The output medium type for an insertion indicates the type of medium where the components of the insertion will be published. It is not possible to assign invalid components to an insertion. This is, on the basis of the output medium type, only a particular set of components may be used. The Output Medium Type field is protected; it is preferably filled in by the system and is preferably not modified by users. Pagination Status. This field is used to indicate the "lowest" Pagination Status of a component belonging to the insertion. The Pagination Status field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Physical Page. This field displays the physical page to which the insertion has been assigned. Default publication sizing information, gleaned from data maintained by the Configuration Manager, will be displayed. Modifications to the physical pages field of the insertion necessarily modify the Physical Page fields of all components it contains. As with all other modifications to the run information header fields, modifications to one field may cause the information to be displayed in another field to automatically c ange. e ys ca age e s n e o e u cat on, u ca on a e, one, Edition, Logical Section, Logical Page, Physical Section and Absolute Page fields in that a modification to the Physical Page field may result in the entries in the other fields to change to reflect valid publication information. In addition to the physical pages specified in the Configuration Manager, the Physical Page field may be set to TBD — "To Be Determined." The Physical Page field will preferably be protected; Physical Page information for an insertion may be changed by invoking the Assign and/or Place commands. Placement Priority. This field will be used as an indication of the importance for an insertion to appear in a particular position. It is anticipated that it will be used primarily by the algorithmic editorial pagination placement utility. The Placement Priority field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Previous Editorial Status. This field is used to indicate the previous Editorial Status of the insertion. The Previous Editorial Status field is protected; it is preferably filled in by the system and cannot be modified by users. Previous Internet Status. This field is used to indicate the previous Internet Status of the insertion. The Previous Internet Status field is protected; it is preferably filled in by the system and cannot be modified by users. Previous Pagination Status. This field is used to indicate the previous Pagination Status of the insertion. For a description of all possible entries, see the Pagination Status section of chapter 6. The Previous Pagination Status field is protected; it is preferably filled in by the system and cannot be modified by users. Priority. This field displays information obtained from the Priority field in the standard NAA wire service header for the insertion. The priority field is unique in that so s o e e are no necessa y a p a e ca . n e n e a es or examp e, e priority field would be sorted in the following order: F (flash), B (bulletin), U (urgent), R (regular), D (deferred), H (hold), S (Sunday). The sort order of the priority field is validated against a configuration file maintained in the database. The Priority field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Publication. This field indicates the target publication for the insertion. Information in this field may be derived by the configuration information maintained in Configuration Manager. Modifications to the Publication field of the insertion necessarily modify the Publication field of all components it contains. The Publication field is linked to the Publication Date, Zone, Edition, Logical Page, Logical Section, Physical Page, Physical Section and Absolute Page fields in that a modification to the Publication field may result in the entries in the other fields to change to reflect valid publication information. In addition to the publication specified in the Configuration Manager, the Publication field may be set to TBD — "To Be Determined." The Publication field will preferably be protected; publication information for an insertion may be changed by invoking manual commands. Publication Date. This field displays the date when the insertion is expected to be published. The date is displayed using the date configuration specified on the workstation. Modifications to the publication date field of the insertion necessarily modify the Publication Date field of all components it contains. The Publication Date field is linked to the Publication, Zone, Edition, Logical Page, Logical Section, Physical Page, Physical Section and Absolute Page fields in that a modification to the Publication a e e may e en ie s o c ange publication information. In addition to the publication dates specified in the Configuration Manager, the Publication Date field may be set to TBD - "To Be Determined." The Publication Date field will preferably be protected; publication date information for an insertion may be changed by invoking manual commands. Responsible Department or Desk. This field displays the name of the department or desk responsible for ensuring that the production of this insertion takes place successfully. The Responsible Department or Desk field is preferably not protected; it may be modified by the system or an authorized user while another user has the insertion's components open for edit. Slug. This field contains the name of the insertion. Insertion names are derived from configuration information established on system installation; some publications may choose to organize insertion slugs on the basis of logical page numbers, others may choose to do so on the basis of physical page configurations. The following example presumes the customer chose to organize insertion slugs on the basis of logical page information. Information is presented in the following format: logicalpage, logicalsection, pub, pubdate, edition, zone as in 3,Sports,Star,24-Mar-1999,5,N Moving the mouse pointer over the page information in an insertion slug will cause a "balloon help" window to appear showing the physical and absolute page equivalents of the logical page assignment. In systems configured to show page numbers in relation to the physical page, moving the mouse pointer over the page information in an insertion slug will cause a balloon help window to appear showing the logical and absolute page equivalents of the physical page assignment. The Slug field for insertions is protected; it is preferably filled in by the system and preferably not modified by users. me rea e . s a e e sp ays e me w en a pa cu ar nser on was created. The date and time are displayed using the date configuration specified on the workstation. The Time Created field is protected; it is preferably filled in by the system and preferably not modified by users. Time Modified. This date field displays the time the last component of the insertion was modified. The date and time are displayed using the date configuration specified on the workstation. The Time Modified field is protected; it is preferably filled in by the system and preferably not modified by users. X Position field represents the position on the X axis of the upper left-hand comer of the component. For the insertion, it is the upper left-hand comer of the overall bounding box. This field is protected if the component or insertion is locked by the pagination editor or has a status of Placed or higher. When the story is locked by the pagination editor, only the session holding the lock may change the position. When the status is greater than Placed, the position may only be changed by the pagination editor. Y Position field represents the position on the Y axis of the upper left-hand comer of the component. For the insertion, it is the upper left-hand comer of the overall bounding box. This field is protected if the component or insertion is locked by the pagination editor or has a status of Placed or higher. When the story is locked by the pagination editor, only the session holding the lock may change the position. When the status is greater than Placed, the position may only be changed by the pagination editor. Zone. This field displays the zone in which the insertion is intended to be published. o ica ons o e one e o e nse on necessar y mo y e one ie s o all components it contains. The Zone field is linked to the Publication, Publication Date, Physical Page, Physical Section, Edition, Logical Page, Logical Section and Absolute Page fields in that a modification to the Zone field may result in the entries in the other fields to change to reflect valid publication information. In addition to the zones specified in the Configuration Manager, the Zone field may be set to TBD — "To Be Determined." The Zone field will preferably be protected; zone information for an insertion may be changed by invoking manual commands. Story Attribute Information: In the present invention, stories have an associated header, which essentially is a collection of data fields in which attributes can be user-defined or generated automatically . A story is a collection of insertions. For publication, a single story includes at least one insertion and there is no limit to the number of insertions that may be included in a story. Stories may enter the system by wire services or another third-party authoring mechanism, or, of course, by reporters and editors, or other sources. A story may also be generated by parsing an incoming graphic, splitting its caption information into a discrete database story apart from the image itself. Some examples of preferred header data include : Author. This field displays the login name of the user first responsible for the creation of content for the story. Author differs from creator in that a story may be created by a user who will have nothing to do with the content, as in the case of a pagination user creating stories as part of the page layout process. The Author field is protected; it is preferably filled in by the system and cannot be modified by users. Copy Count. This protected field displays the number of times this story has been copied. It is acceptable for this field to read either "0" or be blank in the headers of componen s w c ave no een cop e . e opy oun e s pro ec e ; s preferably filled in by the system and cannot be modified by users. Cost/Payment.1 This currency-formatted field is used to maintain dollar amounts for payment of free-lancers for a submission or the amount the newspaper will charge to publish the associated content. By default, the story Cost/Payment field is the sum of the Cost/Payment fields of each of the insertions contained in the story. However, the Cost/Payment field is preferably not protected; it may be modified by the system or a user while another user has the content open for edit. Creator. This is the name of the user who created the story. Creator differs from Author in that the author is the first user to be responsible for a story's content. The creator will often be a pagination user designing a page. The Creator field is protected; it is preferably filled in by the system and cannot be modified by users. Cycle Designator. This field is used to indicate the cycle a wire story was transmitted. This information is parsed from the NAA keyword field and are typically either AM-, PM- or BC-. This field is normally left blank on stories not generated by wire services. The Cycle Designator field is preferably not protected; it may be modified by an authorized user at any time. Deadline Date and Time. Content for this protected date and time field will be derived from the story's insertion with the latest deadline. The Deadline Date and Time field is protected; it is preferably filled in by the system and cannot be modified by users Editor. This protected field displays the login name of the last user to edit the content of any components belonging to an insertion assigned to the story. The Editor field is protected; it is preferably filled in by the system and cannot be modified by users. or a a u . s e s us n wes o u insertion belonging to the story. The Editorial Status field is protected; it is preferably filled in by the system and cannot be modified by users. Feature Modifier. This field is used to specify information generated by the Con- figuration Manager to indicate that the story must be position relative to another editorial or advertising story. The Feature Modifier field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Internal Reference Number. Every story in the database will receive an internal reference number, distinguishing it from other stories. Though multiple versions of a story may share the same internal reference number (allowing the system to identify two modifications of a story as being related even though the other header information and text may differ considerably), no two different stories in the database may share the same internal reference number. The Internal Reference Number will be inserted into a field. The Internal Reference Number is protected; it is preferably filled in by the system and cannot be modified by users. Internet Status. This field is used to indicate the "lowest" Internet Status of an insertion belonging to the story. The Internet Status field is protected; it is preferably filled in by the system and cannot be modified by users. Keywords. This unprotected field displays keywords assigned to the story. The Keywords field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Locked By. The name of the user who currently has the story locked. When a user locks the story, all insertions and components it includes are also locked. Any components a rea y opene or e ng w en e user a emp s o open e s ory w e open read-only mode and, if the user has edit rights in the queues where the locked components reside, he or she will be given the option of "taking a number," which indicates to the system that the lock should be cascaded when the story is unlocked by the previous user. The Locked By field is protected; it is preferably filled in by the system and cannot be modified by users. Locked By Workstation ID. This field will be used for the storage of the workstation ID where the story is locked. If the story is not locked, the field will be blank. The Locked By Workstation ID field is protected; it is preferably filled in by the system and cannot be modified by users. Makeup Date. This unprotected date field displays the date in which the story should go into the production process. To streamline the entry of information into this field, a calendar combo box will be associated with this field. The date is displayed using the date configuration specified on the workstation. The Makeup Date field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Original Slug. This field displays the slug originally assigned to the story. Incoming wire stories will be named using the fields that correspond to the NAA and IPTC keyword entries. The Original Slug field is protected; it is preferably filled in by the system and is preferably not modified by users. Pagination Status. This field is used to indicate the "lowest" Pagination Status of an insertion belonging to the story. The Pagination Status field is protected; it is preferably filled in by the system and cannot be modified by users. Optionally, the cycle designator will be stripped from the slug. Note that because wire services u y y- wor s, com o o es w e same s ug w ex single queue. Parent Internal ID. A unique ID of the parent story to allow a user to trace back from the child. In the case of stories, the parent internal ID would refer to the internal ID of the story used as the source of the current story. The Parent Internal ID field is protected; it is preferably filled in by the system and is preferably not modified by users. Preferably, no validation of the Parent Internal ID field will occur. Thus, if a story's parent has been removed from the database, the Parent Internal ID field may include the ID of a story that no longer exists in the system database. Previous Editorial Status. This field is used to indicate the previous Editorial Status of a component belonging to the insertion. The Previous Editorial Status field is protected; it is preferably filled in by the system and cannot be modified by users. Previous Internet Status. This field is used to indicate the previous Internet Status of an insertion belonging to the story. The Previous Internet Status field is protected; it is preferably filled in by the system and cannot be modified by users. Previous Pagination Status. This field is used to indicate the previous Pagination Status of an insertion belonging to the story. The Previous Pagination Status field is protected; it is preferably filled in by the system and cannot be modified by users. Priority. This field displays information obtained from the Priority field in the standard NAA wire service header for the story. The priority field is unique in that sorts of the field are not necessarily alphabetical. In the United States for example, the priority field would be sorted in the following order: F (flash), B (bulletin), U (urgent), R (regular), D (deferred), H (hold), S (Sunday). The sort order of the priority field is validated against a configuration file maintained in the database. The Priority e s pre era y no pro ec e ; may e mo ie y t e system or an aut or ze user while another user has the content open for edit. Responsibility. This field displays the login name of the user responsible for ensuring that the production of this story takes place successfully. The Responsibility field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Responsible Department or Desk. This field displays the name of the department or desk responsible for ensuring that the production of this story takes place successfully. The Responsible Department or Desk field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Slug. This field contains the slug of the story. For incoming wire material, the key- word field of the NAA 1312 specification or IPTC header equivalent will be used as the name; duplicates will be allowed. Story Slug fields are preferably unprotected. Valid characters for slugs include upper- and lower-case letters A to Z, numbers zero to nine, the period, comma, spaces, hyphens and underscores. Time Created. This date field displays the time when a particular story was created. The date and time are displayed using the date configuration specified on the workstation. The Time Created field is protected; it is preferably filled in by the system and preferably not modified by users. Time Modified. This date field displays the time any component or insertion of a story was modified. The date and time are displayed using the date configuration spec ie on t e wor staton. e me o ie e s protecte ; t s preera y filled in by the system and preferably not modified by users. Wire Reference Number. This field displays the contents of the NAA Slug field. The Wire Reference Number field is protected; it is preferably filled in by the system and is preferably not modified by users.

In the present invention, packages have an associated header, which essentially is a collection of data fields in which attributes can be user-defined or generated automatically . A package defines a mechanism by which stories are defined and how stories are tracked throughout the entire process: from inception to final destination. Packages are the preferred mechanism for workflow management of the present invention. Some examples of preferred header data include: Author. This field displays the login name of the user responsible for the creation of a package. Author differs from creator in that a story may be created by a user who will have nothing to do with the content, as in the case of a pagination user creating components as part of the page layout process or of a desk editor creating story assignments prior to the creation of page layouts. The name of the user who first modifies the content is the author. The Author field is protected; it is preferably filled in by the system and cannot be modified by users. Category. Editors may enter category information pertaining to the package in this field. The Category field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Copy Count. This protected field displays the number of times the package has been copied. It is acceptable for this field to read either "0" or to be blank in the headers of pack-ages which have not yet been copied. The Copy Count field is protected; it is preferably filled in by the system and cannot be modified by users. Creator. This is the name of the user who created a package. Creator differs from Author in that the author is the first user to be responsible for a story's content — the first user to modify a component's text, for example. The creator will often be a pagination user designing a page or an editor assigning stories to his or her reporters. e rea or e s pro ec e ; s pre era y i e n y e sys em an canno e modified by users. Editor. This protected field displays the login name of the last user to edit the package. In instances where a user creates, edits, then stores a newly-created package, the same login name will appear in the Author, Creator and Editor package header fields. The Editor field is protected; it is preferably filled in by the system and cannot be modified by users. Feature Modifier. This field is used to specify information generated by the Configuration Manager to indicate that the story must be position relative to another editorial or advertising story. The Feature Modifier field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. It is anticipated that entries in the Feature Modifier field will be generated by display advertisement placement programs via, for example, an interface API. Internal Reference Number. Every story in the database will receive an internal reference number, distinguishing it from other stories. Though multiple versions of an element may share the same internal reference number (allowing the system to identify two modifications of a story as being related even though the other header information and text may differ considerably), no two different stories in the database may share the same internal reference number. The Internal Reference Number will be inserted into a field. The Internal Reference Number is protected; it is preferably filled in by the system and cannot be modified by users. Keywords. This unprotected field displays keywords assigned to the package. The Keywords field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. r g na ug. s e sp ays e s ug o g na y ass gne to t e pac age. e stories, packages are one of the few types of stories where the user generates the slug. The Original Name field is protected; it is preferably filled in by the system and is preferably not modified by users. Parent Internal ID. A unique ID of the parent story to allow a user to trace back from the child. In the case of packages, the parent internal ID would refer to the internal ID of the package used as the source of the current package. The Parent Internal ID field is protected; it is preferably filled in by the system and is preferably not modified by users. Parent Slug. This field displays the slug of the package from which the current pack- age was copied. The Parent Name field is protected; it is preferably filled in by the system and is preferably not modified by users. Priority. This priority field is unique in that sorts of the field are not necessarily alphabetical. In the United States for example, the priority field would be sorted in the following order: F (flash), B (bulletin), U (urgent), R (regular), D (deferred), H (hold), S (Sunday). The sort order of the priority field is validated against a configuration file maintained in the database. The Priority field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Responsibility. This field displays the login name of the user responsible for ensuring that the production of this package takes place successfully. The Responsibility field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Responsible Department or Desk. This field displays the name of the department or desk responsible for ensuring that the production of this package takes place successfully. The Responsible Department or Desk field is preferably not protected; it may be modified by the system or an authorized user while another user has the content open for edit. Slug. This field contains the slug of the package. The Slug field is preferably unprotected with packages. Time Created. This date field displays the time when a package was created. The date and time are displayed using the date configuration specified on the workstation. The Time Created field is protected; it is preferably filled in by the system and preferably not modified by users. Time Modified. This date field displays the time the most-recently modified component was stored back to the database. The date and time are displayed using the date configuration specified on the workstation. The Time Modified field is protected; it is preferably filled in by the system and preferably not modified by users.

Claims

CLAIM 1. A data management and editorial system, comprising: a central database for storing at least one publishable story, said story comprising data content and at least one insertion related to said data content, said insertion including one or more attributes related to said data content wherein at least one attribute defines a destination for said content, said central database being adapted to relate the content and insertions of said story in a unified data structure to permit said insertions and/or content of said story to be viewed and/or edited.

2. A system as claimed in claim 1, wherein said publishable story includes a publishable event for a print medium, broadcast medium or Internet medium.

3. A system as claimed in claim 1, wherein said content includes text, graphics, video and/or audio data that is computer readable/transmittable.

4. A system as claimed in claim 1, further comprising an a priori database which is used to define preset data related to said story, insertion, and/or content.

5. A system as claimed in claim 1 , wherein each instance of said content being given an associated content header, wherein said header includes data fields related to the format of said content, wherein at least one of said data fields being used to associate said content with at least one said insertion.

6. A system as claimed in claim 5, wherein certain said data fields being generated automatically by said system.

7. A system as claimed in claim 5, wherein certain said data fields being supplied by a user.

8. A system as claimed in claim 1 , wherein at least one instance of said insertion being given an associated insertion header, wherein said insertion header includes data e s re ate to e es na on o sa content, w ere n at east one o sa ata e s being used to associate said insertion with at least one instance of said content.

9. A system as claimed in claim 8, wherein certain said data fields being generated automatically by said system.

10. A system as claimed in claim 8, wherein certain said data fields being supplied by a user.

11. A system as claimed in claim 1 , wherein at least one instance of said story being given an associated story header, wherein said story header includes data fields related to the content and insertions associated with said story.

12. A system as claimed in claim 11 , wherein certain said data fields being generated automatically by said system.

13. A system as claimed in claim 11 , wherein certain said data fields being supplied by a user.

14. A system as claimed in claim 1, further comprising a user interface to permit a user to create and/or edit said story, insertion and/or content.

15. A system as claimed in claim 1 , wherein at least one new instance of said content being given an insertion to define at least the destination of said new instance of said content.

16. A system as claimed in claim 1, wherein said destination includes publication, publication medium, publication zone, publication date and/or publication edition for said content.

17. A system as claimed in claim 1, wherein said central database permitting said content to be edited and defined in another insertion.

18. A system as claimed in claim 1, wherein said central database defining a link between at least two instances of said content between separate insertions, and w ere n an e ng c ange n one ns ance o sa n e con en e ng au oma ca y updated in all linked content.

19. A system as claimed in claim 1, wherein said central database defining a link between certain insertions and related content and being adapted to globally update changes in a linked insertion to all other linked insertions.

20. A system as claimed in claim 4, wherein a story, content or insertion created by a user of said system being checked against said a priori database to determine if any preset rules exist for said story, insertion and/or content.

21. A system as claimed in claim 4, wherein said preset data includes data related to users of said system, groups of said users of said system, default parameters of publishable events, and/or restrictions placed upon said users, said groups, and /or said publishable events.

22. A system as claimed in claim 4, wherein said preset data includes data defining the layout of publishable events and/or common pages between publishable events. 23. A system as claimed in claim 1, further comprising a communications manager to permit external content data to be updated into the central database from an external source.

23. A system as claimed in claim 1 , further comprising an output manager being adapted to gather one or more stories, insertions and content for a given publication, publication medium, publication zone, publication date and/or publication edition and paginate said content for said publication, publication medium, publication zone, publication date and/or publication edition based on user-defined and/or preset pagination criteria, and being adapted to output said content for said publication, pu ca on me um, pu ca on zone, pu ca on a e an or pu ca on e on n a preset format.

24. A system as claimed in claim 1, further comprising a pagination interface to permit a user to paginate said content and defining said pagination data in said content and said insertion for that content.

25. A system as claimed in claim 1 , wherein each said insertion comprises a plurality of different content.

26. A system as claimed in claim 1, wherein said central database includes database translators to permit a user to translate said story, insertion and content into a preset database language.

27. A system as claimed in claim 1 , said system being adapted to permit a user to monitor one or more said stories, content and insertion from creation to said destination, and permitting each said story, insertion and/or content to be viewed and modified from creation to said destination.

28. A data management and editorial system for the production and management of publishable events, comprising: a central database for storing at least one publishable story, said story comprising data content and at least one insertion related to said data content, said insertion including one or more attributes related to said data content wherein at least one attribute defines a destination for said content, wherein a single copy of said content being defined by separate insertions to appear in a plurality of separate publishable events, wherein said database linking at least two said instances of said single copy of said content and updating changes in said content to all linked instances of said content.

. sys em as c a me n c a m , w ere n sa pu s a e event nc u es those instances where content is to be placed into a defined publication, publication medium, publication zone, publication date and/or publication edition. 30. A system as claimed in claim 28, wherein said publishable event includes an instance where content is destined for a print medium, broadcast medium or Internet medium. 31. A system as claimed in claim 28, wherein said content includes text, graphics, video and/or audio data that is computer readable/transmittable. 32. A system as claimed in claim 28, wherein said system further comprising an a priori database which is used to define preset data related to said story, insertion, and/or content. 33. A system as claimed in claim 28, wherein at least one instance of said content being given an associated content header, wherein said header includes data fields related to the format of said content, wherein at least one of said data fields being used to associate said content with at least one said insertion. 34. A system as claimed in claim 33, wherein certain said data fields being generated automatically by said system. 35. A system as claimed in claim 33, wherein certain said data fields being supplied by a user. 36. A system as claimed in claim 28, wherein at least one instance of said insertion being given an associated insertion header, wherein said insertion header includes data fields related to the destination of said content, wherein at least one of said data fields being used to associate said insertion with at least one instance of said content.

. sys em as c a me n c a m , w ere n ce a n sa ata e s e ng generated automatically by said system. 38. A system as claimed in claim 36, wherein certain said data fields being supplied by a user. 39. A system as claimed in claim 28, wherein at least one instance of said story being given an associated story header, wherein said story header includes data fields related to the content and insertions associated with said story. 40. A system as claimed in claim 39, wherein certain said data fields being generated automatically by said system. 41. A system as claimed in claim 39, wherein certain said data fields being supplied by a user. 42. A system as claimed in claim 28, further comprising a user interface to permit a user to create and/or edit said story, insertion and/or content. 43. A system as claimed in claim 32, wherein at least one story, content or insertion created by a user of said system being compared to said a priori database to determine if any preset mles exist for said story, insertion and/or content. 44. A system as claimed in claim 32, wherein said preset data includes data related to users of said system, groups of said users of said system, default parameters of publishable events, and/or restrictions placed upon said users, said groups, and /or said publishable events. 45. A system as claimed in claim 32, wherein said preset data includes data defining the layout of publishable events and/or common pages between publishable events.

. sys em as c a me n c a m , u er compr s ng a commun ca ons manager to permit external content data to be input into the central database from an external source. 47. A system as claimed in claim 28, further comprising an output manager being adapted to gather one or more stories, insertions and content for a given publication, publication medium, publication zone, publication date and/or publication edition and paginate said content for said publication, publication medium, publication zone, publication date and/or publication edition based on user-defined and/or preset pagination criteria, and being adapted to output said content for said publication, publication medium, publication zone, publication date and/or publication edition in a preset format. 48. A system as claimed in claim 28, further comprising a pagination interface to permit a user to paginate said content and defining said pagination data in said content and said insertion for that content. 49. A system as claimed in claim 28, wherein each said insertion comprises a plurality of different content. 50. A system as claimed in claim 28, wherein said central database includes a database translator to permit a user to translate said story, insertion and content into a preset database language. 51. A system as claimed in claim 28, said system being adapted to permit a user to monitor one or more said stories, content and insertion from creation to said destination, and permitting said story, insertion and/or component to be viewed and modified from creation to said destination. 52. An data management and editorial system for the production and management of publishable events, comprising: a central database for storing at least one s a e s o , ry p on en an a p ura y o nser ons related to said content, each said insertions including one or more attributes related to said data content wherein at least one attribute defines a destination for said content, said central database also for storing at least one common page data which defines content that is to appear substantially the same on a given page in multiple destinations, wherein all said insertions that define a destination that is part of a common page being linked together and updating changes in one linked insertion with other linked insertions. 53. A system as claimed in claim 52, wherein said publishable event includes those instances where content is to be placed into a publication, publication medium, publication zone, publication date and/or publication edition. 54. A system as claimed in claim 52, wherein said publishable event includes an instance where content is destined for a print medium, broadcast medium or Internet medium. 55. A system as claimed in claim 52, wherein said wherein said content includes text, graphics, video and/or audio data that is computer readable/transmittable. 56. A system as claimed in claim 52, wherein said central database further comprising an a priori database which is used to define preset data related to said story, insertion, and/or content. 57. A system as claimed in claim 52, wherein at least one instance of said content being given an associated content header, wherein said header includes data fields related to the format of said content, wherein at least one of said data fields being used to associate said content with at least one said insertion. 58. A system as claimed in claim 57, wherein certain said data fields being generated automatically by said system.

. sys em as c a me n c a m , w ere n ce a n sa a a ie s e ng supplied by a user. 60. A system as claimed in claim 52, wherein at least one instance of said insertion being given an associated insertion header, wherein said insertion header includes data fields related to the destination of said content, wherein at least one of said data fields being used to associate said insertion with at least one instance of said content. 61. A system as claimed in claim 60, wherein certain said data fields being generated automatically by said system. 62. A system as claimed in claim 60, wherein certain said data fields being supplied by a user. 63. A system as claimed in claim 52 , wherein at least one instance of said story being given an associated story header, wherein said story header includes data fields related to the content and insertions associated with said story. 64. A system as claimed in claim 63, wherein certain said data fields being generated automatically by said system. 65. A system as claimed in claim 63, wherein certain said data fields being supplied by a user. 66. A system as claimed in claim 52, further comprising a user interface to permit a user to create and/or edit said story, insertion and/or content. 67. A system as claimed in claim 56, wherein a story, content or insertion created by a user of said system being compared to said a priori database to determine if any preset mles exist for said story, insertion and/or content. 68. A system as claimed in claim 67, wherein said preset data includes data related to users of said system, groups of said users of said system, default parameters of pu s a e even s, an or res c ons p ace upon sa users, sa groups, an or said publishable events. 69. A system as claimed in claim 67, wherein said preset mles includes data defining the layout of publishable events and/or common pages between publishable events. 70. A system as claimed in claim 52, further comprising a communications manager to permit external content data to be input into the central database from an external source. 71. A system as claimed in claim 52, further comprising an output manager being adapted to gather one or more stories, insertions and content for a given publication, publication medium, publication zone, publication date and/or publication edition and paginate said content for said publication, publication medium, publication zone, publication date and/or publication edition based on user-defined and/or preset pagination criteria, and being adapted to output said content for said publication, publication medium, publication zone, publication date and/or publication edition in a preset format. 72. A system as claimed in claim 52, further comprising a pagination interface to permit a user to paginate said content and defining said pagination data in said content and said insertion for that content. 73. A system as claimed in claim 52, wherein at least one said linked insertion comprises a plurality of different content. 74. A system as claimed in claim 52, wherein said central database includes a database translator to permit a user to translate said story, insertion and content into a preset database language.

. sys em as c a me n c a m , sa system e ng a apte o perm a user to monitor one or more said stories, content and insertion from creation to said destination, and permitting said story, insertion and/or content to be viewed and modified from creation to said destination. 76. A method of creating a publishable story, comprising the steps of: creating one or more content items related to a publishable event; creating at least one insertion for said content items, said insertion including attribute data including destination data to direct said content to a specified destination; associating two or more said content items and two or more said insertions related to said publishable story to form a unified data stmcture; and storing said content items, insertions and associations on a database. 77. A method as claimed in claim 76, further comprising the steps of linking one or more of said content items and creating additional insertions for each said linked content item, wherein additional instances of a linked content are provided in said additional insertions and wherein a change in one linked content item is automatically applied to all linked content items. 78. A method as claimed in claim 76, further comprising the steps of determining if common page mles exist and linking two or more insertions whose content appears on common pages. 79. A method as claimed in claim 76, further comprising the steps of establishing an a priori database of preset mles and predefined data and comparing one or more instances of said content and insertions to said a priori database to determine if said content or said insertions violates said preset mles or predefined data.

. me o as c a me n c a m , ur er comp s ng e s eps o group ng wo or more insertions and content items destined for a given publication, publication medium, publication zone, publication date, or publication edition and outputting said grouping to said destination. 81. A method as claimed in claim 76, further comprising the steps of paginating said content for a specific publication, publication medium, publication zone, publication date, or publication edition. 82. A system as claimed in claim 28, wherein said destination includes publication, publication medium, publication zone, publication date and/or publication edition for said content. 83. A system as claimed in claim 28, wherein said central database permitting said content to be edited and defined in another insertion. 84. A system as claimed in claim 52, wherein said destination includes publication, publication medium, publication zone, publication date and/or publication edition for said content. 85. A system as claimed in claim 52, wherein said central database permitting said content to be edited and defined in another insertion. 86. A system as claimed in claim 52, wherein said central database defining a link between like content between separate insertions, and wherein an editing change in one instance of said linked content being automatically updated in linked content. 87. A system as claimed in claim 28, wherein said central database defining a link between certain insertions and related content and being adapted to globally update changes in a linked insertion to other linked insertions. 88. A method of creating a publishable story, comprising the steps of: creating one or more content items related to a publishable event; crea ng a eas one nse on or sa con ent tems, sa nse on nc u ng attribute data including destination data to direct said content to a specified destination; creating separate instances of a single copy of said content item and linking at least two instances of said single copy of said content item defined by said insertions; updating changes in said single copy of said content item to other linked instances of said content item; associating two or more said content items and two or more said insertions related to said publishable story to form a unified data stmcture; and storing said content items, insertions and associations on a database. 89. A method as claimed in claim 88, further comprising the steps of determining if common page mles exist and linking two or more insertions whose content appears on common pages. 91. A method as claimed in claim 88, further comprising the steps of establishing an a priori database of preset mles and predefined data and comparing said content and insertions to said a priori database to determine if said content or said insertions violates said preset mles or predefined data. 92. A method as claimed in claim 88, further comprising the steps of grouping two or more insertions and content items destined for a given publication, publication medium, publication zone, publication date, or publication edition and outputting said grouping to said destination. 93. A method as claimed in claim 88, further comprising the steps of paginating said content for a specific publication, publication medium, publication zone, publication date, or publication edition. 94. A method of creating a publishable story, comprising the steps of: crea ng one or more con en ems re a e o a pu s a e even ; creating at least one insertion for said content items, said insertion including attribute data including destination data to direct said content to a specified destination; determining if common page rales exist and linking insertions whose content appears on common pages. associating two or more said content items and two or more said insertions related to said publishable story to form a single, unified data stmcture; and storing said content items, insertions and associations on a database. 95. A method as claimed in claim 94, further comprising the steps of linking one or more of said content items and creating additional insertions for each said linked content item, wherein additional instances of a linked content are provided in said additional insertions and wherein a change in one linked content item is automatically applied to linked content items. 96. A method as claimed in claim 94, further comprising the steps of establishing an a priori database of preset rules and predefined data and comparing said content and insertions to said a priori database to determine if said content or said insertions violates said preset mles or predefined data. 97. A method as claimed in claim 94, further comprising the steps of grouping two or more insertions and content items destined for a given publication, publication medium, publication zone, publication date, or publication edition and outputting said grouping to said destination. 98. A method as claimed in claim 94, further comprising the steps of paginating said content for a specific publication, publication medium, publication zone, publication date, or publication edition.