ssn:ext proposal comment: note on section 5.1

[smrgeoinfo]

text reads:

The RDF Data Cube vocabulary uses the term observation for the results, and the dimensions of a data cube indicate the features of interest and phenomenon times of the results, the measures correspond to the observed properties, and the attributes accommodate information about the procedures and sensors.

shouldn't dataCubeDimension map to sosa:observedProperty (phenomenon), and dataCube:measure correspond to sosa:hasResult

[rob-metalinkage]

dataCube is i think somewhat more general:

1. it doesnt restrict the number of measures or the implied set of observation procedures (SOSA requires all results to be from the one observation procedure - QB could be seen as defining a "virtual" observation procedures made up of a set of individual observations - but mapping gets tricky here..)
2. attributes may be things other than information about the observation

as a more general meta-model the thing to do would be to declare a formal profile of QB to match SOSA semantics. This should likely be a formal profile of QB4ST since observations are intrinsically about "T" - there;s a motivation to review and if necessary update that work in the SDWIG :-) - please dont reinvent that wheel...

[rob-metalinkage]

Such a profile would allow you to map canonical attribute names to specific elements of SOSA/SSN. You could map measures to observation procedures via a QB extension for compound observations - QB is all about describing the packaging and a range of a set, not the individual observation object.

[dr-shorthair]

As @rob-metalinkage implies, I don't think we can go from QB to ObservationCollection in one step.
And since the intervening step would be a significant piece of work, I decided to exclude that from the scope of this document.

However, even with that constraint I agree that this comparison is probably under-cooked and could be improved.

[dr-shorthair]

@rob-metalinkage wrote

SOSA requires all results to be from the one observation procedure

Not quite sure what you mean here. SOSA only supports the description of a single, atomic, observation, so of course there is only one procedure involved.

One of the key things in SSN-ext is the addition of ObservationCollection, which allows for aggregations of atomic observations into homogeneous groupings, in which one or more of observed-property, FOI, procedure, sensor etc are common across the collection. This is why a comparison of SSN-ext with QB is warranted (whereas a comparison of SOSA with QB was not very interesting).

[dr-shorthair]

In the draft I wrote:

the dimensions of a data cube indicate the features of interest and phenomenon times of the results, the measures correspond to the observed properties, and the attributes accommodate information about the procedures and sensors.

@smrgeoinfo has suggested instead that

shouldn't dataCubeDimension map to sosa:observedProperty (phenomenon), and dataCube:measure correspond to sosa:hasResult

I'm confused now. @rob-metalinkage I think you probably know QB best. Can you say which of us is (more or less) correct?

[rob-metalinkage]

Observed property is probably a dimension too - anything you would slice and dice, or characterise, an observation collection with is a dimension.

time could be a measure - if what you are doing is observing when something happened, as opposed to what is happening at a time ? This is certainly true for spatial aspects - observed loci of moving features have different dimensions to measurements of the state of a static feature. QB give you the opportunity to make this clear - thats its big advantage w3c/sdw#1 IMHO (#2 is the ability to bind a property to a codelist - nothing else in the W3C canon seems to support this!)

I would re-write it as more like

For a collection of observations the datacube (qb:) model may be used to express aspects of sampling - such as whether a set of samples are all related to the same ultimateFeatureOfInterest, or the same type of FOI etc. Feature of interest, phenomenon time, sampling procedure will typically be qb:dimension sub-properties, measures will be the observed properties and qb:ComponentDescriptions for measures may indicate result types. qb:attribute sub-properties may be used for qualifying and annotating information.

In future a general model for the inter-relation of dimensions, sensors, observed properties, phenomena, units of measure, sampling precision, procedures, etc. could use qb:dimension concepts to describe sampling strategies.

[dr-shorthair]

See modified narrative at https://raw.githack.com/w3c/sdw/simon-ssn-ext/proposals/ssn-extensions/index.html#rdf-data-cube-vocabulary

[rob-metalinkage]

nice..

in note a typo "correspond with a splice"

[dr-shorthair]

Thanks - fixed.