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)


Duane,

OK - the SCM noun is actually engineered the other way around.

It allows you to point to a CC instance using CCTS terminology - such as 
ABIE, BCC, ACC, and so on - and therefore provide one or more
phyical renderings that relate to a high level CCTS object.

But your mechanism also works - where the CC instance can point to a 
noun instance in the registry.
I would suggest you use a LID based interface for this - rather than a 
UUID based one.

Something like:

 <Property type="ebNoun" registry_addressing="http-binding goes here" 
referenceID="LID_value"/>

Thanks, DW
======================================
 Duane Nickull wrote:

>
>
> David RR Webber wrote:
>
>> 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.
>
>
> You may have misinterpretted my email. I would never advocate that the 
> registry does the assembly, just serves up the artifactrs necessary to 
> be assembled to something like jCAM or whatever else.
>
> Even jCAM has requirements on what must be present in each artifact it 
> assembles.  I would welcome your comments on the CC-Review document as 
> to whether or not they appear to appease CAM's needs.
> I did make a format that allows CAM users to place their own 
> information into a CC or BIE without affecting other users.  For 
> example, if there is a property that only CAM users need, they can 
> have it declared wityhin the CC instance:
>
> <Property type="jCAM_user_ID_here" value="UUID:URN:DRRW1001" />
>
> Duane
>
>>
>> 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. 
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> 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]