Re: units of measure - was RE: Comments on the SOSA and SSN implementations

Hi Rob

i have an open issue in the QB4ST [1] space re UoM - i need to give people
the ability to define spatial resolution, and potentially start and end of
value ranges, and this needs an UoM.


What is the exact reference to the issue in the tracker ? I'm not sure to
fully get what you want to achieve there:

Where could a spatial resolution definition be attached ?
 - to one dimension in one observation ?
 - to one qb:ComponentProperty whose qb:componentProperty is a
qb:DimensionProperty ?

How would the start and end of values range we used ?
 - to annotate the measure in each observation ?
 - to annotate the measure in a slice or a dataset ?
 - to individually annotate a measure in each observation,
 - to individually annotate a measure in a slice or a dataset ?
 - to annotate a qb:ComponentProperty whose qb:componentProperty is a
qb:MeasureProperty ?


The options I see are:
1) declare it as unsolved and out of scope - and just refer to the BP text
on the matter

2) bind QB4ST to a specific namespace (i.e the OGC register which uses
Ucum, as its the only resource within the OGC/W3C governance space I can
see)

3) declare a UoM class and an instance of a skos:ConceptScheme for UoM,
inside QB4ST, and introduce axioms that imply that any UoM resources
referenced belong to this if you use QB4ST to describe such data.
4) rely on UoM being specified by the CRS being referenced - and push the
problem to canonical CRS resources and also representations as the client
will need to be able to extract the uoM details reliably.


We can define a canonical means to attach UoM as metadata to a Component
(Dimension or measure), which is still a Good Thing I think.


I think that last sentence well in line with the spirit of the Data Cube
spec.


--- the rest of this mail might be off topic, it was an initial answer ---

the sdmx-attribute:unitMeasure attribute property in the RDF Data Cube REC
can be used to annotate the measure(s) component(s) in an Observation, and
I believe it would apply to each and every measure in the Observation.

If it is applied to the DataSet or to some slice, then the normalization
algorithm make it propagate to each of the individual Observations.
If we need to annotate measure components individually, that could be
possible by not using the sdmx-attribute:unitMeasure attribute property,
but instead use some complex OWL data in each measure.

For example, adapting Example 9 from RDF Data Cube REC, and using QUDT 1.1:

eg:o1 a qb:Observation;
  qb:dataSet eg:dataset-le1 ;
  eg:refArea ex-geo:newport_00pr ;
  eg:refPeriod <
http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y>
;
  sdmx-dimension:sex sdmx-code:sex-M ;
  # remove this sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year>
;
  eg:lifeExpectancy [
    a qudt:QuantityValue ;
    qudt:unit unit:Year365Day ;
    qudt:numericValue 76.7 ]
  eg:averageWeight [
    a qudt:QuantityValue ;
    qudt:unit unit:Kilogram ;
    qudt:numericValue 63.3 ]
  eg:averageHeight [
    a qudt:QuantityValue ;
    qudt:unit unit:Meter ;
    qudt:numericValue 1.72 ] .

The pros of this solution is that every measure can have a separate units,
and one can also annotate them with some more metadata, such as the
confidence interval

The cons are that more triples are necessary for each measure in each
observation, and I don't see any proper way to attach the qudt:unit
metadata at the level of a dataset or a slice.

Kind regards,
Maxime



Any thoughts?


Rob

[1] http://w3c.github.io/sdw/qb4st/



On Fri, 3 Feb 2017 at 09:38 <Simon.Cox@csiro.au> wrote:

Yes – agree that UoM is out of scope for SDWWG and SSN. It is a much more
general issue – arguably it is a fundamental gap in almost all programming
languages and libraries. A reasonable case can be made that there are
almost no floats, doubles or decimals in the real world that should not be
accompanied by a scaling factor (to turn them into amounts or quantities).
There are a few dimensionless quantities in physics, but even those require
some annotation to make them comprehensible.



When I was editor of ISO O&M there was a push from outside the project team
for UoM to be added to the scope of ISO 19156.

The appearance of the word ‘Measurements’ in the title of O&M triggered
this (which is itself really a hangover from the early history of that
project), but we decided to keep the scope of O&M narrow –
property-value-estimation activities + sampling. If we were starting again
I’d probably suggest calling it O&S (observations & sampling).



Simon



*From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
*Sent:* Friday, 3 February, 2017 01:16
*To:* Maxime Lefrançois <maxime.lefrancois@emse.fr>; Cox, Simon (L&W,
Clayton) <Simon.Cox@csiro.au>; andrea.perego@jrc.ec.europa.eu;
rgarcia@fi.upm.es
*Cc:* public-sdw-wg@w3.org
*Subject:* RE: units of measure - was RE: Comments on the SOSA and SSN
implementations



+1  and this was the same choice made by ssn for the same reason.  Although
 I think we should be helpful  and suggest ways of doing this (ie examples
of using it with popular UoM ontologies) . This is really the job of the
“primer’ we were to write, but at this point I think the “primer” will be
postponed to the follow on SDW Activity that is being mooted.



*From:* Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr
<maxime.lefrancois@emse.fr>]
*Sent:* Thursday, 2 February 2017 11:27 PM
*To:* Simon.Cox@csiro.au; andrea.perego@jrc.ec.europa.eu; rgarcia@fi.upm.es
*Cc:* public-sdw-wg@w3.org
*Subject:* Re: units of measure - was RE: Comments on the SOSA and SSN
implementations



Dear all,



There exists numerous ways to encode quality values, quantity values, their
units of measures. Existing solutions include ontologies (QUDT, OM, ...),
and the use of some custom datatypes [1]. As it has been noted in some
mails, QUDT is evolving, so is OM, and I expect some new solutions directly
based on UCUM to be proposed soon.



This is not part of the SDW charter, and I strongly believe it should be
carefully left out of the scope of the SSN REC document. I don't believe
SDW is legitimate in encouraging one solution or another, especially since
these solutions are not W3C REC themselves. There potentially may be a
future W3C group that could work on this specific topic.



I would like to draw you attention on how we dealt with this point in the
ITEA2 SEAS project deliverable D2.2 where the SEAS Knowledge Model is
defined [2].

Section 4.2 defines the core module EvaluationOntology [3], which describes
how we practically model the attribution of a value to a property.



In a nutshell, we leave the choice to the users of the SEAS ontologies.



[1] - Maxime Lefrançois, Antoine Zimmermann, Supporting Arbitrary Custom
Datatypes in RDF and SPARQL, In Proc. Extended Semantic Web Conference,
ESWC, May 2016, Heraklion, Crete, Greece

[2] -
http://www.maxime-lefrancois.info/docs/SEAS-D2_2-SEAS-Knowledge-Model.pdf

[3] - https://w3id.org/seas/EvaluationOntology



Kind regards,

Maxime Lefrançois

http://maxime-lefrancois.info/



Le ven. 16 déc. 2016 à 00:20, <Simon.Cox@csiro.au> a écrit :

Hi Andrea -

Thanks for pointing that out. Looks like

dqv:value rdfs:equivalentProperty oml:amount .
sdmx-attribute:unitMeasure rdfs:equivalentProperty oml:uom .

We could re-use, or at least assert this alignment in a mapping graph
somewhere.

But it also looks like DQV (like QUDT) binds the scaled number to a
quantity-type (using dqv:isMeasurementOf).
That is a variation from SSN/SOSA/O&M, where the quantity-type is not bound
to the result but is implied by the value of 'observedProperty'.
SSN/SOSA/O&M also focus on the act-of-observation and a link to or
description of the procedure used (not shown in your dqv example).

Simon

-----Original Message-----
From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu]
Sent: Thursday, 15 December, 2016 19:30
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; rgarcia@fi.upm.es
Cc: public-sdw-wg@w3.org
Subject: Re: units of measure - was RE: Comments on the SOSA and SSN
implementations

Simon, all,

About units of measure, I wonder whether we should also take into account
how this is modelled in DQV.

As said in an earlier thread [1], DQV does not actually defines explicitly
how to this, but they use a consistent approach in their examples [2], by
using dqv:value + sdmx-attribute:unitMeasure. E.g.:


:myDataset a dcat:Dataset ;
     dqv:hasQualityMeasurement :myDatasetPrecision, :myDatasetAccuracy .

:myDatasetPrecision a dqv:QualityMeasurement ;
    dqv:isMeasurementOf :spatialResolutionAsDistance ;
    dqv:value "1000"^^xsd:decimal ;
    sdmx-attribute:unitMeasure
<http://www.wurvoc.org/vocabularies/om-1.8/metre> .

:spatialResolutionAsDistance  a  dqv:Metric;
     skos:definition "Spatial resolution of a dataset expressed as
distance"@en ;
     dqv:expectedDataType xsd:decimal ;
     dqv:inDimension dqv:precision .


I'm not saying this must be adopted in SSN (unless it satisfies SSN
requirements, of course), but I think it is important to clarify when
the different approaches should be used, and to explain whether/how they
are interoperable or not (e.g., through mappings).

If we are going to have two different ways of modelling this piece of
information, adopters may be unsure which one they should use. So, some
guidance may help their consistent implementation.

Thanks

Andrea

---
[1]https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0084.html
[2]https://www.w3.org/TR/vocab-dqv/#ExpressDatasetAccuracyPrecision


On 15/12/2016 3:00, Simon.Cox@csiro.au wrote:
>> * Units of measurement
>> Also, regarding values, I think that right now the ontology falls short
on supporting how to describe them when they require a unit of measurement.
Along the documentation plenty of examples are included that mention a unit
of measurement (e.g., "20m") but in the documentation of sosa:hasValue it
only appears "23 or true", without mentioning the unit anymore. Since
sosa:hasValue is a datatype property, do we expect people to attach the
unit of measurement to a sosa:Result?
>
>
> I believe that the original SSN relied on dul:Region as a super-class
that includes things that can be represented as scaled numbers, but didn't
go into details.
>
>
> In om-lite (
http://www.semantic-web-journal.net/content/ontology-observations-and-sampling-features-alignments-existing-models-0
and http://def.seegrid.csiro.au/ontology/om/om-lite ) we included the
> - MeasureObject - as a generic/abstract class for scaled values -
http://def.seegrid.csiro.au/ontology/om/om-lite#MeasureObject
> - SimpleMeasure - as convenient minimal representation option -
http://def.seegrid.csiro.au/ontology/om/om-lite#SimpleMeasure
>
> For om-lite there is a small set of examples here:
>
https://www.seegrid.csiro.au/subversion/xmml/ontologies/trunk/O&M-OWL/examples.ttl
> In here you can find the following:
>
> ...
>   oml:result [
>       rdf:type oml:MeasureObject ;
>       oml:uom <http://qudt.org/vocab/unit#Kilogram> ;
>       rdf:value "0.28"^^xsd:double ;
>     ] ;
> ...
>
> ...
>   oml:result [
>       rdf:type oml:SimpleMeasure ;
>       oml:amount "0.28"^^xsd:double ;
>       oml:uom <http://www.opengis.net/def/uom/UCUM/0/kg> ;
>     ] ;
> ...
>
> ...
>   samfl:size [
>       rdf:type oml:SimpleMeasure ;
>       oml:amount "0.46"^^xsd:double ;
>       oml:uom <http://qudt.org/vocab/unit#Kilogram> ;
>     ] ;
> ...
>
> I am certainly not proposing that this is the only solution, but provides
a bit of a framework to work with.
>
> Simon
>
>
> -----Original Message-----
> From: Raúl García Castro [mailto:rgarcia@fi.upm.es]
> Sent: Thursday, 15 December, 2016 03:31
> To: public-sdw-wg@w3.org
> Subject: Comments on the SOSA and SSN implementations
>
> Dear all,
>
> I've been reviewing the implementations of SOSA and SSN and here you have
some comments (plus a couple of pull requests) on each of them and on the
combination.
>
> SOSA
> ----
>
> * sosa:Platform
> The documentation says "(including rdf:type rdfs:Class, owl:Class
humans)", should this be "(including humans)"?
>
> * sosa:Sample
>  From the documentation, a Sample is a FeatureOfInterest (shouldn't
Sample be a subclass of FeatureOfInterest?). I also think that there is no
need for a Sample class; I would just state that a FeatureOfInterest can
have as a sample another FeatureOfInterest. In any case, unless some of
these changes are made, the current model "does not allow" taking samples
of samples.
>
> * sosa:hasValue
> Why not including meta:domainIncludes sosa:Result in this property?
>
> * Units of measurement
> Also, regarding values, I think that right now the ontology falls short
on supporting how to describe them when they require a unit of measurement.
Along the documentation plenty of examples are included that mention a unit
of measurement (e.g., "20m") but in the documentation of sosa:hasValue it
only appears "23 or true", without mentioning the unit anymore. Since
sosa:hasValue is a datatype property, do we expect people to attach the
unit of measurement to a sosa:Result?
>
> * sosa:hosts
> The documentation mentions a SamplingDevice that is not mentioned in the
ontology.
>
> * sosa:madeObservation
> Why is the inverse observedBy property not defined?
>
> * sosa:phenomenonTime and sosa:resultTime I would remove these properties
from SOSA, mainly because I think that they aim for a richer level of
detail than the other concept descriptions in the ontology.
> Having them inside is no main problem, but then their definition is quite
weird since one is defined as an object property and the other as a
datatype property. I understand why they have been defined that way, but it
is not elegant.
> On the one hand, in sosa:phenomenonTime we talk about time intervals and
instants; we have here an opportunity to link to the W3C Time ontology, and
even talk about TemporalEntities?
> On the other hand, in sosa:resultTime we talk about xsd:dateTime (being
the only property in the ontology that specifies a rdfs:range); to be
coherent we should talk about time instants.
>
> * Importing SKOS
> I would move the last triples defining the SOSA ontology to the
beginning. Related to these, why do we need to import SKOS?
>
> SSN
> ---
>
> * ssn:startTime and ssn:endTime
> They are not documented in the ontology with rdfs:comment (it happens in
others such as observedBy). And the link that appears in the description is
"broken" (http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Base#Time).
> They are not used in any of the other entities in the ontology; should we
remove them?
>
> * dul:includesEvent
> The dul:includesEvent property has dissapeared and the local restriction
that relates an Observation to a Stimulus has dissapeared to.
> Maybe it has been made in purpose, but the possibility of relating those
two classes is not there anymore.
>
> * ssn:SensorDataSheet
> This class is not related to other classes or properties in the model.
> Should we remove it or relate it?
>
> SSN+SOSA
> --------
>
> Taking the SSN ontology as it is (in GitHub) and SOSA, right now it
cannot be said that one is a core module of the other, since:
>   -  SSN does not reuse SOSA vocabulary terms (this could be implemented
by mappings)
>   - SOSA adds actuation and sampling
>   - SOSA renames plenty of classes and properties. In some cases maybe
the intended meaning is more or less equivalent, but in others it radically
changes (for example, ssn:hasValue is an object property and sosa:hasValue
is a datatype property).
>   - The modelling decisions in both are different; for example, in SOSA a
Sensor is hosted by a Platform, in SSN a SensingDevice (not a Sensor) is on
a Platform.
>
> The result is that currently we don't have a clean view on the ontology
as a whole as a composition of modules. And for anyone using the ontology
it will be quite difficult to digest everything (e.g., there are 2
time-related properties in SOSA attached to an observation, in SSN there
are another 2 attached to an observation and 2 that are not attached to
anything.
>
> In other words, my opinion is that right now SOSA is something derived
from SSN but we still have plenty of work to do (either changing SOSA, SSN,
or both) to put them together so it can be considered a proper core module.
>
> If not, the risk is to produce two different (even if compatible)
ontologies which is not desirable for interoperability.
>
> In other (now more positive) words, I think that SOSA is the result of a
very good work, and I'd like it to be a proper core part of SSN.
> Let's see how we can do it!
>
> Kind regards,
>

--
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.