Re: Misleading definitions of dqv properties

Hi Riccardo, Jeremy,

I think this proposal is an improvement! It keeps the direction of the properties, and avoid the possible confusion with the daQ names.

Let me summarize:
- dqv:inMetric would be equivalent to daq:metric (and we wouldn't have any dqv:hasMetric that can be interpreted to be daq:hasMetric)
- dqv:inDimension would be the inverse of daq:hasMetric (and we wouldn't have any daq:hasDimension that can be interpreted wrongly to be daq:hasDimension)
- dqv:inCategory would be the inverse of daq:hasDimension

I have one problem though: I really don't like the sound of a Measure being 'in' a Metric. A Measure is made according to (or following?) a metric, or something like this, but it's not 'in' a metric.
In fact I'm also not super keen on a metric 'in' a dimension, but that's less a problem. And I'm perfectly ok with the sound of a dimension being 'in' a category.

So I'd suggest to try at least to find a different name for dqv:inMetric. We could have dqv:computedMetric, following how daQ represents other features of quality observations (i.e. using daq:computedOn, daq:computedBy). Or maybe dqv:evaluatesMetric? This may match the mathematical approach where metric are functions, and functions are 'evaluated' for specific input values (sorry I'm not an expert in English mathematical wording...).

Actually the more I think of it, the more I believe that:

- following the convention :x for properties and :X for classes (just as daQ and DataCube do, cf my earlier mail [1]) would make our like easier. We could try to have the group vote on this!

- 'measure' in dqv:QualityMeasure is not an optimal choice when there's a class called dqv:Metric that needs to be related to it by a property with a nice name ;-)

Antoine

[1] https://lists.w3.org/Archives/Public/public-dwbp-wg/2015Dec/0101.html

On 2/11/16 12:21 PM, Riccardo Albertoni wrote:
> Dear Jeremy and All,
> After some extra thinking, I am seriously reconsidering your proposal about  renaming the properties,
>   I have  just realized that your proposal  might solve the issue https://www.w3.org/2013/dwbp/track/issues/231, and in my view, that brings a completely new shine on it ;)
>
>   Of course,  the proposal puts some extra work on Editors, but  at the end,   it does not substantially change the decisions the group has already taken (i.e. direction of the properties),   besides  it avoids some clash  between property names  which  definitely  makes less complex understanding the relation between DAQ and DQV.
>
>
> So let's try to put it  in a form we can vote on it
>
> Proposal:  rename  in DQV document and  the related turtle serialization
> dqv:hasMetric in  dqv:inMetric
> dqv:hasDimension in dqv:inDimension
> dqv:hasCategory in dqv:inCategory
>
>
> With this solution, we'll still have a coherent name convention for the metric/dimension/category hierarchy ( dqv:in* instead of dqv:has*)  and  we'll get rid of unnecessary "inconsistencies" between DQV and DAQ ...  it  sounds like two birds with one stone ..
>
> @Antoine:  if we agree on this proposal we can claim victory on  issue 231, can't we ?
>
>
> Best,
> Riccardo
>
>
>
>
> On 8 February 2016 at 22:43, Debattista, Jeremy <Jeremy.Debattista@iais.fraunhofer.de <mailto:Jeremy.Debattista@iais.fraunhofer.de>> wrote:
>
>     I understand that this is might be a hassle. I am only mentioning this issue, as it was also raised by the guys at protege. Maybe from a ‘reading' point of view, it is easier to say that for example a /metric is in a dimension /rather than a /metric has dimension/. This is only an opinion, and of course we should decide on a definition.
>
>     The script should be provided anyway… that does not hurt. I can help with that. I also have a daq to csv converter if you think that it is useful to have.
>
>     Cheers,
>     Jer
>
>
>
>
>>     On 08 Feb 2016, at 11:09, Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it <mailto:riccardo.albertoni@ge.imati.cnr.it>> wrote:
>>
>>     Hi Jeremy,
>>
>>       as far as I understand the examples you have mentioned  are not  inconsistencies,  DQV and DAQ are actually two separated namespaces, and thus even if dqv:X and daq:X  have similar "names", they are two distinct properties.
>>
>>      During the process of inclusion of  DAQ into DQV, the group  members  decided to  invert some properties  because they thought they would  have been  more intuitive in that way, or for other  reasons .. .  I have to admit    I  am a little reluctant  in amending the group's decision  at this stage, even   considering the amount of issues  we have yet had the time to address  ;)
>>
>>      I can agree that having the same X with different meaning might be somehow confusing when you use both ontologies and you move back and forth  from DAQ to DQV,   but  sincerely, I consider this as a very minor  issue, I also believe that no many persons will really need to move back and forth from  DAQ to  DAQ.
>>
>>     At the end, if I am wrong, and moving back and forth from DQV to DAQ is such a  common need,   we can always consider to provide a SPARQL script/query to automatize the translation between  the two ontologies, as  suggested by Phil in the last DQV call.
>>
>>     Does it sound reasonable?
>>
>>
>>     Cheers,
>>     Riccardo
>>
>>     PS. Could you share your last version of DAQ, I do not see the inverse properties you have mentioned at the DAQ web site I usually refer to  [1].
>>
>>     [1] http://butterbur04.iai.uni-bonn.de/ontologies/daq/daq#
>>
>>
>>     On 8 February 2016 at 18:16, Debattista, Jeremy <Jeremy.Debattista@iais.fraunhofer.de <mailto:Jeremy.Debattista@iais.fraunhofer.de>> wrote:
>>
>>         Hi Riccardo, Antoine,
>>
>>         I was presenting the DQV and realised that the properties “dqv:hasMetric”, “dqv:hasDimension” and “dqv:hasCategory” are a bit misleading - especially if for example it has to be compared with daQ. I would suggest that they are renamed to “dqv:inDimension” etc… (esp. that they are inverse of daQ properties).
>>
>>         For example, dqv:hasDimension is defined to be the inverse of daq:hasMetric.. whilst in dqv we also have dqv:hasMetric. This might lead to unnecessary inconsistencies.
>>
>>         What do you think?
>>
>>         Cheers,
>>         Jer
>>
>>         --
>>         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 <tel:%2B39-010-6475624> - fax +39-010-6475660 <tel:%2B39-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.ge.imati.cnr.it/Albertoni
>>     http://purl.oclc.org/NET/riccardoAlbertoni
>>     FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf
>>     ----------------------------------------------------------------------------
>
>
>     --
>     This message has been scanned for viruses and dangerous content by
>     *E.F.A. Project* <http://www.efa-project.org>, 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 Thursday, 11 February 2016 23:07:18 UTC