ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] FW: Final 3.0 Draft

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Hans Teijgeler" <hans.teijgeler@xxxxxxxxxxx>
Date: Fri, 13 Apr 2007 09:50:55 +0200
Message-id: <002401c77da0$7af38ed0$6c7ba8c0@hans>
Duane,    (01)

Small typo: the link to Section 5.6.2. in line 490 is incorrect, since there
is no section with that number.    (02)

Regards,
Hans    (03)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Duane Nickull
Sent: Friday, April 13, 2007 3:44
To: [ontolog-forum]
Subject: [ontolog-forum] FW: Final 3.0 Draft    (04)

FYI
------ Forwarded Message
From: "Crawford, Mark" <mark.crawford@xxxxxxx>
Date: Thu, 12 Apr 2007 18:35:38 -0700
To: "Stuhec, Gunther" <gunther.stuhec@xxxxxxx>
Cc: <irvchmielewski@xxxxxx>, <alain.chapdaniel@xxxxxxxxxxx>,
<anderst@xxxxxxxxxxxxx>, <andreas.schultz@xxxxxxx>, <Aschoka@xxxxxxxxxxx>,
<bogdanfy@xxxxxxxxxxxxx>, <buchinski.ed@xxxxxxxxxxxxx>,
<debra.cimbala@xxxxxxxxxxxxx>, <dill@xxxxxxxxx>, <diskray@xxxxxxxxxxxxxxxx>,
<edgar.gluck@xxxxxxx>, <F.De_Vos@xxxxxxxxxx>,
<francis.berthomieu@xxxxxxxxxxxxxxxxx>, <frank.vandamme@xxxxxxxxx>,
<fred@xxxxxxxxxxxxx>, <fvuille@xxxxxxxxxxxxx>, <garret.minakawa@xxxxxxxxxx>,
<Gilles.Brandel@xxxxxxx>, <hsedi@xxxxxxxxxxxxx>,
<ivan.bendini@xxxxxxxxxxxxxxxxx>, <james.whittle@xxxxxxxxxxxx>,
<jbarrett@xxxxxxxxxxx>, <jean_luc_champion@xxxxxxxxx>,
<jlsmith@xxxxxxxxxxx>, <john.bezant@xxxxxxxxxxxxxx>,
<kenji.itoh@xxxxxxxxxxxxx>, <klambert@xxxxxxx>, <kris.ketels@xxxxxxxxx>,
<kumarsivaraman@xxxxxxxxxxxxx>, <marianne.khouzam@xxxxxxx>,
<marion.royal@xxxxxxx>, <Michael.Onder@xxxxxxxxxxxx>,
<mollyaanderson@xxxxxxxxx>, <mrowell@xxxxxxxxxxxxxxxxxxxx>,
<nada_reinprecht@xxxxxxxxxxxxx>, <nivezic@xxxxxxxx>,
<olli-pekka.pauna@xxxxxxxxxxxx>, <paula.heilig@xxxxxxxxxxxxx>,
<phruby@xxxxxxxxxxxxx>, <plothian@xxxxxxxxxxxx>, <rachelf@xxxxxxxxxxxxx>,
<sally.m.chan@xxxxxxxxxx>, <serm@xxxxxxxx>, <srudelic@xxxxxxxx>,
<sutterst@xxxxxxxxxxxxxx>, <tripathi@xxxxxxxxxxxxx>, <yavo@xxxxxxxxxxx>,
<yunker@xxxxxxxxxx>, <jim.wilson@xxxxxxx>,
<fabrice.bourge@xxxxxxxxxxxxxxxxx>, Řyvind Aassve <oyvind@xxxxxxxxxxxx>,
Jean-Luc SANSON <jean-luc.sanson@xxxxxx>, <tripathi@xxxxxxxxxxx>, "Dietrich,
Jens (Finanzen) Ref-36" <Jens.Dietrich@xxxxxxxxxxxxxxxxxx>,
<sue.probert@xxxxxxxxxxxxxx>, Stig Korsgaard <STK@xxxxxxxxxxxxxxx>, Duane
Nickull <dnickull@xxxxxxxxx>, Mary Kay Blantz <mblantz@xxxxxxxxxxxxx>,
<Gilman.Daniel@xxxxxxx>, <abcoates@xxxxxxxxxxxxxx>, Gait Boxman
<gait.boxman@xxxxxx>
Conversation: Final 3.0 Draft
Subject: Final 3.0 Draft    (05)

Gunther,    (06)

Attached is the final 3.0 draft for tomorrow.  We need to review 5 examples
and 1 definition before release.    (07)

Kind Regards,    (08)

Mark     (09)




> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@xxxxxxxxx]
> Sent: Tuesday, March 06, 2007 12:56 PM
> To: sue.probert@xxxxxxxxxxxxxx; Stig Korsgaard; Mary Kay Blantz; 
> abcoates@xxxxxxxxxxxxxx; Gait Boxman
> Cc: Stuhec, Gunther; alain.chapdaniel@xxxxxxxxxxx; 
> anderst@xxxxxxxxxxxxx; andreas.schultz@xxxxxxx; Aschoka@xxxxxxxxxxx; 
> bogdanfy@xxxxxxxxxxxxx; buchinski.ed@xxxxxxxxxxxxx; Crawford, Mark; 
> debra.cimbala@xxxxxxxxxxxxx; dill@xxxxxxxxx; diskray@xxxxxxxxxxxxxxxx; 
> edgar.gluck@xxxxxxx; F.De_Vos@xxxxxxxxxx; 
> francis.berthomieu@xxxxxxxxxxxxxxxxx;
> frank.vandamme@xxxxxxxxx; fred@xxxxxxxxxxxxx; fvuille@xxxxxxxxxxxxx; 
> garret.minakawa@xxxxxxxxxx; Gilles.Brandel@xxxxxxx; 
> Gilman.Daniel@xxxxxxx; hsedi@xxxxxxxxxxxxx; irvchmielewski@xxxxxx; 
> ivan.bendini@xxxxxxxxxxxxxxxxx; james.whittle@xxxxxxxxxxxx; 
> jbarrett@xxxxxxxxxxx; jean_luc_champion@xxxxxxxxx; 
> jlsmith@xxxxxxxxxxx; john.bezant@xxxxxxxxxxxxxx; 
> kenji.itoh@xxxxxxxxxxxxx; klambert@xxxxxxx; kris.ketels@xxxxxxxxx; 
> kumarsivaraman@xxxxxxxxxxxxx; marianne.khouzam@xxxxxxx; 
> marion.royal@xxxxxxx; Michael.Onder@xxxxxxxxxxxx; 
> mollyaanderson@xxxxxxxxx; mrowell@xxxxxxxxxxxxxxxxxxxx; 
> nada_reinprecht@xxxxxxxxxxxxx; nivezic@xxxxxxxx; 
> olli-pekka.pauna@xxxxxxxxxxxx; paula.heilig@xxxxxxxxxxxxx; 
> phruby@xxxxxxxxxxxxx; plothian@xxxxxxxxxxxx; rachelf@xxxxxxxxxxxxx; 
> sally.m.chan@xxxxxxxxxx; serm@xxxxxxxx; srudelic@xxxxxxxx; 
> sutterst@xxxxxxxxxxxxxx; tripathi@xxxxxxxxxxxxx; yavo@xxxxxxxxxxx; 
> yunker@xxxxxxxxxx; jim.wilson@xxxxxxx; 
> fabrice.bourge@xxxxxxxxxxxxxxxxx; Řyvind Aassve; Jean-Luc SANSON; 
> tripathi@xxxxxxxxxxx; Dietrich, Jens (Finanzen) Ref-36
> Subject: Re: Cardinality and TBG17
> 
> Now I am confused.  I thought that the parent container should 
> logically declare the cardinality.  Are you talking about data 
> elements making an ecapsulated reference to cardinality that is to be 
> used as a restrictive tenet for all contextual uses of that element?  
> Wouldn't that logically severely limit the re-use with little or no 
> benefit? An element does not declare its own cardinality, a construct 
> that uses it does.
> Therefore B*'s
> should not have a notion ipso facto, only A*'s.
> 
> I also see huge issues if you use an encapsulated model for 
> cardinality logic.  The same type of thing breaks XML Schema if you an 
> make a declaration like this:
> 
> <xs:Element name="foo">
>   </xs:Choice>
>       <xs:Element name="bar" minOccurs="1" />
>      <xs:Element name="bah" minOccurs="1" /> ...
>   </xs:Choice>
> 
> Note the conflict in logic.  What should have happened here is that 
> Foo is 100% responsible for declaring the cardinality of all children 
> elements.
> Bar and bah should not decide how many times they are appearing and 
> the overall semantics of the construct should be used as a logic 
> guide.
> 
> Or am I way off base here??
> 
> D
> 
> 
> On 3/6/07 7:50 AM, "Sue Probert" <sue.probert@xxxxxxxxxxxxxx> wrote:
> 
> > I vote for option 2 but with the provisos that
> > 
> > a) If just one BBIE is based on a BCC specified with the
> cardinality 0:1 then
> > that BBIE MAY be specified as either optional or mandatory
> i.e. 0:1 or 1:1.
> > 
> > b) if multiple BBIEs are present each based on the same BCC
> specified with the
> > cardinality 0:1 then none of them can be specified to be
> mandatory i.e. each
> > MUST be 0:1.
> > 
> > Similarly for any BCC specified as 1:1 I would say that
> > 
> > a) If just one BBIE is based on a BCC specified with the
> cardinality 1:1 then
> > that BBIE MUST also be specified as mandatory i.e. 1:1.
> > 
> > b) if multiple BBIEs are present each based on the same BCC
> specified with the
> > cardinality 1:1 then again none of them can be specified to
> be mandatory i.e.
> > each MUST be 0:1.
> > 
> > To me the difference between these two cases is that the
> usage rules for the
> > implementation of the BBIEs would have to specify that:
> > 
> > a) in the case of the 0:1 BCC one of the BBIEs defined, but
> only one, MAY be
> > used in a syntax instance
> > 
> > b) in the case of the 1:1 BCC one of the BBIEs defined, but
> only one, MUST be
> > used in a syntax instance
> > 
> > cheers
> > 
> > Sue
> > 
> > 
> > -----Original Message-----
> > From: Stig Korsgaard [mailto:STK@xxxxxxxxxxxxxxx]
> > Sent: 06 March 2007 15:24
> > To: Mary Kay Blantz; abcoates@xxxxxxxxxxxxxx; Gait Boxman
> > Cc: Duane Nickull; Stuhec, Gunther; alain.chapdaniel@xxxxxxxxxxx; 
> > anderst@xxxxxxxxxxxxx; andreas.schultz@xxxxxxx; Aschoka@xxxxxxxxxxx; 
> > bogdanfy@xxxxxxxxxxxxx; buchinski.ed@xxxxxxxxxxxxx; Crawford, Mark; 
> > debra.cimbala@xxxxxxxxxxxxx; dill@xxxxxxxxx;
> diskray@xxxxxxxxxxxxxxxx;
> > edgar.gluck@xxxxxxx; F.De_Vos@xxxxxxxxxx; 
> > francis.berthomieu@xxxxxxxxxxxxxxxxx; frank.vandamme@xxxxxxxxx; 
> > fred@xxxxxxxxxxxxx; fvuille@xxxxxxxxxxxxx;
> garret.minakawa@xxxxxxxxxx;
> > Gilles.Brandel@xxxxxxx; Gilman.Daniel@xxxxxxx; hsedi@xxxxxxxxxxxxx; 
> > irvchmielewski@xxxxxx; ivan.bendini@xxxxxxxxxxxxxxxxx; 
> > james.whittle@xxxxxxxxxxxx; jbarrett@xxxxxxxxxxx; 
> > jean_luc_champion@xxxxxxxxx; jlsmith@xxxxxxxxxxx; 
> > john.bezant@xxxxxxxxxxxxxx; kenji.itoh@xxxxxxxxxxxxx;
> klambert@xxxxxxx;
> > kris.ketels@xxxxxxxxx; kumarsivaraman@xxxxxxxxxxxxx; 
> > marianne.khouzam@xxxxxxx; marion.royal@xxxxxxx; 
> > Michael.Onder@xxxxxxxxxxxx; mollyaanderson@xxxxxxxxx; 
> > mrowell@xxxxxxxxxxxxxxxxxxxx; nada_reinprecht@xxxxxxxxxxxxx; 
> > nivezic@xxxxxxxx; olli-pekka.pauna@xxxxxxxxxxxx; 
> > paula.heilig@xxxxxxxxxxxxx; phruby@xxxxxxxxxxxxx;
> plothian@xxxxxxxxxxxx;
> > rachelf@xxxxxxxxxxxxx; sally.m.chan@xxxxxxxxxx; serm@xxxxxxxx; 
> > srudelic@xxxxxxxx; sue.probert@xxxxxxxxxxxxxx;
> sutterst@xxxxxxxxxxxxxx;
> > tripathi@xxxxxxxxxxxxx; yavo@xxxxxxxxxxx; yunker@xxxxxxxxxx; 
> > jim.wilson@xxxxxxx; fabrice.bourge@xxxxxxxxxxxxxxxxx; Řyvind Aassve; 
> > Jean-Luc SANSON; tripathi@xxxxxxxxxxx; Dietrich, Jens
> (Finanzen) Ref-36
> > Subject: RE: Cardinality and TBG17
> > 
> > 
> > I vote for keeping option one.
> > 
> > If BCC in the ACC is 0..1 - Only option is none BBIE, one
> BBIE 0..1 or one
> > BBIE 1..1 allowed in the ABIE.
> > 
> > 
> > Best Regards
> > 
> > Stig Korsgaard
> > M.Sc.E Standardisation Manager
> > Tel:  +45 3370 1083
> > Cell:  +45 3016 1083
> > Mail:  stk@xxxxxxxxxxxxxxx
> > 
> > Danish Bankers Association
> > Amaliegade 7
> > DK-1256 Copenhagen K
> > Tel: 3370 1000
> > Fax: 3393 0260
> > mail@xxxxxxxxxxxxxxx
> > www.finansraadet.dk
> > 
> > -----Original Message-----
> > From: Mary Kay Blantz [mailto:mblantz@xxxxxxxxxxxxx]
> > Sent: 2. marts 2007 13:47
> > To: abcoates@xxxxxxxxxxxxxx; Gait Boxman
> > Cc: Duane Nickull; Stuhec, Gunther; alain.chapdaniel@xxxxxxxxxxx; 
> > anderst@xxxxxxxxxxxxx; andreas.schultz@xxxxxxx; Aschoka@xxxxxxxxxxx; 
> > bogdanfy@xxxxxxxxxxxxx; buchinski.ed@xxxxxxxxxxxxx; Crawford, Mark; 
> > debra.cimbala@xxxxxxxxxxxxx; dill@xxxxxxxxx;
> diskray@xxxxxxxxxxxxxxxx;
> > edgar.gluck@xxxxxxx; F.De_Vos@xxxxxxxxxx; 
> > francis.berthomieu@xxxxxxxxxxxxxxxxx; frank.vandamme@xxxxxxxxx; 
> > fred@xxxxxxxxxxxxx; fvuille@xxxxxxxxxxxxx;
> garret.minakawa@xxxxxxxxxx;
> > Gilles.Brandel@xxxxxxx; Gilman.Daniel@xxxxxxx; hsedi@xxxxxxxxxxxxx; 
> > irvchmielewski@xxxxxx; ivan.bendini@xxxxxxxxxxxxxxxxx; 
> > james.whittle@xxxxxxxxxxxx; jbarrett@xxxxxxxxxxx;
> jean_luc_champion@xxxxxxxxx;
> > jlsmith@xxxxxxxxxxx; john.bezant@xxxxxxxxxxxxxx;
> kenji.itoh@xxxxxxxxxxxxx;
> > klambert@xxxxxxx; kris.ketels@xxxxxxxxx;
> kumarsivaraman@xxxxxxxxxxxxx;
> > marianne.khouzam@xxxxxxx; marion.royal@xxxxxxx;
> Michael.Onder@xxxxxxxxxxxx;
> > mollyaanderson@xxxxxxxxx; mrowell@xxxxxxxxxxxxxxxxxxxx; 
> > nada_reinprecht@xxxxxxxxxxxxx; nivezic@xxxxxxxx; 
> > olli-pekka.pauna@xxxxxxxxxxxx; paula.heilig@xxxxxxxxxxxxx; 
> > phruby@xxxxxxxxxxxxx; plothian@xxxxxxxxxxxx; rachelf@xxxxxxxxxxxxx; 
> > sally.m.chan@xxxxxxxxxx; serm@xxxxxxxx; srudelic@xxxxxxxx;
> Stig Korsgaard;
> > sue.probert@xxxxxxxxxxxxxx; sutterst@xxxxxxxxxxxxxx;
> tripathi@xxxxxxxxxxxxx;
> > yavo@xxxxxxxxxxx; yunker@xxxxxxxxxx; jim.wilson@xxxxxxx; 
> > fabrice.bourge@xxxxxxxxxxxxxxxxx; yvind Aassve; Jean-Luc SANSON; 
> > tripathi@xxxxxxxxxxx; Dietrich, Jens (Finanzen) Ref-36
> > Subject: Cardinality and TBG17
> > 
> > Hi,
> > 
> > We need a very clear answer on this one; glad to see all
> the discussion.
> > 
> > A BCC has a cardinality of 0..1.
> > 
> > There are two possibilities for the BBIEs:
> > 
> > 1)  A max of one BBIE based on that BCC is permitted.  This
> is what TBG17 is
> > doing now.
> > 
> > 2)  An unlimited number of BBIEs based on that BCC are
> permitted.  They
> > would be differentiated by qualification of the Property
> Term, and would be
> > either 1..1 or 0..1.
> > 
> > Cheers,
> > Mary Kay
> > 
> > PS  Please avoid the 'but there could be a lot of BBIEs in
> different ABIEs
> > based on the ACC'.   We know that part.
> > 
> > ----- Original Message -----
> > From: "Anthony B. Coates (Miley Watts)" <abcoates@xxxxxxxxxxxxxx>
> > To: "Gait Boxman" <gait.boxman@xxxxxx>
> > Cc: "Duane Nickull" <dnickull@xxxxxxxxx>; "Stuhec, Gunther"
> > <gunther.stuhec@xxxxxxx>; <alain.chapdaniel@xxxxxxxxxxx>; 
> > <anderst@xxxxxxxxxxxxx>; <andreas.schultz@xxxxxxx>;
> <Aschoka@xxxxxxxxxxx>;
> > <bogdanfy@xxxxxxxxxxxxx>; <buchinski.ed@xxxxxxxxxxxxx>;
> "Crawford, Mark"
> > <mark.crawford@xxxxxxx>; <debra.cimbala@xxxxxxxxxxxxx>;
> <dill@xxxxxxxxx>;
> > <diskray@xxxxxxxxxxxxxxxx>; <edgar.gluck@xxxxxxx>;
> <F.De_Vos@xxxxxxxxxx>;
> > <francis.berthomieu@xxxxxxxxxxxxxxxxx>; <frank.vandamme@xxxxxxxxx>; 
> > <fred@xxxxxxxxxxxxx>; <fvuille@xxxxxxxxxxxxx>;
> <garret.minakawa@xxxxxxxxxx>;
> > <Gilles.Brandel@xxxxxxx>; <Gilman.Daniel@xxxxxxx>;
> <hsedi@xxxxxxxxxxxxx>;
> > <irvchmielewski@xxxxxx>; <ivan.bendini@xxxxxxxxxxxxxxxxx>; 
> > <james.whittle@xxxxxxxxxxxx>; <jbarrett@xxxxxxxxxxx>; 
> > <jean_luc_champion@xxxxxxxxx>; <jlsmith@xxxxxxxxxxx>; 
> > <john.bezant@xxxxxxxxxxxxxx>; <kenji.itoh@xxxxxxxxxxxxx>; 
> > <klambert@xxxxxxx>; <kris.ketels@xxxxxxxxx>;
> <kumarsivaraman@xxxxxxxxxxxxx>;
> > <marianne.khouzam@xxxxxxx>; <marion.royal@xxxxxxx>; 
> > <Michael.Onder@xxxxxxxxxxxx>; <mollyaanderson@xxxxxxxxx>; 
> > <mrowell@xxxxxxxxxxxxxxxxxxxx>; <nada_reinprecht@xxxxxxxxxxxxx>; 
> > <nivezic@xxxxxxxx>; <olli-pekka.pauna@xxxxxxxxxxxx>; 
> > <paula.heilig@xxxxxxxxxxxxx>; <phruby@xxxxxxxxxxxxx>; 
> > <plothian@xxxxxxxxxxxx>; <rachelf@xxxxxxxxxxxxx>;
> <sally.m.chan@xxxxxxxxxx>;
> > <serm@xxxxxxxx>; <srudelic@xxxxxxxx>; <stk@xxxxxxxxxxxxxxx>; 
> > <sue.probert@xxxxxxxxxxxxxx>; <sutterst@xxxxxxxxxxxxxx>; 
> > <tripathi@xxxxxxxxxxxxx>; <yavo@xxxxxxxxxxx>; <yunker@xxxxxxxxxx>; 
> > <jim.wilson@xxxxxxx>; <fabrice.bourge@xxxxxxxxxxxxxxxxx>;
> "Mary Kay Blantz"
> > <mblantz@xxxxxxxxxxxxx>; "yvind Aassve"
> <oyvind@xxxxxxxxxxxx>; "Jean-Luc
> > SANSON" <jean-luc.sanson@xxxxxx>; <tripathi@xxxxxxxxxxx>;
> "Dietrich, Jens
> > (Finanzen) Ref-36" <Jens.Dietrich@xxxxxxxxxxxxxxxxxx>
> > Sent: Friday, March 02, 2007 7:34 AM
> > Subject: Re: Glossary definition: restriction
> > 
> > 
> >> On Fri, 02 Mar 2007 12:12:48 -0000, Gait Boxman
> <gait.boxman@xxxxxx>
> >> wrote:
> >> 
> >>> What it means is that the BCC may appear on instances of
> the ACC. Of
> >>> course we decided those instances don't exist, so we have
> to infer that
> >>> to BIE. So assuming the 0..1 BCC has an equivalent BBIE
> in context X,
> >>> and the ACC has an equivalent ABIE in context X, what are
> the possible
> >>> cardinalities for BBIE in ABIE following restriction?
> >>> Well, 1..1 works, it's in 0..1, 0..0 also works, and so
> does 0..1. What
> >>> wouldn't work is anything repeatable.
> >> 
> >> ACCs don't have instances, only ABIEs (and other BIEs).
> The point I was
> >> making was whether the upper bound applies to individual
> derived BBIEs, or
> >> to all of the derived BBIEs taken together as a group.
> That is the point
> >> where we have found different people have been taking different 
> >> interpretation.
> >> 
> >>>> It throws up the question of whether CCs should have
> cardinalities at
> >>>> all.  Indeed, the overwhelming majority are
> 0..unbounded, but there are
> >>>> some that are 0..1, and with specific intent, so we need
> to decide what
> >>>> that means.
> >>> If we drop cardinality we might as well drop content
> models altogether.
> >> 
> >> And I wasn't suggesting we want to drop cardinality in
> CCs, just that if
> >> we have it, it has to have a clear meaning and usage.
> >> 
> >>>> Remember, though, that what CCTS is most worried about is the 
> >>>> derivation of content models.  That is the focus of the
> CCTS spec.  I
> >>>> would suggest that from a CCTS perspective, European
> Address and Dutch
> >>>> Address would restrictions of the Address ACC, but the
> Dutch Address
> >>>> would not be considered to be a restriction of the
> European Address
> >>>> (since restriction doesn't allow you to remove a
> mandatory item, as
> >>>> that is an extension of cardinality).
> >>> Help, since when is the Netherlands outside of Europe? If
> we can't use
> >>> restriction along the natural context axis for
> geopolitical axis we're
> >>> in for an enormous problem. That's the whole principle of
> context driven
> >>> specialization.
> >> 
> >> No, that isn't the principle, not as I understand it.  The
> principle is
> >> that you should be able to use business context to select
> the appropriate
> >> BIEs for a message (or perhaps even to produce appropriate
> "anonymous"
> >> BIEs on the fly for a message).  That means that you need
> to be able to
> >> select the Dutch Address for a Dutch message based on its
> context, or to
> >> select the European Address is that is what the business context 
> >> requires.  It doesn't means that the Dutch Address BIE needs to be 
> >> directly derivable from the European Address BIE.  In that
> direction lies
> >> madness, because data structures simply don't follow
> business context that
> >> closely.
> >> 
> >>>> Now, from a separate UCM/CCMA perspective, clearly the
> business context
> >>>> of a Dutch Address (i.e. "netherlands") is a 
> >>>> subset/restriction/narrowing of the business context of
> a European
> >>>> Address ("europe").  That's something that needs to be taken into 
> >>>> account in CCMA, but is different to the "restriction"
> process that we
> >>>> are describing in the CCTS glossary, primarily so that
> when we talk
> >>>> about "restriction" in the CCTS spec, people know what
> we are referring
> >>>> to.
> >>> I'm not prepared to start doing things differently in
> CCMA for things
> >>> that should follow CCTS. If restriction means something
> different in
> >>> CCMA than in CCTS the only thing we can say is that
> somebody messed up
> >>> totally. CCMA is in the same (semantic) domain as CCTS.
> >>> While I appreciate that XML type restriction is something
> different,
> >>> that has very little to do with CCTS or CCMA restriction concepts.
> >> 
> >> I'm not saying that CCMA should "do things differently" in
> any practical
> >> sense.  The point is that English, in spite of its
> attempts to subsume the
> >> vocabularies of numerous languages, still has far fewer
> words than the
> >> number of distinct concepts that we need to describe.  So
> we "overload"
> >> words and give them multiple meanings.  The point I am
> making is that we
> >> have an overloaded usage of "restriction" here.  There is data 
> >> restriction, and there is semantic domain restriction.  These are 
> >> different things.  For the CCTS glossary, I was suggesting
> that we define
> >> restriction in a way that covers its usage in the CCTS
> spec, which is a
> >> way that would be appropriate for some other specs.  The
> alternative is to
> >> have a multi-part definition with the different meanings
> of "restriction",
> >> a bit like the dictionary entry for "set".  That would be
> appropriate for
> >> a separate CEFACT glossary document, but I think it would
> be overkill for
> >> the glossary in the CCTS spec (but comments and
> disagreements to that are
> >> welcome).
> >> 
> >> Cheers, Tony.
> >> --
> >> Anthony B. Coates
> >> Senior Partner
> >> Miley Watts LLP
> >> Experts In Data
> >> +44 (79) 0543 9026
> >> Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312, 
> >> UN/CEFACT TMG, MDDL, FpML, UBL.
> >> http://www.mileywatts.com/
> >> 
> > 
> > 
> > 
> > 
> 
> --
> **********************************************************
> Sr. Technical Evangelist - Adobe Systems, Inc.           *
> Chair - OASIS SOA Reference Model Technical Committee    *
> Blog: http://technoracle.blogspot.com                    *
> Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
> **********************************************************
> 
>     (010)

------ End of Forwarded Message    (011)


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 12-Apr-07
11:52    (012)



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 12-Apr-07
11:52    (013)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (014)

<Prev in Thread] Current Thread [Next in Thread>