W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > March 2016

Re: Parameters for metrics - Issue-223

From: Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it>
Date: Tue, 8 Mar 2016 19:55:46 +0100
Message-ID: <CAOHhXmQt7aibdgE+9k0QLEn92urtUU_JKM-eXsFtiefdfmTxxA@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: Public DWBP WG <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 8 March 2016 18:56:22 UTC