Warning:
This wiki has been archived and is now read-only.
Examples for metrics extra parameters
What we need: - the notion of parameter: dqv:paramater (required by the issue) - a notion for a parameter to be mandatory and mapped to RDF Data Cube structures: dqv:mandatoryParameter (extra requirement so as to have better compatibility with RDF Data Cube)
TODO: mapping to Data Cube may be the same for mandatory or optional parameters. We need to check.
There's a property in daQ, daq:requires (which is not needed by Jeremy's mapping to RDF Data Cube). So later on, if we have a mandatory parameter it could be aligned with this property.
Contents
Example 1: Using sub-properties
(Originally described in Riccardo's email)
We can introduce a property dqv:parameter.
Linkset Importing requires two extra properties :onLanguage and :onProperty, respectively ranging in the ISO 639-1 language codes, and rdfs:properties.
A possible way to manage extra parameters follows..
:onLanguage rdfs:range <http://www.loc.gov/mads/rdf/v1#Language> ; rdfs:subPropertyOf dqv:parameter .
:onProperty rdfs:range rdf:Property ;
rdfs:subPropertyOf dqv:parameter .
we can use the subclassing trick, in order to enforce that a certain type of metric has certain parameters specified. For example, LinksetImporting is a subclass dqv:Metrics with the extra properties onLanguage and onProperty
:MetricWithLanguageAndPropertyParameter rdfs:subClassOf dqv:Metric ,
[ rdf:type owl:Restriction ;
owl:onProperty :onLanguage ;
owl:cardinality "1"^^xsd:nonNegativeInteger
] ,
[ rdf:type owl:Restriction ;
owl:onProperty :onProperty ;
owl:cardinality "1"^^xsd:nonNegativeInteger
]
Then we can instantiate the class of metric MetricWithLanguageAndPropertyParameter with two metrics which work on Italian and English prefLabel respectively,
:linksetImportingENSKOSPrefLabel rdf:type :MetricWithLanguageAndPropertyParameter ;
skos:definition " Importing on English PrefLabel"@en;
dqv:hasDimension :completenessOfComplemented ;
:onProperty :skosPrefLabel ;
:onLanguage <http://id.loc.gov/vocabulary/iso639-1/en> .
:linksetImportingITSKOSPrefLabel rdf:type :MetricWithLanguageAndPropertyParameter ;
skos:definition "Importing on Italian PrefLabel"@en;
dqv:hasDimension :completenessOfComplemented ;
:onProperty :skosPrefLabel ;
:onLanguage <http://id.loc.gov/vocabulary/iso639-1/it> .
And finally we can state the actual quality measurements.
The problem is that this pattern produces dqv:parameter statements that are quite confusing with what would expect from such a property:
:linksetImportingITSKOSPrefLabel dqv:parameter <http://id.loc.gov/vocabulary/iso639-1/it> .
(because then the property dqv:parameter has as object what is essentially a parameter value than a parameter)
:actual_metricValue rdf:type dqv:QualityMeasurement ;
dqv:value 0.5 ;
dqv:isMeasurementOf :linksetImportingITSKOSPrefLabel .
:actual_metricValue2 rdf:type dqv:QualityMeasurement ;
dqv:value 1 ;
dqv:isMeasurementOf :linksetImportingENSKOSPrefLabel .
Example 2: Not using sub-property
In this option the parameters are introduced as instances of a class of parameter properties
:onLanguage rdfs:range <http://www.loc.gov/mads/rdf/v1#Language> ; rdfs:type dqv:ParameterProperty .
:onProperty rdfs:range rdf:Property ;
rdfs:type dqv:ParameterProperty .
we can use the subclassing trick, in order to enforce that a certain type of metric has certain parameters specified. For example, LinksetImporting is a subclass dqv:Metrics with the extra properties onLanguage and onProperty
:MetricWithLanguageAndPropertyParameter rdfs:subClassOf dqv:Metric ,
[ rdf:type owl:Restriction ;
owl:onProperty :onLanguage ;
owl:cardinality "1"^^xsd:nonNegativeInteger
] ,
[ rdf:type owl:Restriction ;
owl:onProperty :onProperty ;
owl:cardinality "1"^^xsd:nonNegativeInteger
]
Then we can instantiate the metric MetricWithLanguageAndPropertyParameter with two metrics which work on Italian and English prefLabel respectively,
:linksetImportingENSKOSPrefLabel rdf:type : MetricWithLanguageAndPropertyParameter ;
skos:definition " Importing on English PrefLabel"@en;
dqv:inDimension :completenessOfComplemented ;
:onProperty :skosPrefLabel ;
:onLanguage <http://id.loc.gov/vocabulary/iso639-1/en> .
:linksetImportingITSKOSPrefLabel rdf:type : MetricWithLanguageAndPropertyParameter ;
skos:definition "Importing on Italian PrefLabel"@en;
dqv:inDimension :completenessOfComplemented ;
:onProperty :skosPrefLabel ;
:onLanguage <http://id.loc.gov/vocabulary/iso639-1/it> .
And finally we can state the actual quality measurements.
:actual_metricValue rdf:type dqv:QualityMeasurement ;
dqv:value 0.5 ;
dqv:isMeasurementOf :linksetImportingITSKOSPrefLabel .
:actual_metricValue2 rdf:type dqv:QualityMeasurement ;
dqv:value 1 ;
dqv:isMeasurementOf :linksetImportingENSKOSPrefLabel .
Mapping with RDF Data Cube
A final consideration about mapping the extra- parameter into RDF structure: in the case of the linkset importing, extra parameters should be modelled as dimensions when defining the RDF cube data structure. I guess we can provide a mapping script that considered the extra parameters adds to the rdf cube structure the proper components. Probably, in this direction, it would be wise to group all the extra parameters that are expected to be mapped as rdf cube dimensions in a specific subproperty (or class of properties) such as http://www.w3.org/ns/dqv#mandatoryParameters, so that they can eventually collected by the mapping script.
another proposal coul be as in the above example but grouping extra parameters that are expected to be transformed into dimension for the rdf data cube under a specific the property http://www.w3.org/ns/dqv#mandatoryParameters
Example 2 can be mapped into one of the following RDF cube data Structure Definitions.
Data structure A which is derived by DAQ dsd. (not yet included in the DQV dratf)
ex:dsdA a qb:DataStructureDefinition ;
qb:component [ qb:dimension dqv:computedOn ;
qb:order 2
] ;
qb:component [ qb:dimension dcterms:date;
qb:order 3
] ;
qb:component [ qb:dimension dqv:isMeasurementOf ;
qb:order 1
] ;
qb:component [ qb:measure dqv:value ; ] ;
# Attribute (here: unit of measurement)
qb:component [
qb:attribute sdmx-attribute:unitMeasure
;
qb:componentRequired false ;
qb:componentAttachment qb:DataSet ; ] ;
However, depending on the kind of application, we might want to include parameters as Dimensional property in the RDF cube data Structure Definition. In that case, an extension of the previous RDF cube data Structure Definition can be considered.
Data structure B ( already described in DQV draft, in the linkset quality example [1])
ex:dsdB a qb:DataStructureDefinition ;
##Copying the structure of daq:dsq
##the dimensions
qb:component [ qb:dimension dqv:computedOn ;
qb:order 2
] ;
qb:component [ qb:dimension dcterms:date;
qb:order 3
] ;
qb:component [ qb:dimension dqv:isMeasurementOf ;
qb:order 1
] ;
qb:component [ qb:measure dqv:value ; ] ;
# Attribute (here: unit of measurement)
qb:component [
qb:attribute sdmx-attribute:unitMeasure
;
qb:componentRequired false ;
qb:componentAttachment qb:DataSet ; ] ;
##Extending the structure of lds:dsq with two new dimensions
qb:component [ qb:dimension :onProperty ;
qb:order 4
] ;
qb:component [ qb:dimension :onLanguage ;
qb:order 5
] .
Due to the constraint indicated in the RDF DATA CUBE, Each dqv:QualityMeasurementAssessmentDataset must have only one qb:dataStrutureDefinition, and dqv:qualityMeasurement can belong to a dqv:QualityMeasurementAssessmentDataset only. As a consequence, only one between the two data structures discussed can be adopted for each dqv:QualityMeasurementAssessmentDataset. It is intersting to note that in case the second data structure is selected,
- we do not need to specify ParameterProperty, as we need one metric only ( eg. :linksetImporting) which is dqv:isMeasurementOf of all the measurements independently from the values of the parameters.
- there is no explicit association between metric and parameters, parameters appears only as dimensions in the data cube.
So probably, the two solutions should be sold as alternatives.
In particular, if the dqv:QualityMeasurementAssessmentDataset includes measurements of metrics having an inhomogeneous set of extra parameters then the first data structure is the right choice.
If the dqv:QualityMeasurementAssessmentDataset includes only measurements for metrics having exactly the same set of parameters, such as in the previous case, where only linkset importing was in the dqv:QualityMeasurementAssessmentDataset, the second data structure can be considered.
Example 3: Using Shapes
Proposal recently discussed in https://lists.w3.org/Archives/Public/public-dwbp-wg/2016Mar/0051.html
not yet sorted out ... but essentially this solution would use shaql to describe the parameter signature of the Metric (what is currently handled in examples 1 and 2 with the technical subclass of Metric :MetricWithLanguageAndPropertyParameter. We could replace this class by a Shape that is connected with the concrete metric :linksetImportingENSKOSPrefLabel. This shapes would constrain all the instance of QualityMeasurement that are related to the metric by dqv:isMeasurementOf.
So it can be applied as an alternative to both example 1 and 2.
In both cases, we can think about a script which adds extra parameters specified in metrics in an extra data cube structure, (e.g as attributes or dimensions in rdf cube data structure ?!?!?) so that quality measurements (which are rdf cube observation) can be organized also around the actual parameters value.
