HajoRijgersberg/OM

Complex units

Opened this issue · 21 comments

Hi Hajo,

is there any fundamental reason why complex units (e.g., for complex power in electricity, falling into real power, reactive power, and angle $\phy$)?

I realize that complex numbers are not available as primitive types in XML: https://docstore.mik.ua/orelly/xml/schema/ch04_04.htm

Hi Georg,

Could you explain your first sentence a bit more? The sentence seems to be incomplete in some way.
Apart from that, do you mean compound units with complex units, like m/s, m2, kg/m3, etc.?

Interesting point. Indeed I have not encountered complex numbers in XML, XSD, RDF or OWL so far.
If anyone could comment on this, that would be appreciated!

Best, Hajo

Hi Hajo,

well, some physical phenomena are described using complex numbers (real number plus imaginary number). My example above is power in an AC grid: If in an AC cable voltage and current are out of phase by some angle φ, then some power Q oscillates back and forth through the cable, described as reactive power (as opposed to the active power P, see https://en.wikipedia.org/wiki/AC_power). A complete description of the power in a cable is then given through the complex power S = (P + i × Q) (which elegantly captures the two values and the phase angle). Reactive power plays an important role in grid operations.

P is usually expressed in watt, Q in "volt-ampere reactive" (var), and S in "volt-ampere" (VA). All of these units are watt by dimension, the different names just serve for distinction.

S can be expressed as a tuple, for example (|S|, cos(φ)), or (P, Q), etc. It would also be nice to be able to just give S as a complex number. But a complex type literal is not foreseen in XML. Therefore I am looking for a good way to capture that in om-2. I will try to figure it out, but of course I would be highly interested in how you would do it! :-)

Cheers,
Georg

Hi Georg,

That's a very interesting and clear explanation, thanx! Quite a challenge indeed to express that in OM. Seems like apart from scalar, vector and matrix types, we should have a complex type or something like that. Of course then we need two parts that the particular quantity consists of. Not sure how to accomplish that. I keep myself recommended for ideas indeed and I'll discuss it within my organization. One of the authors of OM has a background in physics.

Thinking very simply, we could start with defining the three quantities you mention in OM (active power, reactive power, and complex power I think?) as subclasses of power. We could also define the units volt-ampere reactive and volt-ampere, and link them to the corresponding classes. Since the numerical value of a measure in OM is a string, the value of the complex power could be expressed as P + i x Q. Not very convenient, but perhaps a start.

Let's (again) keep each other updated! :)

Cheers, Hajo

Hi Hajo,

two thoughts.

You already have a unit om-2:one for scalar quantities (dimension one), basically for dimensionless quantities. Would it help to also add the imaginary unit i?

Also, in #27 you already discuss multi-value units (unit chains, conjugate units, couple units). Would a similar approach work for actual tuples (complex numbers are a 2-tuple (or pair) of a real and an imaginary number).

With some hints from you I would work on that. It is needed for a running project.

Hi Georg,
I presume that the imaginary part of a complex number doesn't have a different unit than the real part. It seems more like a special tuple, a complex number, with two parts that have different roles: the real part and the imaginary part. Or should we perhaps define '+', '*' and 'i' in an imaginable future mathematical ontology? Or do such ontologies perhaps already exist? It's been a long time ago that I have dived in mathematical ontologies.

So indeed, I see the relation with the measure chains/tuples, in issue 27. Although - as mentioned above - the parts seem to have these different roles, where in the discusses chains/tuples in that issue they all have equivalent roles.

Hope I have given some hints this way. Not sure though. Looking forward to your reply! :)

Right, I agree with your argument. A pair of real and imaginary value together would have one unit together. A complex power S would have an active power P (real value), and a reactive power Q (imaginary value), so S = (P + i Q). The unit would be the unit of S. P and Q have different roles. Also, a tuple is different than a chain. So, agreed.

So first: How can we consolidate that with om-2:Measure (where currently a measurement expects one single real numerical value)? I think it would be overkill to simply always allow complex numerical values, for most measurements they would not make sense.

Second: Given the ubiquity of AC electricity application, we have some generally used, simplified, conventions.

  • P, the active power, is measured in watt
  • Q, the reactive power, is measured in voltampere-reactive (var)
  • S, the complex power, is measured in voltampere (VA)
  • |S|, the absolute value of the complex power (the apparent power), is also measured in VA.
    All of them equivalent to watt by dimension. Most people with a technical (instead of a scientific) background would use this and not bother with complex numbers. The phase angle ϕ is by convention given through its cosine cos(ϕ).

I tried to add classes and individuals for these. I know this is a lot to ask, but I would be really grateful for some review/comment as to whether I am on the right track. Actual complex measurements can wait a bit.

@prefix : <http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ic-forecast: <http://ontology.tno.nl/interconnect/forecast> .
@base <http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units> .

<http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units> rdf:type owl:Ontology ;
                                                               owl:imports <http://www.ontology-of-units-of-measure.org/resource/om-2> ;
                                                               <http://purl.org/dc/elements/1.1/creator> "Georg Jung - Vito" .

#################################################################
#    Classes
#################################################################

###  http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#ActivePower
:ActivePower rdf:type owl:Class ;
             rdfs:subClassOf <http://www.ontology-of-units-of-measure.org/resource/om-2/Power> ;
             rdfs:comment "Active or real power, to be measured in watt (W)."@en ;
             rdfs:label "active power" .


###  http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#ApparentPower
:ApparentPower rdf:type owl:Class ;
               rdfs:subClassOf <http://www.ontology-of-units-of-measure.org/resource/om-2/Power> ;
               rdfs:comment "Apparent power, the magnitude of complex power, to be measured in volt-ampere (VA), equivalent to watt."@en ;
               rdfs:label "apparent power" .


###  http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#ReactivePower
:ReactivePower rdf:type owl:Class ;
               rdfs:subClassOf <http://www.ontology-of-units-of-measure.org/resource/om-2/Power> ;
               rdfs:comment "Reactive power, to be measured in volt-ampere reactive (var), equivalent in dimension to watt."@en ;
               rdfs:label "reactive power" .


#################################################################
#    Individuals
#################################################################

###  http://www.ontology-of-units-of-measure.org/resource/om-2/kilowatt
<http://www.ontology-of-units-of-measure.org/resource/om-2/kilowatt> owl:sameAs :kiloVoltAmpereReactive .


###  http://www.ontology-of-units-of-measure.org/resource/om-2/watt
<http://www.ontology-of-units-of-measure.org/resource/om-2/watt> owl:sameAs :voltAmpere ,
                                                                            :voltAmpereReactive .


###  http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#kiloVoltAmpereReactive
:kiloVoltAmpereReactive rdf:type owl:NamedIndividual ,
                                 <http://www.ontology-of-units-of-measure.org/resource/om-2/PrefixedUnit> ;
                        <http://www.ontology-of-units-of-measure.org/resource/om-2/hasDimension> <http://www.ontology-of-units-of-measure.org/resource/om-2/power-Dimension> ;
                        <http://www.ontology-of-units-of-measure.org/resource/om-2/hasPrefix> <http://www.ontology-of-units-of-measure.org/resource/om-2/kilo> ;
                        <http://www.ontology-of-units-of-measure.org/resource/om-2/hasUnit> <http://www.ontology-of-units-of-measure.org/resource/om-2/watt> ;
                        <http://www.ontology-of-units-of-measure.org/resource/om-2/symbol> "kvar" ;
                        rdfs:comment "Power unit for reactive power"@en ;
                        rdfs:label "kilovolatampere reactive" .


###  http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#voltAmpere
:voltAmpere rdf:type owl:NamedIndividual ;
            rdfs:comment "volt ampere (VA) is equivalent to watt by dimension. It is used to measure complex power S or apparent power |S| in an AC power grid."@en ;
            rdfs:label "volt ampere" .


###  http://www.semanticweb.org/jungg/ontologies/2021/5/ic-units#voltAmpereReactive
:voltAmpereReactive rdf:type owl:NamedIndividual ;
                    rdfs:comment "volt ampere reactive (var) is equivalent by dimension to watt. It is used to measure reactive power (\"wattless power\") in an AC power grid."@en ;
                    rdfs:label "volt ampere reactive" .

Maybe a word about the context. There is a giant EU project going on (50+ partners) where semantic web technology is to be used to establish interoperability in a technical field. The main ontology used there does not stand the test of practice. I am convinced that you approach would. Let me know if you want to know more... Moving on to issue #27 😁

So first: How can we consolidate that with om-2:Measure (where currently a measurement expects one single real numerical value)? I think it would be overkill to simply always allow complex numerical values, for most measurements they would not make sense.

I have to think about this. A class om:StructuredMeasure should be defined, with subclasses om:TupleMeasure, om:ComplexNumberMeasure, a.o. But could it be a subclass of om:Measure? Maybe not, because om:StructuredMeasure doesn't need the properties om:hasNumericalValue and om:hasUnit of om:Measure. To be continued.

Second: Given the ubiquity of AC electricity application, we have some generally used, simplified, conventions.

I realize that in the example the real and imaginary parts do have different units, as well as the overall measure. So, this is in contrast with what I just indicated in #27...

I tried to add classes and individuals for these. I know this is a lot to ask, but I would be really grateful for some review/comment as to whether I am on the right track. Actual complex measurements can wait a bit.

Thanx, I really appreciate that, and I'm very willing to review. The only thing is, I have to do that a bit later. Hope that's no problem for you. I'll try in the next few days.

Maybe a word about the context. There is a giant EU project going on (50+ partners) where semantic web technology is to be used to establish interoperability in a technical field. The main ontology used there does not stand the test of practice. I am convinced that you approach would. Let me know if you want to know more...

Yes, sounds very interesting!

Quick note: Algebraically, complex numbers are an extension of R2. Over addition and multiplication with R they are isomorphic, but vector cross product R2 × R2R2 is not the same as multiplication in C × CC. Not sure what that means for complex numbers becoming a sub-class of 2-tuples...

Second quick note: var and VA are (more or less) just aliases for watt. They carry the information about the physical nature of the power they describe just due to practical convention. The complex power S has really just one unit (VA, same as watt), but two numerical components (real and imaginary). It does not have two different units. Even if we look at each part separately (e.g., only the reactive power), the unit is still the same, only we use an alias for distinction. I think that was a bit unclear in my explanation above.

Tuples are also interesting to me to express ranges (a min and a max value). I need that too, but I still work on a solution which works around adding to om-2, rather I work with the structures that make use of om-2. A solution inside om-2 however would still make this easier.

I temporarily made my personal e-mail address public on Github, contact me if you'd like to know more about the project.

Sorry, I haven't found the time to dive into your longer message. My aim now is to that end of the week/weekend. I'll keep your last notes in my mind when I do that.

Min-max and variations (e.g. min-mean-max) are very important to my opinion. Possibly we can incorporate that too. Seems like - again - special kinds of tuples.

I can't find your email address. Maybe I was too late.. Or where precisely can I find it?

I too feel Min-max and variations (e.g. min-mean-max) are are very important, they are best represented by tuples, and sit under Uncertainty, something that's not well represented anywhere I've looked.
Given I haven't (yet) deployed OM I haven't felt brave enough to start a New OM Issue on this as I'm uncertain (aha, a pun) on how to link it in.
I would love to contribute to an OM discussion on representing Uncertainty.

Hi @HajoRijgersberg,

It's georgjung@acm.org. I will be on a break however from today until August 9.

@taxles, thanks for chipping in. In terms of uncertainty, there is already standard distribution as an aggregate function in OM, although I am not sure how to use it. Generally, uncertainty would be very useful, so I would like to hear your ideas.

Currently I was not looking for uncertainty though, actually I wanted a range. Kind of like a tolerance (a temperature band, power constraints for charging, etc.). I suppose however that a min-mean-max tuple is even better. If that falls into the same category as uncertainty that great, but I am not entirely sure (is a tolerance the same as an uncertainty?).

Thanks Georg, I'll email you.
And indeed Taxles, thanks for discussing. No, you don't have to be "uncertain" as far as I'm concerned! :D
Yes, I do think that uncertainty has to do with min-max ranges, distributions, etc. Tolerance seems more like a role, but it is already a good example of the fact that modeling these kinds of things is not an easy task. I must therefore be honest (of course) that I cannot estimate how quickly this process will go. For example, we also need to think of good names for the various functions, and what their operands are called, etc. And then this all has to happen in spare time. But I think it's a very important topic and hope that with both your contributions and Jack's (see qudt/qudt-public-repo#420) we can come to a design!
As mentioned, Georg, I will first study your longer post above. To be continued!

Thanks Hajo,
the 'uncertainty' issue has been around for a very long time and (I feel) it's far more important that it be discussed and better understood before any attempts be made to model it.
As such I've just created new Issue Uncertainty (#52) to help progress the discussion.
I'll generate (and post) a summary of my study to date.
Regards, AL.
Alastair Paton

Thanx Al, for creating the new issue, and looking forward to your post there! :)

Hi Georg,

I have just studied your proposal of classes and instances. Sorry, I was mistaken that it would take me longer to study; I thought I would because I thought it was a proposal for the complex numbers and so on.
Your proposal seems Ok to me. I only have some minor issues and some further hints:

  • As to voltAmpereReactive, am I correct that we should use a dash between 'Ampere' and 'Reactive'? I admit this is very minor, but I always intend to define everything as correct as possible.

  • You could also define the symbols and dimensions for the different quantities, again using om:hasSymbol and a class restriction on om:hasDimension, just like:

    <owl:Class rdf:about="&om;Length">
    rdfs:subClassOf
    owl:Restriction
    <owl:onProperty rdf:resource="&om;hasDimension"/>
    <owl:hasValue rdf:resource="&om;length-Dimension"/>
    </owl:Restriction>
    </rdfs:subClassOf>
    </owl:Class>

  • You could define label, hasSymbol and hasDimension for the various units just like you did for kiloVoltAmpereReactive.

  • You use 'sameAs' for indicating that some units are the same. This is Ok, but in OM we define units in terms of each other (actually a set of base units), just like with the inch:

    <om:hasFactor rdf:datatype="&xsd;float">2.54e-2</om:hasFactor>
    <om:hasUnit rdf:resource="&om;metre"/>

  • We could restrict the om:hasValue property of the three quantity classes to the corresponding units. That's a bit more complicated to do, but I can do that, especially once I incorporate your classes and units in OM. It is not the most crucial thing to do though, at this very moment.

So, you're definitely on the right track - much more than that! :)

Cheers, Hajo

Hi Georg,

I see I hadn't really responded to your quick notes. Now I do:

Quick note: Algebraically, complex numbers are an extension of R2. Over addition and multiplication with R they are isomorphic, but vector cross product R2 × R2 → R2 is not the same as multiplication in C × C → C. Not sure what that means for complex numbers becoming a sub-class of 2-tuples...

Not sure too. But if I think very simply, I think we only need to represent complex numbers (or: complex number measures), and do not have to deal with computations. At least, that is out of the scope of OM. In a broader sense - semantics of mathematics, computations, etc. - that would of course be very interesting. Purely due to time restrictions I couldn't focus on that - apart from that a very interesting subject...

Second quick note: var and VA are (more or less) just aliases for watt. They carry the information about the physical nature of the power they describe just due to practical convention. The complex power S has really just one unit (VA, same as watt), but two numerical components (real and imaginary). It does not have two different units. Even if we look at each part separately (e.g., only the reactive power), the unit is still the same, only we use an alias for distinction. I think that was a bit unclear in my explanation above.

Thanx, I do think your explanation was already clear. But now it's even clearer.
In general I have always had some difficulties with units that are the same; I mean: how to model them? As different units that have a conversion factor of 1, or as one unit with different names? I have not found an answer to that question so far, over the years. You say 'aliases', do you mean that they are actually one unit with several - alternative - names? Now that I write this question, I do not think so, because these alternative names (var and VA) can not be used in general as alternative names for watt...

Tuples are also interesting to me to express ranges (a min and a max value). I need that too, but I still work on a solution which works around adding to om-2, rather I work with the structures that make use of om-2. A solution inside om-2 however would still make this easier.

In issue #52 we are working on a design for OM now. So, I'll include min-max there. Don't know when the design will be finished though - it's all in spare time. I think - because we will define a range of special measures - I will need to start OM 3.0, because the om:Measure as we have it now will become om:SimpleMeasure (as I see it now), and om:Measure will be the overarching class of all measure classes.
So, I'm also very interested in your solution!

Cheers, Hajo

Hi Hajo,

Not sure too. But if I think very simply, I think we only need to represent complex numbers (or: complex number measures), and do not have to deal with computations. [...]

True. My thinking was probably too complicated. Still, R2 is not the same as C.

In general I have always had some difficulties with units that are the same; I mean: how to model them? As different units that have a conversion factor of 1, or as one unit with different names? I have not found an answer to that question so far, over the years. You say 'aliases', do you mean that they are actually one unit with several - alternative - names? Now that I write this question, I do not think so, because these alternative names (var and VA) can not be used in general as alternative names for watt...

Well, alternative ways to express units do make sense. For example, gas mileage is the same as area, with 20 miles per gallon being roughly 0.1 mm2, as brilliantly explained in Droppings. But this is something you already capture in om, with watt and joule per second (same unit) or meter and yard (same dimension). The base unit approach is tried and true, and watt vs var is the only example I know where (in a technical application) the names should not be mixed. The only real problem from a physics point of view is the 'r' (reactive). Just like with kWp ("kilowatt peak", used to measure/advertise the theoretical peak power of solar panels, in reality the power they yield is lower and depends on the momentary exposure/irradiation), it is awkward to suffix a perfectly fine physical unit with a qualifier that basically says that you are making things up and which has no dimension. 😉

The problem with reactive power is that it cannot be put to work (it goes straight to entropy). It was therefore called "Wattless power", which is a weird expression. As reactive power has the same dimension as active power physically but differs technically, a distinction was needed (don't call it watt, it's wattless). Watt is the same as Volt × Ampere, which in turn are units only really used in electricity. So there is our distinction, use VA for "wattles" power. Not an elegant solution, but engineers have been using that for a century and a half. Not something you and I need to solve now.

Tuples are also interesting to me to express ranges (a min and a max value). I need that too, but I still work on a solution which works around adding to om-2, rather I work with the structures that make use of om-2. A solution inside om-2 however would still make this easier.

In issue #52 we are working on a design for OM now. So, I'll include min-max there. Don't know when the design will be finished though - it's all in spare time. I think - because we will define a range of special measures - I will need to start OM 3.0, because the om:Measure as we have it now will become om:SimpleMeasure (as I see it now), and om:Measure will be the overarching class of all measure classes.
So, I'm also very interested in your solution!

I'll check that out. Also, I will make sure that we are early adopters of OM 3.0! And thanks so much for reviewing my baby steps at ontology design, I cannot stress enough how much this feedback helps!

Hi Georg,

Still, R2 is not the same as C.

Think so too. Would be relevant for an ontology that supports computations. Has been a goal of mine once, but so far I have stuck with units stuff... ;)
I really hope, in a far future, to define such things. Although I would like to (re)start then by looking at the state of the art (the current popular approaches).

gas mileage is the same as area, with 20 miles per gallon being roughly 0.1 mm2

Interesting! I should think about proper ways how to define (model) that in OM. I guess it is not straightforward since in general of course length per volume is not the same area. Now that I write this, it is 1/area (reciprocal area).

But this is something you already capture in om, with watt and joule per second (same unit) or meter and yard (same dimension).

Correct, but watt and joule per second, and meter and yard, are defined as different units in OM, with conversion factors between them. (Watt = 1 joule per second; yard = 0.9144 meter.)

watt vs var is the only example I know where (in a technical application) the names should not be mixed.

Clear. This comes down to that watt and var should be defined as different units, with a conversion factor of 1 between them. I think.

The only real problem from a physics point of view is the 'r' (reactive).

It's strange, but we'll just accept it and adopt it like that. I guess. Do you think so too?

Just like with kWp ("kilowatt peak", used to measure/advertise the theoretical peak power of solar panels

Good example! Indeed, it deviates from the SI, but if people use it that way massively we should define it. OM also supports things outside the SI, like other systems of units or units that are used very widely.

The problem with reactive power is that it cannot be put to work (it goes straight to entropy). It was therefore called "Wattless power", which is a weird expression. As reactive power has the same dimension as active power physically but differs technically, a distinction was needed (don't call it watt, it's wattless). Watt is the same as Volt × Ampere, which in turn are units only really used in electricity. So there is our distinction, use VA for "wattles" power. Not an elegant solution, but engineers have been using that for a century and a half. Not something you and I need to solve now.

No problem, we can define VA and indicate for the quantity 'reactive power' that it should be used. I guess wattles power is an alternative name for reactive power?
Indeed, we should not change this, because people will not adopt that.

Tuples are also interesting to me to express ranges (a min and a max value). I need that too, but I still work on a solution which works around adding to om-2, rather I work with the structures that make use of om-2. A solution inside om-2 however would still make this easier.

In issue #52 we are working on a design for OM now. So, I'll include min-max there. Don't know when the design will be finished though - it's all in spare time. I think - because we will define a range of special measures - I will need to start OM 3.0, because the om:Measure as we have it now will become om:SimpleMeasure (as I see it now), and om:Measure will be the overarching class of all measure classes.
So, I'm also very interested in your solution!

I'll check that out.

Looking forward to it, thanx! :)

Also, I will make sure that we are early adopters of OM 3.0! And thanks so much for reviewing my baby steps at ontology design, I cannot stress enough how much this feedback helps!

Glad it helps! And thanx for all your words and ideas! And thanx for your intention to use OM 3.0 once it's there! :)

Ok, I think this concludes most of the discussion:

  • VA and var are different units than watt, but have a conversion factor of 1. Therefore, VA and var can be introduced into OM as we had them modeled above. I implemented your comments from #51 (comment), except for restricting the om:hasValue property, but I suppose I know how I would do that.
  • Actual complex numbers could be handled like numbers from R2, since arithmetic is not modeled. This might get approached in OM 3.0. It is no longer urgent, since with the distinction VA - var - watt, a technically viable solution now exists.
  • Unit cancellation is strange: miles per gallon is reciprocal area, liters per 100 kilometer is area. That is just a reality...

So I will go with this and otherwise wait for OM 3.0. Attached is the turtle file with VA and var defined, use freely if it turns out useful for you: ic-units.ttl

Let's close this issue. Thanks!!

VA and var are different units than watt, but have a conversion factor of 1. Therefore, VA and var can be introduced into OM as we had them modeled above.

I definitely think so too!

Actual complex numbers could be handled like numbers from R2, since arithmetic is not modeled. This might get approached in OM 3.0. It is no longer urgent, since with the distinction VA - var - watt, a technically viable solution now exists.

Ok.

Unit cancellation is strange: miles per gallon is reciprocal area, liters per 100 kilometer is area.

Yes, that is correct. Earlier you stated that miles per gallon was area.. :)

Attached is the turtle file with VA and var defined, use freely if it turns out useful for you: ic-units.ttl

Thanx, I'll study it and intend to incorporate it soon into OM!

Because of time reasons I have not yet been able to continue this study/incorporation yet, Georg, but it's not from my list!