- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Wed, 9 Mar 2016 20:27:41 +0100
- To: Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it>
- CC: Public DWBP WG <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
Hi Riccardo, On 3/8/16 7:55 PM, Riccardo Albertoni wrote: > Hi Antoine, > > On 6 March 2016 at 23:12, Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>> wrote: > > 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. > You may be right, actually The problem is that my mind is utterly confused by sub-properties that are applied to sub-classes and the completely broken formatting of our emails (see https://lists.w3.org/Archives/Public/public-dwbp-wg/2016Feb/0024.html) I'm also confused by the fact that "onProperty" is a sub-property of "requires". The name of the property "required" screems for the required parameter to appear as object, not sub-property. Could you put your example on a wiki page? Then I can create later a version with the parameters as objects of dqv:requires statements and we can compare. > 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? I think it does, but again my brain is so confused... > > 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 meant that I was curious to hear what Jeremy would have to say. Indeed daQ uses sub-classes, so I was expecting an example from daQ could shed some well-engineered light showing the value of the 'sub-class trick' you had proposed. Or in fact if your solution was the same as the one for daQ. I couldn't find any example with daq:requires! > 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? No, you're right. It does impose OWL Full on everything by default, but I'm ok to accept it if there's some clear value! > > > 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? > Precisely! > > 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)? > I'm actually afraid that we can't split the issue, because depending on the way dqv:requires shall be used, I may require to change its name :-) Cheers, Antoine > > > > 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 <mailto: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 Wednesday, 9 March 2016 19:28:14 UTC