Thanks Rob,
I left one thought out on my previous mail regarding the
'contract' vs 'Dex' issue. I am reminded that normally (AP) users set up a
Protocol Implementation Concurrence Statement (PICS), in which to record an
exchange agreement. The Protocol Implementation
Conformance Statement (PICS) proforma states the options or the combinations of
options that may be included in the implementation. Maybe this could be adapted as the basis of contracts,
extending it to include the business concept requirement definitions,
templates (or refs to templates) and mappings to the
identified Dex.
I
think the more we can show re-use of already accepted ideas (like PICS) &
reduce introduction of new terms, the better - even if we have to redfine that
term for Dex users.
regards,
Tim
-----Original Message----- From: Rob Bodington
[mailto:rob.bodington@eurostep.com] Sent: 08 September 2005
12:01 To: 'Tim Turner'; plcs-dex@lists.oasis-open.org Cc:
'Martin Gibson'; 'Phil Rutland' Subject: RE: [plcs-dex] Business
concepts
I have taken your
point about templates being refined / or defined in a business concept and am
investigating the impact on the XSL
-----Original
Message----- From: Tim Turner
[mailto:tjt@lsc.co.uk] Sent:
08 September 2005 16:54 To:
'Rob.Bodington@eurostep.com'; Tim Turner;
plcs-dex@lists.oasis-open.org Cc: 'Martin Gibson'; 'Phil
Rutland' Subject: RE:
[plcs-dex] Business concepts
Hi, I have snipped a little of
the headers to save endless scrolling to read my latest
comments.
No
problem, but since we're talking about 'architecture' etc., I would like
to raise a question about templates which has been at the back of my mind
recently.
Is
it possible that different templates (maybe similar, but refined), would
be developed by & for business specific purposes? I raise this
question because it seems like a possible scenario, given that we
have been developing templates for the generic (or widest accepted) usage.
Just as with the reference data - we started off just with the most
generic stuff required to support a capability, but now we have bus.
specific ref.data. If bus. specific concerns can generate new/refined
templates, then acc. to fig1, this would probably require a new
capability.
If
your current fig1 below is correct, then this would somehow feedback to
the capabilities in general & the exsting templates. However, if
somehow the templates were managed separately from the capability, then
different templates could be 'plugged-in' to support the different
bus.concepts & ref.data. This might then reduce the number of
escalating capabilities required and even consolidate some where there is
already considerable overlap. If the Dexs had the ability to act as a
configuration mechanism (as they do now for
capabilities) they might also specify which templates
(assuming several valid for each cap) are to be usedwithin a data
exchange contract.
[RBN]
Don't quite understand what you mean by feedback. The business concepts
are in affect the definition of a mapping from a business construct to
PCLS entities. This mapping is expressed via templates. The templates are
defined within a capability as they are expressing how to use a subset of
the information model of a capability.
[Tim
Turner] Changing a template as a result of a business concept
requirement would (acc. to your existing diagram below) require a change to
the capability's use of the same template. Just as you mention
above, it's an interpretation of the capability's info model. However, what
is the relationship between a template defined purely for the generic
capability and one which is defined through a business concept?
If one is based upon the other, how do we show that? I think there are, or
will be a need for both and we'll need to re-jig the figure to accomodate
this aspect.
RBN2]
No - the template is "used" - not "defined" in the business
concepts
[Tim
Turner] See my last comment below.
Irrespectively of
this waffle, I would suggest that your fig might use the term DEC (Data
Exchange Contract) rather than overload DEX.
[RBN]
I would rather not introduce yt more terms (which is why I tried to
understand if a data exchange contract had anything more than a business
DEX)
[Tim
Turner] Your figure labels a Business DEX as a Data Exchange
Agreement. Previously, they were called contracts. I don't know when the
name changed.
RBN2]
If it is a DEX - lets call it a DEX
[Tim
Turner] I have not been present during some of the recent meetings,
but from the definition you repeat below (which 'identifies' the Dex to be
used / refered to in a contract) I cannot quite see how you arrived at
"Once
I looked into this I felt that it was really a dex defined using business
concepts". This
justification sounds like a re-write of a Dex acc. to a business terms rather
than a mapping of the business concepts to those provided in the Dex.
Your
good effort on manufacturer_item shows exactly how some business requirements
can be mapped to the template suggested for parts. This business requirement
representation and concept mapping are precisely what needs to go into the
contract. The contract may just reference the relevant Dex specification (my
preference) or include it in an Annex (versioned copy of..). However, I don't
think that this justifies calling the contract a
Dex.
I
believe that moving away from the standard Dex term is a dangerous one,
as this will confuse just about everyone. If it is a contract -
lets call it one! :-)
Also, I'd
perhaps suggest that a business concept is not defined_by a
capability. The business concept can be exchanged 'in the context of' a
specified capability. It is actually the bus.concept which defines the
context (through the ref data and mapping) in which the capability is
used. (I think this is what led me to thinking about templates
specific for a particular type of bus.concept...)
[RBN]
I'm not sure that I agree. Take a look at the manufacturers_item example.
I think that it is important that a business concept is defined by
templates that are within the capabilities. The reason being is that as
far as possible we want to have a consistent interpretation of the PLCS
model. That is why we have capabilities and
templates.
[Tim
Turner] In this sentence you say that each bus. concept must be defined
by templates within a capability. I think that each capability
should have a slot for a template, (else we may have to develop new
capabilities for each bus. usage). By default, the generic one is used
unless a business concept defines another (for use within a defined Business
Dex). The alternate may be (should be?) based upon the original/default
template. The manufacturers_item example provides one view of a template
defined in the context of TLSS. I can easily imagine another project might
define something similar, but different for their project, based
upon other business concepts. Which of these two should go into C002?
Or should there be a generic one by default?
RBN2]
I absolutely agree that a template should be defined in a capability and
that all capabilities should define temapltes. The opnly reason why there is
a template defined in Manufactures-Item is that the required template
"representing_part" had not been defined in the capability representing
part. I thought that I had made this clear in my email about manufacturers
item (which is why I send you the VISIO for representing part) - sorry I was
obviously not clear enough.
[Tim
Turner] I am not talking about where the suggested template
for representing parts is currently stored. I'm talking about the fact that
for some business users, there are occaisions when a template as defined by a
certain capability may not be sufficient. E.g. specifying a particular
subset of reference data for part_identification_code; such as setting the
organization id to always be 'XYZ' etc.,. For these occaisions we may
need to either modify the original template in the capability, create &
manage a new template or just leave it as is (not recommended). The point is
that we have not identified a process to deal with this issue & the
resolution of it may impact the architecture figure.
regards,
Tim
-----Original
Message----- From: Rob
Bodington [mailto:rob.bodington@eurostep.com] Sent: 31 August 2005
12:35 To: 'Tim Turner';
plcs-dex@lists.oasis-open.org Cc: 'Martin Gibson'; 'Phil
Rutland' Subject: RE:
[plcs-dex] Business concepts
Hi
I
confess - I was a bit hasty in sending out the
diagram.
I
meant to explain that we previously talked about "Data exchange
contracts" but never really defined them beyond:
Identify the DEX
and its version
Identify the
relevant conformance class (documented in the DEX)
Identify business
concepts (which again refer to business specific sets of reference data)
Reference data
library / ref data sources
Bounding scope of
reference data
Data
representation rules and constraints (for data validation)
Explanation of how
that information is represented is defined in the capabilities
Once I looked
into this I felt that it was really a dex defined using business
concepts. Hence the suggestion that it should be referred to as a
"Business DEX". What else would go into an exchange contract (apart from
the legal / service / availability / liability aspects) and do we want
to provide that in DEXlib?
I
agree with you Tim, that a Business DEX should use the same XML as a
PLCS DEX.
However, a PLCS
DEX refers to the PLCS activity model. A Business DEX, might
not.
I
need to look into the impact of using the DEX XML to represent Business
DEXs.
In
the meantime, here is an updated diagram reflecting the comments so
far.
BTW - so far
nobody has said they preferred the original diagram, so I will make the
change in the help files (we can modify this as a result of any further
discussion)
-----Original
Message----- From: Tim
Turner [mailto:tjt@lsc.co.uk] Sent: 31 August 2005
16:41 To:
'rob.bodington@eurostep.com'; plcs-dex@lists.oasis-open.org Cc: 'Martin Gibson'; 'Phil
Rutland' Subject: RE:
[plcs-dex] Business concepts
I
had not heard of business dex before. However, in our context I can
see it might be useful.
However, I
don't know that a Dex is defined by business concepts (fig2). I'd
suggest that they use business concepts. Also, I'd presume that they may
be based upon a PLCS Dex. In fact, both should be based upon the PLCS
Dex template.
How
will Dexlib differentiate between these two types of
Dexs though?
-----Original
Message----- From:
Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 31 August 2005
08:46 To:
plcs-dex@lists.oasis-open.org Cc: 'Martin Gibson'; 'Phil
Rutland' Subject: RE:
[plcs-dex] Business concepts
Hi
In the
proposed diagram, I should probably include Templates in a capability.
Also, The
Business DEXs that are arguably the same as a Data exchange agreement-
though a data exchange agreement may well have additional legal
information.
There perhaps
should also be a relationship between a "Business DEX" to a "PLCS DEX"
indicating that the Business DEX conforms to the PLCS
DEX.
-----Original
Message----- From:
Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 31 August 2005
13:21 To:
plcs-dex@lists.oasis-open.org Cc: 'Martin Gibson'; 'Phil
Rutland' Subject: RE:
[plcs-dex] Business concepts
Hi
I have also
attempted to refine the diagram that shows the relationship between
the DEXS, business concept, ref data etc.
If everyone
agrees, I would like to replace the following figure in Introduction
with the diagram below
-----Original
Message----- From:
Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 31 August 2005
12:01 To:
plcs-dex@lists.oasis-open.org Cc: Martin Gibson; Phil
Rutland Subject:
[plcs-dex] Business concepts
Hi
I have now
completed the changes to the business concepts.
Basically, a
business concept must be defined within a context.
This has
meant a fair amount of change to DEXlib XSL. If you find that anything
does not work, please tell me.
Details on
how to create a business concept are provided in the
"Developing a
Business concept" help pages. This also explains the new business
concept directory structure. If this does not make sense, then let me
know, or propose some changes.
I
have also provided a section in the "Introduction" help pages that
describes business concepts. Whilst I was at it, I "improved"
the section describing
reference data. See what you think.
If anyone has
been developing business concepts, please contact me about migrating
the old business concepts to the new.
I have
deleted the existing business concept directories:
dexlib/data/busconcept/allowance_parts_list
dexlib/data/busconcept/bc_template
dexlib/data/busconcept/identify_a_part_and_its_constituent_parts
dexlib/data/busconcept/manufacturers_item
Let me know
if these should e retained.
I have
created one example context TLSS and defined a single business concept
within it: "manufacturers_item"
Regards Rob
------------------------------------------- Rob
Bodington Eurostep Limited Web Page: http://www.eurostep.com
http://www.share-a-space.com Email:
Rob.Bodington@eurostep.com Phone: +44 (0)1454 270030 Mobile: +44
(0)7796 176 401
DISCLAIMER:
***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this
message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient, any disclosure,
copying, or distribution of the message, or any action or omission taken
by you in reliance on it, is prohibited and may be unlawful. Please
immediately contact the sender if you have received this message in
error. This e-mail originates from LSC Group. Registered in England
& Wales No 2275471 Registered Office: Devonport Royal Dockyard,
Devonport, Plymouth, PL1 4SG
DISCLAIMER:
***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this
message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient, any disclosure,
copying, or distribution of the message, or any action or omission taken
by you in reliance on it, is prohibited and may be unlawful. Please
immediately contact the sender if you have received this message in error.
This e-mail originates from LSC Group. Registered in England & Wales
No 2275471 Registered Office: Devonport Royal Dockyard, Devonport,
Plymouth, PL1 4SG
DISCLAIMER:
***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this
message is confidential and may be legally privileged. It is intended solely
for the addressee. Access to this message by anyone else is unauthorised. If
you are not the intended recipient, any disclosure, copying, or distribution
of the message, or any action or omission taken by you in reliance on it, is
prohibited and may be unlawful. Please immediately contact the sender if you
have received this message in error. This e-mail originates from LSC Group.
Registered in England & Wales No 2275471 Registered Office: Devonport
Royal Dockyard, Devonport, Plymouth, PL1 4SG
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY
MARKED*** The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message by
anyone else is unauthorised. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or omission
taken by you in reliance on it, is prohibited and may be unlawful. Please
immediately contact the sender if you have received this message in error.
This e-mail originates from LSC Group. Registered in England & Wales No
2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1
4SG
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
|