Re: comments on DUV and some proposals

Hi João Paulo,

Thanks for your feedback!

Some new issues were created according to your comments and they will be
included in the FPWD of DUV for further discussion.

With respect to A, I propose to use prov:SoftwareAgent instead of
> Experience/Application/WebOfThing. I propose to change duv:consumes to
> duv:consumed. Further, I think that we need to be able to reify this
> Consumption (or Usage if we prefer that other term). This would be a
> solution similar to what PROV does with respect to attribution. It includes
> a simples wasAttributedTo, but this can be qualified with an Attribution
> resource, which reifies the attribution and allows for more information
> about the attribution to be captured. I think we should do this here
> because A is actually the core of DUV, and is currently only one property
> in the whole thing.
>

https://www.w3.org/2013/dwbp/track/issues/177
https://www.w3.org/2013/dwbp/track/issues/176


>
> With respect to B, I don’t think we need to enter the business of
> specifying the range of cito:hasCitingEntity, specially not with bibo. So,
> in my opinion, we should say nothing about this, and therefore introduce no
> dependence to bibo. With respect to cito, the only thing we would be doing
> is subClass cito:CitationAct into duv:DataCitationAct (I propose to rename
> duv:Citation, because since we are using cito, we should use their
> convention in the nominalization which is better and clarifies that
> Citation here is an Act.) We should examine this solution altogether,
> because citing data is already possible without us doing any specialization
> of the vocabulary. So, B, could be altogether left out from DUV and we
> could just give examples of how to cite data using cito (and even bibo). If
> we decide to include duv:DataCitationAct then there should be some reason
> further than constraining cito:hasCitedEntity to have a range of
> dcat:Dataset.
>

https://www.w3.org/2013/dwbp/track/issues/173


>
> With respect to C, if we go with Open Annotation, then we could call what
> is currently called duv:Feedback as duv:DataRatingAnnotation. However, note
> that Open Annotation suggests that we do not subclass oa:Annotation because
> of particular motivations for annotation but instead use SKOS and create
> instances of oa:Motivation. In this case, we should eliminate duv:Feedback
> altogether, and just understand User feedback/rating as a new instance of
> oa:Motivation (e.g., oa:rating). (see current list at [3], which does not
> include in my opinion something like oa:rating). What currently is
> duv:has_rating would be some subclass of oa:hasBody (or it would just be
> oa:hasBody). This requires more discussion as I found the current examples
> unclear, which bodies of the annotations that are just text.
>

So, perhaps, all our effort with respect to “C”, would just be in creating
conventions to use Open Annotation and not a specialization thereof.

https://www.w3.org/2013/dwbp/track/issues/178


> I did not understand duv:retains.
>

https://www.w3.org/2013/dwbp/track/issues/174

kind regards,
Bernadette



>
> I am sorry I have to send regrets for the meeting today.
>
> Best regards,
> João Paulo
>
> [1] http://dublincore.org/documents/2012/06/14/dcmi-terms/
> [2] http://www.w3.org/TR/prov-o/
> [3] http://www.openannotation.org/spec/core/20130208/core.html
>
>
>


-- 
Bernadette Farias Lóscio
Centro de Informática
Universidade Federal de Pernambuco - UFPE, Brazil
----------------------------------------------------------------------------