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

Martin Hardwick hardwick at steptools.com
Tue Jun 10 10:22:23 EDT 2014


Hi Thomas,

Thanks for this feedback.

I am growing in favor of using a simple URN for all the "famous" (well 
known units).

Hence, we might have in the reference section of a P21 e3 file:

#10=<urn:iso:metre>;
#20=<urn:iso:inch>;
#30=<urn:iso:centigrade>;
#40=<urn:iso:Fahrenheit>;
#50=<urn:iso:furlong> ;
#60=<urn:iso:inches-per-second>;

And so on for all the units that the standards want to recognize. There 
would not need to be any files to define these units (but there could 
be). Software systems would be expected to "know" them from the URN and 
that would include knowing how to convert between them.

(Without benefit of a conversion based expression - oh my gosh what will 
happen if there is an apocalypse and the only people left are idiot 
savant nerds who only know how to follow mathematical expressions and 
cannot remember any units except the ones stored in the NIST library 
which was the only building in Washington to survive the catastrophe of 
course) - Yes I will be made to regret this statement.

Martin


On 6/10/2014 9:29 AM, Thomas Liebich 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* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.named_unit> that 
>> defines a unit on the basis of a *measure_with_unit* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.measure_with_unit>. 
>>
>>
>> NOTE    The *value_component* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.measure_with_unit.value_component> attribute 
>> of the *measure_with_unit* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.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* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.si_unit>, 
>> millimetre, through a *measure_with_unit* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.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* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.si_unit>, 
>> millimetre, either directly or through the unit called "inch".
>>
>> _EXPRESS specification:_
>>
>> |*)
>> ENTITY conversion_based_unit
>>   SUBTYPE OF (named_unit 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resource_docs/fundamentals_of_product_description_and_support/sys/18_schema.htm#measure_schema.named_unit>);
>>   name : label 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resource_docs/fundamentals_of_product_description_and_support/sys/25_schema.htm#support_resource_schema.label>;
>>   conversion_factor : measure_with_unit 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resource_docs/fundamentals_of_product_description_and_support/sys/18_schema.htm#measure_schema.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* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/support_resource_schema/support_resource_schema.htm#support_resource_schema.label> by 
>> which the *conversion_based_unit* is known.
>>
>> *conversion_factor: *the *measure_with_unit* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.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* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.conversion_based_unit.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* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.si_unit>, 
>> degree Celsius, through a *measure_with_unit* 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resources/measure_schema/measure_schema.htm#measure_schema.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 : R 
>> <file:///Users/tom/Documents/2013/SMRLv5/SMRL_v5_rc5/data/resource_docs/fundamentals_of_product_description_and_support/sys/18_schema.htm#measure_schema.measure_with_unit>EAL;
>> 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 
>> <mailto:hardwick at steptools.com>> wrote:
>>
>>> *P21 e3 DIS Testing*
>>> Minutes of June 5, 2104 Telecon
>>>
>>>
>>>     Attendees
>>>
>>> Martin Hardwick <hardwick at steptools.com> <mailto:hardwick at steptools.com>
>>> Robert Lipman <robert.lipman at nist.gov> <mailto:robert.lipman at nist.gov>
>>> Michael Benda <mjbenda at rockwellcollins.com> 
>>> <mailto:mjbenda at rockwellcollins.com>
>>> Hedlind Mikael <mikael.hedlind at scania.com> 
>>> <mailto:mikael.hedlind at scania.com>
>>> Dave Loffredo <loffredo at steptools.com> <mailto:loffredo at steptools.com>
>>> Ed Paff <ejp at transcendata.com> <mailto:ejp at transcendata.com>
>>> Tom Thurman <thomas.r.thurman at imonmail.com> 
>>> <mailto:thomas.r.thurman at imonmail.com>
>>>
>>>
>>>     Apologies for Absence
>>>
>>> Jochen Fritz <jfritz at steptools.com> <mailto:jfritz at steptools.com>
>>>
>>> Nicolas Figay <nicolas.figay at eads.net> <mailto: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:
>>> urnIndicates this URI is a URN, instead of the more common URL (http)
>>> iso URN namespace  (other examples are oid, usbn)
>>> stdISO standard
>>> isooriginating organization (other examples are iec, iso-ies, iso-cie)
>>> 10303STEP standard
>>> -41part of multipart standard (hyphens required)
>>> Techassociated 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> 
>>> <mailto:hardwick at steptools.com>
>>>
>>> <Minutes_p21e3_DIS_conference_call_05062014.docx>_______________________________________________
>>> wg11 mailing list
>>> wg11 at steptools.com <mailto: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
>
> -- 
> Signature
>
> 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 <mailto:tl at aec3.de>
> Internet: www.aec3.de <http://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./
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> wg11 mailing list
> wg11 at steptools.com
> http://lists.steptools.com/mailman/listinfo/wg11

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.steptools.com/pipermail/wg11/attachments/20140610/c558f31c/attachment.html>


More information about the wg11 mailing list