[wg11] units of measure, from Minutes of Part 21 E3 DIS testing telecon on June 5, 2914
Thomas.r.thurman
thomas.r.thurman at imonmail.com
Tue Jun 10 20:15:12 EDT 2014
The purpose behind the units thing in P21 ed3 EXAMPLEs is to help move things forward,
as opposed to just having examples in p41.
The BIPM has made general quantities and units document publicly available, but ISO 80000-x
is still behind a paywall which means I have to buy a copy of it to understand what a term means.
What is the business process for moving forward?
Regards,
Tom
Sent from my iPad
> On Jun 10, 2014, at 4:11 PM, Martin Hardwick <hardwick at steptools.com> wrote:
>
>
> Hi Ed,
>
> Thanks for these comments and before anyone gets the wrong idea let me state emphatically that Part Edition 3 is NOT, NOT, NOT planning to define any units. We are only looking at what might become possible if URI's are allowed in the Part 21 standard.
>
> One option for the relevant committees is to keep the status quo and demand that all units are defined from first principles as is currently the case in all the STEP Application Protocols. Thus every time an inch is used it must be defined as being 25.4 millimeters. (As an aside I wonder what would happen if a file defined an inch as 25.3 millimeters. Would the software notice? Would it follow through and convert all the units by the given formula. Would the result be a correct model? What about the accuracy constraints? Has STEP been consistent about applying the conversion across all the cases?)
>
> The second option is to use URL's. This is the option that is being most actively investigated by the P21 e3 group. This option is currently running into several small issues with respect to conversion based units. As I understand it the issues are derived from problems in the PLIB expression schema, but on a more personal level I have always thought it crazy to encode expressions in the PLIB expression schema.
>
> This started me thinking about the URN option in more detail. As I understand it a URN is used when the systems are expected to "know" the definition.
>
> Hence I wonder why we cannot define
>
> <urn:iso:inch>
>
> In the context of an AP242 file this would mean the current definition only with the conversion GUARANTEED to be 25.4. For an OWL system it would be whatever OWL systems expect and so on. It is a URN so nothing has to be at the other end of the definition, but something could be so STEP could say this URN is defined by the definitions at the following URL (which can then be as complex as any standards organization can imagine).
>
> I really wonder what the advantage of a convoluted URN such as urn:iso:std:iso:31:term:metre might be. Does this mean that different standards groups are going to define different metres?
>
> There is also the practical issue for system implementors of what to do if someone types the URN's slightly wrong which increases as the URN gets longer.
>
> As an implementor <urn:iso:inch> seems just about acceptable because there is very small possibility that we will want to have two definitions for inch in STEP files - one defined by ISO and another defined by Martians <urn:mars:inch>. A more practical example might be the definition of pint which is different between the UK <urn:iso:uk:pint> and the USA <urn:iso:usa:pint>. I can see that ISO might shy away from making this kind of distinction, but in this case can STEP should define its own name space <urn:step:inch> for its own STEP files.
>
> Thanks for your attention. If we are going to have to write URN's that are as long and convoluted as the URL's then we may as well stick with the URL's, so I am hoping there is a better solution.
>
> Martin
>
>
>
>> On 6/10/2014 4:42 PM, Barkmeyer, Edward J wrote:
>> Martin,
>>
>> I agree that fuddling with Part 41 representations of measurement units that should have reference IRIs is “so 1990s”. But moving on requires a wider commitment.
>>
>> urn:iso: ... is a well-defined identifier form, and ISO CS is the registry for it. See IETF RFC 5141. (http://www.rfc-editor.org/info/rfc5141)
>>
>> Some of these units are defined terms in ISO 31, ISO 1000 and ISO 80000. As a consequence they have a well-defined URN per the RFC.
>> For example, the URN for ‘metre’ is (I think):
>> urn:iso:std:iso:31:term:metre
>> It is doubtless the case that one of the ISO measurement units standards defines cm/s, but it is unlikely that any defines ‘furlong’ or ‘inches per second’. That is why Part 41 has the conversion_based_unit construct.
>>
>> SC4 has authority from ISOCS to define ISO URNs by attaching :tech:<whatever> to any (Part of any) SC4 developed standard identifier, with the proviso that these identifiers are, in fact, defined in the technical specification. It is in fact possible for Part 21 to specify URNs of the form:
>> urn:iso:std:iso:10303:tech: xxx
>> without identifying the Part number. I suspect that WG12 would consider it inappropriate for Part 21 to contain such specifications, however.
>>
>> Further, there is an issue in WG3 to align ISO 15926-4 with ISO 80000 and perhaps to incorporate some elements of NASA QUDT, which is an OWL ontology of every unit NASA has ever dreamed of using, based on a fundamental ontology that mirrors ISO 80000 and the International Vocabulary for Measures (VIM). So, it may be possible that these desired “common units” have the form:
>> urn:iso:std:iso:15926:-4:tech:class:INCHES_PER_SECOND
>> or something the like. It is definitely the intent of WG3 that they will have a URI
>> http://iso.org/std/iso/15926/-4# INCHES_PER_SECOND
>> or something the like (and that is only because W3C decided that http: is the universal prefix for IRIs, and no longer denotes a protocol). But WG3 would really prefer that QUDT was a referenceable standard in its own right, with its own IRI path.
>>
>> With the above as background, it is important for SC4 to avoid participating in the construction of another cottage industry. It would be a “good thing” for SC4 to bring its interested parties to a common table and come up with a common solution to this problem for SC4 specifications, instead of one-off conventions for the favorite technology of each Working Group.
>>
>> -Ed
>>
>>
>>
>> From: wg11 [mailto:wg11-bounces at steptools.com] On Behalf Of Martin Hardwick
>> Sent: Tuesday, June 10, 2014 10:22 AM
>> To: Thomas Liebich; wg11
>> Subject: Re: [wg11] Minutes of Part 21 E3 DIS testing telecon on June 5, 2914
>>
>> 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 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.
>>
>>
>>
>>
>> _______________________________________________
>> wg11 mailing list
>> wg11 at steptools.com
>> http://lists.steptools.com/mailman/listinfo/wg11
>
> _______________________________________________
> 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/1789ada6/attachment.html>
More information about the wg11
mailing list