Re: comments on the DUV

Joao Paulo,

Wow great comments!  I will try to answer in your feedback below:

Many thanks,

Eric S.

On Fri, Jan 15, 2016 at 4:55 AM, João Paulo Almeida <jpalmeida@ieee.org>
wrote:

> Dear Eric, Sumit and Bernadette,
>
> Thank you very much for the work you are doing on the DUV.
>
> Here does some comments on the current version of the DUV document, which
> I hope can improve it.
>
> — Concerning the current diagram
> ----------------------------------------------
> Rdfs:literal appears three times in the diagram.
> Skos:Concept also appears three times
> oa:Annotation appears two times.
> foaf:Agent appears twice.
>
>
Eric feedback:  Joao Paulo, we can try a diagram with only one class
mentioned, do you think this is a showstopper for getting comments from
others or can this wait until the next review?


> To me, this should be avoided, because it is counter-intuitive.
>
> I still find it very confusing that some properties appear in the diagram
> and not in the text and also vice-versa. I think that the diagram should be
> in full sync with the text. This is useful as an overview of the vocabulary.
>
> Eric feedback:  This is in error, and we are continuing to receive
feedback and changing properties.  I apologize for being out of sync and I
must do better to keep those in line.


> — Concerning the scope of the vocabulary
> -------------------------------------------
> I do not see conceptually, how duv:hasDistributor and duv:recordCreator
> are in the scope of DUV.   There was not text for duv:recordCreator, so
> what is this property used for? How different is it from dct:creator, which
> is also used?
>
> Eric feedback:  Our goal here was to show how to provide a complete
electronic record based on what we are seeing being needed from data
librarians.  Perhaps we should make it clearer in the text explaining the
rationale for these.  duv:recordCreator was a reification attempt at
describing how recorded the original duv:DataCitation.  I think we can
remove this.


> Same for duv:classification. This seems to be used to classify foaf:Agents
> using skos, … How is this in scope of DUV?
>
> Eric feedback:  We wanted to expand on how to describe Agents, in the past
you may recall we attempted this by using prov:Agent, but found even that
was too limiting.  Agent in terms of usage may not be a specific person
they may be "System Biologist", "Financial Analyst" and we wanted a way to
describe this in a consistent way.



> — Concerning the descriptions of the concepts
> -------------------------------------------
>
> I did not understand duv:UsageTool. Why is this needed? The description is
> cryptic to me. It says “A synopsis describing the way a tool can use a
> dataset or distribution.” A tool is not a synopsis. So, this seems to
> confuse real-world entity (a tool) with a text, a description?
>
> Eric feedback: The class should be providing a description explaining how
the dataset/distribution can be used with a tool from a human readable
perspective.  I took the term synopsis from the terminology used in "man"
pages in linux.  Is this clearer?


> duv:RatingFeedback is described as “predefined criteria”. But we do not
> define these criteria in DUV. So, “predefined” is a bit vague to me. When
> are the criteria defined? By the way, I disagree with defining
> RatingFeedback as “criteria”. A criterion is “a principle or standard by
> which something may be judged or decided”. So, someone creating an instance
> of RatingFeedback may USE some predefined criteria, but the feedback itself
> if not a criteria. Remember that this is a subclass of Annotation, so a
> Feedback is just an annotation.
>
> Eric feedback: This guidance is helpful, we were trying to describe
"discrete" in some way, by pre-defined I think of "like, dislike", "1 star
- 5 star" etc.  Thanks for walking through the example, it looks like some
corrections here may be in order.


> — Concerning dependencies with other vocabularies
> -------------------------------------------
>
> I find that many dependencies to other vocabularies have been created in
> the DUV, which makes it hard for people to use it without “buying in” these
> other vocabularies. Some of these dependencies in my view could be
> separated into a section that only indicates that the user could consider
> using these other vocabularies to express some additional information… An
> example is disco:fundedBy. This is a single property from disco, that
> creates a dependency between DUV and disco. Same for PRISM (with
> prism:publicationDate) and PAV (with pav:Version). I would recommend that
> all these be factored out from the  “core part” of DUV.
>
>
Eric feedback:  The prism and pav recommendations come directly from the
SPAR ontologies community author so those will need to stay.  In the bigger
picture, I think of this as simple vocabulary reuse and we are not asking
anyone to buy into the rest of the third party vocabulary.


> In section 7.4 there is a rev vocabulary dependency (rev:Feedback). What
> is the status of this vocabulary? Again, I think we should avoid these
> dependencies as much as possible, especially if the status of the referred
> vocabularies is unclear.
>
>
Eric feedback:  Hmmmm, I will double check on this, but it may be a typo.

>
> Regards,
> João Paulo
>
>
> A minor typo:
> dct:Identifier should be dct:identifier
>
>