[wg11] units of measure, from Minutes of Part 21 E3 DIS testing telecon on June 5, 2914
Martin Hardwick
hardwick at steptools.com
Wed Jun 11 17:35:44 EDT 2014
Ed,
We may well be compelled to apply for the URN but in defense of not
doing so let me say:
1. The true purpose of a URN (in my opinion) is to reference something
that should already be known to the reader. In STEP we already know what
the definition of an inch is - it has been the same in every P21 file
for the last 20 years.
2. Why would someone outside of STEP want to access the STEP definition
of inch as encoded in a P21 file (and stored at the Part 41 URL given
earlier in the e-mail trail)? If no one external to STEP is going to
reference why register?
The key reason for using <urn:step:inch> is that it is a familiar
notation more or less. Most people know that a URN is the alternative to
a URL and that it is to be used when something is already known .
Calling it a stepid as in <stepid:step:inch> would not have this advantage.
Thanks for sticking with me on this.
Martin
PS Let me try to prevent messages about being STEP centric by reminding
us all that I am also proposing/suggesting the use of <urn:ifc:inch> and
<urn:iso15926:inch>
On 6/11/2014 4:51 PM, Barkmeyer, Edward J wrote:
> Signature
>
> Martin,
>
> Well, if you take that view, why use ‘urn’ at all? Why not call it
> ‘stepid:’? If you are not going to abide by the standard, why use the
> standard prefix?
>
> And if there is no registry for these names, what happens when some
> other organization chooses to use urn:step for their names? Of
> course, there will never be any company that uses STEP and the
> Step.org estate planning people, but the possibilities for the ‘step’
> acronym are hardly restricted to SC4. That is why we have registries
> – to insure that symbols are unique.
>
> The Linked Open Data people may be wrong about the future, but I can
> guarantee that the closed world of standards in SC4 is already a thing
> of the past. Integrating data across multiple models and sources is
> the future of industrial IT. If it weren’t, your Part 21 project would
> not be. With a little effort, we can avoid creating a pit that
> someone will fall into 2 years from now.
>
> -Ed
>
> *From:*Martin Hardwick [mailto:hardwick at steptools.com]
> *Sent:* Wednesday, June 11, 2014 2:43 PM
> *To:* Barkmeyer, Edward J; Thomas.r.thurman
> *Cc:* Thomas Liebich; wg11; Palmer, Mark E. Mr.;
> magne.valen.sendstad at gmail.com
> *Subject:* Re: [wg11] units of measure, from Minutes of Part 21 E3 DIS
> testing telecon on June 5, 2914
>
>
> Why does a URN have to be registered?
>
> If one of our documents says <urn:step:inch>_in a STEP model_ means an
> inch as defined at
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
> is anybody going to complain, and if so to whom?
>
> Martin
>
> On 6/11/2014 1:26 PM, Barkmeyer, Edward J wrote:
>
> Fine. Then someone has to do the ICANN registration process for
> urn:step! And since I assisted Joanna Goodwin and Holger Apel
> with that rigamarole producing RFC 5141, I can tell you they
> didn’t make it easy. It is NOT like paying $100 for a domain name.
>
> I undertook that for SC4, so that urn:iso:std:iso:10303:term:xxx
> would be automatically valid, and so that SC4 could define URNs
> beginning urn:iso:std:iso:10303:tech and other such identifiers.
> If you want urn:step, you should have stepped up in 2004-5 when we
> did that (but you probably would not have had support from JTC1
> and TC68 and TC154).
>
> I don’t really care whether you use URNs or not. Sir Tim got his
> way and denatured http: and made the whole URN effort largely
> useless. (It was neither the first nor last waste of my time in
> standards land.) What you do have to realize is that there is a
> formal procedure for creating URIs of either kind, and if you
> elect not to use what has already been done, you get to put the
> resources into repeating the procedure.
>
> STEP as a whole is a sow’s ear, but it works and using it is a lot
> cheaper than trying to roll your own silk purse.
>
> -Ed
>
> *From:*Martin Hardwick [mailto:hardwick at steptools.com]
> *Sent:* Wednesday, June 11, 2014 12:56 PM
> *To:* Barkmeyer, Edward J; Thomas.r.thurman
> *Cc:* Thomas Liebich; wg11; Palmer, Mark E. Mr.;
> magne.valen.sendstad at gmail.com <mailto:magne.valen.sendstad at gmail.com>
> *Subject:* Re: [wg11] units of measure, from Minutes of Part 21 E3
> DIS testing telecon on June 5, 2914
>
> On 6/11/2014 12:39 PM, Barkmeyer, Edward J wrote:
>
> Martin,
>
> Why is:
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
>
> less “convoluted” than: urn:iso:std:iso:31:term:metre
>
> ???
>
> You tell me. I want to use <urn:step:inch>
>
> As implementors we have found that less typing means less scope
> for mistakes.
>
> If there is going to have to be lots of typing then
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
> is better than urn:iso:std:iso:31:term:metre because there are
> lots of ways to check for badly type URL's and hardly any to check
> a badly typed URN.
>
> Your URN requires me to remember:
> 1. Type iso twice
> 2. The standard number is 31
> 3. The concept being defined is a term
>
> As an implementor I can do all this. Just look at what we did for
> units in Part 21 Edition 1 and 2.
>
> Martin
>
>
> The http: form just uses a different ISO CS directive for
> formulating IRIs, which is “jealously guarded” by ISO CS in
> exactly the same way!
>
> In both cases, ISOCS specifies what everything up to the “tech”
> part must be, and the SC gets to define what follows.
>
> The point of the ISO URNs of the form above is that MERELY by
> having the term defined in an existing ISO standard, there IS a
> standard IRI for the term. And if multiple standards define
> “metre”, then it is very important that you know WHICH meaning is
> intended by the reference!
>
> Why would it be better for ISO 10303 to define what it means by
> “inch” than what some industry reference standard defines “inch”
> to mean? Do I have to find a different IRI if I am using an ASTM
> standard? or an API standard?
>
> The problem is to get a reference standard that defines the
> “conversion based units” (English measure, et al.) that we want to
> be able to use, and then to use one of the ISO-specified forms for
> creating the corresponding IRI, whether it begins http: or urn:.
> Enabling such things is exactly why ISOCS went to the trouble of
> registering the URN and URL forms and publishing the corresponding
> directives. And if the reference standard is not an ISO standard,
> then we will be bound by whatever URI syntax that particular SDO
> set up. So, if urn:ifc, or http://ifc.org/, is an ICANN registered
> prefix, and the IFC defines urn:ifc:inch, or whatever “convoluted”
> form IFC decides on, we could use that and be done.
>
> The point of all this is that the references for constructing IRIs
> are already in place. What is necessary is the **standard** that
> defines the terms you want to use, so that the IRI that refers to
> that term in that standard can be employed. Stop worrying about
> the IRIs and figure out where/what the reference standard is to
> be. By way of assisting in this, I have put in a request to a
> NIST SI/BIPM person to identify an appropriate specification for
> English measures, but I have not yet received a response.
>
> -Ed
>
> *From:*Martin Hardwick [mailto:hardwick at steptools.com]
> *Sent:* Wednesday, June 11, 2014 6:35 AM
> *To:* Thomas.r.thurman
> *Cc:* Barkmeyer, Edward J; Thomas Liebich; wg11; Palmer, Mark E.
> Mr.; magne.valen.sendstad at gmail.com
> <mailto:magne.valen.sendstad at gmail.com>
> *Subject:* Re: [wg11] units of measure, from Minutes of Part 21 E3
> DIS testing telecon on June 5, 2914
>
>
> Again my purpose is to investigate how P21 e3 might help. The most
> we can venture is to produce some recommendations and examples.
>
> My summary of the previous e-mails is that the ISO namespace
> <urn:iso> is jealously guarded to keep the peace between the
> committees. We are never going to be able to use it to make
> something easy for the implementors.
>
> However, before giving up on URN's I would like to get opinion on
> the following: Can we define our own namespaces?
>
> We might do this for each standard, or at the level of SC4.
>
> For example, if we decide to use URNs to define units for STEP then
> 1. The URN for inch might be <urn:step:inch>;
> 2. The URN would be mapped by appropriate wording in the
> appropriate place to the URL
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>
> <http://standards.iso.org/iso/10303/tech/reference_data/-41/units.stp#INCH>;
> 3. The URN would only have to have meaning for a STEP model.
>
> We would then do the same for ifc <urn:ifc:inch> and iso15926
> <urn:iso15926:inch> etc.
>
> The appropriate wording in #2 could be words in the standards
> document, or it could be a rule in the standards document telling
> you where to find a server with the permitted URNs.
>
> Martin Hardwick
> Team Leader ISO STEP-Manufacturing
>
>
>
> On 6/10/2014 8:15 PM, Thomas.r.thurman wrote:
>
> 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 <mailto: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#
> <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*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.named_unit> that
> defines a unit on the basis of a
> *measure_with_unit*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.measure_with_unit>.
>
>
> NOTE The *value_component*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.measure_with_unit.value_component> attribute
> of the *measure_with_unit*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.si_unit>,
> millimetre, through a *measure_with_unit*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C18_schema.htm#measure_schema.named_unit>|);|
> | name : |label
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C25_schema.htm#support_resource_schema.label>|;|
> | conversion_factor : |measure_with_unit
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C18_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Csupport_resource_schema%5Csupport_resource_schema.htm#support_resource_schema.label> by
> which the *conversion_based_unit* is known.
>
> *conversion_factor: *the *measure_with_unit*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_schema.htm#measure_schema.si_unit>,
> degree Celsius, through a *measure_with_unit*
> <file:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresources%5Cmeasure_schema%5Cmeasure_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:///%5C%5C%5C%5C%5C%5C%5C%5CUsers%5Ctom%5CDocuments%5C2013%5CSMRLv5%5CSMRL_v5_rc5%5Cdata%5Cresource_docs%5Cfundamentals_of_product_description_and_support%5Csys%5C18_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>
> <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>
> <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 <mailto: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 <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 <mailto:wg11 at steptools.com>
>
> http://lists.steptools.com/mailman/listinfo/wg11
>
> _______________________________________________
> wg11 mailing list
> wg11 at steptools.com <mailto: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/20140611/b5c1edd7/attachment.html>
More information about the wg11
mailing list