Subject: Environmental Aspects of Object Management
From: Carla Shafer (cshafer@munex.net)
Date: Sat 19 Feb 2000 - 23:34:15 MET
From: "Carla Shafer" <cshafer@munex.net> Subject: Environmental Aspects of Object Management Date: Sun, 20 Feb 2000 11:34:15 +1300
List address to send message to everyone: ifets-discuss@LISTSERV.READADP.COM
Details of current discussion: http://ifets.ieee.org/discussions/discuss.html
---------------------------------------------------------------------------
I'm a consultant, and was recently called by a client to review a large
educational resource repository project, which led me to this discussion.
My research area for the past several years has focused on developing an
"environmental modeling" process -- which I'll explain in a moment -- to
address problems inherent in the prevailing data and object modeling
approaches. While I'm here temporarily, I'd like to present for
consideration three environmental modeling patterns and suggest how their
use might enhance the LO proposal.
As we all know, the processes involved in teaching and learning encompass
huge variation in both praxis and theory. This is due in part to the hoary
age of the discipline, and in part to the wide range of environments in
which education takes place. This situation is very different from the
comparatively consistent environments in which application programming is
performed. Consequently, the task of proposing an LO model is much more
complicated than, say, developing the UML (Unified Modeling Language).
Counter intuitively, perhaps, one way to get a handle on the complexity of
this task might be to broaden the project.
To demonstrate this approach, the following paragraphs explore the
possibility of combining the object modeling process with a traditional
normalized data model, framed by a common "pattern repository"
architecture. I describe the result as an "environmental model." Systems
implementing the model are characterized by a very stable infrastructure
that in itself is free of both content and social values. Yet, because
content development is integrated right into the model, the outcome in
practice is a rich eco-system of ever-changing problem-solution,
subject-object relationships that reflect the content and values of system
users. Here are the key concepts:
Pattern 1) An object or data model should reflect reality, not require
reality to conform to it.
Pattern 1 might be restated for the LO project as: you don't want to write
rules defining what an object is, and then require producers and users of
educational materials to conform. An object model, to be useful, needs to
be a very permanent, stable thing. Reality, on the other hand, is neither
stable nor permanent. You especially don't want your rules to be dependent
on the existence of a particular technology. (Will Java be the modus
operandi 20 years from now? Who knows?) This is not to say that an object
model for TCP/IP deliverable applications is not needed. Rather, that a
technology-explicit model needs to be positioned within a larger framework
for which it's presence or absence (should it become obsolete) is not
critical. Here is where granularity is key; you must be self-conscious
about whether you are writing a model that is technology specific (a
learning object model for Java, for example), or a generic learning object
model, which is very broad indeed. (It appears to me that this has not been
clearly addressed in the LO project dialog, nor is it reflected in how the
proposed model is shaping up. Correct me if I'm wrong.)
The only way to start working towards that larger framework is to begin
with an attempt at modeling reality. A first step might be to achieve
consensus on a lexicon that would be so comprehensive that, when
implemented, it would allow users to easily and quickly drill down to a
subset of useful objects -- for any yet-to-be-defined task, in any
yet-to-be-defined operating environment, that plug together in any
yet-to-be-defined way. If this sounds like monumental task, it is. However,
Patterns 2 and 3 begin to show how it might be achieved, and why the effort
would be worthwhile.
Pattern 2) It's not possible to create a sound object model without
considering the environment in which objects interact.
I believe if we were to start by thinking about the teaching/learning
environment, a lot of the issues currently under discussion (granularity,
attributes, etc.) would resolve themselves rather elegantly. To give you an
example of what I mean, I've posted a diagram that I did last year in the
process of developing a model for managing the documentation cycle of
funded projects. I've since applied the model to a number of other projects
with good results.
<http://www.munex.net/cshafer/PROF-model.gif>
What we did in starting this project was to sit down and try to come up
with the most elemental set possible of object/entity relationships
required to replicate a process. We ended up with four Core Entities:
Proposition, Resource, Object, and Fragment. (Hence, the PROF model.)
The center-stage entity in the diagram, is called a "Proposition," a term
drawn from the original subject of the model where it represented a
discrete item in a funding proposal and its relationships to other
Proposition items. However, since the moniker essentially describes an
environmentally qualified action objective, it could just as easily
represent a learning/teaching task, with attributes modified accordingly.
The most distinctive quality of the Proposition is that it has no set
granularity. It is a relational object that can be made up of more granular
child propositions or be part of a larger, even extended, propositional
family. Think of a genealogist trying to construct a large family tree. It
turns out that genealogical relational patterns provide an extremely
flexible way to model many complex structures besides families, especially
when you introduce "personas" that make it possible for objects to take on
tentative relationships, behaving differently in different environments.
*** Optional Technical digression: For example, P/1a "to learn Spanish"
could be a legitimate proposition, and so could the much more granular P/1b
"to learn to conjugate the Spanish verb, to be." Where P/1b is a child of
P/1a. P/2n "to learn to conjugate the French verb, to be." might take on a
"cousin" persona to P/1b, and so on. (See end note for a reference to an
elegant "genealogical" object relationship model.) ***
The Proposition is the hub that creates an operational environment for
itself by drawing on Resources (persons, organizations, or citations) and
Objects (applications, publications, and other physical tools).
The core entity set is completed by Fragments. As the name suggests, these
are fragments of expository material without intrinsic value outside of the
host environment. They reflect how environments are enriched through
interactive participation that produces storable artifacts: ad hoc
commentary, reflection, evaluation and so on.
Finally, the PROF core entities are held together by Roles, which refine
the model by defining the relationships within the schema. (Those of you
who are familiar with data modeling will notice Star Schema qualities here,
and will see that we are approaching a combined data- object-model
solution.) Roles are also the key that unlocks the object model, because
now objects can take on different personas based on their relationship to
the Proposition in question. Objects and Resources may also have Roles that
are independent of the Proposition, defined externally to the environment.
For example, the object is owned, distributed, located, etc. Even though
these Roles may be defined outside of the environment they reside within
it; it is the only place where they have any meaning.
Someone has already mentioned pattern languages in this discussion; I'm
currently exploring what would happen to the PROF model if we substituted
patterns for propositions. This would open the door to a central
educational pattern repository that could provide a rich environment within
which to drill, manage and distribute Learning Objects. It would also
provide the mechanism linking the model to grounded praxis, allowing
teachers and students around the world to participate in defining learning
environments and object roles.
*** Optional Technical Digression: I'm thinking of a repository that could
be distributed, i.e. no need to centralize it. A simple server application
could turn it into an "Internet" of best practices and distributed objects.
Institutions could maintain a controlled internal repository or access
established repositories in the larger network setting. ***
Now, since the environmental model (which must somehow reflect a dynamic
reality, ideally in real time) is determining the roles of objects, we can
focus on getting down to the elemental attributes required to identify an
object. It starts to get a lot simpler because the lexicon basically only
needs to convey intrinsic features: class (it's a book, it's a computer
application, it's a physical object), technical operating requirements
(it's electrical, it's solar, it's Windows98, Mac OS, or Java),
conduit_class (grouping objects designed to plug into each other via a
standardized mechanism), conduit characteristics (if it plugs into other
similar objects, how), and other technical functions. Keep the focus on
what it _does_, not how it's used. You get the idea.
Pattern 3) The Object domain, and the relationships of objects to objects,
should not be defined by the model.
Picture a child in a playroom with a set of Legos and a set of those
little snap-together wooden tracks with cars. The individual Lego blocks
are clearly objects. So are the track segments in the car set. In
classifying these objects we might note that Lego blocks link together
integrally, and track segments link together integrally; we don't see any
interconnectivity options between the two systems. However, like as not,
the child is going to build a town of Lego blocks and use the track set to
supply streets and highways, creating an entire environment that no one
ever imagined.
Moral: make sure that the LO project doesn't limit the environmental
universe of education to Legos. A well constructed environmental schema
will allow new uses and object combinations to evolve organically, will not
preclude technical innovation, will let standards migrate in a natural
pattern that reflects changing educational capacities as well as emerging
technologies. Yet it will still exert pressure to standardize OO
components. Why? Because there will be economic incentive to build objects
that conform to the most common environments, and that can be easily mixed
and matched to form new environments. And because users will be driving the
definition of environments in public space (that's where the little
repository server comes in, but that's another night's work!), successful
environments will diffuse rapidly, while innovation will be quickly
rewarded as producers respond to the demand for new learning objects.
Building a holistic system that encourages demand-driven supply will result
in an energetic and self-regulating LO economy.
In this brief sketch, I've tried to demonstrate how you might construct an
environmental model that combines the longevity and strength of a data
model, the flexibility of an object model, and the reflexivity of grounded
praxis as education moves through what is shaping up to be a period of
intense change and institutional restructuring.
Good luck to all of us!
______________________
REFERENCES:
For more on Pattern Languages, I recommend starting at the Portland Pattern
Repository <http://www.c2.com/cgi/wiki?WikiPagesAboutWhatArePatterns>
For a thorough rethinking of genealogical relationship modeling, as well as
a good environmental modeling example, try immersing yourself in the
GENTECH Genealogical Data Model RFC for a few hours.
<http://www.gentech.org/lexhome.htm>
Carla J. Shafer, President/CEO
Munex, Inc.
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Munex is an Application Service Provider (ASP)
and data warehousing service offering
enterprise-scale applications to municipal
governments across public and private networks.
Find out more at http://www.munex.net
The Municipal Information Exchange
phone: 607 255-6810
cellular: 607 279-6077
fax: 708 575-8658
ICQ: 6262998
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
---------------------------------------------------------
Forum website: http://ifets.ieee.org/
Forum's contact person: kinshuk@massey.ac.nz
Info on Join/Leave List: http://ifets.ieee.org/maillist.html
---------------------------------------------------------
This archive was generated by hypermail 2a24 : Sat 19 Feb 2000 - 23:42:40 MET
