RE: BSR - the Basic Semantic Register

[John McClure <hypergrove@olympus.net>]

Hello,
I'd like to pitch in on this one - Martin's paper validates a number of my
own views, that 'roles' are a highly important element when solving certain
problems. As the architect of the Data Consortium Namespace
(www.dataconsortium.org/namespace/DCN150.DTD.pdf), I'd like to share how we
interchange many-to-many relationships. I'd like to note that the DCN is an
open-source effort, and that we welcome all comments about its architecture
and implementation.

Meanwhile, I hope you find our technical approach useful.
Regards,
John McClure
Hypergrove Engineering, Inc.
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)
====================================================================

Containment can also be looked upon as a relationship between a container
and its containees. Often, as is the case for the DCN, container-containee
and parent-child relationships are handled specially for functional and for
performance reasons. Nevertheless, the model still devolves to that which
addresss roles and relationships. In fact, the DCN allows multiple
representations for a given semantic, relegating to an object model the job
of establishing the canonical "information set" represented by the XML
elements in the DCN data-stream.

In the DCN, each resource involved with a m-to-m relationship is linked to
the relationship itself. For instance, let's assume that we want to markup
that a location, Loc01, is a 'child of' Loc02 and Loc03, while Loc02 and
Loc03 are the 'parent of' Loc01 and Loc04. Here is one form of markup for
this (using DCN elements).
====================================================================
<Location id='Loc01'>
   <!-- here's a list of the containing locations -->
   <list xsi:type='locations' name='parentLocations'>
   <Location id='Loc02'>
	<list xsi:type='locations' name='childLocations'>
	<Location id='Loc01'/>
	<Location id='Loc04'/>
	</list>
   </Location>
   <Location id='Loc03'>
	<list xsi:type='locations' name='childLocations'>
	<Location id='Loc01'/>
	<Location id='Loc04'/>
	</list>
   </Location>
   </list>
</Location>

====================================================================
The DCN accommodates a role-centered markup style, where a <Role> is used
to identify the
   (1) 'subjects' of a role, i.e., the resources that are 'performing' the
role, and
   (2) the 'factors' of a role, that is, the resources that are the
'contexts' in which or for which the other (subject) resources perform the
role.
====================================================================
<Location id='Loc01'>
   <!-- here's a list of roles performed by the parent element-->
   <list xsi:type='roles' name='locationRoles'>
   <Role xsi:type='LocationRole' name='Containee'>
	<list xsi:type='locations' name='subjectLocations'>
	<Location id='Loc01'/>
	<Location id='Loc04'/>
	</list>
	<list xsi:type='locations' name='factorLocations'>
	<Location id='Loc02'/>
	<Location id='Loc03'/>
	</list>
   </Role>
   </list>
</Location>

====================================================================
The following encoding style explicitly identifies the roles being
performed by each of the resources. In other words, this encoding makes the
"Container" role explicit.
====================================================================
<Location id='Loc01'>
   <!-- here's a list of roles performed by the parent element-->
   <list xsi:type='roles' name='locationRoles'>
   <Role xsi:type='LocationRole' name='Containee'>
	<list xsi:type='locations' name='subjectLocations'>
	<Location id='Loc01'/>
	<Location id='Loc04'/>
	</list>
	<list xsi:type='roles' name='relatedRoles'>
	<Role xsi:type='LocationRole' name='Container'>
	   <list xsi:type='locations' name='subjectLocations'>
	   <Location id='Loc02'/>
	   <Location id='Loc03'/>
	   </list>
	</Role>
	</list>
   </Role>
   </list>
</Location>

|-----Original Message-----
|From: Philip Goatly [mailto:philip.goatly@bolero.net]
|Sent: Friday, January 26, 2001 2:33 AM
|To: William J. Kammerer; ebXML Core
|Cc: Peter Guldentops; Zahida Christie; kara.Wales@bolero.Net
|Subject: Re: BSR - the Basic Semantic Register
|
|
|Folks,
|  I too enjoyed Martins' paper. Unless I missed the point however, I don't
|see how it deals with many to manty relationships.
|
|  Perhaps he ould be kind enough to explain for simple souls like me.
|
|OR maybe I was at fault in not explaining myself too clearly.
|
| Let's look at at say packing a product;
|
|  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 !!!
|
|       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. Thus this becomes a
|generalised problem of many to many relationships
|and how to handle them in a hierarchical structure.
|
|       This was a common problem in the 1970's when virtually all DBs were
|Hierarchical. I remember it well.
|
|       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 ?
|
|Cheers, Phil
|
|" If the only tool you have is a hammer the whole world looks
|like a nail "
|Anon.
|
|
|
|
|
|
|----- Original Message -----
|From: "William J. Kammerer" <wkammerer@foresightcorp.com>
|To: "ebXML Core" <ebxml-core@lists.ebxml.org>
|Sent: Friday, January 26, 2001 3:49 AM
|Subject: Re: BSR - the Basic Semantic Register
|
|
|> Martin Bryan was glad that I not only enjoyed his paper, but that I also
|> found it despite his typo in the URL.  Martin may rest assured that I
|> regard his site - The SGML Centre - as one of my favorites and have
|> bookmarked http://www.sgml.u-net.com/, whence I found the paper via the
|> "Helpful Papers" link.
|>
|> But Martin asks "If BSR is only available to paying customers should
|> ebXML adopt it as its base?"  The BSR standard does seem pricey at
|> around $70, but it would probably only be needed by ebXML software
|> developers, if at all.
|>
|> Actually, the standard itself, ISO/TS 16668:2000 Basic Semantics
|> Register (BSR)  - Rules, Guidelines and Methodology, just describes the
|> process for building the names, which Martin has probably already
|> figured out.  The valuable part is the Proposed BSR content, including
|> the Semantic components and the Semantic Units, freely available at
|> http://forum.afnor.fr/afnor/WORK/AFNOR/GPN2/TC154WG1/. Also check out
|> the stuff at the BSR Consortium, at http://www.ubsr.org/.
|>
|> All the ISO standards cost money, but that hasn't kept us from using
|> others, like ISO/IEC 11179 Specification and standardization of data
|> elements,  ISO 8601:1988  Representations of dates and times, ISO 3166
|> Country Codes, ISO 6093:1985 Representation of numerical values in
|> character strings, ISO 5218:1977 Representation of Human Sexes, ISO
|> 639-2 language code, and ISO 4217 3-Letter Alphabetic Currency Code.
|> We've talked about these enough in the past - and most of the coded
|> lists are free at their respective Registration Authorities.  To find
|> some of them, go to http://www.foresightcorp.com/, and click on
|> "Resources," then "Code Lists" for a list of External Code Lists used in
|> EDI.
|>
|> Even EDIFACT relies on ISO 9735 for describing its syntax and control
|> structures.  And the ISO 6523 ICDs, which I've talked about in TR&P, are
|> free.  As are the S.W.I.F.T. BICs, based on the ISO 9362 Bank Identifier
|> Code.
|>
|> If the standard is not free, usually the important things we want
|> are: the codes and their formats.  Never pay retail.
|>
|> William J. Kammerer
|> FORESIGHT Corp.
|> 4950 Blazer Memorial Pkwy.
|> Dublin, OH USA 43017-3305
|> +1 614 791-1600
|>
|> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
|> "Commerce for a New World"
|>
|>
|
|