Lists Home |
Date Index |
Michael Kay wrote:
>>We tended to use repository to refer to the place where you
>>kept a model.
>>Digital shipped a Common Data Dictionary for the VAX in the
>>early '80s. I don't
>>remember any integration with CASE or modeling tools at that
>>time. Later we used
>>repository as the container for models stored by products
>>such as Excelerator,
>>Application Factory, CorVision, and IBM AD/Cycle.
>>The terminology difference might be a "which side of the
>>pond?" issue, or it
>>might simply be what software you were working with.
>I think the original theory was that a data dictionary would hold
>everything, then some vendors (especially RDBMS vendors) came out with
>products called data dictionaries that held a lot less, then the term
>"repository" was coined (by IBM?) to refer to the original concept of what
>data dictionaries were meant to be in the first place.
>In ICL we had a data dictionary product from about 1978 that held
>information in four quadrants: the upper half contained the conceptual
>process model and data model, the lower contained the processes and data
>structures as implemented.
>The other interesting thing about it (given that we're on an XML list) was
>that the data in the dictionary itself (i.e. the metadata) was controlled
>using a [meta]schema not unlike an XML schema, in that all the different
>kinds of data in the dictionary (e.g COBOL data definitions, relational
>table definitions, 4GL reports, screen layouts) were described using a BNF
>grammar. As with XML, this provided the means to describe a very rich
>fine-grained data model using a schema of only modest complexity, compared
>at any rate with an equivalent UML description. In effect, the dictionary
>was an XML database supporting a predefined but extensible set of about 250
>document types. A COBOL record description, for example, would be one
>document type, a screen layout for the TP monitor would be another, and they
>were all richly hyperlinked. And of course, the schema language in which
>these 250 document types were described was itself one of the 250 document
>A number of companies, including ICL itself (with me as chief designer),
>tried to implement this kind of concept later using object databases and
>failed. I can't help feeling that doing it now with XML would work rather
Managing controlled vocabularies (data dictionary) is one of the
important applications that
the OASIS ebXML Registry  is designed to handle.
The ebXML Registry is both a registry and a repository.
The repository holds arbitrary content while the registry holds meta
data that describes the content.
The ebXML Registry is now an ISO standard (ISO 15000 part 3 and 4).
The ebXML Registry on its
own only provides publish, management of discovery of vocabulary
elements. What is also needed
is a vocabulary assembly tool that can assemble vocabularies from finer
grained vocabulary elements.
Work is underway in OASIS CAM TC and other places to define such a
vocabulary assembly capability.
Vocabulary may be defined using Ontologies (e.g. OWL) or ebXML Core
Components and Business
Work is also underway within the Semantic Content Management SC of ebXMl
Registry to provide
native support for managing ontologies and using them as semantic meta
data to annotate content in
a semantically richer manner.
The ebXML Registry TC welcomes comments and participation from
of the xml-dev community on our ongoing work.
 OASIS ebXML Registry Specifications
 freebXML Registry a Royalty Free Implementation of ebXML Registry
 Web Content Management Using ebXML Registry (Paper for XML 2004)
 Semantic Content Management SC (work-in-progress)