[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 standards. 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. Ciao, Rex 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 >k32F2Lbc007185 > >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 :-) > >Cheers > >Carl > >----- Original Message ----- From: "Rex Brooks" <rexb@starbourne.com> >To: "Carl Reed OGC Account" ><creed@opengeospatial.org>; ><emergency@lists.oasis-open.org> >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 >>measure: >> >>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 >>yours; >>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 >>non-starters. >> >>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.) >> >>Ciao, >>Rex >> >>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 >>>OGC >>> >>>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») >>>(0010783E) >>>--------------------------------------------------------------------- >>>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 >>>at: >>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >>-- >>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») >(0010A3B3) -- 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]