OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] [TN Proposal] Mapping Business Information Models toebXML RegistryInformation Model (Was: [regrep] UN/CEFACT-ICG adopts freebXMLRegistry)


Farrukh,

You are not missing anything.

As my reply to Duane points out - we've been down this rat hole before.

The *last* thing you want to do is try and use the registry to do 
assembly itself - that's an intractible problem. 
That is why you have jCAM engines, et al.

Instead - you simply model a flat UMM CC structure onto RIM, and 
optionally extend that with SCM noun instances as needed.

That's it - no more.

Then its up to the backend UML modelling tools to reference that content 
and do clever things internally as they wish.  They can also
optionally output CAM template instances as XML - to drive the use of 
the registry content semantics.

That was the lesson we learned before - keep this very simple - separate 
the task out into logical parts - semantics, relationships (OWL), assembly;
do not try and mix those into one hair ball.

DW.

Farrukh Najmi wrote:

> Farrukh Najmi wrote:
>
>> Duane Nickull wrote:
>>
>>> I would propose that this approach is flawed since CCTS is a special 
>>> case.  If you read the entire CCTS set of documents AND UMM, you 
>>> will clearly see a need for more than a simple mapping and storage.  
>>> This is documented in my requirements in CC-Review.  CC's and BIE's 
>>> need to serialize the information and carry it to persistent stores 
>>> outside the registry. That places a requirement of duplication of 
>>> certain RIM instance data in the CC instance, so it can be used 
>>> without a registry system present in the way that UMM dictates 
>>> Business information entities be used.
>>
>>
> The requirement you mentions as special (the need to duplicate content 
> into metadata) is actually very common based on my experience. Our 
> proposed TN would address this pattern explicitly using the Content 
> Cataloging feature.
>
> What am I missing?
>
>>
>> A few special cases in CCTS mapping do not obviate the need for a 
>> generic mapping TN that covers most domain specific mapping and 90%+ 
>> of CCTS.
>> What is the downside of doing a generic mapping document as you see it?
>>
>>>
>>> Duane
>>>
>>> Carl Mattocks wrote:
>>>
>>>> Mapping Domain Patterns in ISO/TS 15000 Registry Information Model
>>>> should be of interest to those who need to take a risk free approach
>>>>
>>>> <quote who="Chiusano Joseph">
>>>>  
>>>>
>>>>> Excellent idea. I recall mention of this during the earlier CC-RIM in
>>>>> summer 2003.
>>>>>
>>>>> Regarding the title: Perhaps can do something with the word 
>>>>> "Business",
>>>>> as it seems to convey that the TN would cover only information at a
>>>>> higher layer, and I don't think we would much care what the
>>>>> meaning/intent of the information was. Perhaps we could:
>>>>>
>>>>> (1) Drop the word "Business" (becomes "Mapping Information 
>>>>> Models...")
>>>>> (2) Supplement it ("Mapping Business and Domain Specific Information
>>>>> Models..."), or
>>>>> (3) Substitute it (no particular word comes to mind right now)
>>>>>
>>>>> Joe
>>>>>
>>>>> Farrukh Najmi wrote:
>>>>>  
>>>>>
>>>>>> Yet another important thing I did not mention is that as we were
>>>>>> discussing the
>>>>>> mapping from CCTS UML Model to ebRIM UML model I suggested that the
>>>>>> registry TC
>>>>>> should create a TN titledsomething like:
>>>>>>
>>>>>> "Mapping Business Information Models to ebXML Registry Information
>>>>>> Model"
>>>>>>
>>>>>> This TN would provide the generic patterns and algorithms for 
>>>>>> mapping
>>>>>> any
>>>>>> Business or Domain specific information model to ebRIM.
>>>>>>
>>>>>> This is an idea that Nikola had come up with a long time ago. As I
>>>>>> recall he had
>>>>>> even made a list of such patterns at some point.
>>>>>>
>>>>>> As more and more domains are adopting ebXML Registry standard 
>>>>>> they are
>>>>>> faced
>>>>>> with the recurring need to map between their info model and ebRIM.
>>>>>> Currently
>>>>>> this is being done ad hoc. With the proposed TN this recurring 
>>>>>> need will
>>>>>> be
>>>>>> nicely addressed.
>>>>>>
>>>>>> I view the proposed TN to be very valuable indeed to the ebXML 
>>>>>> Registry
>>>>>> user
>>>>>> community. I expect the paper to be relatively brief.
>>>>>>
>>>>>> I have spoken to Nikola about resurrecting his work in this area 
>>>>>> and he
>>>>>> graciously agreed. During the course of next week Nikola and I will
>>>>>> collaborate
>>>>>> to put an initial draft of the proposed TN for the teams review.
>>>>>>
>>>>>> Thanks in advance for sharing any thoughts on this idea and 
>>>>>> specially on
>>>>>> the
>>>>>> title of the note.
>>>>>>
>>>>>> -- 
>>>>>> Regards,
>>>>>> Farrukh
>>>>>>
>>>>>> Farrukh Najmi wrote:
>>>>>>
>>>>>>   
>>>>>>
>>>>>>> The UN/CEFACT Information Content Management Group (ICG) has
>>>>>>>       
>>>>>>
>>>>>>
>>>>>>
>>>>>> officially
>>>>>>   
>>>>>>
>>>>>>> adopted the ebXML Registry standard as the center
>>>>>>> piece of their new Information Content Management Architecture.
>>>>>>>
>>>>>>> The architecture will be implemented as a federation of autonomous
>>>>>>>       
>>>>>>
>>>>>>
>>>>>>
>>>>>> ebXML
>>>>>>   
>>>>>>
>>>>>>> Registries operated by various UN/CEFACT members countries and
>>>>>>> organization. They are also envisioning a top level UN/CEFACT ebXML
>>>>>>> Registry as the leader of the registry federation. The UN registry
>>>>>>> federation will store Core Component artifacts as well as many 
>>>>>>> other
>>>>>>>       
>>>>>>
>>>>>>
>>>>>>
>>>>>> UN
>>>>>>   
>>>>>>
>>>>>>> defined artifacts.
>>>>>>>
>>>>>>> At ICG invitation I attended a two day meeting Thursday and Friday.
>>>>>>> On Thursday I presented ebXML Registry standard to them and 
>>>>>>> discussed
>>>>>>> their requirements and how ebXML Registry standard met those
>>>>>>> requirements. On Friday we developed the blueprint for their
>>>>>>> ebXML Registry based architecture which was then presented to the
>>>>>>>       
>>>>>>
>>>>>>
>>>>>>
>>>>>> broader
>>>>>>   
>>>>>>
>>>>>>> participant of the UN/CEFACT conference.
>>>>>>>
>>>>>>> It was good to see David Webber in the audience who contributed to
>>>>>>> the lively discussion. The presentation was well received.
>>>>>>>
>>>>>>> I will send link to the UN/CEFACT Information Content Management
>>>>>>> Architecture slides as soon as it gets posted on their web site:
>>>>>>>
>>>>>>>   http://www.disa.org/cefact-groups/icg/
>>>>>>>
>>>>>>> All in all I am overwhelmed by the success of this meeting and hope
>>>>>>>       
>>>>>>
>>>>>>
>>>>>>
>>>>>> that
>>>>>>   
>>>>>>
>>>>>>> this momentum in the adoption of the ebXML Registry standard 
>>>>>>> continues
>>>>>>> to escalate.
>>>>>>>
>>>>>>> We as a team should feel very proud of the success of our standard.
>>>>>>>
>>>>>>>       
>>>>>>
>>>>>>
>>>>>>
>>>>>> To unsubscribe from this mailing list (and be removed from the 
>>>>>> roster of
>>>>>> the
>>>>>> OASIS TC), go to
>>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>>>
>>>>>>
>>>>>> To unsubscribe from this mailing list (and be removed from the 
>>>>>> roster of
>>>>>> the OASIS TC), go to
>>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>>>
>>>>>>     
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Kind Regards,
>>>>> Joseph Chiusano
>>>>> Associate
>>>>> Booz Allen Hamilton
>>>>>
>>>>> To unsubscribe from this mailing list (and be removed from the 
>>>>> roster of
>>>>> the OASIS TC), go to
>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the 
>>> roster of the OASIS TC), go to 
>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>
>>>
>>
>>
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]