- From: Eric Stephan <ericphb@gmail.com>
- Date: Fri, 5 Jun 2015 05:55:18 -0700
- To: João Paulo Almeida <jpalmeida@ieee.org>
- Cc: Public DWBP WG <public-dwbp-wg@w3.org>
- Message-ID: <CAMFz4jgd5j6jWCr4veK0m0C4wxPMaHU7qAAhA-sRPbZKWGL0OA@mail.gmail.com>
Joao Paulo, Thank you for your comments, as you are aware this is our first draft. Unfortunately given the timing we will not have time to review and respond to your thorough comments prior to the meeting. Having said this, the editor team still feels the need to collect and review all additional comments from the team and public. Cheers, Eric S On Fri, Jun 5, 2015 at 5:38 AM, João Paulo Almeida <jpalmeida@ieee.org> wrote: > Dear All, > > When analyzing the current version of the Data Usage Vocabulary, I found > the need to propose several changes, so I attach here a diagram with my > proposal for DUV. > > I hope that you will agree with me that, while we have a good start, we > are not ready to go FPWD with DUV. > > One general remark is that the current version relies on a number of > vocabularies (some of which are not stable like bibo, cito). I think we > should minimize those dependencies as much as possible, and replace them > with more stable and well-known vocabularies, more specifically I mean DCMI > Metadata Terms (dct [1], which is already used in DCAT), and the W3C PROV > Ontology (prov [2]). I am not sure about the status of Open Annotation and > how we should we use (details below). Further, there are some fragments > which do not need to be “reinvented", so we can just reuse. This is to me > the case with Application. > > I see three clear modules for the DUV effort: > > - A) Data usage representation (in the sense that a software agent is > dependent on the dataset) > - B) A particular kind of usage which is citation > - C) User feedback/rating representation > > Detailed comments below: > > 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. > > 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. > > 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. > > I did not understand duv:retains. > > 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 > > >
Attachments
- image/png attachment: B7524D0D-509B-4353-B063-012E9A33DC35.png
Received on Friday, 5 June 2015 12:55:50 UTC