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
|