- From: Phil Archer <phila@w3.org>
- Date: Fri, 11 Dec 2015 16:50:35 +0000
- To: Eric Stephan <ericphb@gmail.com>
- Cc: Public DWBP WG <public-dwbp-wg@w3.org>
Thanks Eric, If you want to refine the definition of an existing term then making it a sub class or sub property of the existing one is the right thing to do. That's a good explanation/justification for defining your own terms. But if it's just a different word (author cf.creator) then IMO it's not a good reason. dc:hasVersion - yes, fine, sorry, should have thought of that. But I would always use dcterms rather than dc. dcterms more or less supersedes dc, so dcterms:hasVersion works for me. As for including/not including terms in the diagram - readability makes sense and over-complex diagrams are not readable. However, I'd be surprised to see terms listed that were not shown in the diagram at all. Given the nature of the DUV, with different areas, would it possible to 'zoom in' to, say, the citation section and in that diagram show all the classes and properties? HTH Phil. On 11/12/2015 15:32, Eric Stephan wrote: > Phil, > > My responses below: > > > duv:author - why can't you just use dcterms:creator? You have this defined > as a sub property of dc:creator (not dcterms I notice, and dc is missing > from the table of namespaces). If there's a reason, OK, but dcterms:creator > is pretty universal. > >>> +1 I had this originally - made a change at 1am this morning, not a good > time to go off road. > > duv:hasPublisher - again, why not dcterms:publisher? > >>> +1 See earlier response. > > I can't find duv:hasProducer in the diagram but I see that it has a range > of prov:Agent and skos:Concept. > >>> Not all properties will be shown in the diagram. I was thinking of this > as being more conceptual than exact. My preference is to provide a general > orientation. > > That seems to be confusing two things there. The producer will be an Agent > that will have either a classification or a role of some kind. That seems > similar to org:classification which takes a skos:Concept as its range. > >>> Hmmm okay will take a look and respond back later. > > See just above > http://www.w3.org/TR/vocab-org/#index-of-classes-and-properties > > Googling around this topic I also came across > http://rdf-vocabulary.ddialliance.org/discovery.html#dfn-disco-fundedby which > seems very relevant, in particular a property fundedBy. > >>> Interesting +1 > > duv:edition - looks like pav:version to me?? > >>> Is dc:hasVersion more socialized? > > duv:Publication - not foaf:Document? > >>> We had this as an action item for some time, with little response. Yes > we can go with foaf:Document. > >>> Having agreed with reusing vocabularies, one concern that I have as a > vocabulary editor is that the "definitions" listed in the other > vocabularies are so general that it is difficult to convey the meaning I > want to the reader. How do we reuse properties and classes and "refine > their definition" to help orient people to the particular point of view we > are trying to convey? > > Many thanks again, > > Eric S > > > > On Fri, Dec 11, 2015 at 5:51 AM, Phil Archer <phila@w3.org> wrote: > >> Eric, Sumit, Berna, >> >> I'm just looking through the DUV again and have some questions/comments. >> >> First up - I like the new diagram, that looks much clearer and it's >> therefore easier to understand. >> >> I think you can remove the rev namespace from the table - I don't see >> that's use anywhere now? >> >> The note at the beginning of the examples (The vocabularies are out of >> date, and need to be improved. This needs to be an action item once the >> vocabulary specification has been completed.) isn't clear to me which >> vocabs you want to update. Maybe the note can be clarified a little? >> >> Going through the list of classes and properties I see several that on >> first appearance look like duplicates, or near duplicates, of existing well >> known examples. If there is good reason to define new classes and >> properties rather than reusing those others, OK, but I think the text >> should include that reasoning. If not, then maybe the existing term can be >> used? >> >> These are the ones that stand out to me: >> >> duv:author - why can't you just use dcterms:creator? You have this defined >> as a sub property of dc:creator (not dcterms I notice, and dc is missing >> from the table of namespaces). If there's a reason, OK, but dcterms:creator >> is pretty universal. >> >> >> duv:hasPublisher - again, why not dcterms:publisher? >> >> I can't find duv:hasProducer in the diagram but I see that it has a range >> of prov:Agent and skos:Concept. That seems to be confusing two things >> there. The producer will be an Agent that will have either a classification >> or a role of some kind. That seems similar to org:classification which >> takes a skos:Concept as its range. >> >> See just above >> http://www.w3.org/TR/vocab-org/#index-of-classes-and-properties >> >> Googling around this topic I also came across >> http://rdf-vocabulary.ddialliance.org/discovery.html#dfn-disco-fundedby >> which seems very relevant, in particular a property fundedBy. >> >> duv:edition - looks like pav:version to me?? >> >> duv:Publication - not foaf:Document?? >> >> If you and the WG are ready to publish this as the next WD, I'm happy with >> that but I think one or more issues should be raised to help tie down where >> DUV terms differ from existing ones. >> >> HTH >> >> Phil. >> >> -- >> >> >> Phil Archer >> W3C Data Activity Lead >> http://www.w3.org/2013/data/ >> >> http://philarcher.org >> +44 (0)7887 767755 >> @philarcher1 >> >> > -- Phil Archer W3C Data Activity Lead http://www.w3.org/2013/data/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Friday, 11 December 2015 16:50:35 UTC