Okay, I see. The VA Fileman model is fairly similar to
what you describe. "Objects" can have any number of
attributes, those attributes may or may not be
references to objects of a give type (or set of
types), atomic values (integers, strings, dates, etc.)
or they may be collections of "sub-objects". In UML
teerminology, this is composition rather than
aggregation: these "sub-objects" may not exist except
as part of a composiite.
Now, in the project I'm currently working on it is
necessary to define mappings between these schemas and
relational tables. This turns out to be fairly
complicated because the data models on either must
satisfy different constraints and semantic
requirements that only make sense at the object level
and above rather than at the attribute level. If I
understand correctly, the protocol used in a lab test
could impose a constraint that doesn't make sense at
the level of individual measurements, but at a higher
level of abstraction. But, again speaking as a layman,
I can't imagine that you'd want to map elements when
the protocols are different, but you might want to
keep track of the degree of "conceptual similarity"
between two results, and constraints requiring that a
specific protocol be used.
Forgive me if I'm just rehashing old territory here.
I've been trying to read the documents posted here as
I have the opportunity, but between work and another
project I'm working on, I'm feeling pretty swamped. On
the other hand, this *is* something that does interest
me. I've been working on using UML as a language to
mofel interfaces between disparate systems, and on a
more academic level, I'm interested in what might be
called "high level patterns" and the extent to which
building conceptual hierarchies allows us to treat
typical problems in a computationally tractable
manner. That was the point of my post on hierarchical
vision and musical structures.
--- Thomas Beale <[EMAIL PROTECTED]> wrote:
>
>
> Greg Woodhouse wrote:
>
> > --- Thomas Beale <[EMAIL PROTECTED]>
> wrote:
> > >
> > > The above trees are pretty much what archetypes
> are
> > > - archetypes are models for
> > > such trees.
> >
> > Hmm...so if I could risk a naive question, would
> it be
> > fair to say that archetypes corresponds to
> > (hierarchies in) semantic networks? There's a
> paper
>
> One archetype is a fairly self-contained formal
> definition of a concept,
> such as "ante-natal exam" or "blood lipids results".
> It's hierarchies
> are not classificaiton hierarchies, but structural
> ones. That is, they
> indicate what the compositional structure of the
> information is, not the
> meaning of each piece. Meanings are defined
> elsewhere - in
> terminologies. The point of archetypes is to define
> models which express
> the constraints on data instances, so as to know
> which instances can
> still be called examples of the model. The
> constraints are statements
> about allowed structure, terms (in particular
> positions), values, types,
> state values and so on.
>
> So a BP archetype gives the structure of a blood
> pressure measurement -
> which is the structure of the information you are
> trying to create. If
> you want the semantic definition of blood pressure,
> which may include
> relationships of various kinds, definitions of I ...
> V sounds, and other
> concepts, look in a terminology like SNOMED. The
> archetype uses these
> definitions, it does not replicate them.
>
> - thomas beale
>
>
=====
Greg Woodhouse
[EMAIL PROTECTED]
When the mind knows, we call it knowledge.
When the heart knows, we call it love.
When the being knows, we call it prayer.
--Anonymous
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
