[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: There is a meaning, but it's not in the data alone

• To: gtn@r...
• Subject: Re: There is a meaning, but it's not in the data alone
• From: Pete Kirkham <pete.kirkham@b...>
• Date: Thu, 24 Jan 2002 13:47:25 +0000
• Cc: xml-dev@l...

gtn@r...
>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.
********************************************************************

• Prev by Date: RE: Strategies for a lowly XML document
• Next by Date: RE: There is a meaning, but it's not in the data alone
• Previous by thread: Re: There is a meaning, but it's not in the data alone
• Next by thread: RE: There is a meaning, but it's not in the data alone
• Index(es):
  • Date
  • Thread