RE: operating and survival conditions

I did a manual conversion of the GML Units model into RDF/SKOS, as part of a
proposal to OGC to junk the GML dictionary model in favour of RDF. It is
shown below. We ended up not pursuing this in the GML group, because we
decided it was not our business to prescribe any specific schemas for
'vocabularies', but I offer it here as something that might be useful. 

================

# $Id: GMLUnitsSKOS.turtle,v 1.0 2008/08/03 sjdc Exp $

@prefix skos: <http://www.w3.org/2004/02/skos/core#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xs:   <http://www.w3.org/2001/XMLSchema#> .
@prefix gml: <http://www.opengis.net/gml/3.2/>.

gml:UnitDefinition rdf:type rdfs:Class;
	rdfs:subClassOf skos:Concept.
	
gml:quantityType rdf:type rdfs:Property;
	rdfs:subPropertyOf skos:semanticRelation;
	rdfs:domain gml:UnitDefinition. 

gml:symbol rdf:type rdfs:Property;
	rdfs:subPropertyOf skos:label;
	rdfs:domain gml:UnitDefinition. 
	
gml:BaseUnit rdf:type rdfs:Class;
	rdfs:subClassOf gml:UnitDefinition.

#use skos:inScheme for unitsSystem
	
gml:DerivedUnit rdf:type rdfs:Class;
	rdfs:subClassOf gml:UnitDefinition.

gml:derivationUnit rdf:type rdfs:Property;
	rdfs:range gml:UnitExponent;
	rdfs:domain gml:DerivedUnit; 
	rdfs:domain gml:ConventionalUnit. 

gml:UnitExponent rdf:type rdfs:Class.

gml:unit rdf:type rdfs:Property;
	rdfs:domain gml:UnitExponent;
	rdfs:domain gml:UnitFactor;
	rdfs:range gml:UnitDefinition.

gml:exponent rdf:type rdfs:Property;
	rdfs:domain gml:UnitExponent;
	rdfs:range xs:integer. 

gml:ConventionalUnit rdf:type rdfs:Class;
	rdfs:subClassOf gml:UnitDefinition.
	
gml:conversionToPreferredUnit rdf:type rdfs:Property;
	rdfs:range gml:UnitFactor;
	rdfs:domain gml:ConventionalUnit. 

gml:UnitFactor rdf:type rdfs:Class.

gml:factor rdf:type rdfs:Property;
	rdfs:domain gml:UnitFactor;
	rdfs:range xs:double.   

<!--
The units schema above is illustrated in the following sample dictionary of
units of measure. 
-->

gml:Units rdf:type skos:Collection;
	skos:prefLabel "Units Dictionary";
	skos:note "A dictionary of units of measure";
	skos:member gml:SIBaseUnits;
	skos:member gml:SIDerivedUnits;
	skos:member gml:ConventionalUnits.

gml:SIBaseUnits rdf:type skos:ConceptScheme;
	skos:prefLabel "SI Base Units";
	skos:note "The Base Units from the SI units system";
	skos:hasTopConcept gml:m.

gml:SIDerivedUnits rdf:type skos:ConceptScheme;
	skos:prefLabel "SI Derived Units";
	skos:note "The Derived Units from the SI units system. These are all
derived as a product of SI Base Units, except degrees Celsius in which the
conversion formaula to the SI Base Unit (kelvin) involves an offset. ";
	skos:hasTopConcept gml:rad.

gml:ConventionalUnits rdf:type skos:ConceptScheme;
	skos:prefLabel "Conventional Units";
	skos:note "A collection of Conventional Units. These are units of
measure which are either widely used or important within a specific
community. For most of these there is
1. a known derivation from more primitive units, which may or may not be SI
Base Units, or
2. a known conversion to a preferred unit, which may or may not be an SI
Base or Derived unit, through rescaling and offset,
or both.".

gml:m rdf:type gml:BaseUnit;
	skos:prefLabel "metre";
	skos:prefLabel "meter"@en_US;
	skos:definition "The metre is the length of the path travelled by
light in vacuum during a time interval of 1/299 792 458 of a second";
	skos:inScheme gml:SIBaseUnits;
	gml:symbol "m";
	gml:quantityType "length".
	
gml:rad rdf:type gml:DerivedUnit;
	skos:prefLabel "radian";
	skos:definition "The metre is the length of the path travelled by
light in vacuum during a time interval of 1/299 792 458 of a second";
	skos:inScheme gml:SIDerivedUnits;
	gml:symbol "rad";
	gml:quantityType "plane angle";
	gml:derivationUnit 
		[	gml:unit gml:m;
			gml:exponent "1"];
	gml:derivationUnit
		[	gml:unit gml:m;
			gml:exponent "-1"].
		
gml:m3 rdf:type gml:DerivedUnit;
	skos:prefLabel "cubic metre";
	skos:inScheme gml:ConventionalUnits;
	gml:symbol "m3";
	gml:quantityType "volume";
	gml:derivationUnit 
		[	gml:unit gml:m;
			gml:exponent "3"].
	
gml:l rdf:type gml:ConventionalUnit;
	skos:prefLabel "litre";
	skos:inScheme gml:ConventionalUnits;
	gml:symbol "l";
	gml:quantityType "volume";
	gml:conversionToPreferredUnit 
		[	gml:unit gml:m3;
			gml:factor "0.001"]. 

Etc.  


--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre 
Institute for Environment and Sustainability 
Spatial Data Infrastructures Unit, TP 262 
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy 
Tel: +39 0332 78 3652 
Fax: +39 0332 78 6325 
mailto:simon.cox@jrc.ec.europa.eu 
http://ies.jrc.ec.europa.eu/simon-cox 

SDI Unit: http://sdi.jrc.ec.europa.eu/ 
IES Institute: http://ies.jrc.ec.europa.eu/ 
JRC: http://www.jrc.ec.europa.eu/
--------------------------------------------------------
 
Any opinions expressed are personal unless otherwise indicated. 

-----Original Message-----
From: bermud@gmail.com [mailto:bermud@gmail.com] On Behalf Of Luis Bermudez
Sent: Tuesday, 6 July 2010 14:41
To: P.Barnaghi@surrey.ac.uk
Cc: simon.cox@jrc.ec.europa.eu; Michael.Compton@csiro.au;
public-xg-ssn@w3.org
Subject: Re: operating and survival conditions

All,

UCUM in OWL: http://marinemetadata.org/ucum  Was a conversion via an XSLT
from UCUM to OWl back in 2006.

We needed to define the rdf:ID as a combination of name and code to
guarantee uniqueness. We did preserve all the property values related to a
unit form the original XML.

<unit rdf:ID="hand_hd_i">
      <name>hand</name>
      <Code>[hd_i]</Code>
      <CODE>[HD_I]</CODE>
      <printSymbol>hd</printSymbol>
      <isMetric>no</isMetric>
      <class>intcust</class>
      <printSymbol>hd</printSymbol>
      <property>height of horses</property>
      <value_value>4</value_value>
      <value>4</value>
      <value_Unit>[in_i]</value_Unit>
      <value_UNIT>[IN_I]</value_UNIT>
   </unit>

Other projects publishing units are as follows:
http://marinemetadata.org/search/node/units

Finally I know there as a work going on at CIM3 lead by Frank Olken.
But searching, the only resource I found was this presentation
http://ontolog.cim3.net/file/work/OntologySummit2009/OntologySummit2009_Symp
osium_20090406-07/units-ontology-talk-v01--FrankOlken_20090406.pdf

-Luis


On Wed, Jun 23, 2010 at 11:43 AM,  <P.Barnaghi@surrey.ac.uk> wrote:
> It seems MMI has also a measurement ontology;
>
> Luis can probably help us to get more information.
>
> http://marinemetadata.org/ucum
>
> http://marinemetadata.org/community/teams/ont/ogcowlharmonization/ontr
> ep
>
> Best regards,
> Payam
>
> ________________________________________
> From: Simon Cox [simon.cox@jrc.ec.europa.eu]
> Sent: 23 June 2010 14:56
> To: Barnaghi P Dr (Electronic Eng); Michael.Compton@csiro.au; 
> public-xg-ssn@w3.org
> Subject: RE: operating and survival conditions
>
> The problem with SWEET is that it does not have an open, or even 
> particularly orderly, maintenance process.
> This is a known issue, and the NSF funders have been trying to rectify 
> the problem, but it has not been solved yet.
> It is managed by a very small group with no formal contact with 
> authoritative external bodies.
>
> e.g. they took their Geological Timescale from Wikipedia.
> The IUGS Commission for Stratigraphy is the authority in this area, 
> and Wikipedia ( and thus  SWEET) were incorrect in several places.
> On investigation I found out that this part of SWEET was done by a
> (vacation?) student, who understandably had little experience in 
> research and collaboration.
>
> This appears to be symptomatic of a rather casual approach to 
> governance, which SWEET can get away and still be taken seriously 
> because of the NASA monicker.
> It's a shame as the fundamentals are good, but the attention to detail 
> really lets them down.
>
> --------------------------------------------------------
> Simon Cox
>
> European Commission, Joint Research Centre Institute for Environment 
> and Sustainability Spatial Data Infrastructures Unit, TP 262 Via E. 
> Fermi, 2749, I-21027 Ispra (VA), Italy
> Tel: +39 0332 78 3652
> Fax: +39 0332 78 6325
> mailto:simon.cox@jrc.ec.europa.eu
> http://ies.jrc.ec.europa.eu/simon-cox
>
> SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: 
> http://ies.jrc.ec.europa.eu/
> JRC: http://www.jrc.ec.europa.eu/
> --------------------------------------------------------
>
> Any opinions expressed are personal unless otherwise indicated.
>
> -----Original Message-----
> From: P.Barnaghi@surrey.ac.uk [mailto:P.Barnaghi@surrey.ac.uk]
> Sent: Wednesday, 23 June 2010 15:19
> To: simon.cox@jrc.ec.europa.eu; Michael.Compton@csiro.au; 
> public-xg-ssn@w3.org
> Subject: RE: operating and survival conditions
>
> I hope that I have understood it correctly; Can we use a part of 
> NASA's SWEET ontology for the units of measurement?
>
> Best regards,
> Payam
>
>
> ________________________________________
> From: public-xg-ssn-request@w3.org [public-xg-ssn-request@w3.org] On 
> Behalf Of Simon Cox [simon.cox@jrc.ec.europa.eu]
> Sent: 23 June 2010 13:59
> To: Michael.Compton@csiro.au; public-xg-ssn@w3.org
> Subject: RE: operating and survival conditions
>
> What is the rationale behind URLs like
>
> http://purl.oclc.org/NET/muo/ucum/unit/temperature/degree-Celsius ?
>
> 1.  It appears that the project that set this up stopped in 2008 2.  
> It doesn't appear to offer any real semantic value - the RDF seems to 
> be confined to rdf:type information, which doesn't get you far. No 
> definitions, conversions, or even links to more authoritative definitions.
> 3.  The slash URI ultimately maps to a # URI, which implies a finite 
> set in a primary-resource, which is not scalable for an unbounded set 
> like units of measure. (Compare this with the OGC URI scheme, which 
> allows any terminal symbol that can be constructed following the UCUM 
> algorithm - i.e. it effectively delegates the detail to UCUM. ) 4.  
> I'm a bit baffled why they call it 'ucum' but then do *not* use the 
> symbols defined in UCUM
>
> I fully agree that an authoritative source of URIs for units and 
> quantities is required, but submit that this is a poor choice.
>
> --------------------------------------------------------
> Simon Cox
>
> European Commission, Joint Research Centre Institute for Environment 
> and Sustainability Spatial Data Infrastructures Unit, TP 262 Via E. 
> Fermi, 2749,
> I-21027 Ispra (VA), Italy
> Tel: +39 0332 78 3652
> Fax: +39 0332 78 6325
> mailto:simon.cox@jrc.ec.europa.eu
> http://ies.jrc.ec.europa.eu/simon-cox
>
> SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: 
> http://ies.jrc.ec.europa.eu/
> JRC: http://www.jrc.ec.europa.eu/
> --------------------------------------------------------
>
> Any opinions expressed are personal unless otherwise indicated.
>
> -----Original Message-----
> From: public-xg-ssn-request@w3.org 
> [mailto:public-xg-ssn-request@w3.org] On Behalf Of 
> Michael.Compton@csiro.au
> Sent: Tuesday, 22 June 2010 15:00
> To: public-xg-ssn@w3.org
> Subject: operating and survival conditions
>
> I've marked up Payam's suggestion for operating and survival 
> conditions into an OWL file (as an extension of the current version of 
> the ontology).  See 
> http://www.w3.org/2005/Incubator/ssn/wiki/Operating_Model
>
> I hope I've interpreted it properly.  All comments welcome - Payam, if 
> you see anything amiss let me know.
>
> On the same page is an example that encodes the operating and survival 
> conditions for a sensor.
>
> Both files are attached here.
>
> Michael=
>



-- 

Luis Bermudez Ph.D.
Coastal Research Technical Manager
Southeastern Universities Research Association (SURA) bermudez@sura.org -
Office: (202) 408-8211
1201 New York Ave. NW Suite 430, Washington DC 20005

Received on Tuesday, 6 July 2010 13:47:04 UTC