[
Lists Home |
Date Index |
Thread Index
]
gtn@rbii.com
>The "domain model" as you put it, is roughly equivalent to a
>vocabulary with an associated set of semantics. So long as you agree
>on the terms, you can communicate, and that is the whole point.
The domain model has no fixed language, only semantics.
The abstract information model (what we are going to represent X as) is a viewpoint
on this domain model (what we know about X).
The AIM may be an ontological framework or an EXPRESS or a MOF L1 model (such as a
UML domain model class diagram; UML fudges this a bit by using the same language
for its domain models [which are abstract subsets of the information in a domain,
not models of a whole domain] and for application constructs).
Instances of entities within these abstract models have concrete encodings, some of
which may be XML.
A vocabulary is part of the mapping of an entity to a concrete syntax (this is also
true for natural language, though the domain models for different people are often
inconsistant).
> A learning or training model...
> len
An abstract information model may be used as such, or models which are instances of
the AIM.
Certain models of avionics control systems in XML based CASE systems I've
architected have been able to be queried for requirements and ownership constraints,
instantiated as ADA modules, browsed and summarized for learning purposes, mapped
onto SVG and rendered as pdf, analysed for hazards with multidisciplinary teams in
distributed locations, and analysed for change impacts. Many uses, each
application using a subset of the one information model.
What is important is that to use an XML element of a given namespace you need both
a common information model, and a common encoding of that model into XML. You
can't use the schema, or even a common mapping of schema to data classes, as
coherent business logic is the vital thing. This is not anything special about
XML, it applies to all encodings of information.
If you build systems with the same syntax, as defined in the schema or DTD, then
you can parse this information or present it, and perform syntactic manipulations
on it. This is fine for presenting text, as there are mechanisms to map syntax to
presentation.
If you build systems with different information models, then you cannot have
verifiable communication if they are going to manipulate the information in complex
ways. It is this discovery that inspired STEP to produce a set of abstract
information models, each targetted a a specific domain subset, to underpin the
interchange of CAD data.
If you resolve a namespace into something, then that must contain both a syntax and
a mapping of that syntax to a model to be useful, or you are stuck in text
processing rather than information.
Pete
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
|
