OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] RE: OGC UoM Best Practices guidance

Thanks Carl,

Just a couple of minor points.

1. I have two places where the equivalent to UoM 
is stated as MeasuementUnit and Measurement Unit, 
respectively, in the HumanMarkup Primary Base 
Schema (.xsd and .owl) and in the CIDOC CRM 
(.rdfs). CIDOC stands for International Council 
of Museums and CRM just mean Conceptual Reference 
Model though it is a fully articulated ontology 
and gets very concrete. However, it is an 
academically accepted work of more than a decade 
now for classifying human artifacts, so I have 
decided to use it as a major mechanism to unify 
various standards including health informatics 
and human information exchange.

I'm working on the problem of translating XSD to 
OWL and back, trying to come up with some 
recommendations for definitional equivalence in 
order to make it possible, at as simple a level 
as I can, and in a way that won't break the basic 
principles of XML, XML Schema, RDF, RDF Schema, 
or OWL.

What a pain! and I am not just referring to the 
naming and design rules that the EM Msg SC is now 
at least looking at. However, I am making 
progress. So, short of having to develop a 
controlled vocabularies thesaurus to deal with 
Geospatial issues, my question is if there is any 
possibility for suggesting that UoM switch to MU? 
That way one naming convention mismatch in this 
case can be avoided, and I can just set up an 
<xs:attribute name = "MeasurementUnit" type= "OGC 
MU"> where OGC MU is the QName abbreviation for 
the namespace, and I can import) the darn thing 
(which XML Schema stipulates as a URN) and keep a 
local copy with schemaLocation="./specname" 
...and that way developers can take the whole 
package and just start using it without 
themselves going crosseyed sorting out the 

2. We still don't have the cookbook recipe for 
using GML in targetArea for EDXL_DE cookbook or 
however we make these aids available.

Cryminee the things I do for interoperability! As 
you can see I'm deep implementation mode.


At 8:59 AM -0600 4/2/06, Carl Reed OGC Account wrote:
>Content-Type: text/plain;
>	format=flowed;
>	reply-type=response
>X-MIME-Autoconverted: from 8bit to 
>quoted-printable by mail.opengeospatial.org id 
>Gary and Rex -
>Fully understand. The OGC UoM and related 
>Observations and Measurements work have been 
>designed to insure that ALL metadata for a given 
>measurement (say from a sensor) can be 
>accurately captured, encoded, and communicated. 
>The OGC members have determined that for our 
>standards work related to sensors etc that we 
>must insure that the accuracy of measurement 
>semantics, measurement precision, and 
>measurement accuracy and so forth must be 
>accommodated. This does not mean that an 
>application needs to use all of the capabilities 
>- just that that they must be there if needed. 
>Much of this decision has to do with the level 
>of ambiguity that an application can live with. 
>This is why UoM is important.
>Anyway, attached is the latest OGC Observations 
>and Measurement document. The members approved 
>release of this Discussion Paper last month. Has 
>not yet been posted to the OGC web site but will 
>be soon.
>There are numerous examples showing how UoM can 
>be expressed as part of a larger sensor 
>observation encoding payload. Also shows use of 
>GML, O&M and UoM used in concert.
>Not sure if this will make Gary's life any easier :-)
>----- Original Message ----- From: "Rex Brooks" <rexb@starbourne.com>
>To: "Carl Reed OGC Account" 
>Sent: Wednesday, March 29, 2006 9:32 AM
>Subject: [emergency] RE: OGC UoM Best Practices guidance
>>At the risk of catching a ration of flame from 
>>most all sides involved with this discussion, I 
>>tend to favor two ways of dealing with units of 
>>1. Specify that uom be specified either in the 
>>specification or that each implementation must 
>>specify what uom it uses, mandatory--and in web 
>>services, you just don't partner with companies 
>>whose uom in their wsdl does not match up with 
>>2. Specify metric system, period.
>>Both are aimed at letting the marketplace 
>>enforce the standard, but Darwinism has a bad 
>>name in these parts, since it inevitablly means 
>>letting chips fall where they may, and in these 
>>parts chips are people so both of these are 
>>In the choice arena between the concerns of 
>>programming realities on the ground versus 
>>getting critical information correct in 
>>critical moments, I tend to fall on the side of 
>>insisting on putting the burden on the quality 
>>assurance cycles in software development and 
>>test the bleep out of every last thing and just 
>>keep testing till it works 95% of the time. 
>>(Reality says 80% flies, but in this case, I 
>>have to remind folks that in these parts chips 
>>are people.)
>>At 10:42 AM -0700 3/28/06, Carl Reed OGC Account wrote:
>>>As I mentioned.
>>>Carl Reed, PhD
>>>CTO and Executive Director Specification Program
>>>The OGC: Helping the World to Communicate Geographically
>>>This communication, including attachments, is 
>>>for the exclusive use of addressee and may 
>>>contain proprietary, confidential or 
>>>privileged information. If you are not the 
>>>intended recipient, any use, copying, 
>>>disclosure, dissemination or distribution is 
>>>strictly prohibited. If you are not the 
>>>intended recipient, please notify the sender 
>>>immediately by return email and delete this 
>>>communication and destroy all copies.
>>>"The important thing is not to stop questioning." -- Albert Einstein
>>>Attachment converted: Macintosh 
>>>HD:Units_of_Measure_Rec#10783E.pdf (PDF /«IC») 
>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>generates this mail.  You may a link to this group and all your TCs in OASIS
>>Rex Brooks
>>President, CEO
>>Starbourne Communications Design
>>GeoAddress: 1361-A Addison
>>Berkeley, CA 94702
>>Tel: 510-849-2309
>Attachment converted: Macintosh 
>HD:05-087r3_Observation#10A3B3.doc (WDBN/«IC») 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]