RE: [plcs-dex] RE: Capability property value ranges + documents

Tim,

Sorry for the delay, and thanks for getting back to me.

’m going to work on properties later this month, and will be back then with comments.

I hope that’s OK?

Peter

From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 20 december 2006 17:47
To: Peter Bergström; Tim Turner; Hendrix, Thomas E
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE: Capability property value ranges + documents

Peter,

sorry for the delay - I would like to tidy up the discussion we previously had on properties and documents.

I did not have time to respond to some points which you rightly raised back in May due to moving onto other work - however, I am now in the process of working on the document templates for TLSS and realised this discussion had not been resolved. I have included your original mail beneath my clarifications to your individual questions below.

Firstly, it was my original opinion - like yours, that this should all be managed through one set of capabilities rather than making documents require a separate, specific capabilities for providing the same functionality as other products. If nothing else, it means a greater amount of maintenance in the longer term & possible redundancy if/when dependent capabilities change (like they are now).

However, it was decided by those originally providing the properties functionality that documents were not within the scope of that work (& I now think I understand why) - hence I had to create my own capability for this purpose.

Hence I hope to answer as many of the questions below as possible as propose some resolutions.

regards,

Tim

From: Peter Bergström [mailto:peter.bergstrom@eurostep.com]
Sent: 25 May 2006 03:30
To: 'Tim Turner'; 'Hendrix, Thomas E'
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE: Capability property value ranges

OK, so the rule was OK, and we _could_ use document properties.
[Tim Turner Replies:] We could but ....

But why not use product properties as they are instead? A document is a product, and there is nothing in the product properties as they are now that is illegal for documents - since they are products, right?
[Tim Turner Replies:] I think here you are suggesting that we do not use the properties designed specifcally for documents, because if we were to use a document_property_representation, then yes, there are further constraints on the model to restrict the types of representation_item (to either descriptive_document_property or numerical_document_property - see C087), plus the value of the context.kind attribute must be set to "document parameters". Also, if you were to use assigned_document_property, then you are restricted (sensibly) to only types of File and Document_definition entities to which properties could be assigned.

Previously, and I think this now gets to the heart of the matter - Document_definition was an Abstract Supertype existing separately from Product_view_definition. Since properties for products are associated thru the Product_view_definition entity meant that Documents had to be treated differently - and this was the case when the capabilities were originally documented.

However, this appears to have been corrected in the IS version of the PLCS ARM and now Document_definition is a subtype of product_view_definition, but the caps are still behind.

Aside: I was not asked to review the document model changes but they look ok - although document_assignment seems to permit circularity (e.g. I can now assign a document_version to another document_version via a document_assignment..!).

So I don't understand what you say we have to prune out unnecessary items, and have to ensure that we don't allow for any illegal associations? [Tim Turner Replies:] If we do not allow usage of the document property model (specifically those mentioned above) then we would need to ensure that the many constraints & rules are respected in the template parameter options and allowable reference data.

To a document_definition or a subtype of file, you may assign Assigned_property, in which case you are using product properties _as they are_.[Tim Turner Replies:] Yes and this allows many un-realistic associations IMHO, which was why the subtype was provided (I presume).

[Tim Turner Replies:] If we were to mandate that the document property model is not used in an exchange file then you would be correct and the general property model could be used as is. As it now stands, documents can be assigned properties from either position which leaves ambiguity in the model as to which interpretation should be followed.

You may also assign a Assigned_document_property, and then you branch off into the document specific properties which are similar to the product properties _but not the same_.
[Tim Turner Replies:] Without using the full document property model it is possible to relate a document_property_representation (such as number of pages) to something other than a document_definition or file (by using assigned_property) to an instance of state, for example, which to me is meaningless. So either we use it all or we allow some strange associations to take place. Of course not using any of the document property model at all would allow any (& potentially meaningless) properties to be assigned - so we would be relaxing the model too much perhaps!

Why would we ever use document_properties that are specific?[Tim Turner Replies:] Document_property_representation has a function which restricts the values of the .name attributes of document properties assigned. Hence for a document_property_representation with a .name of "document content" the document property.name must be one of "detail value", 'geometry type', or 'real world scale'. If 'document creation' is used then it restricts to one of 'creating interface', 'creating system', or 'operating system' etc..

However, this function probably needs to be removed or re-engineered now as it enforces certain combinations of the .name attributes for Document_property_representation and Representation.items, which should probably be given in reference data to be consistent with the rest of the approach. Note. there are other alternatives to work around this problem - as has been done for similar things elsewhere (e.g. view_definition_context & product_category).

The only other benefit in using the document property subtypes would be in the separation of properties and reference data associated with documents verses those for other types of product, e.g. part, individuals..etc..

There would seem to be 3 solutions;

------------------------------------------------------

i) use the document property model & develop templates/ref data accordingly;

ii) remove C087 & ban use of the document property model in favour of the general product property model & allow odd associations

iii) option ii) + additional rules to constrain populations.

Under i) the document property model is documented in C087 (which requires updating as suggested) but would permit a clear representation of this part of the model. However, the templates need to be developed (could be refined from product_properties).

Under ii) The general property model appears to be very open in comparison - allowing many (potentially meaningless) properties to be defined against documents and other product subtypes. Plus it is not certain that banning usage would be adhered to without a SEDS against 239.

Under iii) Again, I think we can't modify the model without a SEDS..

Given the circularity in the model (refered to earlier) I suspect that more rules are required in any case.

Proposal:

---------------

All in all, I think it's a subjective decision to be made between i & ii; I would favour i) with sticking to what we have at present & just refine a new set of templates for documents. This would also demand a specific set of reference data to go with it.

Option ii) is possible, but relaxes the model (not always a good thing) & may be difficult to enforce outside of our community (e.g somebody else may create the templates for them instead at a later date or still use the document properties because they are in the model. To avert this we would need to state boldly the objection for their use in CC076 if we had concensus.Otherwise reference needs to be made to C087 from C076 for use with documents.

Comments?

-----------------

Regards,

Tim

OK, so the rule was OK, and we _could_ use document properties.

But why not use product properties as they are instead? A document is a product, and there is nothing in the product properties as they are now that is illegal for documents - since they are products, right? So I don't understand what you say we have to prune out unnecessary items, and have to ensure that we don't allow for any illegal associations?

To a document_definition or a subtype of file, you may assign Assigned_property, in which case you are using product properties _as they are_.

You may also assign a Assigned_document_property, and then you branch off into the document specific properties which are similar to the product properties _but not the same_.

Why would we ever use document_properties that are specific?

Peter

From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 22 maj 2006 20:49
To: 'peter.bergstrom@eurostep.com'; Tim Turner; 'Hendrix, Thomas E'
Cc: 'plcs-dex@lists.oasis-open.org'
Subject: RE: [plcs-dex] RE: Capability property value ranges

Hi Peter,

For the issue about document properties, I think the rule is saying that for each instance of assigned_document_property, it must point to one item in the described_element select list (document_definition/file etc..), which I think is fair; if you're going to bother to define a property you might as well assign it to the document it is defined for. This only reinforces the fact that each property must be represented separately (rather than a list/set etc..). There can be many descriptive_document_property or numerical_document_property instances assigned to each described_element (e.g. no of pages, weight, size etc.).

The 30 rules on assigned_property.described_element select type basically serve to limit the 32 choices in the select type referenced down to 2 (document_definition/file)... which is an odd way of achieving the requirement, but legal from what I can tell (note this is done elsewhere within PLCS also).

I raised the subject of why documents had to be dealt with differently around 1.5 yrs ago & after a long discussion had to create another capability for this purpose. It is still foggy in my mind what the reasons were, but I guess we could trawl the archive. If C076 can cover the template requirements for document properties then I think that would be useful, but we then would need to move the contents of C087 somewhere which I'm not certain would make others so happy & may complicate what we have. So we might need to keep C087, however, the template could easily be referenced from C076 for the purposes of properties though we have to ensure that whichever template is used doesn't allow illegal associations to be made. I suspect that the template for docs will need to be based upon that for products but may need to prune out the unecessary items & include those specific for docs.

Other points below accepted

regards,

Tim

From: Peter Bergström [mailto:peter.bergstrom@eurostep.com]
Sent: 22 May 2006 13:39
To: 'Tim Turner'; 'Hendrix, Thomas E'
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE: Capability property value ranges

Thanks Tim, I think I have understood your requirements, and propose to do the following:

1) In Cap00 Repr_value_with_unit I will include your template repr_value_with_unit. I propose to change the in-parameter name unit_class_name to unit (you need to change your figures accordingly).
I will commit this capability as I propose it shortly.
The template should also be given a real number (ROB: How do I achieve this, and which number should I give it?)

2) In Cap079 Repr_properties_numerically I will leave the template repr_properties_numerically (I never intended to remove it, but was not clear earlier).
You propose to make a reference parameter for entity Numerical_item_with_value, and I will consider it, but I think we should have an example of somewhere where we would possibly need it (and I can't find any, except possibly in the repr_location - where you say you don't need it). If somebody can give me an example, I'll put it in. Otherwise I think it is easier (= less confusion) not to include it.
I will also change the names of the in-parameters as follows:
- unit_class_name becomes unit
- rep_class_name becomes context
- rep_ecl_id becomes context_ecl_id
This will require changes in existing caps and templates that already use it, but I think it affects only the property capabilities I'm already using, and the 2410 Business Concept. I will write issues against the business concept, and correct the property templates accordingly.

3) I will not use your template Repr_numerical_value_with_unit, since I can't find a need for it (since we have what's needed for properties in cap079). If an example is provided (same as above) I will instead include the reference parameter in the template repr_properties_numerically, and that will solve that.

Regarding document_properties, I'm terribly confused. I tried to include them in the full property-solution, but was flabbergasted by the express where rule wr1:

ENTITY Assigned_document_property

SUBTYPE OF (Assigned_property);

SELF\Assigned_property.described_element : document_property_item;

DERIVE

SELF\Assigned_property.name : STRING := 'document property';

UNIQUE

UR1 : SELF\Assigned_property.described_element;

WHERE

WR1 : SIZEOF(['AP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF.DOCUMENT_DEFINITION',

'AP239_PRODUCT_LIFE_CYCLE_SUPPORT_ARM_LF.FILE'] * TYPEOF(SELF\

Assigned_property.described_element)) = 1;

END_ENTITY; (* declared in: Document_properties_arm *)

Hopefully I have misunderstood the rule, but as far as I understand, a document must have ONE AND EXACTLY ONE property !!!

If this is true, the entire document_property part of the model is crap, and we should just ignore it. A Document is a subtype of Product, so why treat it differently - Use Product-properties!!

And really, even if I have misunderstood the document property rule above, why _would_ we treat document properties different from any other product properties? I would just add to the confusion, IMHO.

My proposal is to write in the cap076 that it applies for all subtypes of Product (including Document), and remove Cap087.

Peter

From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 22 maj 2006 18:14
To: 'peter.bergstrom@eurostep.com'; Tim Turner; 'Hendrix, Thomas E'
Cc: 'plcs-dex@lists.oasis-open.org'
Subject: RE: [plcs-dex] RE: Capability property value ranges

Hi Peter,

I have made some observations below. Hopefully, it clarifies your questions :-)

regards,

Tim

From: Peter Bergström [mailto:peter.bergstrom@eurostep.com]
Sent: 20 May 2006 14:07
To: 'Tim Turner'; 'Hendrix, Thomas E'
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE: Capability property value ranges

Hi Tim,

Now I have looked at your templates, and the way you use them, and I have a few questions:

In your template representing_numerical_value_with_unit you have included the Property_value_representation entity, but as far as I understand from Cap Representing_location you are not using it. The inclusion appears to have been a copy-paste mistake. If so, I think I understand your requirements (i.e. everything but Property_value_representation.
[Tim Turner Replies:] Correct - on on the 1st point, less so on the second! I found template representing_numerical_value_with_unit unecessary after reviewing the requirements again, but left it in case it was useful for others.

The reason for including the Property_value_representation is that for complex subtypes of Value_with_unit e.g. Numerical_value_with_unit there is a rule which states that it must be referenced by an instance of representation (as a .item if I remember). The point is that you cannot just instantiate the NIWU by itself due to the rule inherited by Measure_item.

For locations, it is only required to use Value_with_unit, which then removes the requirement for a separate representation (it is not a subtype of Measure_item). The representation, however, is useful for associating the values with a product, property or process (for which there are the relevant hooks in those parts of the model) - however, Location is (unfortunately) none of the above.

I can see two resolutions here:

1) I change the Representing_numerical_value in cap Representing_properties_numerically to include a reference parameter ^item, in which case you would get exactly what you have now, or

2) I edit your representing_numerical_value_with_unit by deleting the Property_value_representation entity, and use that in Representing_numerical_value. It would then have a reference parameter ^item, and it would be located in Cap Representing_value_with_unit.
[Tim Turner Replies:] did try to use C079 to begin with but realized that the NIWU was allowed as a ref parameter, so began with my own version to enable the assignment to a location. I also deleted the prop_val_rep & context because I could see no use in Location for it - until I discovered the rule during validation. Hence the state of the template representing_numerical_value_with_unit in rep.locns cap.

The first choice is the easiest for me, but kind of cludgy, so I think I go for the second choice.
[Tim Turner Replies:] I think your I think we will need both a template for representing_value_with_unit where the value_with_unit is referenceable and a template for representing_properties_numerically. I would suggest to make the numerical_value_with_unit entity instance referenceable as well so that other representations can re-use them when necessary.

So I would keep your existing Representing_numerical_value in C079, but make the NVWU referenceable. I also recommend adding the template for Value_with_unit to C00, as is.

I'm however not sure that I will include the representing_value_with_unit template in Cap Representing_value_with_unit. To me, I can't see the difference between a value with unit and a numerical value with unit, and it seem to me that it will only confuse issues ('which one is applicable where?'). Can you or someone else enlighten me regarding their difference?
[Tim Turner Replies:] See my points above. I think the value with unit template is needed for those items which are not product, processes or properties, but which need a value with unit.

Also, bear in mind that there is also the document_property_representation which will need to re-use some of these templates as this is not covered.

Comments?

Cheers,

Peter

From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: den 18 maj 2006 17:01
To: 'Hendrix, Thomas E'; 'peter.bergstrom@eurostep.com'
Cc: 'plcs-dex@lists.oasis-open.org'
Subject: RE: [plcs-dex] RE: Capability property value ranges

Hi Peter,

For your info, I have just managed to get my sourcefoge account operational again & have uploaded some work from last week during the outage.

Inside representing_location, you will see that there are 7 templates - 2 of which are additional templates that were done during development of this capability. These are; representing_value_with_unit (- the previous one in C00 - version 1.6 had many errors) & representing_numerical_value_with_unit. The first should be moved to the appropriate place while the second was found not to be necessary - but I have left it since it works & may serve a purpose sometime.

Kind regards,
Tim

NB - all work without error in GI

-----Original Message-----
From: Hendrix, Thomas E [mailto:thomas.e.hendrix@boeing.com]
Sent: 18 May 2006 10:30
To: peter.bergstrom@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] RE: Capability property value ranges

Peter,
Go for it.

Regards,

Tom

Thomas E. Hendrix
Phone: 206-544-5276
thomas.e.hendrix@boeing.com

-----Original Message-----
From: Peter Bergström [mailto:peter.bergstrom@eurostep.com]
Sent: Thursday, May 18, 2006 6:39 AM
To: Hendrix, Thomas E
Cc: plcs-dex@lists.oasis-open.org
Subject: Capability property value ranges

Tom,

I'm editing the property capabilities in DEXlib now, and need three templates in cap representing_property_value_ranges, one for range, one for limit and one for value with tolerance.

Can I take over the editorship temporarily, or will you do it?

Peter Bergström
Eurostep AB

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

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.

plcs-dex message