Re: [topbraid-users] Re: unit as range error

Tue, 11 Oct 2011 07:41:02 -0700

Michel; As Irene pointed out, the objective of QUDT is to provide a general-purpose solution that addresses a wide range of use cases.  If you'd like to make your modifications, I'd suggest creating another model, say bohmsQUDT and import the QUDT model.  You can then add your datatype type triples wherever you need without requiring any modification to the standard model.

-- Scott

On 10/11/11 2:48 AM, Bohms, H.M. (Michel) wrote: 


In my case I want to model units as simple as possible. This means that I just want to be as standard as possible without all the special flexibilities  like prefixes etc. In that scenario the unit for height is ok (because it is the same for every class that has height as domain). (ie Mm>m becomes a conversion issue not a modelling issue).

Clearly I see the more flexible cases and now also the more flexible modelling solutions. The more flexible however the more we go away from standard owl semantics (ie via quantity value) and come into our own unit/property meta-modelling....

I do have however another issue:
If I now want to use them as range I have to manually add all the 'rdf:type rdfs:datatype' clauses for all units.
Or can this be done more simple (or could we convince the nasa guys to adapt (or maybe have TBC variant of the ontology where all clauses are added for all units?)

Thx Michel

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Irene Polikoff
Sent: maandag 10 oktober 2011 23:04
To: [email protected]
Subject: RE: [topbraid-users] Re: unit as range error

Hi Simon,

< Your solution here seems to be to give the same context (units) to all values of a particular property.>

I think some applications (especially, scientific and engineering) need very rich support for units of measure. Other applications may have lighter treatments. 

QUDT ontologies attempt to enable a range of use cases.

The blog example is very simple in that it says that the property (height) has a certain unit as its rdfs:range. Alternatively, an OWL restriction could have been used to say that in a context of a certain class, the range of values is centimeters, in the context of another class, it is meters, etc. 

In both cases the choice is being made to treat units as datatypes. 

If you look at QUDT ontologies, you will see that there is a class Quantity Value defined as follows:

Annotation Properties

description: A quantity value expresses the numerical value of a quantity with respect to a chosen unit of measure. For example, the value of Planck's constant in Joule-Seconds (J s) is approximately 6.62606896E-34, whereas the value in Erg-Seconds (erg s) is approximately 6.62606896E-27.

label:	Quantity value

Other Properties

subClassOf:	

value for quantity only Quantity
numeric value only qudt:numericUnion
standard uncertainty only xsd:double
standard uncertainty max 1
value for quantity max 1
relative standard uncertainty max 1
numeric value exactly 1
relative standard uncertainty only xsd:double unit only Unit unit exactly 1 Thing

type Class

So, instead of treating a property such as 'height' as a datatype property, one can create an instance of a Quantity Value and say what Quantity is being measured, what is the numeric value and what is the unit of measure where things like centimeter, etc. are resources - instance of class Unit and things like height are resources as well - instances of class Quantity.
By Quantity here we don't mean a number but an observable property of an object, event or system that can be measured and quantified numerically.

The QUDT is actually even richer than that because it also has support for quantity kinds and dimensions.

For example, the speed of light in a vacuum and the escape velocity of the Earth are both quantities of the kind speed but are of different magnitudes.

What is the GI community?

Irene Polikoff 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Simon Cox
Sent: Monday, October 10, 2011 12:01 AM
To: TopBraid Suite Users
Subject: [topbraid-users] Re: unit as range error

I just saw this discussion.

This echoes a permathread in the GI community as well, and is arguably one of the biggest gaps in almost all computer languages in terms of their application to the real world.

The point is that 304.8mm=1ft, 1kg=2.205lb, etc.
They are alternative and entirely equivalent serializations of the same quantity.
Quantities have no meaning without a unit of measure, and generally should not be transported without the uom being provided either locally or by the context.

Your solution here seems to be to give the same context (units) to all values of a particular property.
The GI community has traditionally used UML for conceptual modelling, and has a base class 'Measure' to handle this.
Translated into OWL it looks llike this:

base:Measure
      a       rdfs:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality "1"^^xsd:nonNegativeInteger ;
                owl:onProperty meas:units
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality "1"^^xsd:nonNegativeInteger ;
                owl:onProperty meas:value
              ] .

meas:units
      a       owl:FunctionalProperty , owl:DatatypeProperty ;
      rdfs:comment "Value should be a valid UCUM symbol"^^xsd:string ;
      rdfs:domain base:Measure ;
      rdfs:range xsd:string ;
      dc:description "The value of this property is a designator for the units of measure or scale for the quantity"^^xsd:string .

meas:value
      a       owl:FunctionalProperty , owl:DatatypeProperty ;
      rdfs:domain base:Measure ;
      rdfs:range base:Number ;
      dc:description "The value of this property is a number that is scaled by the unit of measure to obtain a quantity"^^xsd:string .


Simon

On Oct 5, 6:53 pm, "Bohms, H.M. (Michel)" <[email protected]> wrote:


      

        
Hi Holger

I just recently discovered the great unit pattern/ontology.

However when I try to put say unit:Kilogram as range the box stays red.


      

      
 (I imported the local file)


      

        
I see this issues reported earlier for older versions but should have 
been


      

      
resolved in later versions.


      

        
[cid:738164810@05102011-25D7]

thx for feedback, Michel
This e-mail and its contents are subject to the DISCLAIMER


      

      
athttp://www.tno.nl/emaildisclaimer


      

        
 Outlook.jpg
203KViewDownload


      

      
--
You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

--
You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en



    

  





-- 

You received this message because you are subscribed to the Google

Group "TopBraid Suite Users", the topics of which include TopBraid Composer,

TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.

To post to this group, send email to

[email protected]

To unsubscribe from this group, send email to

[email protected]

For more options, visit this group at

http://groups.google.com/group/topbraid-users?hl=en






























					Reply via email to