Re: FW: [plcs-dex] Unique constraints

[David Price <david.price@eurostep.com>]

When implementating PLCS it's the most specific ontology that's most 
important, not the PLCS ontologies. External_class_library should refer to 
the organization-specific extension ontology that imports the PLCS (and 
perhaps other) ontologies. Otherwise, you cannot know the correct set of 
superclasses/subclasses that are possible. You already have the Class.id to 
specify the URI of the class so just use it properly. You'd only need one 
External_class_library instance in an exchange file and this would mean that 
External_class_library and RDL are synomyms and mean "the set of ontologies 
required for a given context" and the identifier for the RDL or 
External_class_library is that of the most organization-specific ontology.

I think the versioning question is pretty much independent of the identifier 
question.

On Versioning Classes

Seems to me we have to agree on what it means for two classes to be the same, 
and then what it means to have versions of a class. A relatively 
straightforward approach follows.

Two classes are the same if they have the same membership, in the broader 
sense of possible members over time (or in 4D if you prefer to think that 
way), not only those members contained in an exchange today.

Classes may have versions (of their definitions). So, two versions of a class 
have the same membership. A version of a class simply changes something about 
its definition (e.g. clarifies or adds text). Of course, the original intent 
of the developer can be taken into account (e.g. when a definition is 
too "loose" and allows unintended membership then treating the new definition 
as a version of the existing class seems practical).

When the cases arise where developers are considering a "new version of a 
class" where membership is different, then in fact they're developing a 
superclass or subclass of the existing class (i.e. they are developing a 
different class). That said, a new superclass (and perhaps even a subclass) 
can replace the industrial usage of an existing class. In these cases it is 
possible for the old class to be deprecated or indeed eventually removed from 
the ontology. That's a pragmatic, not semantic, decision.

I have to write this stuff up for an RD Methodology spec project so ... more 
to come.

Cheers,
David

On Friday 15 December 2006 13:37, Tim Turner wrote:
> Title: Versioning and identification of RD and RDL
>
> All,
>
> Partly connected to Davids and Tims questions/comments below regarding
> "Unique constraints", is the question of versioning and identifying
> Reference Data (RD) and Reference Data Libraries (RDLs).
>
> For those of you who doesn't already know, I have earlier suggested (and
> still is in favour of) the use of "meaningless identifiers" for the OWL
> rdf:ID element instead of an english human interpretable term. What hasn't
> been discussed is if versions of RD classes/libraries will become a reality
> and how this should be handled.
>
>  I have put together a couple of slides with some of my thoughts and how I
> look at this topic. I hope they can contribute to this discussion...
>
> Regards,
>   Mats
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Mats Nilsson, FMV
>
>    _____
>
> Från: Tim Turner [mailto:tjt@lsc.co.uk]
> Skickat: den 14 december 2006 19:07
> Till: plcs-dex@lists.oasis-open.org
> Ämne: 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
> <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
> <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
> <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.eurostep.com <http://www.eurostep.com>
>
> > >> <http://www.share-a-space.com/ <http://www.share-a-space.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