RE: ebXML Entity Classes - Resend

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

Mary Kay,

Yes, I've seen some listserv traffic (e.g., from Martin Bryan), that speaks
of rendering CC data in XML Schema!  But that's an end-result (read SYNTAX)
rendering of the table data.  An XML Schema defines syntactic rules.  These
rules have been derived from semantic rules, but as can be observed, neither
XML, nor XML Schema, nor X12, nor UN/CEFACT syntax do full justice to the
rules semantics implies.  Nor do they do justice to the capture of semantic
meaning, since that is not thier purpose in life.

The intent of CC is to capture semantic information as metadata conforming
to some convenient and processable syntax for representing metadata.  I
agree that the spreadsheet is a good tool for such initial data capture.
However, capture in a formal language customarily used to represent metadata
provides a better source for processing metadata to yield specific data
instance syntaxes. If the metadata model is sufficiently rich in detail and
properly populated, algorithmic processes can construct syntactic rules for
languages used to transmit data instances, and for transformers to convert
from one data representation to another.

At some point, I would expect that the current spreadsheet data would be
converted to the selected metadata format.  By that time, I would also
expect that screen based tools used to capture metadata would store such
data directly in the selected metadata format, eliminating the need to use a
spreadsheet for future metadata capture.  Even then, the spreadsheet as a
display tool for core component data might continue to prove useful, in
which case the spreadsheet itself could be automatically geenrated from the
stored metadata.

Cheers,
        Bob

-----Original Message-----
From: Blantz, Mary Kay [mailto:mblantz@netfish.com]
Sent: Tuesday, February 27, 2001 7:07 PM
To: 'Miller, Robert (GXS)'; ebxml-core@lists.ebxml.org
Subject: RE: ebXML Entity Classes - Resend


We're only using the Excel spreadsheet to capture data.  It turned out,
no surprise, that it was one format that everyone, everywhere seemed to
have on their laptops.

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Tuesday, February 27, 2001 4: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