After following this discussion, and having some conversations with Jack Hodges 
(as he mentioned in an earlier post), I feel moved to voice an opinion. My 
understanding, for a long time now, has been that QuantityKind is a 
context-free concept closely tied to, and defined by, a dimension-vector which 
is some combination of the 7 basic dimensions. A Quantity, on the other hand, 
is a contextual concept that relates an application to the QUDT ontology. 

 

Easy examples are things like “Steve’s height”. More controversial are concepts 
like “height”. In my view, height is a contextual concept, and thus should be 
an instance of Quantity. Height depends on what you consider to be “up” or 
“down”. Length is a context-free concept and ties directly to one of the basic 
dimensions. 

 

Recalling an earlier discussion among a few of us, I would call pulse-rate or 
heartbeat-rate examples of Quantity, with a corresponding QuantityKind of 
Dimensionless. This doesn’t mean we can’t curate collections of Quantity 
instances for various domains.

 

I know this is not entirely consistent with some of the current population in 
QUDT. But the reason I have this position is that it avoids the slippery slope 
of trying to decide how contextual you get before something stops being a 
QuantityKind and starts being a Quantity.

 

My view:

 

More contextual

 

Steve’s height - Quantity

Person height - Quantity

height - Quantity

length – QuantityKind (dimension Length**1)

 

Less contextual

 

 

I’m willing to reconsider if presented with a compelling argument!

 

 

- Steve

 

Steven R. Ray, Ph.D.

Distinguished Research Fellow

Carnegie Mellon University

NASA Research Park

Building 23 (MS 23-11)

P.O. Box 1
Moffett Field, CA 94305-0001

Email:    [email protected]

Phone: (650) 587-3780

Cell:      (202) 316-6481

Skype: steverayconsulting

cid:[email protected]

 

From: [email protected] [mailto:[email protected]] 
On Behalf Of Irene Polikoff
Sent: Tuesday, May 09, 2017 8:23 AM
To: [email protected]
Subject: Re: [topbraid-users] RE: owl modelling issue in tbc

 

Yes, possibly. As I said "Or may be some variation on the above that 
distinguishes between bridge heights and other height measurements.” I didn’t 
find a height quantity kind in QUDT. 





My main point on how a restriction could look like, however, was that there 
would be some class, instances of which are certain quantities e.g., bridge 
heights. Thus, a restriction on the class Bridge could point to that class. 





I think other modeling patterns are also possible with QUDT. I t would be good 
to have a few examples of how to use it.





On May 9, 2017, at 9:58 AM, Jack Hodges <[email protected]> wrote:

 

Irene,

It seems to me that 'height' should be a quantity kind and not a quantity. A 
bridge's height could be a quantity but height is too general. The question to 
ask of qudt is whether there are like quantity kinds, such as weight, size, 
velocity, etc., which there are. A quantity kind is more of a type that is 
associated with a dimensionality but no value. A quantity has a value, which 
makes it contextual.

I could see Michael creating a bridge class in some kind of device taxonomy 
(since it has functionality), and I could see a device having any number of 
named quantities that are causally related to its functionality. After all, 
height and weight are of little value unless we are talking about how they 
impact a design or use of an object.

-- 
You received this message because you are subscribed to the Google Group 
"TopBraid Suite Users", the topics of which include the TopBraid Suite family 
of products and its base technologies such as SPARQLMotion, SPARQL Web Pages 
and SPIN.
To post to this group, send email to [email protected]
--- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

 

 


 
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
 

Virus-free.  
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
 www.avg.com 

-- 
You received this message because you are subscribed to the Google Group 
"TopBraid Suite Users", the topics of which include the TopBraid Suite family 
of products and its base technologies such as SPARQLMotion, SPARQL Web Pages 
and SPIN.
To post to this group, send email to [email protected]
--- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Group 
"TopBraid Suite Users", the topics of which include the TopBraid Suite family 
of products and its base technologies such as SPARQLMotion, SPARQL Web Pages 
and SPIN.
To post to this group, send email to [email protected]
--- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to