[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: A few of my own : RE: Problems with Classifications
Sam, this is an great posting!! I plead ignorance to the wealth of
information on this topic (no pun), but it represents comparable thoughts
that I have had in last few months about classification schemes. I will
study this is detail, but I can quickly see that it has potential.
My current thoughts has been based in UML; perhaps a mapping is possible or
already exists.
If you are suggesting we should think beyond the traditional classification
schemes, I agree. All of our examples to me look more like object models
(M0 level) and that is not powerful enough in my book. I always had the
belief that classification schemes can span across multiple metalevels (in
OMG terms), and the more abstract such as the MOF, the easier it is to map
to code or xml interfaces, etc.
Also, I believe that individuals have different viewpoints on an object, and
multiple classification schemes should be supported. I strongly we should
support the concept of views, common in RDBMS. For example, if I used the BP
metamodel as a classification scheme, I could potentially find trading
partners that used a specific communications protocol such as http, or for
another person, find trading partners that offered a product or service.
The result set could be of the same type (e.g., TradingPartnerList ), while
the root would be different. I have used the analogy of a fishing net in
the past, where the net represents a model, and I pick different spots on
the net to represent different views on the same information. Therefore
specifying a parent of a classification scheme is NOT necessarily a good
idea, and needs to be looked at in our information model.
I also believe that multiple classification schemes can be assigned to the
same object which Topics seems to suppport. I believe that schemes can be
interrelated, which addresses a real life scenario of incorporating a common
business object into UML class diagram and tracking which models use that
CBO.
Soooo...having said that...do we absolutely need to specify and persist a
scheme's composition or do we just discover the composition of a scheme at
runtime via the DOM? Perhaps we treat composition as arbitrary and move
on...
thoughts?? flame??
Scott
-----Original Message-----
From: Sam Hunting [mailto:shunting@ecomxml.com]
Sent: Friday, September 29, 2000 3:51 PM
To: Len Gallagher; Nieman, Scott
Cc: ebxml-regrep@lists.ebxml.org
Subject: Re: Problems with Classifications
Strong analysis of the weaknesses of representing a classification scheme
with nested containment!
Recalling the requirement not to "reinvent the wheel", has the WG considered
representing classification schemata with
ISO 13250 for "Topic Maps" or is (forthcoming) allied specification, XTM, or
topic maps for XML? Topic maps meet the requirements for classification
schemes expressed below.
Some pointers:
http://www.oasis-open.org/cover/topicMaps.html
http://www.topicmaps.com/
Sam Hunting
EComXML
XML Evangelist
----- Original Message -----
From: "Len Gallagher" <LGallagher@nist.gov>
To: "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>
Cc: <ebxml-regrep@lists.ebxml.org>
Sent: Friday, September 29, 2000 10:31 AM
Subject: Problems with Classifications
>
> ebXML RegRep group,
>
> At our teleconference yesterday we agreed to go with version 0.2 of the
> Information Model specification for the Proof of Concept (poc)
> demonstration in Tokyo. That seems OK since a demo can always work around
> problems. However, I think the representation of classification schemes
in
> version 0.2 is broken and implementors should be aware of that as they
> prepare their products for the demo.
>
> Consider the following simple classification scheme for wood (W) that
could
> be used to classifiy all wood as either hardwood (HW) or softwood (SW).
>
> W
> / \
> / \
> HW SW
>
> This would be represented in the version 0.2 information model as 3
> ClassificationNode's, where each node is a ManagedObject with one
> additional attribute, namely a pointer to its parent. So the three nodes
> would be represented as:
>
> (W, -)
> (HW,W)
> (SW,W)
>
> These three nodes are stand alone objects, the model does not capture the
> fact that the definer thought of them as a group of three nodes to
> determine a classification scheme.
>
> Later a different definer wants to create a classification scheme for
> materials (M) and wants to re-use the existing scheme for wood. The intent
> is that all materials will be classified as plastic (P), wood (W) and its
> subclassifications, or other (O), and the intended classification scheme
is:
>
> M
> / | \
> / | \
> P W O
> / \
> / \
> HW SW
>
> The new definer creates the new nodes for M, P, and O, but wants to
> reference W for wood. There is no way the second definer can have W point
> to M as parent because W already has a null pointer for its parent
> attribute, and that node is owned by a different definer. So the definer
> will have to create a new node W' that points to M as its parent and
> somehow has a Ref to W as that portion of the hierarchy. We'll get the
> following representation:
>
> (M, -)
> (P, M)
> (W',M) with Ref to W
> (O, M)
>
> The only way to capture this reference to W in the existing model is for
> there to be a strong 1:1 association from W' to W captured in the metadata
> for W'. This is possible, but the association would have to be uniquely
typed.
>
> Now suppose a product is classified as HW, and a user asks the registry to
> provide the path to HW from the root node. The representation is broken
> because there is no unique path to a root; instead, there are two choices:
> W-->HW derived from the first classification scheme or M-->W'-->HW
> derived from the second classification scheme.
>
> There is no way for the system to determine which path is intended because
> the system didn't retain the information that there were two separate
> classification schemes involved in the definitions! And the user has no
way
> to communicate to the system which classification scheme is intended.
>
> SOLUTION
>
> It was a mistake to try to simplify the notion of classification scheme by
> deleting the notion of a classification scheme being a separate object
with
> a fixed set of nodes as its content. We need to go back to the concepts as
> discussed in version 0.1 and think of a classification scheme as a
distinct
> object, with a fixed number of nodes, and a partial ordering over those
> nodes to determine a fixed hierarchy.
>
> All that is needed to achieve the desired result is an identifier for each
> separate classification scheme, say A for the original scheme and B for
the
> derived one. Then the classification HW specified by the user could be
> qualified by the intended classification scheme, A or B, to determine
which
> path is the correct root-to-node path for that node.
>
> As a follow-on, we could relax the requirement that each node be a
> ManagedObject and instead only require that each classification scheme be
a
> Managed <space> Object with metadata captured in a corresponding
> ManagedObject. Then one could easily create new classification schemes
> using existing classification schems for its various nodes, with no
> abiquity when questions involving predecessors, descendents, or levels are
> posed. The UML diagram I distributed earlier this week defines the
> necessary subtype relationships and associations among
> ClassificationScheme, ClassificationItem (or Node), and
> ClassificationLevel. The diagram is missing the notion that a
> ClassificationItem could reference another ClassificationScheme, but that
> is an upward compatible extension.
>
> -- Len
>
> p.s. May I again respectfully submit that Managed <space> Object be
called
> a RegisteredObject, or possibly a ManagedObject if that fits better with
> ebXML terminology in other working groups, and that what's currently
called
> ManagedObject be re-named a RegistryEntry. This would relieve untold
> confusion! Too many people think of the managed object being the Profile
> or BusinessProcess that is registered instead of the metadata for that
object.
>
>
>
>
> At 06:18 PM 9/28/00 , Nieman, Scott wrote:
> >The dialup information is:
> >USA: 800.892.0357
> >Sorry no toll-free for International callers: usa 612.352.7899
> >25 call-in sites are reserved
> >
> >Meeting ID: 0942
> >
> >Agenda:
> >1) registry service v0.8 review
> >2) repository information model
> >
> >Scott
>
> **************************************************************
> Len Gallagher LGallagher@nist.gov
> NIST Work: 301-975-3251
> Bldg 820 Room 562 Home: 301-424-1928
> Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213
> **************************************************************
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC