Re: BSR - the Basic Semantic Register

[Philip Goatly <philip.goatly@bolero.net>]

Hi Bob,

 Yes we are doing just that in 'coded tables'

Cheers, Phil

www.bolero.net Auto-generating XML from UML  since Dec 1999

----- Original Message -----
From: "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Friday, January 26, 2001 3:50 PM
Subject: RE: BSR - the Basic Semantic Register


> Good People,
>
> Like Phil aand a good many others, I too have "been there, done that" with
> respect to hierarchical DB's and their advantages (yes there are some
> advantages over RDBs), and their limitations.  I even authored a really
good
> DB manager way back then that our company still uses in some products.
>
> Given a relational organization of some business data, it is a trivial
> exercise to construct a 'relational DB' message.  Just define a message
> having 'n' compound 'elements', whose members are the set of primitive
> 'elements' that make up one DB record construct.  Define the message as
> being a collection of such records, in any order, and in any quantity.
>
> But do we really want 100% relational-DB messages?
>
> Hierarchical relationships are legend in the real world.  I would
accomodate
> that by designing hierarchical message constructs to the extent that they
> model real world hierarchical relationships.  Then I would augment that
> design with relational message constructs to handle the relationships
> (key/key relations) that are not directly addressed by the hierarchical
> model.
>
> Cheers,
>         Bob
>
>
>
>
> -----Original Message-----
> From: Philip Goatly [mailto:philip.goatly@bolero.net]
> Sent: Friday, January 26, 2001 6:11 AM
> To: Martin Bryan; William J. Kammerer; ebXML Core
> Cc: Peter Guldentops; Zahida Christie; kara.Wales@bolero.net
> Subject: Re: BSR - the Basic Semantic Register
>
>
> Hello Martin,
>
>     Yes  agree that is one way to do it - been there done it in the 1970s-
> however if hierarchies are 'deep' then the permutationsand combinations
can
> become large and cumbersome. I am suggesting therefore that 'deep'
> hierachies are best avoided if the relationship/s are capable of many to
> many.
>
>  A 3 level many to many is capable of  6 combinations and 4 level 24 etc.
or
> something like that
>
>
> Cheers, Phil
>
> ----- Original Message -----
> From: "Martin Bryan" <mtbryan@sgml.u-net.com>
> To: "Philip Goatly" <philip.goatly@bolero.net>; "William J. Kammerer"
> <wkammerer@foresightcorp.com>; "ebXML Core" <ebxml-core@lists.ebxml.org>
> Cc: "Peter Guldentops" <peter.guldentops@bolero.net>; "Zahida Christie"
> <zahida.christie@bolero.net>; <kara.Wales@bolero.Net>
> Sent: Friday, January 26, 2001 11:53 AM
> Subject: Re: BSR - the Basic Semantic Register
>
>
> > Philip
> >
> > >   There are 2 scenarios which I would liek to contemplate:
> > >
> > >   1. One Product packed in many containers.
> > >
> > >         The layout in XML could be as follows
> > >
> > >           <Product>
> > >                 <Container> </Container>
> > >                 <Container> </Container>
> > >                 <Container> </Container>
> > >                  ........
> > >          </Product>
> > > 2. Many products in one container
> > >
> > >           <Container>
> > >                  <Product> </Product>
> > >                  <Product> </Product>
> > >                  <Product> </Product>
> > >            </Container>
> > >
> > >   The challenge is one cannot predict how a packer will pack a
> > consignment -
> > > It will depend on many factors like the size
> > > of containers, the dimension of product/s etc or just how a
particualar
> > > packer feels on a particular day !!!
> >
> > Agreed, but then what is the business process? If the process is
shipping
> > then you start from the container that has to be moved. If the process
is
> > ordering you start from the products that have to be packed in the
> > container. The person ordering does not care how many containers are
> needed.
> > The shipper gets to match the orders with the containers.
> > >
> > >        There are of couyrse solutions to the above like allowing one
OR
> > "|"
> > > the other BUT if a hierarchy is expressed in
> > > sevearal levels the permutations become larger.
> >
> > XML models have choices defined using OR groups, and choices based on
the
> > use of all of a set of elements without ordering.
> >
> > > Thus this becomes a
> > > generalised problem of many to many relationships
> > > and how to handle them in a hierarchical structure.
> >
> > Any one instance of a message has a single hierarchy because it has
chosen
> > one of the alternatives, but the model allows for all possible
> hierarchies.
> >
> > >        This was a common problem in the 1970's when virtually all DBs
> were
> > > Hierarchical. I remember it well.
> >
> > Those of us with fond memories of Hierarchical DBs are getting rarer by
> the
> > day :-)
> >
> > But do not confuse the hierarchical nature of the message for the need
to
> > store it in a hierarchical database. A good XML database uses XML
> datatypes
> > to define the hierarchy, not the XML elements that form the message.
> > >
> > >        In general designers tended to flatten the hierarchies as much
as
> > > possible and relate hierarchies thru data fields -
> > >        and then Ted Codd et al 'invented' the relational Database
which
> is
> > > the main paradigm today.
> >
> > >       How does XML deal with many to many ?
> > >       How will ebXML deal with many to many ?
> >
> > Through divorcing modelling from instances. Each message has a single
> > hierarchy that represents a choice from a model that defines the set of
> > permitted hierarchies.
> >
> > Martin Bryan
> >
>