- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Sun, 6 Mar 2016 23:12:22 +0100
- To: Public DWBP WG <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
Hi Riccardo, I like the idea of having dqv:requires, and I think we should continue along the line of the example on Linkset quality metrics that have 'language' and 'RDF property' as parameters. So right now I'm in favour of your SECOND PROPOSAL. However there could be some problems with the modeling you suggest: 1. ex:onProperty and ex:onLanguage to me don't fit as sub-properties of dqv:requires. the object of an ex:property statement is not the object of a dqv:requires statement. I'd rather have these two properties as object of dqv:requires statement: [ :importingForPropertyPercentage a dqv:Metric ; skos:definition "Ratio between novel preferred labels or the alternative labels gained via skos:exactMatch link and preferred labels or the alternative labels already in the dataset."@en dqv:expectedDataType xsd:double ; dqv:requires ex:onProperty , ex:onLanguage ; dqv:inDimension :completeness . ] 2. I'm not sure that the trick of subclassing works. I think it implies that instances of Measurement would also be also instances of Metric, and this doesn't smell good (as Measurement so far are related to instance of Metric using dqv:isMeasurementOf, not rdf:type). In fact even if it works, it could result in complex hierarchies of Metrics, just to represent quite technical requirements. And it seems at odds with the idea of having dqv:requires. To me, we should have either (i) dqv:requires, or (ii) a subclass trick, or (iii) both but then some automatic process that translates from one to the other. I'm actually curious to hear how daq:requires is handled in daQ. Especially as daQ still has Metrics as classes, so it would be better compatible with the subclass trick than the current version of our DQV, which doesn't explicitly type Metrics as classes. Jeremy have you got any hint on this? Personally I'd rather wait and see if we can do something using dqv:requires and RDF Shapes. Especially considering that Shapes can have closed world assumption, and that's really the semantics we're after for enforcing 'requires' semantics at the level of the measurements. Maybe we can split the issue, once we agree that at least we need dqv:requires, and how to use it with the parameters (i.e. how onLanguage and onProperty should be related to the instance of the Metric)? Finally, I can't say anything about the relationship with Datacube dimensions. Maybe we can first resolve the most immediate problems? And also re-write the example: for some reason the formatting is really hard to read in your email. By the way I would have some suggestions for the example at [1] right now: - use dcterms:LinguisticSystem not madsrdf:Language - implement now your suggestion in the email on the use 'onLanguage' and 'onProperty' as property names, instead of the very generic-sounding 'language' and 'property'. I hope this can help us move forward on this one, Antoine [1] http://w3c.github.io/dwbp/vocab-dqg.html#ExpressQualLinkset > Dear All, > Some considerations about ISSUE-223: Parameters for metrics > https://www.w3.org/2013/dwbp/track/issues/223, > which hopefully will help in closing this issue. > > > As already explained by Jeremy, > DAQ includes the possibility to express that a metric has some extra > parameters, for example a metric about completeness can point to a specific > dataset providing the "ground truth", by using the property daq:requires. > > In that case, we can have > > :instanceCompleteness > a dqv:Metric; > daq:requires :groundTruth; > dqv:hasDimension :completeness. > > > so my FIRST basic PROPOSAL is to add explicitly in the DQV draft a > property dqv:requires, which is defined in analogy with DAQ. > > in addition to this, Werner in his reply has suggested that we can even > think to subclass the properties. > > That sounds extremely interesting to me, since it might model in more > precise way the extra parameters required by metrics such as the Linkset > Importing, a metric on which my group is working, that we have already > mentioned in DQV draft 's section 5.7 "Express the quality of a linkset". > > thus my SECOND PROPOSAL is to add the following example in dqv to provide > guidance on how to add extra parameters for quality metrics. > > I would exploit the Linkset Importing as example for showing how to add > extra parameters. > > Linkset Importing requires two extra properties :language and :property, > respectively ranging in the ISO 639-1 language codes, and rdfs:properties. > > A possible way to manage extra parameters follows.. > > #### http://example.com/ex#onLanguage > > <http://example.com/ex#onLanguage> rdfs:range < > http://www.loc.gov/mads/rdf/v1#Language> ; > > rdfs:subPropertyOf < > http://www.w3.org/ns/dqv#requires> . > > > ### http://example.com/ex#onProperty > > <http://example.com/ex#onProperty> rdfs:subPropertyOf < > http://www.w3.org/ns/dqv#requires> . > > > 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 > ### http://example.com/ex#LinksetImporting > > <http://example.com/ex#LinksetImporting> > > rdfs:subClassOf < > http://purl.org/eis/vocab/daq#Metric> , > < > http://www.w3.org/ns/dqv#Metric> , > [ rdf:type > owl:Restriction ; > owl:onProperty < > http://example.com/ex#onLanguage> ; > > owl:someValuesFrom <http://www.loc.gov/mads/rdf/v1#Language> > ] , > [ rdf:type > owl:Restriction ; > owl:onProperty < > http://example.com/ex#onLanguage> ; > > owl:allValuesFrom <http://www.loc.gov/mads/rdf/v1#Language> > ] , > [ rdf:type > owl:Restriction ; > owl:onProperty < > http://example.com/ex#onProperty> ; > > owl:someValuesFrom rdfs:Resource > ] , > [ rdf:type > owl:Restriction ; > owl:onProperty < > http://example.com/ex#onProperty> ; > > owl:allValuesFrom rdfs:Resource > ] . > > > > Then we can instanciate the metric LinksetImporting with two metrics which > work on Italian and English prefLabel respectively, > > > ### http://example.com/ex#linksetImportingENSKOSPrefLabel > > <http://example.com/ex#linksetImportingENSKOSPrefLabel> rdf:type < > http://example.com/ex#LinksetImporting> ; > > <http://www.w3.org/ns/dqv#hasDimension> < > http://example.com/ex#completenessOfComplemented> ; > > <http://example.com/ex#onProperty> < > http://example.com/ex#skosPrefLabel> ; > > <http://example.com/ex#onLanguage> < > http://id.loc.gov/vocabulary/iso639-1/en> . > > > > ### http://example.com/ex#linksetImportingITSKOSPrefLabel > > <http://example.com/ex#linksetImportingITSKOSPrefLabel> rdf:type < > http://example.com/ex#LinksetImporting> ; > > <http://www.w3.org/ns/dqv#hasDimension> < > http://example.com/ex#completenessOfComplemented> ; > > <http://example.com/ex#onProperty> < > http://example.com/ex#skosPrefLabel> ; > > <http://example.com/ex#onLanguage> < > http://id.loc.gov/vocabulary/iso639-1/it> . > > > > And finally we can state the actual quality measurements. > > > ### http://example.com/ex#actual_metricValue > > <http://example.com/ex#actual_metricValue> rdf:type > <http://www.w3.org/ns/dqv#QualityMeasure> ; > > <http://www.w3.org/ns/dqv#value> 0.5 ; > > <http://www.w3.org/ns/dqv#hasMetric> < > http://example.com/ex#linksetImportingITSKOSPrefLabel> . > > > > ### http://example.com/ex#actual_metricValue2 > > <http://example.com/ex#actual_metricValue2> rdf:type > < > http://www.w3.org/ns/dqv#QualityMeasure> ; > > <http://www.w3.org/ns/dqv#value> 1 ; > > < > http://www.w3.org/ns/dqv#hasMetric> < > http://example.com/ex#linksetImportingENSKOSPrefLabel> . > > 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 dqv:requires > subproperty such as http://www.w3.org/ns/dqv#mandatoryParameters, so that > they can eventually collected by the mapping script. > > THIRD PROPOSAL: as in the second 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 > > please let me know which of the previous proposals you support or if you > have any amendments. > > > Cheers, > Riccardo
Received on Sunday, 6 March 2016 22:12:54 UTC