Subject: Re: Environmental Aspects of Object Management
From: Clark Quinn (cquinn@knowledgeplanet.com)
Date: Mon 21 Feb 2000 - 00:01:48 MET
Date: Sun, 20 Feb 2000 15:01:48 -0800 From: Clark Quinn <cquinn@knowledgeplanet.com> Subject: Re: Environmental Aspects of Object Management
List address to send message to everyone: ifets-discuss@LISTSERV.READADP.COM
Details of current discussion: http://ifets.ieee.org/discussions/discuss.html
---------------------------------------------------------------------------
>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.
Looking to how OO has advanced from the initial model is an
interesting possibility to find guidance to similarly expand LO's.
I've worried a bit about drawing the metaphor too far, but on the
other hand we should look to diverge before we converge!
>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."
In some ways this reminds me of the new move in software engineering
called Design Patterns (is that what you're referring to as a
"pattern repository"?). Rather than objects, if I understand
correctly, they're more general frameworks of reusable solutions (I
suppose you could build libraries of objects around them).
If so, my guess is that they correspond to teaching philosophies at
the level of
"problem-based learning" or "cognitive apprenticeship". Frameworks
which you then instantiate for the particular audience, topic, etc.
>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.
I can see two ways to interpret this.
One is to say that there are no proper constraints on objects, and my
understanding of OO design says that while there are a number of ways
to make your 'carveup' of the domain into objects, there's sort of a
'natural level' where you get maximum flexibility and maximum
encapsulation (much like Rosch's natural categories). And you do
have to clearly determine your interfaces.
The other way is to interpret what you're saying, and I'll take it as
your meaning, is that you can give guidelines about what constitutes
the characteristics of good objects, and then let the context guide
the settling of constraints into a fit that meets those
characteristics and the domain.
>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.)
Right now, I believe, there's more focus on labelling legacy content,
and I'm advocating looking ahead to what gives us flexibility. How
should we design and tag objects to achieve the best tradeoffs
between development effort and reuse. We will eventually settle into
a good solution, but how much can we anticipate?
And I definitely agree (and it's pretty much generally accepted) that
we aren't looking towards a particular technology for specification,
only for implementations.
>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.
Sounds like a great goal, and that's the focus of several different
efforts (would that there were more coordination).
>Pattern 2) It's not possible to create a sound object model without
>considering the environment in which objects interact.
I think that's why the IEEE/LTSC project has working groups that are
specifying much more than just the tagging scheme.
>Pattern 3) The Object domain, and the relationships of objects to objects,
>should not be defined by the model.
I do think the efforts are working to limit the specification to the
minimum needed for interoperability. Whether they succeed remains to
be seen.
There seems to be a tension between trying to reach your
comprehensive lexicon and not covering too much. It's a non-trivial
effort that is going on, and I'll look more deeply into your
examples. -- Clark
-- Clark Quinn KnowledgePlanet.com (510) 768-2408 cquinn@knowledgeplanet.com--------------------------------------------------------- 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 : Mon 21 Feb 2000 - 01:19:03 MET