Re: comments on the DUV

Dear Eric,

Thanks for your reply. See my comments inline.
 
> ‹ 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.

JP: I still think that DUV should focus on usage, feedback, ... These little
things that we think may be missing are still off scope, and should be
treated elsewhere by other standardization efforts. Are these things
strongly required by DUV?

 
> ‹ 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?
 
JP: I don¹t think so. It seems to be that the label will be used to provide
some textual description of the tool. But the resource represents the tool,
and not a synopsis.


> 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.

JP: I am OK with ³discrete². What I meant is that the description text is
currently misleading (with ³predefined² and ³criteria²), and will probably
confuse readers with respect to the way to use this notion.
 
> ‹ 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.

JP: Probably not a typo as it even links to
http://vocab.org/review/terms.html#Feedback

JP: We seem to disagree on this issue of dependencies as we discussed on the
call andŠ Phil also seems to favour using all those other vocabs.  Again, my
point is that DUV becomes more complex to learn and to use because of all
these ³imports². And also, there is the issue of stability of all these
other vocabs. I would favour a more minimalistic approach, as to me it seems
a bit complex and tied up right now. But that¹s something that is certainly
subjective and the group should debate.

Regards,
João Paulo