owl modelling issue in tbc

[Bohms, H.M. (Michel)]

 

Dear all,

 

I am comparing different approaches for modelling “attributes”:

1. Simple/most direct as OWL datatype properties
2. As classes to allow for more meta-data like units
3. As named individuals according to QUDT2.0 (NASA/TQ).

 

One of the criteria is the complexity of restrictions. As example I look at a card=1 restriction for a height attribute for a Bridge class.

The first 2 are quite easy (the first is most simple/direct OWL, the second option needs some property chaining) but the third one I am unsure whether I can stay within OWL or that I have to move into SPIN/SHACL/…. territory.

 

EXAMPLE

 

Having from qudt2.0:

qudt:hasQuantity, qudt:hasValue, qudt:Quantity, qudt:hasQuantityKind.

 

And defined:

 

:Bridge rdf:type owl:Class .

:Height rdf:type qudt:QuantityKind .

 

I am looking for an OWL (RDFS/RDF)-based restriction for the red part below (avoiding extra explicit subclasses):

 

:Bridge rdf:type owl:Class ;

rdfs:subClassOf [rdf:type owl:restriction ;

“there exists one Quantity via qudt:hasQuantity, having qudt:hasQuantityKind=:Height

.

 

owl:hasValue doesn’t seem to help because it’s too restrictive (there can be other attributes).

owl:someValuesFrom seems to work on the class-level only

some special expression possible?

ie some QCR (card=1) on qudt:hasQuantity where the Qualified-part is an intersection of qudt:Quantity AND owl:hasValue qudt:hasQuantity=Height?

Thx a lot for your advice! Or suggestion for a more general forum to post such a question…(apologies upfront)

Michel Böhms, TNO (NL)

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

 

[Bohms, H.M. (Michel)]

Trying myself it seems that:

:Bridge

  rdf:type owl:Class ;

  rdfs:subClassOf owl:Thing ;

  rdfs:subClassOf [

      rdf:type owl:Restriction ;

      owl:onClass [

          rdf:type owl:Class ;

          rdfs:subClassOf :Quantity ;

          rdfs:subClassOf [

              rdf:type owl:Restriction ;

              owl:onClass [

                  rdf:type owl:Class ;

                  rdfs:subClassOf :QuantityKind ;

                  rdfs:subClassOf [

                      rdf:type owl:Restriction ;

                      owl:hasValue :Height ;

                      owl:onProperty :hasQuantityKind ;

                    ] ;

                ] ;

              owl:onProperty :hasQuantityKind ;

              owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;

            ] ;

        ] ;

      owl:onProperty :hasQuantity ;

      owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;

    ] ;

.

 

Does not give any error in tbc, so it might be actually what I was after!

Anyway, comments on correctness still very welcome!

 

Thx Michel

[Holger Knublauch]

Hi Michel,

do you need these restrictions for classification purposes or constraint checking? I believe this would inform the technology choice.

Note that TopBraid has very limited support for OWL QCRs, esp not for form validation.

Holger

--
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 topbrai...@googlegroups.com
---
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 topbraid-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Irene Polikoff]

I think QUDT expects that the data would look along these lines:

ex:Bridge1 a ex:Bridge;

qudt:quantity ex:Quantity1.

ex:Quantity1 a ex:Height;

qudt:quantityValue ex:QuantityValue1;

qudt:quantityKind qudt:Length .

ex:QuantityValue1 a qudt:QuantityValue;

qudt:numericValue ’50’;

qudt:unit unit:Meter .

ex:Height rdfs:subClassOf qudt:Quantity.

Or may be some variation on the above that distinguishes between bridge heights and other height measurements. Other variations are also possible.

Then, QUDT could be used to perform dimensional analysis e.g., to validate that the appropriate unit of measure is used. If only unit of measure is known, then quantity kind (Length) could be inferred, so some classification could be done. QUDT could also be used to convert the values to another system of units - for example, feet. Although conversion would already be outside of OWL.

QUDT differentiates between the actual properties being measured and quantity kinds: 

"A quantity is the measurement of an observable property of a particular object, event, or physical system. A quantity is always associated with the context of measurement (i.e. the thing measured, the measured value, the accuracy of measurement, etc.) whereas the underlying quantity kind is independent of any particular measurement. Thus, length is a quantity kind while the height of a rocket is a specific quantity of length; its magnitude that may be expressed in meters, feet, inches, etc. Examples of physical quantities include physical constants, such as the speed of light in a vacuum, Planck's constant, the electric permittivity of free space, and the fine structure constant. Or, as stated at Wikipedia, in the language of measurement, quantities are quantifiable aspects of the world, such as time, distance, velocity, mass, momentum, energy, and weight, and units are used to describe their measure."

So, in principle, you could do something like

ex:Bridge

  rdfs:subClassOf [

      rdf:type owl:Restriction ;

      owl:onClass ex:Height ;

      owl:onProperty qudt:quantity ;

      owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;

    ] ;

.

However, sine it is in OWL, there is an open world assumption, so if there wasn't a quantity of type ex:Height for a given bridge, it would not be an issue. And, if a given bridge has two quantities of type ex:Height, this wouldn’t raise any issues either - unless each time you create a new instance of Height you say that it is a different individual from all other instances of Height (which is just not practical).

So, as Holger says, the way you want to model depends on the use case. If you are trying to do constraint checking to ensure that there is height, SHACL would be the way to go.

<image001.gif>

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

-- 
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 topbrai...@googlegroups.com
--- 
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 topbraid-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bohms, H.M. (Michel)]

Hi Holger

Still open.. for now we analyse how complex the modelling sec is.

 

(but validation would be more relevant than autom. classification).

 

And we best compare in case of “all in owl/rdfs/rdf”,

Gr michel

[Bohms, H.M. (Michel)]

Hi Irene

 

Thx for your feedback!

 

Some counter feedback.

 

1.

In qudt2.0 one would instantiate QuantityKind with Height (not subclass)

(well that is how I understood it earlier from Ralph). Like:

:Height

rdf:type qudt:QuantityKind ;

qudt:generalization quantity:Length .

 

(ie use the qudt defined “generalization” property to do the subclassing in the meta-data so to say).

But maybe your way (really subclassing is an alternative way which would indeed simplify the restriction like you showed).

I’ll check that.

 

2.

Typically we have a closed world interpretation. That would mean that with the current complex restriction (see earlier mail) we would be beyond OWL-RL and so beyond your OWL-RL SPIN closed world support…so indeed to keep in mind depending on the things we want to do with it…….(so if we want to really validate then go for SPIN-constraints or SHACL indeed).

3.

So far I use the example to determine modelling styles and to show people the modelling consequences (class-level but especially also data-level). In general we want to promote ‘simplicity’ esp. when dealing with big data where the structure IS typically also quite simple (ie csv-like TB inputs).

 

Greetings, Michel

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

 

From: topbrai...@googlegroups.com [mailto:topbrai...@googlegroups.com] On Behalf Of Irene Polikoff

Sent: dinsdag 9 mei 2017 04:45
To: topbrai...@googlegroups.com

[Ralph TQ [Gmail]]

Michel

Irene is correct.

See http://www.qudt.org/pages/QUDToverviewPage.html 

For:

A quantity is the measurement of an observable property of a particular object, event, or physical system. A quantity is always associated with the context of measurement (i.e. the thing measured, the measured value, the accuracy of measurement, etc.) whereas the underlying quantity kind is independent of any particular measurement. Thus, length is a quantity kind while the height of a rocket is a specific quantity of length; its magnitude that may be expressed in meters, feet, inches, etc. Examples of physical quantities include physical constants, such as the speed of light in a vacuum, Planck's constant, the electric permittivity of free space, and the fine structure constant. 

In other words, quantities are quantifiable aspects of the world, such as time, distance, velocity, mass, momentum, energy, and weight, and units are used to describe their measure. Many of which are related to each other by various physical laws, and as a result the units of some of the quantities can be expressed as products (or ratios) of powers of other units (e.g., momentum is mass times velocity and velocity is measured in distance divided by time). These relationships are discussed in dimensional analysis. Those that cannot be so expressed can be regarded as "fundamental" in this sense.

A quantity is distinguished from a "quantity kind" in that the former carries a value and the latter is a type specifier.

On May 9, 2017, at 12:22 PM, Bohms, H.M. (Michel) <michel...@tno.nl> wrote:

Hi Ralph,

 

Could I please have your feedback on the issue (1.) below?

 

So how to deal with end-user properties like “height”?

(green parts are the same)

 

1. I did so far

 

ex:Bridge1 a ex:Bridge ;

qudt:hasQuantity ex:Quantity1 .

 

ex:Quantity1 a qudt:Quantity ;

qudt:quantityValue ex:QuantityValue1 ;

qudt:hasQuantityKind ex:Height .

 

ex:QuantityValue1 a qudt:QuantityValue;

qudt:numericValue ’50’;

qudt:unit unit:M .

 

ex:Height rdfs:subClassOf qudt:Quantity.

 

2. Irene proposed

 

ex:Bridge1 a ex:Bridge ;

qudt:hasQuantity ex:Quantity1 .

 

ex:Height rdfs:subClassOf qudt:Quantity.

 

ex:Quantity1 a ex:Height;

qudt:quantityValue ex:QuantityValue1;

qudt:hasQuantityKind qudt:Length .

 

ex:QuantityValue1 a qudt:QuantityValue;

qudt:numericValue ’50’;

qudt:unit unit:M .

 

Both seem valid approaches (although mine would explain your qudt:generalization property, although this could also be tehre for qudt-internal use only…). Clearly, Irene’s variant would make (owl) restrictions easier having height explicitly available as Class so it can be used directly in a QCR…

 

Thx a lot for your ideas! Michel

[Bohms, H.M. (Michel)]

Hi Ralph

 

Just checking 😊

 

Note that both approaches seem to be according to your link/text.

 

How would I know (from that text) that for an own user-defined property like ‘height’ I would have to specialize Quantity and not instantiate QuantityKind?

 

(ie why isn’t ‘height seen as a more specialized variant from length, a fact that can be even described using your own specific specialization object property call “qudt:generalization”).

 

 

As a matter of fact I just followed your proposal sent to me on 14-09-2016… :

Has these approach changed meanwhile maybe?

 

Thx a lot,

Sorry for coming back on this, just want to understand/use the right way!

Michel

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

[Jack Hodges]

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.

[Irene Polikoff]

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.

[Steve Ray]

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:    stev...@sv.cmu.edu

Phone: (650) 587-3780

Cell:      (202) 316-6481

Skype: steverayconsulting

 

From: topbrai...@googlegroups.com [mailto:topbrai...@googlegroups.com] On Behalf Of Irene Polikoff

Sent: Tuesday, May 09, 2017 8:23 AM
To: topbrai...@googlegroups.com

 

Virus-free. www.avg.com

[Bohms, H.M. (Michel)]

Hi Steve,

See after >

 

 

 

From: topbrai...@googlegroups.com [mailto:topbrai...@googlegroups.com] On Behalf Of Steve Ray
Sent: dinsdag 9 mei 2017 21:00
To: topbrai...@googlegroups.com
Subject: RE: [topbraid-users] RE: owl modelling issue in tbc

 

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.

 

Ø    I see your point here and like the idea to differentiate contextual versus context-free (the latter being any algebraic combi of the basic quantities).

 

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.

 

• First note that your proposal is yet another variant of modelling than the 2 I introduced earlier:

1. Me: height is instance of QuantityKind
2. Irene: height is subClassOf Quantity
3. You: height is instance of Quantity

 

• Although I like your distinction between contextual/non-contextual I do not agree your “THUS”. The difference between Quantity and QuantityKInd is currently much more like a ‘valued quantity’ versus a ‘quantity’. Ie length=10M versus length, not between height and length.

 

 

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!

 

Ø    I think starting point for resolution of this issue is going back to the intended meaning of qudt:QuantityKind.

Ø    Interpretation 1: only basic quantities and their algebraic derivations

• Interpretation 2: any quantity including contextuals like height (the name “QuantityKind does suggest this). Note that height is also  also mentioned btw as quantity in eg ISO 31-1.
• In case of 1, we have to decide how to deal with the non-contextual ones:
  • I think Irene’s option is not the way to go since height is  not the same as the concept of ‘ValuedHeight’.
  • Also it’s not an instance of Quantity as said earlier
  • It is really a QuantityKind but not a standard one: so maybe you have to subclass QuantityKind into Standard/ReferenceQuantityKind and UserDefinedQuantityKind…

Gr Michel

 

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.