OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ebxml-dev] ebXML core components derivation by restriction

Ron, Carl,
 
<Fred>Wrt OWL/RDF, in my experience there are few non-academic souls on
this earth that really comprehend those standards (so much the same like
CCTS ;-). I am not one of them (yet). Personally, I would love to see
convergence between the OWL/RDF ontology work and the CEFACT/OASIS Core
Components work. As far as I understood though, OWL/RDF is mainly related
to semi-structured data, while Core Components are applicable to very
structured data (even an SAP system must understand it ;-).</Fred>

<Ron>Since you say you "would love to see convergence between the OWL/RDF
ontology work and the CEFACT/OASIS Core Components work" then perhaps you
are open to the notion that the objects (BIEs) and properties (CCs) of
CCTS can be represented in an ontology framework. If that is true, then
perhaps we have a starting point for further discussion.</Ron>

We sure have! I'd be very interested in it. Note however that in CCTS
speak ABIE's represent the objects and ASBIE's and BBIE's the properties.
The BIE-CC axle is the level of abstraction.

<Carl>If you are open to this idea please help me produce a (storybook)
use case
that will be referenced by the ebXMLRegistry Semantic Content SC.</Carl>


Carl, I am open to that idea. Any suggestions how to set up such
storybook?

<Ron>For the properties, if you start with the basic premise that Core
Components are fundamentally basic data representation types (date, date
time, amount, name, etc.) plus allowable specializations or extensions
(e.g., cost amount, price amount, tax amount, first name, middle name,
last name, etc.) those basic data representation types are the root or top
of an ontology of Core Component types. The basic data representation
types (date, amount, text, etc.) are the highest level of abstraction for
the properties. Each basic data representation type is the foundation for
its own ontology.

For the objects, it becomes necessary to force BIEs to a sufficiently high
level of abstraction that conceptually they become mutually exclusive
concepts in the context of an enterprise. Some basic high level of
abstraction objects applicable to any business enterprise include:
Enterprise, Product, Document, Person, Process, Asset, etc. Each basic
high level of abstraction object can also be subtyped and therefore each
is the foundation of its own ontology. For example, Purchase Order
Document, Work Order Document, Invoice Document, Contract Document, etc
are all types of documents.

I recommend that you look at
http://www.ebxmlforum.org/articles/ebFor_20040306.html and also
http://www.udef.org/specdoc/UDEFv1pt03-July-2003.htm for the complete list
of basic data representation types (properties) and a candidate list of
basic business enterprise objects. As suggested in the article, the UDEF
tree structures could provide a ready made library of Core Components and
BIEs.

I am open to the idea of helping create a use case (storybook) referenced
by the ebXML Registry Semantic Content SC.</Ron>

Do have a look at the REA ontology
(http://www.msu.edu/user/mccarth4/rea-ontology/), that is targeted to the
application area of the exchange of economic values. In my opinion it is a
good starting point as top-ontology. The key concepts in it are Agents,
Resources, Commitments and Events.

<Ron>How do you want to proceed?</Ron>


I am open to any suggestion.

Fred

 

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]