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: RIM as a Data Dictionary


Looking for the TC's thoughts here please:

 

Recently, one of my US federal contacts who has seen multiple demos of ebXML Registry asked me the following question: Can RIM be used as a Data Dictionary?

 

Here is the original inquiry:

 

<Inquiry>

Someone suggested using the ebXML registry (meaning the RIM) as a 'data dictionary'. While it does support some 11179 constructs, I don't think this is a good application of the RIM (in addition to the bunch of custom code that would be needed).

 

I would prefer that the registry provide metadata input to a dictionary, each of which is a component of a federated metadata system.

</Inquiry>

 

I then asked for a clarification of their use of the term "data dictionary", since it is broad:

 

<Clarification>

For our purpose, lets assume that our data dictionary contains typical 'stuff': metadata for classes, attributes, relationships, and domain codelists for the attributes -- all from our enterprise logical data model. Might even contain metadata for our operational databases --- tables and columns, and their mapping to the logical data model. It also contains metadata for our data stewards, along with business definitions and names for the classes and attributes. This is all good stuff that where we can apply 11179.

</Clarification>

 

In closing, they said:

 

<Closing>

My own opinion is that, while the registry rim does not directly support this level of data dictionary, we could use the rim, but we would need to write a lot of code to provide the functionality. But that's not the purpose the XML registry rim, so my response is no, we don't use the XML registry for our data dictionary.

</Closing> 

 

My thought is that since our RIM is abstract and extensible, there are at least 2 possibilities:

 

(1) One could implement ebXML Registry per our specs and configure it such that the RegistryObjects were the items listed within <Clarification> above;

(2) A vendor could create an application that offers such functionality, with ebXML Registry as its engine - and if this existed, it could be used by this person;

 

Other thoughts?

 
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 


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