[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: FpML-AWG View generation syntax




Dear Brian and AWG -

You identified three characteristics that distinguish the Master Schema from a conceptual model. IMHO all three characteristics do not preclude the Master Schema being a conceptual model. Each of those three characteristics may be a characteristic of a conceptual model.

Annotations are normal - There are differences between the Master Schema and a typical conceptual model but the use of annotations is not one of them. The decoration of a conceptual model with annotations for view-specific models is a normal usage of a conceptual model. Annotating a conceptual model with annotations does not stop it being a conceptual model, it simply makes it annotated. Annotation is a usage rather than a characteristic of a conceptual model. IMHO the use of annotations does not preclude thinking about the Master Schema as a conceptual model.

Cardinality is reasonable - It is entirely reasonable to add default cardinalities to a conceptual model, as you have done. Certainly the OMG supports cardinality in its MDA definition of CIM conceptual models. A conceptual model in W3C XSD might have cardinality present, and one in W3C OWL probably wouldn't. My experience is that cardinality is often omitted from a conceptual model due to a combination of either a set based ontology technology  that doesn't do cardinality well and because the conceptual model may also be more abstract. IMHO the use of default cardinalities does not preclude thinking about the Master Schema as a conceptual model.

Types are bog-standard - It is bog-standard to included types such as "specific (default) data types (including things like facets, restrictions, etc.) of all elements" in a conceptual model. Once you get beyond names and terms, type descriptions are normally the next thing to be added. IMHO the inclusion of types is an essential part of a conceptual model.


The point I was making is that "If it walks like a duck and quacks like a duck, I would call it a duck." We use the Master Schema as a conceptual model to generate view-specific schemas, and it has the characteristics of a conceptual model. Ducks come in many shapes, sizes, and colours and in the same way conceptual models differ from each other, but they are all still conceptual models.

I would call it a duck.

Matthew Rawlings
+44 7917 596 827



"Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Sent by: awg@xxxxxxxx

28/12/2007 15:25

Please respond to
awg@xxxxxxxx

To
<awg@xxxxxxxx>
cc
Subject
RE: FW: FpML-AWG View generation syntax





I agree that the view generation shares some characteristics of the conceptual-logical modeling transformation.  However, the master schema does in fact contain (default) cardinalities.  It also specifically defines the specific (default) data types (including things like facets, restrictions, etc.) of all elements.  It also contains annotations that allow all of the view-specific schemas to be generated without any further information.  It seems to me that all of these things make the master schema different from a normal conceptual model, and more like a superset as Tony describes.  Certainly the master schema wasn't intended as a conceptual model.

Brian

-----Original Message-----
From: awg@xxxxxxxx [mailto:awg@xxxxxxxx] On Behalf Of Anthony B. Coates (Miley Watts)
Sent: Thursday, December 20, 2007 6:57 AM
To: awg@xxxxxxxx
Subject: Re: FW: FpML-AWG View generation syntax

I agree that we should copy standard terminology, but I don't believe that  
"conceptual model" is appropriate here.  There is nothing very conceptual  
about the master Schemas.  If anything, they are superset Schemas, and I  
think it is better described as that.  They are no more "logical" or  
"conceptual" than any of the individual view Schemas, they are just  
broader in scope.

Cheers, Tony.

On Thu, 20 Dec 2007 02:29:17 -0000, <matthew.d.rawlings@xxxxxxxxxxxx>  
wrote:

> I suggest the document adopts standard modelling terminology:
> The 'master schema' is a Conceptual Model. Its perspective or view is the
> global context.
> Each 'view' is a Context and its resulting schema is a Logical Model. Its
> perspective or view is a local context.
>
> It is common in conceptual modelling to leave the  
> cardinality/multiplicity
> of Properties (elements, attributes, references) undefined. The
> cardinality is added in during the transformation from the Conceptual
> Model to the Logical Model - i.e. the 'view' generation process adds
> cardinalities for the first time. This for example is what ISO20022 does
> in the generation of the local views (Message Layer) from its global view
> (Business Layer).
>
> It is also common in conceptual modelling to localize names of classes  
> and
> properties in the transformation to the Logical Model (local context
> views). I suggest that as this is such a common operation this be
> supported explicitly.
>
> Matthew Rawlings
> +44 7917 596

--
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),  
UN/CEFACT, MDDL, FpML, UBL.
http://www.mileywatts.com/
-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe awg youremail@address
To view archives: http://www.fpml.org/_wgmail/_awgmail/threads.html



-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe awg youremail@address
To view archives: http://www.fpml.org/_wgmail/_awgmail/threads.html


This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.