RE: Semantic API

Obviously I nicked this from the ebXML standard http://www.ebxml.org/ to get
a full overview.





Business Process and Business Document Analysis Overview 12

Copyright C ebXML 2001. All Rights Reserved.

7 Business Process Modeling 284

7.1 Overview 285

Business process models define how business processes are described.
Business processes 286

represent the "verbs" of electronic business and can be represented using
modeling tools. The 287

specification for business process definition enables an enterprise to
express its business 288

processes so that they are understandable by other enterprises. This enables
the integration of 289

business processes within an enterprise or between enterprises. 290

Business process models specify interoperable business processes that allow
business partners to 291

collaborate. While business practices vary from one organization to another,
most activities can be 292

decomposed into business processes that are more generic to a specific type
of business. This 293

analysis, utilizing business modeling, will identify business processes and
business information 294

metamodels that can likely be standardized. The ebXML approach looks for
standard reusable 295

components from which to construct interoperable processes and components.
296

7.2 Business Process and Information Metamodel 297

The Metamodel is a description of business semantics that allows Trading
Partners to capture the 298

details for a specific business scenario using a consistent modeling
methodology. A Business 299

Process describes in detail how Trading Partners take on roles,
relationships and responsibilities to 300

facilitate interaction with other Trading Partners in shared Business
Process. The interaction 301

between roles takes place as a choreographed set of Business Transactions.
Each Business 302

Transaction is expressed as an exchange of electronic Business Documents.
The sequence of the 303

exchange is defined by the Business Process, messaging and security
considerations. Business 304

Documents are composed from re-useable business information components. At a
lower level, 305

Business Processes can be composed of re-useable Common Business Processes,
and Business 306

Information Objects can be composed of re- useable Business Information
Objects that may be 307

composed of core components and domain components. 308

The Metamodel supports requirements, analysis and design viewpoints that
provide a set of 309

semantics (vocabulary) for each viewpoint and forms the basis of
specification of the semantics 310

ebXML BP/CC Analysis Team March 2001

and artifacts that are required to facilitate business process and
information integration and 311

interoperability. 312

An additional view of the Metamodel, The Specification Schema, is also
provided to support the 313

direct specification of the nominal set of elements necessary to configure a
runtime system in order 314

to execute a set of ebXML business transactions. By drawing out modeling
elements from several 315

of the other views, the Specification Schema forms a semantic subset of the
Metamodel. 316

The Specification Schema is available in two stand-alone representations, a
UML profile, and a 317

DTD. Figure 7.2-1 shows the high-level elements of The Specification Schema.
318



I really liked the spec until schema started to raise it's ugly head. The
ebXML standard is very good but it is still a explicit profiling mechanism.


Then the Web god doth speak
http://www.scientificamerican.com/2001/0501issue/0501berners-lee.html

Ontologies
Of course, this is not the end of the story, because two databases may use
different identifiers for what is in fact the same concept, such as zip
code. A program that wants to compare or combine information across the two
databases has to know that these two terms are being used to mean the same
thing. Ideally, the program must have a way to discover such common meanings
for whatever databases it encounters.

A solution to this problem is provided by the third basic component of the
Semantic Web, collections of information called ontologies. In philosophy,
an ontology is a theory about the nature of existence, of what types of
things exist; ontology as a discipline studies such theories.
Artificial-intelligence and Web researchers have co-opted the term for their
own jargon, and for them an ontology is a document or file that formally
defines the relations among terms. The most typical kind of ontology for the
Web has a taxonomy and a set of inference rules.

The taxonomy defines classes of objects and relations among them. For
example, an address may be defined as a type of location, and city codes may
be defined to apply only to locations, and so on. Classes, subclasses and
relations among entities are a very powerful tool for Web use. We can
express a large number of relations among entities by assigning properties
to classes and allowing subclasses to inherit such properties. If city codes
must be of type city and cities generally have Web sites, we can discuss the
Web site associated with a city code even if no database links a city code
directly to a Web site.

Inference rules in ontologies supply further power. An ontology may express
the rule "If a city code is associated with a state code, and an address
uses that city code, then that address has the associated state code." A
program could then readily deduce, for instance, that a Cornell University
address, being in Ithaca, must be in New York State, which is in the U.S.,
and therefore should be formatted to U.S. standards. The computer doesn't
truly "understand" any of this information, but it can now manipulate the
terms much more effectively in ways that are useful and meaningful to the
human user.

With ontology pages on the Web, solutions to terminology (and other)
problems begin to emerge. The meaning of terms or XML codes used on a Web
page can be defined by pointers from the page to an ontology. Of course, the
same problems as before now arise if I point to an ontology that defines
addresses as containing a zip code and you point to one that uses postal
code. This kind of confusion can be resolved if ontologies (or other Web
services) provide equivalence relations: one or both of our ontologies may
contain the information that my zip code is equivalent to your postal code.

Our scheme for sending in the clowns to entertain my customers is partially
solved when the two databases point to different definitions of address. The
program, using distinct URIs for different concepts of address, will not
confuse them and in fact will need to discover that the concepts are related
at all. The program could then use a service that takes a list of postal
addresses (defined in the first ontology) and converts it into a list of
physical addresses (the second ontology) by recognizing and removing post
office boxes and other unsuitable addresses. The structure and semantics
provided by ontologies make it easier for an entrepreneur to provide such a
service and can make its use completely transparent.


It is very hard to explain relevance because it is totally dependent on the
quality of ontology references. We have two applications each with a
internal application ontology both reference external more generic
ontologies which hopefully at some converge on a singular ontology reference
hopefully at the first hop. Relevance is a reverse of TBLs Search agents
where we know where the data is we just have to find the question.

Like the command line parameter TRACERT [DNSNAME] a list of each hop from
one router to the next across the net is displayed in order of occurrence.
With two destinations and a common source I guess this is what I would call
a expression of relevance.

This is about as far as I have got with my 'Chess' engine as a lateral hop
is exponential to a vertical and I am having much more fun learning the
finer points of gambits.

The AI is quite easy it's the construction of the business process and data
ontology's that is causing me the headaches.



-----Original Message-----
From: www-rdf-interest-request@w3.org
[mailto:www-rdf-interest-request@w3.org]On Behalf Of
jos.deroo.jd@belgium.agfa.com
Sent: 17 April 2001 10:00
To: indtec@eircom.net
Cc: www-rdf-interest@w3.org
Subject: Re: Semantic API




> [...]

fresh thoughts!

> What I have seen so far from anyone out the is still explicit declaration
as
> opposed to inference and selection by relevance.

what do you mean with *selection by relevance* ?

--
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/