Dear Pat, (01)
>> Hence we can say:
>>
>> :T_101 iso6892-1:upperYieldStrength
>> [ a :UniaxialStress ; :expressedAs
>> [ number: "400" ; reference: :MPa ] ] .
>>
>
>I take it that this is RDF, and could be expressed using triples using
>a blank node, thus:
>
>:T_101 iso6892-1:upperYieldStrength _:x .
>_:x :expressedAs "400"^^:MPa .
>_:x rdf:type :UniaxialStress . (02)
More or less. Joel's e-mail has just dealt with this. (03)
>> This does not mean that T_101 is a member of the equivalence class
>> "400
>> MPa". Instead there is a precisely defined, but "indirect",
>> relationship
>> between T_101 and "400 MPa".
>
>There is indeed such a relationship ('property' in RDFspeak), but I
>see no reason to call it "indirect". In your formalization it has no
>name, but it could easily be given one. It is the functional
>composition of :expressedAs with iso6892-1:upperYieldStrength, in fact. (04)
I have defined iso6892-1:upperYieldStrength as a mapping (property in
RDFspeak) with:
domain: iso6892-1:TensileTest
range: UniaxialStress (05)
For each member of iso6892-1:TensileTest there is 0 or 1 member of
UniaxialStress that is the upperYieldStrength. The 0 occurs if the test
piece does not yield during the test. (06)
There is a composition of the mappings iso6892-1:upperYieldStrength and
expressedAs, but I think that this is less useful for two reasons: (07)
a) I may wish to say that iso6892-1:lowerYieldStrength(Test_101) = 0.95
times iso6892-1:lowerYieldStrength(Test_101). Operators such as times and
relationships such as > are more simply defined for a magnitude of stress
than for an expression of a magnitude of stress as a (number, reference) pair. (08)
b) The composition of the mappings iso6892-1:upperYieldStrength and
expressedAs has a cardinality of 0 or many. This is because if the test
piece does yield, the magnitude of stress at which it does can be expressed
in many ways (by reference to psi, MPa, bar etc.). (09)
>The implicit classification into direct vs. indirect properties is
>what I was questioning. Even if it is well-defined - which I currently
>doubt - nobody yet has indicated what use it is, or why anyone should
>bother even thinking about it when writing an ontology. (010)
I agree that this is difficult to pin down, but there does seem to be
something there which is worth working on. (011)
Take the example of a ship, for which there is a waterline length, beam,
draft, length overall, and air draft. It is certainly convenient to regard
each of these as a relationship between a ship and a length magnitude, that
is defined by:
a) a process of extracting a point pair from a ship;
b) classifying the point pair by length magnitude. (012)
Alternatively we can regard a waterline length magnitude as an equivalence
class of ship. We can now cast about for a way of expressing a waterline
length magnitude. One way is as "10 knot Froude number". Hence we can have a
waterline length magnitude that is expressed as (0.3, 10 knot Froude number). (013)
We now have two quite independent quantities:
- length with magnitude expressed with reference to the metre;
- waterline length with magnitude expressed with reference to the 10 knot
Froude number. (014)
We have made no judgement as to which is the simple quantity and which is
the complicated one. However if we have a theory that says there is an
isomorphism between the set of waterline length equivalence classes for
ships and the set of length equivalent classes for point pairs, we seize
upon it with glee. We can now throw away one of our measurement approaches.
The decision to throw away "10 knot Froude number" as a measurement of
waterline length is quite arbitrary. (015)
It is merely convenience that we have: (016)
:my_ship :hasWaterlineLength [ a :Length ; :expressedAs [ :number "30" ;
:reference "metre" ] ] . (017)
rather than: (018)
:my_point_pair :definesWaterlineLength [ a :WaterlineLength ;
:expressedAs [ :number "0.3" ; :reference "10 knot Froude number" ] ] . (019)
If the customary way of measuring the distance between two points were to:
a) build a ship that fits exactly between the points;
b) tow the ship at 10 knots;
c) observe the ratio of the wave length of the wake to the length of the ship,
then the second choice would be more convenient. (020)
The division between the kinds of quantity defined in ISO 80000, and the
many thousands of "indirect properties" (mappings between a class of
physical object and a kind of quantity) used in different fields of
engineering, may be entirely arbitrary. (021)
Good night,
David (022)
At 11:13 01/10/2009 -0500, you wrote:
>
>On Oct 1, 2009, at 4:53 AM, David Leal wrote:
>
>> Dear Chris and others,
>>
>> An example of "indirect property"
>> ---------------------------------
>> Recently I have been working on an ontology for materials testing
>> (as part
>> of the CEN-ELSSI project).
>>
>> Consider a property such as "upper yield strength as defined by ISO
>> 6892-1"
>> (iso6892-1:upperYieldStrength). This is the stress value for a
>> particular
>> feature (defined in ISO 6892-1) of a stress-extension path that is
>> followed
>> by the test piece, test machine, extensometer assembly during a test
>> conducted according to ISO 6892_1.
>>
>> The property iso6892-1:upperYieldStrength is a property of the
>> stress-extension path that is created by a test. Since there is a
>> one to one
>> relationship between stress-extension path and test,
>> iso6892-1:upperYieldStrength can also be regarded as a property of
>> the test.
>>
>> Test T_101 is performed and is observed to have a
>> iso6892-1:upperYieldStrength of 400 MPa, where "400 MPa" expresses a
>> magnitude of uniaxial stress. A uniaxial stress of "400 MPa" can be
>> defined
>> as an equivalence class of material points, or perhaps of uniformly
>> stressed
>> material planes. There was an instant at which a material plane
>> within the
>> test piece was a member of this equivalence class.
>>
>> The information about particular material planes at particular
>> instants was
>> captured by data logging system of the test machine, but only as raw
>> data.
>> The useful information is the derived property
>> iso6892-1:upperYieldStrength
>> of the test.
>>
>> Hence we can say:
>>
>> :T_101 iso6892-1:upperYieldStrength
>> [ a :UniaxialStress ; :expressedAs
>> [ number: "400" ; reference: :MPa ] ] .
>>
>
>I take it that this is RDF, and could be expressed using triples using
>a blank node, thus:
>
>:T_101 iso6892-1:upperYieldStrength _:x .
>_:x :expressedAs "400"^^:MPa .
>_:x rdf:type :UniaxialStress .
>
>
>> This does not mean that T_101 is a member of the equivalence class
>> "400
>> MPa". Instead there is a precisely defined, but "indirect",
>> relationship
>> between T_101 and "400 MPa".
>
>There is indeed such a relationship ('property' in RDFspeak), but I
>see no reason to call it "indirect". In your formalization it has no
>name, but it could easily be given one. It is the functional
>composition of :expressedAs with so6892-1:upperYieldStrength, in fact.
>
>The implicit classification into direct vs. indirect properties is
>what I was questioning. Even if it is well-defined - which I currently
>doubt - nobody yet has indicated what use it is, or why anyone should
>bother even thinking about it when writing an ontology.
>
>>
>>
>> Multiplying quantities by numbers
>> ---------------------------------
>> Let "200 MPa" and "400 MPa" denote equivalance classes of uniaxial
>> stress.
>> The members of these equivalence classes are states of material
>> planes.
>
>Not in the current proposal. They would be tropes of uniaxial stress;
>each uniquely associated, perhaps, with a state of something, but not
>identical to it. I agree, states would be a much more reasonable idea
>than property tropes.
>
>> The
>> statement that "400 MPa" = 2 times "200 MPa" is probably reasonable
>> because
>> it is easy to think of a physical process which is equivalent to
>> multiplication. Therefore we assume that the set of equivalence
>> classes for
>
>> uniaxial stress is well behaved with respect to the times (by real)
>> operator
>> - pretty much a 1D vector space.
>>
>> Let "iso6892-1:upperYieldStrength 200 MPa" denote an equivalence
>> class of
>> material tests. Does 2 times "iso6892-1:upperYieldStrength 200 MPa"
>> mean
>> anything? Probably not.
>>
>>
>> Possible conclusions
>> --------------------
>> 1) There are simple quantities (equivalence classes), such as uniaxial
>
>> stress, for which we assume a simple behaviour with respect to
>> operators
>> such as times (by real).
>
>But *any* quantity measure - in fact, any property with values - will
>define equivalence classes of things which have a given value of that
>property. They are definable in OWL as the hasValue restriction classes.
>
>> 2) There are physical things with complicated indirect relationships
>> (properties) with the simple quantities.
>> 3) Further equivalence classes can be constructed from the indirect
>> properties.
>
>Exactly. So corresponding to an equivalence class cannot be the
>defining characteristic of simplicity for properties. So, what is it?
>
>> A simple behaviour for such equivalence classes with respect to
>> operators cannot be assumed.
>
>I am still completely in the dark about what you mean by the direct (=
>simple?) /indirect (= complicated?) distinction. I doubt if it can be
>made precise and coherent. But in any case, it seems to provide no
>utility for our business of writing ontologies. And in general,
>imposing arbitrary classifications on the universe which provide no
>utility, is bad engineering. It leads to much wasted time arguing
>about the distinction, how to apply it, when it applies, etc.., none
>of which is any actual use.
>
>Pat Hayes
>
>>
>> Best regards,
>> David
>>
>> At 09:50 01/10/2009 +0100, you wrote:
>>> Pat,
>>>
>>> The direct/indirect distinction was raised by Matthew and can be
>>> found in
>>> ISO 15926. Matthew or David can give you the latest links if you
>>> cannot
>>> google it.
>>>
>>> It is part of an ongoing discussion elsewhere on the list ... e.g.
>>> ---
>>>
>>> Matthew W: "Could you give me a unit (or two) that you think only
>>> applies to
>>> one kind-of-quantity, and I'll see if I can identify another?
>>>
>>> IJ-answer: m (length), kg (mass), and t (duration).
>>> ---
>>>
>>> The issue is, as you have indicated, one about the scope of the UoM
>>> ontology.
>>> This question of 'indirect' units was being discussed and I
>>> (assuming that
>>> this meant it was an 'allowed' topic) commented on it. Was I
>>> mistaken? So, I
>>> made no judgment about whether it is in our scope (your question
>>> seems to
>>> imply I did) - I'll let you guys argue about that.
>>>
>>> However, if I was asked to make such a judgement I would say that
>>> it is a
>>> difficult call. With the direct units it is reasonably easy to say
>>> how these
>>> should be used. For indirect properties it is more difficult, but
>>> much more
>>> useful. The engineers I have worked with would like to find some
>>> kind of
>>> answer other than rule of thumb. A substantial proportion of the
>>> quantities
>>> measures in their datasheets are 'indirect'. So, for them, the
>>> distinction
>>> is important.
>>>
>>> If one does include them in, one of the problems is the sheer
>>> number of
>>> indirect relationships and the lack of organisation. I think there
>>> is some
>>> work to be done on explaining / understanding / unbundling the
>>> indirect
>>> relationship if one wishes to get a reasonably general set of rules.
>>>
>>>> Well, indeed. But surely this notion of proper operation is not part
>>>> of an ontology of units and quantities, even if that is understood
>>>> to
>>>> cover issues of how quantities are measured.
>>>
>>> So, if one would like some general classification of indirect
>>> units, my
>>> guess is that it will be.
>>>
>>> Regards,
>>> Chris Partridge
>>> Chief Ontologist
>>>
>>> Mobile: +44 790 5167263
>>> Phone: +44 20 81331891
>>> Fax: +44 20 7855 0268
>>> E-Mail: partridgec@xxxxxxxxxxxxxxx
>>>
>>> BORO Centre Limited
>>> Website: www.BOROCentre.com
>>> Registered in England No: 04418581
>>> Registered Office: 25 Hart Street, Henley on Thames,
>>> Oxfordshire RG9 2AR
>>>
>>> This email message is intended for the named recipient(s) only. It
>>> may be
>>> privileged and/or confidential. If you are not an intended named
>>> recipient
>>> of this email then you should not copy it or use it for any
>>> purpose, nor
>>> disclose its contents to any other person. You should contact BORO
>>> Centre
>>> Limited as shown above so that we can take appropriate action at no
>>> cost to
>>> yourself. All BORO Centre Limited outgoing E-mails are checked
>>> using Anti
>>> Virus software.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Pat Hayes [mailto:phayes@xxxxxxx]
>>>> Sent: 30 September 2009 23:50
>>>> To: uom-ontology-std; Chris Partridge
>>>> Subject: Re: [uom-ontology-std] What is mass?
>>>>
>>>> Chris, before proceeding, could you please tell us what you mean
>>>> by a
>>>> 'direct' property, and why you feel that this direct/indirect
>>>> distinction is relevant to our main goal here of formalizing an
>>>> ontology of quantities and units.
>>>>
>>>> Pat Hayes
>>>>
>>>> On Sep 30, 2009, at 5:30 PM, Chris Partridge wrote:
>>>>
>>>>> Gunther,
>>>>>
>>>>> Your examples seem to agree with my point that indirect
>>>>> properties are
>>>>> different from direct ones.
>>>>> And I see you cash out the indirect property as a state (the option
>>>>> I noted
>>>>> in my original email).
>>>>>
>>>>> In your example, as far as I can ascertain, you describe
>>>>> observing a
>>>>> direct
>>>>> temperature, but you stipulate an indirect temperature - e.g. the
>>>>> "Maximum
>>>>> operating temperature of Machine X" rather than observing or
>>>>> measuring it.
>>>>> My guess is that there is more than mere stipulation involved here.
>>>>> One of things your example does not capture is what operating
>>>>> properly
>>>>> entails.
>>>>
>>>> Well, indeed. But surely this notion of proper operation is not part
>>>> of an ontology of units and quantities, even if that is understood
>>>> to
>>>> cover issues of how quantities are measured.
>>>>
>>>> One can play this game of 'you havn't captured X' for ever.
>>>> Eventually, it will always become circular.
>>>>
>>>> Pat
>>>>
>>>>> Typically there are quite a few ceteris paribus conditions, which
>>>>> are not mentioned here (or are implied by the use of the phrase
>>>>> "act
>>>>> of
>>>>> operating properly").
>>>>>
>>>>> I'll leave it to the engineers to provide examples of scale
>>>>> properties of
>>>>> temperature.
>>>>>
>>>>> Regards,
>>>>> Chris Partridge
>>>>> Chief Ontologist
>>>>>
>>>>> Mobile: +44 790 5167263
>>>>> Phone: +44 20 81331891
>>>>> Fax: +44 20 7855 0268
>>>>> E-Mail: partridgec@xxxxxxxxxxxxxxx
>>>>>
>>>>> BORO Centre Limited
>>>>> Website: www.BOROCentre.com
>>>>> Registered in England No: 04418581
>>>>> Registered Office: 25 Hart Street, Henley on
>>>>> Thames,
>>>>> Oxfordshire RG9 2AR
>>>>>
>>>>> This email message is intended for the named recipient(s) only. It
>>>>> may be
>>>>> privileged and/or confidential. If you are not an intended named
>>>>> recipient
>>>>> of this email then you should not copy it or use it for any
>>>>> purpose,
>>>>> nor
>>>>> disclose its contents to any other person. You should contact BORO
>>>>> Centre
>>>>> Limited as shown above so that we can take appropriate action at no
>>>>> cost to
>>>>> yourself. All BORO Centre Limited outgoing E-mails are checked
>>>>> using
>>>>> Anti
>>>>> Virus software.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: uom-ontology-std-bounces@xxxxxxxxxxxxxxxx
>>> [mailto:uom-ontology-std-
>>>>>> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Gunther Schadow
>>>>>> Sent: 30 September 2009 22:54
>>>>>> To: uom-ontology-std
>>>>>> Subject: Re: [uom-ontology-std] What is mass?
>>>>>>
>>>>>> Chris Partridge wrote:
>>>>>>> They seem to be like Cambridge properties, in as much as it is
>>>>>>> not
>>>>>>> clear
>>>>> how
>>>>>>> mere examination of the object will reveal (the value of) the
>>>>>>> property.
>>>>> So
>>>>>>> some kind of explanation of the relation is needed to
>>>>>>> understand it.
>>>>>>>
>>>>>>> At the practical engineering level, the normal interpretations of
>>>>>>> scale
>>>>>>> operations such as addition (e.g. in the case of mass, putting
>>>>>>> both
>>>>> objects
>>>>>>> with the mass on the same scale) and so on do not seem to work in
>>>>>>> the
>>>>> same
>>>>>>> way.
>>>>>>
>>>>>> This only works for extensive properties. It fails with
>>>>>> temperature
>>>>>> already. So that aspect does not seem to make a difference between
>>>>>> maximum allowable temperature and actual temperature.
>>>>>>
>>>>>> To me "maximum allowable temperature" is the upper bound of the
>>>>>> "operating temperature" interval, which in turn is a criterion
>>>>>> over
>>>>>> the actual temperature property. The way we handle such things in
>>>>>> HL7 is like this:
>>>>>>
>>>>>> "Maximum temperature = 40 degree Celsius" is
>>>>>>
>>>>>> Observation (criterion)
>>>>>> of quantity /core temperature/
>>>>>> at time /any time/
>>>>>> has value [15;40] degree Celsius
>>>>>>
>>>>>> "Actual temperature 25 degree Celsius" is
>>>>>>
>>>>>> Observation (actual)
>>>>>> of quantity /core temperature/
>>>>>> at time 2009-09-30T15:05
>>>>>> has value [24.5;25.5] degree Celsius
>>>>>>
>>>>>> "Actual temperature 43 degree Celsius" is
>>>>>>
>>>>>> Observation (actual)
>>>>>> of quantity /core temperatue/
>>>>>> at time 2009-09-30T15:15
>>>>>> has value [42.5;43.5] degree Celsius
>>>>>>
>>>>>> Comparison between a criterion and an actual quantity is done by
>>>>>> comparing whether the actual quantity is included in the
>>>>>> criterion.
>>>>>> That way one can also define other criteria, such as
>>>>>>
>>>>>> "Alarm temperature at > 35 degree Celsius"
>>>>>>
>>>>>> Observation (criterion)
>>>>>> of quantity /core temperature/
>>>>>> at time /any time/
>>>>>> has value [35;-) degree Celsius
>>>>>>
>>>>>> The difference between the 2 criteria is how they are related to
>>>>>> other information. For example, operating temperature would be
>>>>>> related to the operation act that the machine performs whereas
>>>>>> alarm temperature would be related to the alarm action:
>>>>>>
>>>>>> Act "to operate properly"
>>>>>> isPerformedBy Machine
>>>>>> hasThroughCondition Observation (criterion) for "operating
>>>>>> temperature
>>>>>> range"
>>>>>>
>>>>>> Act "to raise alarm"
>>>>>> isPerformedBy TemperatureMonitor
>>>>>> hasSubject Machine
>>>>>> hasTriggerCondition Observation (criterion) for "alarm
>>>>>> temperature"
>>>>>>
>>>>>> so a lot of these notions of "indirect properties" is in my view
>>>>>> best modeled by additional structures. But nevertheless one can
>>>>>> always define a property as a primitive to stand for such a
>>>>>> complex
>>>>>> model. E.g.,
>>>>>>
>>>>>> "Maximum operating temperature of Machine X" :=
>>>>>> the high boundary of
>>>>>> the range value of
>>>>>> the Observation (criterion)
>>>>>> of quantity /core temperature/
>>>>>> which is the throughCondition of
>>>>>> the act of operating properly
>>>>>> performed by
>>>>>> the Machine X.
>>>>>>
>>>>>> If we avoid such "indirect properties" with such models, there are
>>>>>> then fewer true "direct properties" left, such as /core
>>>>>> temperature/.
>>>>>> However, you still have multiple temperatures, such as
>>>>>>
>>>>>> - core temperature
>>>>>> - surface temperature
>>>>>> - measured by holding a thermometer close to the shell
>>>>>> - measured by an attached thermometer (using heat transfer creme)
>>>>>>
>>>>>> and lo and behold, we can't really compare the core temperature
>>>>>> and
>>>>>> the surface temperature to find out if the machine is still
>>>>>> operating.
>>>>>> But we can compare the surface temperatures with core temperatures
>>>>>> to find out that the surface temperatures are always closer to the
>>>>>> ambient temperature than the core temperature.
>>>>>>
>>>>>> regards,
>>>>>> -Gunther
>>>>>>
>>>>>> --
>>>>>> Gunther Schadow, M.D., Ph.D.
>>>>>> gschadow@xxxxxxxxxxxxxxx
>>>>>> Associate Professor Indiana University School of
>>>>>> Informatics
>>>>>> Regenstrief Institute, Inc. Indiana University School of
>>>>>> Medicine
>>>>>> tel:1(317)423-5521 http://
>>>>>> aurora.regenstrief.org
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
>>>>>> Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
>>>>>> Config/Unsubscribe:
>>>>> http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
>>>>>> Shared Files: http://ontolog.cim3.net/file/work/UoM/
>>>>>> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?
>>>>>> UoM_Ontology_Standard
>>>>>>
>>>>>
>>>>>
>>>>> _________________________________________________________________
>>>>> Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
>>>>> Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
>>>>> Config/Unsubscribe:
>>> http://ontolog.cim3.net/mailman/listinfo/uom-ontology-
>>>> std/
>>>>> Shared Files: http://ontolog.cim3.net/file/work/UoM/
>>>>> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> IHMC (850)434 8903 or (650)494
>>>> 3973
>>>> 40 South Alcaniz St. (850)202 4416 office
>>>> Pensacola (850)202 4440 fax
>>>> FL 32502 (850)291 0667 mobile
>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _________________________________________________________________
>>> Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
>>> Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
>>> Config/Unsubscribe:
>> http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
>>> Shared Files: http://ontolog.cim3.net/file/work/UoM/
>>> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard
>>>
>>>
>>>
>>
>> ============================================================
>> David Leal
>> CAESAR Systems Limited
>> registered office: 29 Somertrees Avenue, Lee, London SE12 0BS
>> registered in England no. 2422371
>> tel: +44 (0)20 8857 1095
>> mob: +44 (0)77 0702 6926
>> e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
>> web site: http://www.caesarsystems.co.uk
>> ============================================================
>>
>>
>>
>> _________________________________________________________________
>> Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
>> Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
>> Config/Unsubscribe:
http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
>> Shared Files: http://ontolog.cim3.net/file/work/UoM/
>> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard
>>
>>
>
>------------------------------------------------------------
>IHMC (850)434 8903 or (650)494 3973
>40 South Alcaniz St. (850)202 4416 office
>Pensacola (850)202 4440 fax
>FL 32502 (850)291 0667 mobile
>phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>
>
>
>
>
>
> (023)
============================================================
David Leal
CAESAR Systems Limited
registered office: 29 Somertrees Avenue, Lee, London SE12 0BS
registered in England no. 2422371
tel: +44 (0)20 8857 1095
mob: +44 (0)77 0702 6926
e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
web site: http://www.caesarsystems.co.uk
============================================================ (024)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard (025)
|