RE: [plcs-dex] Business_specific reference data in representing_part

[Peter Bergström <peter.bergstrom@eurostep.com>]

I rest my case here. PLCS do rely on external reference data, and implementations must take that into account.

I have edited the templates representing_product_as_realized and representing_breakdown_element so they no longer mandate the use of template assigning_business_specific_reference_data for life cycle support and application domain. 


Peter


-----Original Message-----
From: David Price [mailto:david.price@eurostep.com] 
Sent: den 23 januari 2007 14:45
To: plcs-dex@lists.oasis-open.org
Subject: Re: [plcs-dex] Business_specific reference data in representing_part

All,

Sounds to me like the DEX development may be mixing standardization with 
implementation - not a good thing. 

Comments like "If we demand <RDL access>, post-processors will be slowed down 
significantly, and imports will be vulnerable to internet down-periods and 
such." are a typical example. Specifying that an RD class is identified as 
http://www.example.com/rd/projectx/classY and is standardized in a set of OWL 
ontologies says almost nothing about how a post-processor actually accesses 
the RD at runtime.

I'd suggest that the TC needs to be making it clear that PLCS DEX-based 
exchange *depends on RD* - full stop. The TC should also not put artificial 
burdens on pre-precessors based on unsubstantiated post-processor efficiency 
issues (i.e. you could actually be making things worse). It should leave it 
to implementors to figure out how to efficiently access an exchange file and 
the related RD. The TC can't know what technology, platform, scale or 
requirements implementor/user organizations have in mind and so details about 
how implementors make processors efficient are not something TC should be 
enforcing at this point in time.

Cheers,
David

On Monday 22 January 2007 16:38, Peter Bergström wrote:
> Tim,
>
>
>
> I would like you to change the reference data template used for
> view_definition_context life_cycle_stage and application_domain in template
> representing_part from assigning_reference_data to
> assigning_business_specific_reference_data.
>
>
>
> This issue comes from implementing post-processors, where it is not always
> possible to know what reference data should be mapped to what attribute of
> view_definition_context without having access to the correct RDL. This
> happens as soon as other values is used than those defined in the OASIS
> standard reference data library. An example: If I chose to define
> 'production' as a life cycle stage and 'electronics' as an application
> domain, it is impossible for computers to understand what value belongs to
> which attribute (or field), without access to the RDL.
>
>
>
> I do not intend that it should be OK to import files without performing a
> validation of the import file, and consolidation with internal data. I do
> think, however, that we should not mandate how the exact implementation of
> the import is done (i.e. in what order the different steps are performed,
> e.g. validating P28 against xml-schema, cashing data into internal memory,
> consolidating against existing data, load data, or whatever the steps are).
> A post-processor must be able to perform validation and consolidation of
> data, but it does not have to know the definition of reference data, or
> what the content of the file really means. It just need enough data to
> perform its job.
>
>
>
> I'm not saying that a PLCS file should be understandable without access to
> the RDL at all times, but I'm saying that for a post-processor to be able
> to load and compare an exchange file with the internal database, the access
> to the RDL must not required. If we demand that, post-processors will be
> slowed down significantly, and imports will be vulnerable to internet
> down-periods and such. But with a simple use of
> assigning_business_specific_reference_data for all cases where there are
> two assignments of reference data to one entity, where they are supposed to
> be mapped against two discrete attributes or fields in the database, this
> problem will be easily overcome. This does not apply to cases when you have
> multiple classifications, since all those values should be mapped to the
> same field or concept. The only occurrence I know of is for the
> view_definition_context where we have life_cycle_stage and
> application_domain, and they are impossible to separate or combine without
> the RDL, as the template is written now. This may also be the case where we
> have both identifier and name attributes for data where it is not possible
> to separate a name from an identification using string comparisons, for
> instance. However, there are not many entities which have both a required
> name and a required identifier, and even less templates that requires both.
> I know that the view_definition_context is a problem for post-processors.
>
>
>
> And if we do not build in a solution to this problem already in the DEXlib
> templates, we will never be able to build post_processors that can operate
> optimized without immediate access to RDLs.
>
>
>
> So please, could you change the use of asg_ref_data in template
> representing_part into asg_business_specific_ref_data (with fixed values
> for the plcs_class)? This change does not change the parameters defined,
> only the path (and the diagrams), so it is really a quite harmless change.
>
>
>
> See template representing_product_as_realized as an example.
>
> Peter
>
>
> This message contains information that may be privileged or confidential
> and is the property of Eurostep Group. It is intended only for the person
> to whom it is addressed. If you are not the intended recipient, you are not
> authorized to read, print, retain, copy, disseminate, distribute, or use
> this message or any part thereof. If you receive this message in error,
> please notify the sender immediately and delete all copies of this message.

-- 
Mobile +44 7788 561308
UK +44 2072217307
Skype +1 336 283 0606