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

What is the status of sdmx though? I looked at it and its definitions are
over specific imho. Uom is a much more fundamental concern than the scope
of the various sdmx vocabs.  This is at the core of the BP challenge... the
difficulty of reuse in a bit of a governance vacuum for common concerns.
Imho Sdw needs to  pave the way for better designed common components under
w3c auspices.

Rob Atkinson

On Thu, 15 Dec 2016, 9:30 AM Andrea Perego <andrea.perego@jrc.ec.europa.eu>
wrote:

> 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.
>
>
>