Re: Data Quality Vocab for SDW

Hi Andrea,

Sorry for the delay...

>>>  >> 2. As Rachel said earlier in this thread [1], the new ISO 19115
>>>  >> supports the possibility of specifying resolution as vertical or
>>>  >> angular distance, and with level of detail.
>>>  >>
>>>  >> Based on the DQV example, I guess the first two should be modelled
>>>  >> as instances of dqv:Metric (:spatialResolutionAsVerticalDistance &
>>>  >> spatialResolutionAsAngularDistance), whereas the level of detail
>>>  >> should be specified with a dqv:QualityAnnotation (or a subclass -
>>>  >> :LevelOfDetail).
>>>  >>
>>>  >> Is this correct?
>>>  >
>>>  > Sorry, I am not sure to fully understand your question,  why  do you
>>>  > think that the level of detail should be expressed as a Annotation?
>>>
>>> My fault, sorry. I missed to explain the context.
>>>
>>> I was referring specifically to how this is done in ISO 19115-1:2014,
>>> where (as Rachel said [1]) the "level of detail" is specified by using
>>> element gco:CharacterString - which is meant to be used with free text
>>> / alphanumeric strings (including URLs), and not with numbers (as
>>> expected by dqv:value, right?).
>>
>> OK, so something like in the following examples?
>>
>> :spatialResolutionAsAngularDistance a dqv:Metric;
>>      skos:definition "Spatial resolution of a dataset expressed as
>> angular distance"@en ;
>>      dqv:expectedDataType xsd:decimal ;
>>      dqv:inDimension dqv:precision
>>      .
>
> +1!
>
>> :myDatasetPrecisionAS a dqv:QualityMeasurement ;
>>      dqv:isMeasurementOf :spatialResolutionAsAngularDistance ;
>>      dqv:value "[a fraction of degree]"^^xsd:decimal
>>      .
>
> I see that "degree" is one of the units of measure listed in wurvoc.org, so the example above might be re-written as follows:
>
> :myDatasetPrecisionAS a dqv:QualityMeasurement ;
>       dqv:isMeasurementOf :spatialResolutionAsAngularDistance ;
>       dqv:value "[a decimal degree]"^^xsd:decimal ;
>       sdmx-attribute:unitMeasure <http://www.wurvoc.org/vocabularies/om-1.8/degree> .
>
> Does this make sense?


Absolutely!
Thanks for spotting the unit of measure.
I'm very much tempted to add this next to the already present example.


>
>> :spatialResolutionAsALevelOfDetail a dqv:Metric;
>>      skos:definition "Spatial resolution of a dataset expressed as level
>> of detail"@en ;
>>      dqv:inDimension dqv:precision
>>      .
>> :myDatasetPrecisionLoD a dqv:QualityMeasurement ;
>>      dqv:isMeasurementOf :spatialResolutionAsALevelOfDetail ;
>>      dqv:value X .
>>      .
>>
>>
>> Note that in the last example, X could be a string as you suggest by
>> using gco:CharacterString. It could also be an instance of skos:Concept
>> that denotes a level of detail (and this has a prefLabel that
>> corresponds to the string one would have expressed in the first way of
>> tackling the requirement). In the latter case then we're in a borderline
>> case where the value would make stronger the temptation to use
>> QualityAnnotation, as the observation is not really a (numerical)
>> measure, but something more conceptual (and possibly derived from a
>> numerical observation).
>
> Thanks, Antoine. This indeed clarifies the intended use of dqv:value.
>
> So, the range is not formally restricted to a literal (as in daq:value [1]), but this property is meant to be used with a "quantity", that can expressed in different ways (a number, free text, a URI reference).
>
> Is this correct?
>


This is the tricky point. At this stage I'm not sure, and this is what my confusing paragraph was trying to express.
At the beginning we were strongly convinced that dqv:value should work with literals, and that Annotation should be used for the non-literal quality assessment. I think this may be a condition to keep direct compatibility with DataCube, which we're very keen on.
But in the meantime many people have expressed the will to have 'measures' where the value space is made of resources.

Do you have any opinion on this matter?

Maybe this will be the last big issue we'll solve...

Cheers,

Antoine

> ----
> [1]http://butterbur04.iai.uni-bonn.de/ontologies/daq/daq#value

Received on Thursday, 28 April 2016 16:01:45 UTC