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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bcm message

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


Subject: RE: [bcm] Semantic Layers: Building out for business stake holders


Bob,

Here, here.   However, the concepts that the BCM group is advancing may not
be easy dumb up as it is a really deep area, just as there is no "Quantum
Physics for Dummies" book available for the same reason.

What business folks do understand is Value Chain Assessment Techniques, as
have been successfully applied at GSA and a number of commercial concerns.
This approach focuses FIRST on defining the business needs and how these
relate to needed processes, supported by technology.   If we can front end
the BCM with some type of Value Chain approach, I believe we can then
position BCM as a critical part of a broader Enterprise Life Cycle.

The ICH published a paper on this Value Chain Approach at the last
SecurE-Biz Summit, and has been posted at www.ICHnet.org.  The most
important part of this business driven EA method is that it has already
produced quantifiable business transformation results at GSA.

Our desire to participate in various technical architecture standards
efforts (OASIS BCM, OMG MDA, IEEE 1471, ISO RM-ODP), is to help bring a real
business focus to these worthwhile efforts.

As we are hosting the OASIS e-Gov TC meeting during our Fall EA Bootcamp in
Northern VA, might I suggest we provide a platform for these and related
issues to be discussed and promoted to the Federal EA community.

Just my 2 Cents.

Cheers,

john



-----Original Message-----
From: Robert Greeves [mailto:GREEVESR@OJP.USDOJ.GOV]
Sent: Tuesday, June 10, 2003 5:27 PM
To: bcm@lists.oasis-open.org
Subject: Re: [bcm] Semantic Layers


This is an excellent discussion of issues that are important to the
evolution of our product.

However, I sincerely hope that when the final product is agreed upon, that
it will be written in a way that Business Executives can comprehend it
without having to know the "jargon" of the Standards community.

I find that concepts such as Metadata, Ontology, Taxonomy and Topic Maps go
over the head of the average business person in government. If we want them
to pay attention to our product we need to voice it in terms of the need to
document our data using International standards, find ways to search for
data that is of interest to us, generate schemas that can be used to
facilitate information exchange, store artifacts in registries/repositories
that will facilitate access and exchange, accommodate data exchange
partnerships, etc., etc. etc. - in other words it needs to be written at the
third grade level of common sense.

****************************************************************************
***

>>> "CarlMattocks" <CarlMattocks@CHECKMi.com> 06/10/03 05:00PM >>>
Folks:

To ensure the 'discussion' on Semantic Layers (et al) has the appropriate
focus - please peruse the assertions below and let me know :
>if it is too trivial
>what questions it prompts
>what it does not say
>where it could be used

Semantic Layers

Classification
Semantic layers use semantic relationships and controlled vocabularies to
increase the meaning of metadata and provide context to items that have
metadata properties . Historically, semantic layers have been used by
(information) scientists to classify unstructured knowledge. Currently there
is a lost of discussion about expanding the application of semantic layers
to provide domain links for semi-structured information and structured
information. Whatever the usage, the key benefits of using semantic layers
are:
&#61623; The body of knowledge is partitioned into logical groupings
&#61623; Users can discover information using a single word search term
&#61623; Topic to sub-topic, drill down searches are supported
&#61623; Domain scopes are declared
&#61623; The ambiguities of the (English) language are less problematic

Controlled Vocabulary, Taxonomy, Thesaurus, Ontology, Business Model, Topic
Maps?
A simple lexicon that only contains the definition of words used by a
particular group of professionals can be considered a controlled vocabulary.
Ontologies, Taxonomies and Thesauri relate terms in a controlled vocabulary
via parent-child and associative relationships. Business Models contain
associative relationships, they also contain explicit grammar rules to
constrain how to use controlled vocabulary terms to express (model)
something meaningful within a domain of interest. More formally :

A controlled vocabulary is a list of elemental terms that have been
enumerated explicitly. This list is controlled by and is available from an
authority, such as, ACORD. Ideally, all elements in a controlled vocabulary
have a unique label and an unambiguous, non-redundant definition, as in:
1. If  a (term) token of an element label is commonly used to mean different
concepts in different contexts, then that token is explicitly qualified to
resolve the ambiguity.
2. If multiple terms are used to mean the same thing, they are considered
(equally alternate) synonyms.

A thesaurus is a networked collection of controlled vocabulary terms. This
means that a thesaurus uses associative relationships in addition to
broader-narrower (parent-child) relationships, e.g. synonym. The
expressiveness of the associative relationships in a thesaurus vary and can
be as simple as "related to term" as in term A is related to term B.

A taxonomy is a collection of controlled vocabulary terms organized into a
hierarchical structure. Each term in a taxonomy is in one or more
parent-child relationships to other terms in the taxonomy. There may be
different types of parent-child relationships in a taxonomy (e.g.,
whole-part, genus-species, type-instance). In a poly-hierarchy, a term can
have multiple parents, yet it has the same children in every location.

An ontology can mean different things and the definition continues to evolve
since developers of agent-based software consider that each (semantic) web
service must be defined in un-ambiguous terms. That is, ontologies allow a
web service to be 'published' using a language that expresses something
meaningful within a specified domain of interest. Therein, the ontology
grammar contains formal constraints (e.g., specifies what it means to be a
well-formed statement, assertion, query, etc.). OWL Web Ontology Language
can be used to explicitly represent the meaning of terms in vocabularies and
the relationships between those terms. However, it is intended to be used
when the information contained in documents needs to be processed by
applications, as opposed to situations where the content only needs to be
presented to humans.

A business model is an explicit model of the constructs and rules needed to
map specific types of processing and data within a domain of interest e.g.
namespace. Many accept the statement that the contents of a domain specific
business model would contain the same type of knowledge as an ontology with
the same scope.

A Topic Map is an ISO standard for building knowledge about a domain and
integrating this encoded knowledge to information resources that are
considered relevant to the domain. Topic maps are organized around topics,
which represent subjects of discourse; associations, representing
relationships between the subjects; and occurrences, which connect the
subjects to pertinent information resources.  The first version used SGML
DTDs the latest version is based on  XSDs (schemas). A topic map processor
is any module or system that can process topic maps.



cheers
carl
Carl Mattocks
CEO CHECKMi
e-mail: CarlMattocks@checkmi.com
*******************************************
Business Agent Software that
Secures Knowledge for Reputation:Protection
*******************************************
CHECKMi Compendium the shortcut to Valued & Trusted Knowledge
*******************************************
www.checkmi.com
(usa)1-908-322-8715


---------------------------------------------------------------------
To unsubscribe, e-mail: bcm-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: bcm-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: bcm-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: bcm-help@lists.oasis-open.org



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