RE: [plcs-dex] Unique constraints

[Tim Turner <tjt@lsc.co.uk>]

Title: RE: [plcs-dex] Unique constraints

Hi,

Just thought I'd add some comments to this thread.

1. In the templates provided for capabilities the external_class_library.id is the agreed PLCS RDL URN. A URN can be used to talk about a resource without implying its location.

The external_class.name is another URN for the subclassification name within the resource identified. However, when a template is instantiated, I believe that the full location/access mechanism for the RDL needs to be provided in the external_class_library.id URN. This is possible because a URN is a type of URI.

2.   The "standardized reference instances" are single entity instances whose attribute value(s) (e.g. view_definition_context.life_cycle_stage and view_definition_context.application_context) are unique in the population of view_definition_context instances. This helps to reduce the number of redundant instances & decreases the file/db size. This is similar to the EXPRESS unique statement for one or more entity attributes.

3. The uniqueness of a specific set of instantiated entities (AFAIA)is possible, but would normally be implemented within the EXPRESS schema as a global Rule. Indeed, I think this has been part of the approach of the NDLO (IMHO). For example, enuring that  all instances of external_class (with an external_class_library whose .id value is 'urn:plcs:rdl:std') assigned to a collection of parts must be unique - can be defined in EXPRESS.

4. I think it is reasonable to want to restrict the same collections of instance data from being repeated throughout a file or db.

5. The solution should not restrict alternates from being specified - they should not be exclusive. Hence the "Tank" classification could exist in any rdl & should be permissable. However, we would seek to limit the same identical combinations of "tank" and the rdl where it might be located.

6. The real question is whether a template can enforce such constraints upon a data set that can only be realised after all the templates have been expanded.

7. My view is that this (6) is an implementation/usage issue for the tool(s) used to create/validate the data populations, and probably only possible when all the templates have been expanded.

8. However, where groups of templates are configured, where one is dependant upon another, it may be possible (with extension to the template instantiation definitions) to check whether the some/all of the parameter values supplied have the same value or not. This may provide a mechanism through which some of these constraints could be executed by an implementation/support tool, before (or as) the instance data is created.

9. Any such constraints placed within or at the template level must support the functionality of the capability for which the template was defined. They must allow the options or configurations allowed within the capability and must not over-constrain the data or limit the semantics.

10. Another question is whether such constraints should form part of the final DEX (EXPRESS) schema?

11. Down the implementation road, it is probably not just uniqueness rules that will be required. For example, ensuring that valid values have been provided across the range of entities to support a particular concept.

Kind regards,
Tim Turner

-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 11 December 2006 17:28
To: plcs-dex@lists.oasis-open.org
Subject: Re: [plcs-dex] Unique constraints

I've been under the impression that Class.id was the full URI. Is that incorrect? It seems like an RDL (which is I assume what External_class_library maps to) is likely to have multiple ontologies in it as well. Or am I missing something?

DP

On Monday 11 December 2006 22:16, Per-Åke Ling wrote:
> See below.
>
> David Price wrote:
> >> For example, If you have a view_definition_context with lifecycle "PLCS"
> >> and application_context "PLCS" there should only be one instance of this
> >> in a part 21 file.
> >
> > These sound more like standardized reference instances.
> >
> >> External classes are another good example. In the
> >> Assigning_reference_data, I would like to specify a uniqueness
> >> constraint which states that the combination of
> >> External_class<=Class.name & External_class_library.id
> >> are unique
> >
> > That's a huge, likely unenforceable, contraint. It's also likely not
> > correct. Only the URIs for the classes need be unique. There are Tanks
> > that are military vehicles and there are Tanks that are storage
> > facilities and as long as they have separate URIs then there isn't really
> > any reason to force uniqueness of that name.
>
> The combination of reference library (as identified by a URN) and a name
> within that library is unique, due to the constraints of OWL (the name
> is used as an id). So, it is certainly enforceable and makes perfect
> sense: In an exchange file or a PLCS repository there is only a single
> object of type External_class_library with a specific ID, and for each
> term in that library there will only be a single instance of
> External_class, Both of these constraints can trivially be expressed in
> Express as uniqueness constraints.
>
> There are much thornier cases such as identification_assignment, where a
> possible uniqueness constraint would depend on organization,
> classification and effectivity. It is not really clear if this is too
> restrictive or even desirable.
>
> >> In other words, there should only be one external-class with that name
> >> in any given RDL
> >>
> >>
> >>
> >> I have modified the DTD, XSL and XML to accommodate this.
> >>
> >> As an example I have modified assigning_reference_data and
> >> assigning_identification
> >>
> >>
> >>
> >> For assigning_reference_data
> >>
> >> The xml is:
> >>
> >>       <unique_rules>
> >>
> >>         <unique_rule name="External class">
> >>
> >>           <unique_param param="class_name"/>
> >>
> >>           <unique_param param="ecl_id"/>
> >>
> >>         </unique_rule>
> >>
> >>       </unique_rules>
> >>
> >>
> >>
> >> This is displayed as:
> >>
> >>
> >>
> >> Uniqueness constraints
> >>
> >> The following parameter combinations specify a uniqueness constraint.
> >>
> >> Unique constraint: External class
> >>
> >> There shall be at most one instance of the entities instantiated by the
> >> template with the combination of the following template parameters:
> >> class_name
> >> <file:///D:\users\rbn\sforge\plcs\dexlib\data\templates\assigning_refere
> >>nce _ data\sys\section.htm#assigning_reference_data_class_name> , ecl_id
> >> <file:///D:\users\rbn\sforge\plcs\dexlib\data\templates\assigning_refere
> >>nce _ data\sys\section.htm#assigning_reference_data_ecl_id> .
> >>
> >>
> >>
> >> What does everyone think?
> >>
> >>
> >>
> >> Regards
> >> Rob
> >>
> >> -------------------------------------------
> >> Rob Bodington
> >> Eurostep Limited
> >> Web Page:  <http://www.eurostep.com/> http://www.eurostep.com
> >> <http://www.share-a-space.com/> http://www.share-a-space.com
> >> Email: Rob.Bodington@eurostep.com
> >> Phone: +44 (0)1452 810 960 (note new number)
> >> Mobile: +44 (0)7796 176 401

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

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