Re: [xml-dev] XML Schema as a data modeling tool

What do you do with an Enterprise ready data model? �Anything and everything you want to do with the given data domains in the given Enterprise! �By definition, the model is good to go for any task you throw at it and requires no more manipulation. At the implementation level you should be able to export to XSD or DDL or WSDL or whatever to the extent that the domain you're modelling makes sense for one of those implementations�(though maybe not automagically, that's dependant on your tool set).

If you don't know the basics of what makes up a graph then a couple of hours with Google will dig up enough Academic resources to keep you busy for however long you may wish to devote to the topic (lifetimes included). �Vertices and edges are common terminology for the abstract representations, nodes tend to show up more on the implementation side. �Graphs are mathematical models, they are often represented with circles and arcs or squares and straight line connectors, but they aren't constrained to look like anything any more than the number 1 (one) is...

Peter Hunsberger

On Thu, Oct 3, 2013 at 12:40 AM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

Wonderful, Peter, I think we are advancing towards a common understanding of the alternative modeling goals and means.

I still wrestle with your posting, trying to understand more clearly what to *do* with an Enterprise-ready model. You wrote:

"A model is Enterprise ready if it applies to all instances of a given set of data domains at all the points in time they are used within a set of applications."

But what does it mean that a model APPLIES TO A DATA DOMAIN? How to decide whether it applies? Given the preoccupation with a particular data domain and a set of applications, say, relational databases and web services - what shall I do with the Enterprise-ready model, how shall I profit from it?

Let me define in an adhoc way some features which a model may have or not and which characterize its intended usage. Perhaps you can (a) add further features as necessary, and (b) make ticks to indicate which of these features an Enterprise-ready model has?

Feature - meaning
==================
Feature "operational" - supports the export of operational data (e.g. a query system, an OO persistence store)
Feature "conceptual" - supports the export of non-operational, conceptual information (whiteboarding ...)
Feature "generative" - supports the generation of other models (e.g. an operational model; generation may be automatic, semi- or non-automatic)
Feature "transmittable" - supports the construction of messages to be exchanged by program agents
Feature "?"
Feature "?"
Feature "?"

(And how about NIEM, how about MLHIM?)

Your iPhones example makes me wonder if the Enterprise-ready model is meant to be operational, too?

The forest-shaped reference model which I advocate is in the first place generative (!), meant to support the design of database and message models; but could it conceivable allow the generation of an Enterprise-ready model, too?

Kind regards,
Hans-Juergen

PS: Can you also say a word about the basic building blocks of which the graph model you are talking about is composed, is it "nodes", "edges" and "something else", and how is a "node" constrained to look, how an edge, how a something else?

Von: Peter Hunsberger <peter.hunsberger@gmail.com>
An: Hans-Juergen Rennau <hrennau@yahoo.de>
CC: Michael Kay <mike@saxonica.com>; "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 16:39 Mittwoch, 2.Oktober 2013

Betreff: Re: [xml-dev] XML Schema as a data modeling tool

I've sort of implied a difference between "Enterprise" models and what I'll call instance models. �I'd say a model is Enterprise ready if it applies to all instances of a given set of data domains at all the points in time they are used within a set of applications (Enterprise would be better but is not always achievable). �I'll qualify this by saying that even across applications such a thing rarely exists, the drive towards having a Master Data Model (MDM) can help, but doesn't necessarily result in such a beast.