- From: Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it>
- Date: Tue, 8 Mar 2016 19:55:46 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: Public DWBP WG <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
- Message-ID: <CAOHhXmQt7aibdgE+9k0QLEn92urtUU_JKM-eXsFtiefdfmTxxA@mail.gmail.com>
Hi Antoine, On 6 March 2016 at 23:12, Antoine Isaac <aisaac@few.vu.nl> wrote: > 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. > Ok let's try to refine the second proposal then .. > > 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 . > ] > Let's have parameters as Objects, I am fine with that especially If we do not want to have the subclass trick. > 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). > I don't think we have the problem about "instances of measurement are also instances of Metric", because I was expecting to have only the declarations of extra-parameters in instances of Metric ( e.g., property name, data types in which parameter ranges), whilst the actual parameters values associated to the metric during the quality assessment are indicated in QualityMeasurement's instances. So we have "parameter definitions /templates" modelled in the class Metric and "parameter values" to be associated to actual measurement/observation. Once the extra parameters of a Metric are defined, a sort of script could generates -the proper rdf cube dataStructureDefinition, extending the default rdf cube data structure of Measurement with the extra parameters, - actual RDF properties associating qualityMeasurements to parameters specified during the assessment.. Does this make any sense for you? > 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? I am open to abandon the subclass trick, it was to provide an example where we reuse the Architectural Ontology Design Patterns of DQV which as far as I have understood is very dear to Jeremy .. perhaps I am pushing the Architectural Ontology Design Patterns too far.. Anyway, I am not sure to understand what you mean when you say "it would be better compatible with the subclass trick than the current version of our DQV, which doesn't explicitly type Metrics as classes". I thought skos:Concept is a class that can be "extended", I know that might be not so usual/natural, But I do not think it is forbidden. (for example, DBPEDIA does it) So In principle we can exploit the same Architectural Ontology Design Patterns of Daq because Metric/dimensions/ category are still classes like they were in Daq, the only difference is that they are also skos:Concept and they can but are not necessarily abstract.. ( issues 204/205) Am I missing something? > 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. > > I guess we can consider to express the parameter definitions/ templates I was previously mentioning by SHACL [2], so that we do not have to (re)invent a way to express the metainformation about extra parameters. Is that what you were thinking? > 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'. > > Ok I am going to consider your suggestions for the example, so far, I added them in our editorial actions ;) Thanks, Riccardo > I hope this can help us move forward on this one, > > Antoine > > [1] http://w3c.github.io/dwbp/vocab-dqg.html#ExpressQualLinkset > > [2] http://w3c.github.io/data-shapes/shacl/ > 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 >> > > > > > -- > This message has been scanned by E.F.A. Project and is believed to be > clean. > > > -- ---------------------------------------------------------------------------- Riccardo Albertoni Istituto per la Matematica Applicata e Tecnologie Informatiche "Enrico Magenes" Consiglio Nazionale delle Ricerche via de Marini 6 - 16149 GENOVA - ITALIA tel. +39-010-6475624 - fax +39-010-6475660 e-mail: Riccardo.Albertoni@ge.imati.cnr.it Skype: callto://riccardoalbertoni/ LinkedIn: http://www.linkedin.com/in/riccardoalbertoni www: http://www.imati.cnr.it/ <http://www.ge.imati.cnr.it/Albertoni> http://purl.oclc.org/NET/riccardoAlbertoni FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf ----------------------------------------------------------------------------
Received on Tuesday, 8 March 2016 18:56:21 UTC