[wg11] Minutes of Part 21 E3 DIS testing telecon on June 5, 2914

Thomas.r.thurman thomas.r.thurman at imonmail.com
Tue Jun 10 18:04:49 EDT 2014


Propose to apply it after.
Will,add an Ip to that effect.

Thanks Thomas!

Tom Thurman

Sent from my iPad

> On Jun 10, 2014, at 7:29 AM, Thomas Liebich <tl at aec3.de> wrote:
> 
> Dear all,
> 
> only as a side remark. During our IFC (ISO16739) developments we faced the same issue - a derived unit involving factor and offset cannot be defined with the current conversion_based_unit.
> 
> So we added a subtype to IFC4, which essentially defines the same, as the proposed extension here for P41.
> See http://www.buildingsmart-tech.org/ifc/IFC4/final/html/link/ifcconversionbasedunitwithoffset.htm
> 
> One important consideration: you need to determine, whether to apply the offset before or after applying the factor. We decided to apply it after.
> 
> hope it gives another insight,
> 
> regards
> Thomas
> 
> -- 
> 
> Am 08.06.2014 01:46, schrieb thomas thurman:
>> Addendum for Fahrenheit discussion.
>> Comments on current approach in part 41 and AP 214:
>> 1-part 41 is specific that any unit that is related to a unit specified in part 41 shall be a ‘conversion_based_unit’.
>> 2-conversion_based_unit only converts the magnitude but does not provide an offset.
>> 3-The use of ISO 13584-20 for such a simple case is long agreed overkill; the example in part 41 F 4.4 has EXPRESS
>> errors (
>> a-the expression_conversion_based_unit shall be a conversion_based_unit (see (1) above.) and
>> b-the attribute redeclaration in e.g., named_unit_variable.associated_variable_environment is invalid.).
>> 4-AP 242 ed1 did not include a structure to support Fahrenheit unit exchange.
>> 5-AP214 used a context_dependent_unit which is invalid (see (1) above). As noted above this was NOT promoted to
>> AP 242.
>> 6-After several attempts to discover a URL,URN for Fahrenheit I gave up and am proposing that SC4 define its own
>> (NIST has a guide that includes a definition of Fahrenheit as a note (I think) but does not provide a URN or URL.).
>> (There are multiple conversion calculators on the web but I am not convinced of their persistence.
>> In any event use of a conversion calculator opens up its own can of worms.)
>> 
>> ==========proposed solution:===========
>> 
>> add a subtype of conversion_based_unit, conversion_based_unit_with_offset to provide the offset.
>> 
>> =========current:============
>> 
>> A conversion_based_unit is a type of named_unit that defines a unit on the basis of a measure_with_unit.
>> NOTE    The value_component attribute of the measure_with_unit defines the conversion factor.
>> 
>> EXAMPLE    An inch is a conversion_based_unit. It is from the Imperial system, its name is "inch", and it can be related to the si_unit, millimetre, through a measure_with_unit whose value is 25.4 millimetre. A foot is also a conversion_based_unit. It is from the Imperial system, its name is "foot", and it can be related to an si_unit, millimetre, either directly or through the unit called "inch".
>> 
>> EXPRESS specification:
>> *)
>> ENTITY conversion_based_unit
>>   SUBTYPE OF (named_unit);
>>   name : label;
>>   conversion_factor : measure_with_unit;
>> WHERE
>>   WR1: SELF\named_unit.dimensions = derive_dimensional_exponents(conversion_factor\measure_with_unit.unit_component);
>> END_ENTITY;
>> (*
>> 
>> Attribute definitions:
>> 
>> name: the label by which the conversion_based_unit is known.
>> 
>> conversion_factor: the measure_with_unit that specifies the physical quantity from which the conversion_based_unit is derived.
>> 
>> Formal propositions:
>> 
>> WR1: The dimensional exponents shall be equal to those from the conversion_factor.
>> 
>> 
>> =========proposed addition to part 41=========
>> A conversion_based_unit_with_offset is a type of conversion_based_unit that includes a scale offset.
>> EXAMPLE    A Fahrenheit is a conversion_based_unit_with_offset. It is from the Imperial system, its name is “fahrenheit", and it can be related to the si_unit, degree Celsius, through a measure_with_unit whose value is 1.8 degree Celsius. The offset is 32 degree Celsius.
>> 
>> EXPRESS specification:
>> 
>> *)
>> ENTITY conversion_based_unit_with_offset
>>   SUBTYPE OF (conversion_based_unit);
>>   offset : REAL;
>> WHERE
>>   WR1: offset <> 0.0;
>> END_ENTITY;
>> (*
>> 
>> Attribute definitions:
>> 
>> offset: the value of the offset represented in the units of the conversion_factor inherited from the conversion_based_unit.
>> 
>> Formal propositions:
>> 
>> WR1: The offset shall not be zero.
>> 
>> Note: If the offset is zero, then the supertype conversion_based_unit is used.
>> =========end proposed addition to part 41=========
>> 
>>> On Jun 6, 2014, at 3:29 PM, Martin Hardwick <hardwick at steptools.com> wrote:
>>> 
>>> P21 e3 DIS Testing
>>> Minutes of June 5, 2104 Telecon
>>> Attendees
>>> Martin Hardwick <hardwick at steptools.com> 
>>> Robert Lipman <robert.lipman at nist.gov> 
>>> Michael Benda <mjbenda at rockwellcollins.com> 
>>> Hedlind Mikael <mikael.hedlind at scania.com> 
>>> Dave Loffredo <loffredo at steptools.com> 
>>> Ed Paff  <ejp at transcendata.com> 
>>> Tom Thurman <thomas.r.thurman at imonmail.com>
>>> Apologies for Absence
>>> Jochen Fritz <jfritz at steptools.com>
>>> Nicolas Figay <nicolas.figay at eads.net> 
>>> 
>>> PMI Splitting
>>> ITI has split the sp3_boxy file produced by NIST into a geometry file and a pmi file. STEP Tools has viewed the geometry file and is working on a viewer for the separated pmi file. The two files and the original NIST data can be found at the following URL:
>>>  
>>> ftp://www.steptools.com/private/P21e3_DIS_testing/PMI/
>>>  
>>> STEP Tools is sponsoring the development of open source programs to split and merge P21 files using the Edition 3 specification. The programs are available at the following URL: http://tinyurl.com/thundercode.
>>>  
>>> ZIP Assemblies
>>> No visible progress has been made on this test case since the last telecom, but the PMI merge and split code is being updated to handle this case as well.
>>>  
>>> ftp://www.steptools.com/private/P21e3_DIS_testing/ZIP_Assembly/
>>>  
>>> In the last telecom:
>>> ·         We decided the sub-tree directory names should include the NUAO identifier(s) for their corresponding node in the assembly tree.
>>> ·         We learned that the LZMA algorithm has been shown to make STEP files three times more compressed than the more commonly used deflate algorithm, but at the cost of an increase in the compression time.
>>> ·         We learned that each compressed file is required to document the algorithm used for its compression in its header and that different components in the same ZIP can used different compression algorithms.
>>> ·         We recommended that the choice of the best compression algorithm should be left to the end user and that the standard should be silent on the matter.
>>>  
>>>  
>>> Unit Definitions
>>> The unit definitions have been merged into a single file called units.stp.
>>>  
>>> ftp://www.steptools.com/private/P21e3_DIS_testing/Units/
>>>  
>>> We continued our discussion on whether unit references should be encoded as a URL or a URN. The following two lines of code show equivalent URL’s and URN’s.
>>>  
>>> <http://standards.iso.org/iso/10303/tech/reference_data/41/si_base_units.stp#METRE>;
>>> <urn:iso:std:iso:10303:-41:tech:unit:metre>;
>>>  
>>> Explanation of URN:
>>> urn                  Indicates this URI is a URN, instead of the more common URL (http)
>>> iso                   URN namespace  (other examples are oid, usbn)
>>> std                   ISO standard 
>>> iso                   originating organization (other examples are iec, iso-ies, iso-cie)
>>> 10303             STEP standard
>>> -41                  part of multipart standard (hyphens required)
>>> Tech               associated or embedded resource defined by committee that created the standard
>>> <the rest>      unspecified -- controlled by committee.
>>>  
>>> In the above example, the URN has small advantage over the URL but perhaps the following URN will be acceptable because a file does not have to exist to define a URN.
>>>  
>>> <urn:iso:metre>;
>>>  
>>> It is also conceivable that the following URN might be acceptable even though there are currently small technical issues stopping the deployment of unit definitions for a Fahrenheit measure in a STEP file.
>>>  
>>> <urn:iso:Fahrenheit>;
>>>  
>>> We further discussed the requirements if all the unit definitions are to be defined in STEP files. The definition of literal constants such as PI, and EXPRESS constants such as negri_pi, have both led to extensive additions to the edition 3 format for which other strong use cases are currently lacking.
>>>  
>>> On the other hand the problem might be that we have not been sufficiently ambitious. It was pointed out that if constants can be defined then we are close to allowing expressions to be defined. The use of the PLIB schema for expressions has never been very satisfactory because the expressions are too hard to read when encoded into the STEP files. However, if Part 21 has an expression evaluation capability (probably in the anchors) then potential STEP applications such as parametrics and construction history might become more tractable. One interesting possibility might be to use Modelica as the expression language.
>>> 
>>> Digital Signatures
>>> STEP Tools gave a demonstration of how to make a digital signature using a private key and a signing certificate and how to verify that a file has not been edited since it was signed using a public key.
>>>  
>>> ftp://www.steptools.com/private/P21e3_DIS_testing/Digital_signatures/
>>>  
>>> We discussed white space and the issues that might arise if a file is read into Notepad/Wordpad and converted from line-feeds to carriage returns or vice versa. These characters are explicitly excluded from the Part 21 character set so they will not be included when computing and verifying the hash value.
>>>  
>>> We discussed supporting multiple signatures. The easiest procedure is for each signature to be applied to all of the characters that precede that signature. Thus each new signee is also verifying the signature of the previous signees.
>>>  
>>> For this to be consistent it would be best if the signatures came after the END-ISO-10303-21 keyword as shown in the example on the ftp site.
>>>  
>>> ·         The next conference call will be held on Friday June 27 at 4PM Paris, 3PM London, 10AM New York and 7AM Seattle.
>>>  
>>> Action Items
>>> 1.    Complete the first ZIP assembly example.
>>> 2.    Consider the best approach for unit definitions: URN’s or URLs’?
>>> 3.    Consider if Edition 3 should offer any support to the definition of parametrics and if so how?
>>> 4.    Extend the digital signatures example to include the creation of signing certificates.
>>> 5.    Demonstrate signing at one site (ITI) and verification at another site (STEP Tools).
>>>  
>>>  
>>> As recorded by Martin Hardwick <hardwick at steptools.com> 
>>> 
>>> <Minutes_p21e3_DIS_conference_call_05062014.docx>_______________________________________________
>>> wg11 mailing list
>>> wg11 at steptools.com
>>> http://lists.steptools.com/mailman/listinfo/wg11
>> 
>> Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> wg11 mailing list
>> wg11 at steptools.com
>> http://lists.steptools.com/mailman/listinfo/wg11
> 
> -- 
> beste Grüße / kind regards
> 
> Dr.-Ing. Thomas Liebich
> Geschäftsführer / Director
> 
> AEC3 Deutschland GmbH
> AG München, Handelsregister HRB 164221
> Geschäftsführer: Dr. Thomas Liebich, Kerstin Hausknecht
> Wendl-Dietrich-Str. 16, D-80634 München
> Tel: +49-89-18703223
> Fax: +49-89-18703224
> E-Mail: tl at aec3.de
> Internet: www.aec3.de
>  
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger Anhänge) von Ihrem System. | This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.steptools.com/pipermail/wg11/attachments/20140610/60f20ee6/attachment.html>


More information about the wg11 mailing list