Re: More feedback on DQV

Hi Christophe,
Thanks a lot for your feedbacks, I am happy that the discussion  is
progressing.

I think Jeremy is going to provide some feedback soon, so it is probably
better to modify the  schema [2] "all at once" after we get the Jeremy's
feedbacks.
The DUV vocabulary is using google graph, which  we might consider as a
valid  alternative to  creately, in the next  DQV schema release.

In regards of  comments you made in [3]

- I agree on changing  "dqv:refersToDcatDataset" in "dqv:refersToDataset";

-  regarding your <<I think the class inheritance arrows for
dqv:CollectionOfMetricsResults and dqv:Standard should be inversed.>>
I am not sure to understand  the rationale behind this suggestion, could
you explain more?

- regarding your <<Besides, I don't see why the collection of metrics has
to be a qb:Dataset>>
Ok, I think we can have daq:qualityGraph as direct specialisation of our
dqv:CollectionOfMetricsResults.
However,  I suggest to  open an issue  we can probably   address after
the DQV FPWD is released , saying "assuming  statistics about dataset  are
 considered a kind of quality information, as indicated in the UC document,
see use case bio2rdf [4], are statistics mentioned in  properly modelled in
the DQV?"
do you agree?

A couple of quick and inline responses to the comments from your very last
 email:


> # dqv:QualityInfo and its specialisation
>
> * is dqv:QualityInfo  the most appropriate name? would be
> dqv:QualityMetadata more appropriate?
> Considering that in the BPs document we speak about meta-data maybe is
> Metadata the best. But on the other hand I'n not keen on hardcoding the
> notion of metadata in a vocabulary. Going for "QualityData" would be a
> middle way solution
>
mmm...  I have to admit that    I am not very comfortable in   calling it
qualityData either.  I mean QualityData is  a possible middle way solution,
  but dqv:QualityInfo/QualityData is currently a superclass of
dqv:ServiceLevelAgreement
and dqv:Standards  which are not proper data.  for this reason,  I would
prefer  dqv:QualityInfo rather  than QualityData.


> * are there other kinds of quality info that is  worth to consider? e.g.,
> opinions, report of known issues, ...
> That would be a good opportunity to link to DUV if we assume that usage
> correlates positively with dataset quality.
>

Sure, I have noticed  that in DUV [5] there is a  class duv:Feedback which
seems to be a good candidate to refer to.
In the current version of DUV,   duv:Feedback is related
to dqg:QualityCriteria,  I am not sure what exactly dqg:QualityCriteria
 stands for, but I guess it is supposed to be a class  in our DQV, and it
might roughly correspond to our dqv:QualityInfo ( or whatever
dqv:QualityInfo will be called at the end of our discussion :) )

So once we have a proper name for  our dqv:QualityInfo, and we have
accomplished our  first internal revision of the DQV,    we can open an
issues " let's find  an agreement on references between DQV and DUV", which
should be discussed with the rest of the group, and we might suggest  to
solve the issue:
-putting duv:Feedback as one of the possible specialization of
dqv:QualityInfo in both DQV and DUV Schemas.
-deleting  dqv:QualityInfo and the relation "describes"  in DUV.

Does this sound reasonable?


> * how the service level agreement can be represented? it is a document on
> the web to refer to or we want to refer to something more structured? is
> there any specific property we should add to dqv:ServiceLevelAgreement?
> According to [1] "An SLA is best described as a collection of promises".
> It is also a document which just lists a couple of things. We could either
> focus on the document aspect as a whole or try to model the list of
> promises and the list of related concepts. My gut feeling is that this
> could lead to writing an elaborated vocabulary that would span out of our
> scope so I'd say we should rather not do that. But we should nonetheless
> anticipate that someone may some day want to work on that.
>
What about then either not indicating any range or set Resource as a range
> ? Then everyone is free to model an SLA as he wants. And in the BPs would
> could hint that structured data is better and a PDF also ok.
>
> Very good point! I agree on leaving it open to further  modelling of
promises by explicitly mention this possibility,  it  sounds like a very
good idea. Concerning your proposal to not indicating any range or set
Resource as a range, I think we should at least suggest a concrete  unique
way to include  a sla human readable descriptions, so that people don't
have the chance to be too much creative attaching  their html, pdf or
 whatever in the quality-related  metadata.


> * how standard are represented under dqv:Standard?  is the class
> dqv:Standard suitable to include ODI certificates,  to represent that a
> DCAT dataset has a certain   compliancy to  5 LOD stars, and other kind of
> bets practices? should we explicitly provide a list/taxonomy of standard/
> certificated to consider?  is the class dqv:Standard really necessary or we
> can rely directly on dcterm:Standard?
> We should be flexible here. If we impose a specific class then ODI
> certificates and 5star models will have to subclass from it, so we should
> make it generic enough conceptually so that this works. To that respect I
> think dcterm:Standard is quite nice so we may want to re-use it. Or
> subclass from it our own Standard which is a verbatim copy of it in case
> some day the meaning of dcterm:Standard changes in a way that brake our
> vocabulary.
>
> I see you point,  I agree we have to be flexible and generic enough but I
am not sure to understand what you are suggesting here.


> * can we assume the following constraint ?
>   x a dcat:Dataset. x dcterms:conformsTo y '''imply'''  x hasQualityInfo
> y. y dqv:Standard
> Think so. We should have more of these BTW :-)
>

Sure, I think other constraints will come out quite naturally during the
design process. I am not very concerned about it, by the way, I'd like that
anyone working on DQV feels free to suggest some ;)

Have a nice weekend,
Riccardo


>
> Cheers,
> Christophe
>
>
>
>
> [1]
> http://www.knowledgetransfer.net/dictionary/ITIL/en/Service_Level_Agreement.htm
>
>
> --
> Christophe Guéret
>
> --
> 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.



[2] https://creately.com/diagram/i8lgl90p1/AXwUzXKQOHvEwUw9eJmxrndw%3D
[3] https://lists.w3.org/Archives/Public/public-dwbp-wg/2015Apr/0209.html
[4] http://w3c.github.io/dwbp/usecasesv1.html#UC-Bio2RDF
[5]
https://docs.google.com/drawings/d/1aq3vPcoj0SPs5BispD6umQNejrBTwkhsSYu6Y1adUjw/edit

-- 
----------------------------------------------------------------------------
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.ge.imati.cnr.it/Albertoni
http://purl.oclc.org/NET/riccardoAlbertoni
FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf