search

HajoRijgersberg / OM

Ontology of units of Measure
88 stars 23 forks source link

Support for n-dimensional values #63

Open Maximvdw opened 2 years ago

Maximvdw commented 2 years ago

Most examples use one dimensional values using om:hasValue (http://www.ontology-of-units-of-measure.org/resource/om-2/hasValue) or http://www.ontology-of-units-of-measure.org/resource/om-2/hasNumericalValue.

If I am not mistaken - it is currently not possible in OM to express multidimensional values. Length has X, Y, Z ranges: http://www.ontology-of-units-of-measure.org/resource/om-2/Length http://www.ontology-of-units-of-measure.org/resource/om-2/xRange but they are are subclasses of length.

Basic examples of quantities that supports X,Y,Z values: http://www.ontology-of-units-of-measure.org/resource/om-2/Acceleration http://www.ontology-of-units-of-measure.org/resource/om-2/AngularVelocity http://www.ontology-of-units-of-measure.org/resource/om-2/MagneticField ...

My personal two possible options:

  1. om:hasValueX, om:hasValueY, om:hasValueZ to explicitly specify if it is a x value for acceleration/length, ... However, semantically this means that there could be a different quantity for X, Y, Z
  2. [My preference] om:hasNumericValueX, om:hasNumericValueY, om:hasNumericValueZ because then you always have the same quantity for those numeric values (which makes sense). In addition, I would use om:hasDimension to specify the dimensions of the values
Maximvdw commented 2 years ago

An example

@prefix my: <http://maximvdw.solidweb.org/sensors#> .
@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix om: <http://www.ontology-of-units-of-measure.org/resource/om-2/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

my:accelerometer a sosa:Sensor ;
    my:hasAcceleration [
        a om:Acceleration ;
        om:hasValue [
            a om:Measure ;
            om:hasUnit om:metrePerSecond-Time;
            om:hasNumericalValueX "1"^^xsd:double ; 
            om:hasNumericalValueY "2"^^xsd:double ; 
            om:hasNumericalValueZ "3"^^xsd:double ; 
            om:hasDimension 3 ;
        ] ;
    ] .

Note that om:hasDimension is currently not valid.

HajoRijgersberg commented 2 years ago

Thanx Maxim, for this very interesting and important issue! We don't know the solution yet, and I think your solution may be valuable to many others; anyone can adopt this approach in one's own ontology, by extending OM in the way that you do. From the perspective of OM itself, and including such an approach, my main concern would be: shouldn't we have to define tuples as the values of om:hasValue, or om:hasNumericalValue?

We have three issues that relate to your issue. In one of the issues we have been thinking about starting an overarching issue, and that may well be the issue that you just have raised. I have also just indicated that in one of the issues where we were thinking about that idea.

If you could contribute to these issues, that would be really great. The issues are actually very relevant for the entire Semantic Web and even beyond: programming languages, databases, etc.

dr-shorthair commented 2 years ago

Spatial vectors need to be related to a geodetic reference frame in order to have any real meaning. That involves considerations of coordinate reference systems. There is a whole load of standards (and standards organizations) which you would need to refer to if you plan to head this direction.

dr-shorthair commented 2 years ago

FWIW Spatial concerns were already raised in https://github.com/HajoRijgersberg/OM/issues/6

Maximvdw commented 2 years ago

While I agree that spatial vectors need a reference, limiting it to a CRS limits the uses of OM for non-geographical use cases. Seeing that the geosparql 1.1 draft already allows a nice declaration of reference frames, I personally do not believe it's the job of "the ontology of units of measure" to handle this. Instead a focus on the actually value representation should go first - in the case of Geosparql they can simply rely on serializations such as WKTliterals, but for vectors in OM it should be more general (seeing we do not always know what these vectors represent).

dr-shorthair commented 2 years ago

Explain to me how a spatial vector can be non-geographical, noting that CRS as defined in ISO 19111 (and OGC Topic 2) includes 'Engineering' reference systems which do not have to be earth-linked.

There are other vectors of interest, but for spatial you can't avoid addressing the complexity of CRS, at least by explaining how you would reference external definitions, and how the components of your vector relate to the dimensions of the chosen CRS.

dr-shorthair commented 2 years ago

As I noted in #6 non-scalar quantities, including spatial points or vectors, would be stretching the scope of OM into much much more complicated places. Do you really want to go there? At the very least, partition it into a separate module. This is not trivial.

Maximvdw commented 2 years ago

Explain to me how a spatial vector can be non-geographical, noting that CRS as defined in ISO 19111 (and OGC Topic 2) includes 'Engineering' reference systems which do not have to be earth-linked.

There are other vectors of interest, but for spatial you can't avoid addressing the complexity of CRS, at least by explaining how you would reference external definitions, and how the components of your vector relate to the dimensions of the chosen CRS.

If I would be creating a virtual game, where I want the data to be stored in RDF, using an existing CRS would be incorrect, since we are working with a virtual coordinate system. It does not have to be earth bound indeed. But virtual is a bit more strict that "earth bound"

Similarly, a use case where you are expressing linear velocity on a 2D tabletop does not require a reference frame.

dr-shorthair commented 2 years ago

I did not say 'existing CRS'.

While there are big catalogues of established geodetic CRS available, ISO 19111 provides a model to define a new CRS, including 'engineering CRS', which can be on-the-fly.

In the example you suggest, the table is the reference frame. There is always a reference frame for spatial data. Once you start heading down that path you will very quickly find yourself bumping into the whole corpus of geospatial standards and practice. I know this issue is attempting to extend the OM scope, but please be aware this is not trivial. For example, in the example you started with, what do X Y Z mean? Is Z positive up or down? That has to be written down somewhere.

Maximvdw commented 2 years ago

I agree that xyz should be specified and described, but I am not sure if reference frames should be extended from within OM. In the end, it's the object that created the measurement that has a spatial position and orientation - the measurement it simply an observation at a specific time. I will revisit this thought after the weekend

HajoRijgersberg commented 2 years ago

Hi Maxim and Simon, Sorry for my late reply, these have really been very busy weeks. Thanx for the very interesting discussion. My first feeling is that there is truth in what you both are saying. OM seems in principle suitable for supporting "abstract" spatial vectors. Maybe that's where we should start. On the other hand, working with reference frames is very important for practical use. And we could even think of one step further: defining twirls, rotations, and the like. We could use the work of Tinne de Laet and Herman Bruyninckx of KU Leuven. This is on the wish list of Herman and me.

HajoRijgersberg commented 1 month ago

Presently I'm thinking on how to model more complex measures, also like 3°4'5". From a querying point of view we have a problem, as different kinds of measures (the present single measures, the angle example mentioned here, and the different multiple tuple measures mentioned in the thread above) make querying more difficult, as one has to anticipate in the queries on all these different kinds of measures. Do you, or anyone, has a view on this?

dr-shorthair commented 1 month ago

3°4'5" is not a measure, it is a representation. It is still a scalar and there is a simple and predictable conversion to a decimal representation.