RE: ebXML Entity Classes - Resend

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

John,

And some comments to your comments below:

Bob

-----Original Message-----
From: John McClure [mailto:hypergrove@olympus.net]
Sent: Monday, March 05, 2001 10:38 AM
To: Miller, Robert (GXS); ebxml-core@lists.ebxml.org
Subject: RE: ebXML Entity Classes - Resend


Thank you for your reply. Comments below.
John

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Monday, March 05, 2001 8:09 AM
To: ebxml-core@lists.ebxml.org
Subject: RE: ebXML Entity Classes - Resend


John,

In ebXML, I believe access to the metadata resources will more likely be
through a Globally Unique Identifier (guid), as this resolves the language
dependency issues.
******
JMc: Well, I've sent out a note twice now to find out what is actually meant
by this, with no reply from anyone.
----
RM: The CC "Spreadsheets" currently use sequential numbers as guid's.
Something that simple would work. though a somewhat more sophisticated
system that addressed such concerns as multiple naming authorities would
please me more. The nnn.nnn.nnn.nnn network addressing scheme is an example
of a successful 'guid' scheme for addressing sites on the internet.  

******
I too believe a rich set of 'class' definitions are critical to success.
They provide a key to guiding generation of XML Schemas et al.  Class
definitions also help organize the metadata associated with the hundreds (or
even thousands!) of XML elements.
*******
JMc: I suspect that we differ alot here. The idea of creating hundreds or
thousands of XML elements is ultimately bound to make clients of the
standard significantly less robust. I am resolutely opposed to thousands of
XML elements. I have found the alternative -- a *small* number of elements
pointing to metadata in a dictionary -- to be a far more powerful
alternative for a number of very good technical and political reasons.
----
RM: I agree we differ in the number of elements.  However many the number of
elements, I still think we are on common ground with respect to classifying
elements.  By "rich set of 'class' identifiers" I did not mean "lots of
classes".  Rather I meant relatively few well structured and endowed (with
properties) classes capable of efficiently expressing metadata associated
with all the business data objects a defining body sees fit to define. 

Business is complex.  Perhaps a parallel to business complexity is language
complexity.  Suppose all the languages of the world were to be represented
in a single document (I hesitate to call it a dictionary, as phrases,
syntax, and common usage also have to be taken into account).  If rendered
in print, a person would find such a document of little use.  Now put the
document on-line with a powerful search engine.  Add metadata to show the
relationships among words and phrases within and across languages, and the
document becomes a translation tool.  

Carefully throw away perhaps 80-90% of all of the words in the document,
leaving just the most used words and expressions, and the document remains
almost as useful as it was in its entirety.  But that still leaves LOTS of
words and phrases.  Throw away too many or throw away the wrong ones and the
usefulness of the document rapidly deteriorates. Throw away duplicates
within and across languages, and lots of additional words and pharses could
be eliminated (resulting in a single world language), but who would speak
and write it?  

In the business world, there are LOTS of documented business data objects.
Yet neither X12 nor UN/CEFACT or any other collection of information on
business data objects comes anywhere near doing justice to the language of
business as existing language dictionaries do for understanding the spoken
and written word.  In my opinion, we are not smart enough in this age to
make do with a limited vocabulary of business data objects.  We haven't even
done a good job to date in documenting the properties and semantic behavior
of the business data objects we have defined for use.  And just as getting
to a single global written language is impractical, so is getting to a
single global business language.

I know we don't share a common view on the number of business data elements
needed.  I hope you now understand why I don't agree with you that a
relatively few will meet the need.  

BTW, I personally do not consider it within the scope of the ebXML effort to
define business data elements, whether 'Core Components' or otherwise.  I do
consider it within the scope of ebXML to specify the framework in which such
elements are defined.  I believe that the work done by X12 and ebXML members
to identify a number of Core Components was necessary to help understand the
requirements, so that a strong and useful framework could be developed.  I
see good work being done on the framework now that wasn't seen before the
Core Components discovery work had progressed far enough to provide
direction.  But the framework is not yet resting on a firm foundation.
Rather it is like a set of prefabricated walls and trusses waiting for the
foundation to be completed so they can be assembled in their proper places. 

If we don't build business data objects upon a solid framework, amassing a
wealth of data elements could be akin to building a Tower of Babel.  If
that's your view of what is happening, I appreciate your desire to minimize
the number of defined elements.  But I still don't would not agree to a
limited vocabulary as the reasonable course of action.

*******
I happen to prefer RDF(S) as the representation syntax for metadata (at this
point in time!).  But again, syntactic representation is an end result of
semantic understanding (in this case meta-metadata understanding).  For that
reason, I would want to start at a higher level (e.g., UML) and work down to
an available syntax like RDF(S).

I appreciate your concern about the difficulty of developing and maintaining
a vast list of semantic object definitions.  But that is just what the
UN/CEFACT and X12 standards orgainizations have been doing for years (though
not to the same level of detail we are now contemplating.)  The X12 and
UN/CEFACT dictionaries are quite impressive.
********
JMc: You've misread me, my friend. I am opposed to a vast list of XML
elements, not a vast list of dictionary entries. The small list of XML
elements corresponds to the names of resource-types. Surely, data-modelers
can do better than elements like <PurchaseOrderReceiptDate> -- where is the
normalization? Have all our DBA skills and theory become moot in the XML
age? I think not.
----
RM: I did read you, friend, and we do differ on this issue.  To take your
example of <PurchaseOrderReceiptDate>, I have no problem with someone
defining and using such a data element.  On the other hand, I would also
have no problem with someone defining that same semantic object as <date
context="PurchaseOrder" type="Receipt"> or some such.  Note that in the
second form both 'context' and 'type' might support multiple values, but
that some combinations of 'context' and 'type' might have no semantic
worthiness.  That is, semantics would likely place constraints on the
contexts applicable to date, and the types applicable to dates within
context (or type within context within date, or any other manner one chooses
to express such constraints.  Where message semantic requirements constrain
a date usage instance to type Receipt within context Purchase Order, use of
an element named <PurchaseOrderReceiptDate> may be a user friendly choice.
And if the message designer just wanted to use <ReceiptDate> in a Purchase
Order Message, and <ReceiptDate> in an Invoice Message, and let it inherit
the message context, that's fine as well.

If I followed the 'guid' for PurchaseOrderReceiptDate, I would be unhappy if
it took me to a self-contained semantic definition.  Rather, I woold want it
to provide only the semantic information unique to the combination of date,
context Purchase Order, and type Receipt.  I would want pointers within that
semantic information to other related semantic information, such as semantic
information generic to all dates. 

I also note that context can play an important role in the meaning of
Receipt in this example.  And that context can extend outside the element.
For example, Receipt within context Purchase Order may have different
semantic meaning and impose different legal contracts within context
"GasSupplyIndustry" than with "RetailIndustry".  


********
I envision a future where the X12 and UN/CEFACT dictionaries give way to a
single global encyclopedia of information objects, defined not in teram of
some given syntax, but rather in terms of their semantic meaning,
interrelationships, and defining processes supporting those
interrelationships. I know that dream is a long way from fulfillment.  Yet I
also know our understanding of business processes and the data which drive
and control them has advanced remarkably in the short period of time
represented as the computer generation.  I certainly believe my dream will
be fulfilled in this century, and really expect it to happen within the
first half of this century.  That's still a long time, and well exceeds my
life expectancy.  But it is absolutely a dream that is within reach of those
now entering the profession.
*******
JMc: I hear you! I suspect though that there will be domains of expertise,
each publishing their dictionary (e.g., the digital form of Black's Law
Dictionary, in the US) whose entries are normally subclasses of the entries
in the 'single global' dictionary.
*******
Cheers,
        Bob

-----Original Message-----
From: John McClure [mailto:hypergrove@olympus.net]
Sent: Thursday, March 01, 2001 5:16 PM
To: ebxml-core@lists.ebxml.org
Subject: RE: ebXML Entity Classes - Resend


Thanks Bob for your considered reply.

So I am gathering -- based on this and other notes -- that ebXML may
eventually go down the MOF/XMI/CWM path when it comes to implementing what
is now in the spreadsheet you mentioned. It's unclear to me this moment how
the upcoming metadata collision between the OMG and W3C camps is going to
work out -- I think both are defining resource-types, OMG via UML, and W3C
via RDFS.

Anyway, I am coming from the perspective of having as few moving parts as
possible. My view is that all "process and relationship descriptions" you
mentioned should be placed into a document separate and distinct from the
XML Schema used to define XML elements. A "dictionary" to me is a document
containing <rdfs:Class> elements, and may contain embedded XMI elements.
Then, XML representations of an instance of a resource-type point at these
entries through a 'name' attribute, e.g.,

	<dcn:Property xsi:type='dcn:Debt' name='my_ns:Mortgage'/>

Now, my single greatest objective is to avoid creating thousands (or even
hundreds!) of XML elements - noone can develop to that! noone can maintain
that! Getting there definitely involves a dictionary. In the ebXML
Architecture, it seems the Registry is for registering XML elements, so I'd
like to respectfully suggest that users register their dictionaries,
instead.
Regards,
John
Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)

For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or
http://www.dataconsortium.org/namespace/DCN150.DTD.htm

For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)


-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Tuesday, February 27, 2001 1:28 PM
To: ebxml-core@lists.ebxml.org
Subject: RE: ebXML Entity Classes - Resend


John,

I've not found many folks who talk RDF.  Even I do not talk it well.  Your
response suggests those who do talk RDF can make the leap form ugliness to
cleanliness.  In my experience, most everyone involved in this effort has
(strong) opinions about terminology.  When I first composed the text some
while back, I was intending to target an X12 audience.

I like RDF, though it does have some shortcomings.  I alos like UML, and in
my opinion, since UML was chosen by ebXML to represent processes,
relationships, etc., I think that should be the vehicle used to define these
classes.  Of course, UML can be be rendered in XMI, RDF, or for the subset
that the BP Schema folks are dealing with, in ebXML BP Schema (or whatever
they call it).  Given my druthers among the three, I would pick RDF.  But I
seem to be in among a very small minority.

Nevertheless, I appreciate your comments, which are on target.  I would very
much like to especially see the CC work rendered in RDF.  Sure would be more
useful than EXCEL spreadsheet.

Cheers,
        Bob

-----Original Message-----
From: John McClure [mailto:hypergrove@olympus.net]
Sent: Tuesday, February 27, 2001 3:08 PM
To: ebxml-core@lists.ebxml.org
Subject: RE: ebXML Entity Classes - Resend


Bob,
May I make a suggestion about the "ebXMLSemanticEntityClass" -- maybe make
it more friendly? The DCN has its own base class, "dcnResource", named
consistent with RDF. Resources are, after all, what we are marking up, I
think. By using words like "Semantic" and "Entity", sometimes that reality
can be obscured. Using friendly terms can clarify relationships for a
reader/implementor.

I also don't understand why xml:base and RDF mechanics for identifying
resources is not used for "OwnerURI" and "OwnerID".

For "EntityName", the DCN uses the <rdfs:label> element for this within its
RDFS dictionary however, since I believe that the Dublin Core's <dc:Title>
element is a better fit, I am planning to change over to that. One reason
that I am suggesting RDFS is because you mentioned needing "SubClassOf", and
RDF Schema provides the <rdfs:subClassOf> element. For "Description", how
about using a <dc:Description> element within an RDF Schema?

Just some thoughts that may be helpful to you. I'll talk to the hierarchy
another time.
Regards,
John McClure
jmcclure@hypergrove.com

Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)

For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or
http://www.dataconsortium.org/namespace/DCN150.DTD.htm

For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Tuesday, February 27, 2001 8:14 AM
To: ebxml-core@lists.ebxml.org
Subject: FW: ebXML Entity Classes - Resend


I've heard from two individuals that my attachment got mangled.  As it was a
very short attachment, I've converted it to inline text (losing some
editting structure in the process - sigh):

> Some thoughts on ebXML Classes
>
> Submitted by Bob Miller
> Introduction
>
> The work of the ebXML Core Components Team establishes a set of  reusable
> semantic entities, and establishes that these entities may exhibit
> parent/child relationships.  Generally, documents which define such
> parent/child relationships do so from a single base class.  This permits
> properties associated with various entities to be elevated to the hishest
> common class to which those properties apply.
>
> This submission proposes a base class for all ebXML entities, and two
> direct subclasses, one for aggregate ebXML entities and one for primitive
> ebXML entities.  It suggests that an additional layer of ebXML classes be
> defined to support properties specific to each of the defined ebXML types
> (e.g., type Amount).
> ebXML Semantic Entity Class
> All ebXML entities should derive from a single base ebXML class.  In this
> paper, I identify this class as:
>
> 	ebXMLSemanticEntityClass
>
> Properties of this object include:
>
> OwnerURI
> The URI identifying the owner of the object being defined.  For the
> ebXMLSemanticEntityClass, the owner is TBD.
>
> OwnerID
> A unique ID in the namespace of the OwnerURI.  For the
> ebXMLSemanticEntityClass, the owner ID is:
> [TBD]
>
> EntityName
> A (language-specific) semantic name for the entity.
>
> Description
> A (language-specific) prose description of the semantic entity used to
> specify semantic intent and usage of a defined entity.  May be a URI.
>
> SubClassOf
> The class of which this object is a subclass. For the Base
> ebXMLSemanticEntityClass, the subclass is NULL.
>
>
> ebXML Entity Classes
> There are exactly two ebXML Entity Classes derived directly from the Base
> ebXML Class.  These are:
>
> EbXMLAggregateEntityClass
>
> The basic ebXML container class, used to contain collections of other
> ebXML entities
>
> SubclassOf:		ebXMLSemanticEntityClass
>
> Properties of this object include:
>
>
> {properties used to convey content structure for the object - TBD.  At a
> minimum, some ability to express relationships among members of the
> aggregate is needed.)
>
>
> EbXMLBasicEntityClass
>
>
> The primitive ebXML data entity, used to contain collections of other
> ebXML objects
> All primitive ebXML data representation types derive from this object
>
> SubclassOf:		ebXMLSemanticEntityClass
>
>
> Properties of this object include:
> MaxLen
> The maximum number of bytes this object is allowed to represent
>
> MinLen
> 		The minimum number of bytes this object is allowed to
> represent
>
>
> EbXMLType
> An ebXML data type selected from an enumeration of defined ebXML data
> types Examples of ebXML data types include 'Amount' and 'Quantity'.  Each
> ebXML data type may be further represented as an ebXML class as a subclass
> of ebXMLBasicEntityClass.
>
> NOTE: It may be appropriate to add other type properties here, such as the
> types used to express entity values in specific syntax renditions, such as
> XML, X12 and UN/CEFACT.
>
Personal Comments

>From a UML perspective, I believe the ebXML SemanticEntityClass and
ebXMLBasicEntityClass would be called abstract classes, as they would not be
used directly in entity instantiations.  The ebXMLAggregateEntityClass and
the classes derived from ebXMLBasicEntityClass which are used to represent
defined ebXML types would be concrete classes.

I pulled this from a prior work I did, and have not attempted to match
nomenclature for the class properties with nomenclature in the ebXML CC
documents.  Also, there may be properties defined in the ebXML CC work that
would be appropriately elevated to the classes I've defined (E.g., the root
class should include the GUID.)

The intent of this submission is to foster discussion whether the ebXML CC
documents should define additional classes to provide a hierarchical class
tree emanting from a root class.

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org