- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Fri, 12 Feb 2016 00:06:43 +0100
- To: Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
- CC: DWBP Public List <public-dwbp-wg@w3.org>
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