DLXS Classes Overview

From DLXS Documentation

(Difference between revisions)
Jump to: navigation, search
Current revision (17:05, 13 August 2007) (edit) (undo)
 
(4 intermediate revisions not shown.)
Line 1: Line 1:
-
<p>The following "classes" of content form the structure for DLXS work. Some
+
[[DLXS Wiki|Main Page]] > [[Mounting Collections: Class-specific Steps]] > DLXS Classes Overview
-
  history on the rationale behind the class-oriented approach is available below.</p>
+
-
<p>Wrttten in October 28, 2000, by John Price Wilkin:</p>
+
<p>DLXS has four basic data models, which are called "classes" in DLXS:</p>
 +
* Bibliographic
 +
* Finding Aids
 +
* Image
 +
* Text
 +
 
 +
<p>Within these classes, there are further variants of the data models. For instance, TextClass has several data models for journals and monographs.</p>
 +
<p>Some history on the rationale behind the class-oriented approach is available from this,
 +
written in October 2000 by John Price Wilkin:</p>
<blockquote>
<blockquote>
<p><em>In early 1999, DLPS began
<p><em>In early 1999, DLPS began
Line 30: Line 37:
   will continue to be a work in progress.</em></p>
   will continue to be a work in progress.</em></p>
</blockquote>
</blockquote>
-
<p>Since 2000:</p>
 
-
<p>Middleware has evolved using object-oriented Perl to manage the classes and
+
 
-
  implement their behaviors. </p>
+
[[#top|Top]]

Current revision

Main Page > Mounting Collections: Class-specific Steps > DLXS Classes Overview

DLXS has four basic data models, which are called "classes" in DLXS:

  • Bibliographic
  • Finding Aids
  • Image
  • Text

Within these classes, there are further variants of the data models. For instance, TextClass has several data models for journals and monographs.

Some history on the rationale behind the class-oriented approach is available from this, written in October 2000 by John Price Wilkin:

In early 1999, DLPS began formally articulating both "behaviors" for systems and the "classes" of systems to which those behaviors belong. Rather than focus on an abstract set of possible behaviors, we focused instead on behaviors we could identify in the systems we built, as well as behaviors that we wished to develop--i.e., a pragmatic approach. In March, 1999, we began to define the classes of systems using a similar (i.e., pragmatic) approach. Staff were charged with beginning to define and articulate the core classes with the following direction: "Just as behaviors have a very practical manifestation, classes should be just as practically instantiated by a piece of middleware (or at most some group of associated pieces of middleware). The sorts of classes we've been talking about are image objects in Image Services, [texts] (with MOA as an end point in the spectrum), journals, bibliographic materials, and a type of reference work that resembles encyclopedias." Further, we said that we "want to make sure this process is not crippled by deep questions of ontology ... and to make sure that it's a part of our current production strategies and thinking. Things will change, of course, and 'classes' that we think of as unitary and monolithic will begin to break out. (For example: At several points, we have talked about the images in Image Services perhaps breaking out off into a separate category those things that are books or manuscripts.)" (jpw e-mail to staff, March 9, 1999)

Responsibility for work on shaping several of the classes was assigned (e.g., John Weise to the image class, and Chris Powell to the text class), and some work was begun. As before, this pragmatic approach means that the classes will continue to be a work in progress.


Top

Personal tools