Re: PROV-ISSUE-472 (Feedback_IH): Review of the DC-NOTE by Ivan Herman [Mapping PROV-O to Dublin Core]

Daniel,

first of all, thank you for the huge changes you have made in the document. I see that you have answered all my issues. 

Unfortunately... having gone through the document again, I spotted some more issues. I am not sure whether these were in the previous version and I just missed them (apologies if this is the case) or whether they came in with this new version. All the comments are editorial.

- 1st paragraph in section 2, last sentence: "And not least," -> "Last, but not least,".  (I was unsure myself and I checked it with a native American English speaker who did not feel comfortable with the current formulation either.) 

- The graphic shapes on Figure 1 and 2 still do not correspond to the ones in the Prov primer. The shape for a prov:Agent should be different... that being said, the figure clearly relates to the simple DC figure, ie, I understand that introduction of a different shape for prov:Agent (ie, ex:publisher) might be a bit disturbing... I leave that to you.

- First paragraph, section 2.3: 'By means of RDFS-reasoning' -> 'By means of OWL 2 RL reasoning'. You have some owl:equivalentXXX statements there, ie, RDFS does not cut it. On the other hand, OWL 2 RL subsumes RDFS.

- Table 3, explanation for dct:dateAccepted '2' -> 'two'

- Table 3, 'dct:dateCopyRighted' -> 'dct:dateCopyrighted'

- Paragraph after table 1, 'it is due the' -> 'it is due to the'

- Paragraph after table 1, 'record such as example 1 will': actually, the example is not numbered:-(

- Paragraph after table 1, last sentence: I wonder whether the conditional is right here. I guess the conclusion is that "Thus, the mapping produces provenance that complies with the current definition of entity but it does not comply with all the PROV constraints[PROV_CONSTRAINTS]." Or do I get it wrong?

- Paragraph before Table 4: 'The summary can be seen below in Table 4' -> 'These can be seen below in Table 4'

- Sections 2.5.1 and 2.5.2: the formatting of the examples should be identical (in 2.5.2 you 'tabulate' the code). I personally prefer the style in 2.5.1, but that is your decision.

- Sections 2.5.2 (all examples). I may be wrong on this but I have the feeling that the qualified structures do not bring any new prov information (in contrast to the ones in 2.5.1). If so, I would propose to remove them to make things simpler.

- Section 3. 'mapping patterns that we used' -> 'mapping patterns used in this document'

- Section 3. 'besides some unqualified dates' -> 'apart from some unqualified dates'

Cheers

Ivan


On Oct 23, 2012, at 06:37 , Daniel Garijo wrote:

> Hi Ivan,
> We have finally finished addressing your feedback and comments.
> I have pushed the latest version (available here: 
> http://dvcs.w3.org/hg/prov/raw-file/208b77ed4e13/dc-note/Overview.html) 
> and changed the the status of the issue to "Pending Review".
> 
> Since you raised a lot of smaller issues, I have created a wiki page
> to answer them all appropriately: 
> http://www.w3.org/2011/prov/wiki/Ivan_Herman_Feedback_On_DC_Note
> 
> This issue is now pending review.
> 
> Thanks again for your feedback!, 
> Daniel
> 
> 2012/8/6 Provenance Working Group Issue Tracker <sysbot+tracker@w3.org>
> PROV-ISSUE-472 (Feedback_IH): Review of the DC-NOTE by Ivan Herman [Mapping PROV-O to Dublin Core]
> 
> http://www.w3.org/2011/prov/track/issues/472
> 
> Raised by: Daniel Garijo
> On product: Mapping PROV-O to Dublin Core
> 
> (Reviewing the latest editor's draft: https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html/)
> 
> Two general comments (and a bunch of minor ones below).
> 
> 1. I think it is worth running the document through a spell checker and get it reviewed by a native English speaker. I found a number of small inadequacies (I added them to my comments) but I cannot claim to have found all; in some cases the sentences are so convoluted that, frankly, I got lost. As a non-English speaker myself I fully realize how frustrating English can be:-) but, well, this is what we got...
> 
> 2. The style of the prose in the document is, here and there, inappropriate for a /TR publication, whether it is a draft or a final note. It documents the draft and state of the discussion within the subgroup, which perfectly o.k., or even raising problems for the Working Group, which is still o.k. But if it goes to the general public one should make a much clearer distinction between what are part of a technical specification and what are still questions to the community, or open issues. Questions and issues should be clearly stated in the document as such to make them clear to the reader. I have drawn the attention to many places in my comments below, but I have clearly missed some...
> 
> See my more detailed comments below
> 
> Thx
> 
> Ivan
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> - 2nd sentence of the introduction: "element set ." -> "element set."
> 
> - 2nd paragaraph of the introduction:
> 
> "Both have different namespaces, usually the elements are used with the dc, the terms with dct or dcterms."
> 
> ->
> 
> "They have different namespaces; if abbreviated, the elements are usually used with the <code>dc</code> prefix, while <code>dct</code> or <code>dcterms</code> prefix is used for the terms."
> 
> In general, it would be good if code (eg., dct:title) was added to the paragraph texts as, well, code, ie, within a <code> pair. The same for the (many) property names in the text.
> 
> - Introduction: "Provenance metadata :" -> "Provenance metadata:"
> 
> - Introduction: "we exclude it from tha mapping" -> "we exclude it from the mapping"
> 
> - The part of the introduction, beginning with
> 
> [[[
> <p>Based on this definition…
> ]]]
> 
> until
> 
> [[[
> has been used by its owners.
> </p>
> ]]]
> 
> is enclosed in an <a> element. There is not anchor or link, but behaves funny if one clicks on the text (at least in Firefox…)
> 
> - Introduction: "Based on their different aspects of provenance, we discuss them below:" I do not understand this sentence. Maybe something like
> 
> "As a next step, we consider sub-categories of the provenance related terms as follows:"
> 
> (A native English speaker may have a better proposal)
> 
> - Introduction, after Table 1: "this definition it may overlap partially with almost half of the DCMI terms, ": do I understand it well that the 'it' is superfluous here?
> 
> - Section 1.1: just to be careful: the prov prefix will map to .../ns/prov-o, eventually, right?
> 
> - In 2.1, perultimate paragraph: "partt" -> "part"
> 
> - Right before 2.2: "Clean-up. Based on the context-free mapping…": Editorially, I do not understand this sentence.
> 
> - In general, I had difficulties to understand the last two paragraphs of 2.1. Without relly looking at the details of the complex mapping these paragraphs do not make too much sense to me. I wonder whether they are necessary at all.
> 
> - First paragraph section 2.2: "it is not clear, how" -> "it is not clear how"
> 
> - First paragraph section 2.2: "The activity of issuing a document does not necessarily change the document, but regarding the PROV ontology, there are two different specializations of this document before and after the issuing activity, distinguishable by the property of the document that states if the document was issued." Please rephrase this sentence. It is very long, difficult to parse…
> 
> - Section 2.2: "1):" and "2):" remove the ':' characters
> 
> - End part of section 2.2: "questions like the following: …" This part of the document is fine when put in an internal draft, but is not very appropriate for a public draft and/or a WG note. The issues and the alternatives should be clearly marked in the text as issues/question/notes.
> 
> In general I found the narrative of 2.2 again very difficult to parse and understand. If you have two different types of mapping that you entertain, please, provide a graph explicitly to both, and not only to one of the two (so that one can really compare).
> 
> - Section 2.3: right before the table: "those mapping in which the group" -> "those mapping for which the group"
> 
> - Table 3, explanation for dct:isVersionOf: "dct:isVersion of" -> "dct:isVersionOf"
> 
> - Table 3, explanation for dct:isFormatOf: "dct.isFormatOf" -> "dct:isFormatOf"
> 
> - I had separate comment on the inverse relationships in my review of prov-o:
> 
> http://www.w3.org/mid/2BB8960E-3025-4116-B43B-4185BB99A68F@w3.org
> 
> But I also see that some of the dct terms are mappend on inverse properties. If those are not really 'core' for Prov-O (and I believe they should not) then we should probably refer to those in this table separately…
> 
> - Table 3: the explanation of dct:hasFormat: "for dct:hasFormat" -> "for dct:isFormatOf"
> 
> - Table 3: explanation dct:replaces: "we propose to map", "we don't find": these formulations are inapprpriate for a draft or a note.
> 
> - Table 3: explanation to dct:type: "It could be mapped to rdf:type if we map the document against PROV-O" on the one hand, I do not understand this sentence; on the other hand, it is inappropriate for a draft or note. Put it as an issue in the document if it is an issue
> 
> - Table 3: explanation of 'created': "We have decided to map it as a subclass because the resources in Dublin Core have associated many dates…" again, this is stylistically inappropriate here.
> 
> - paragraph after table 3: "It would produce "scruffy" provenance (i.e., valid provenance which will not comply with all the PROV consraints [PROV_CONSTRAINTS])" what does 'it' refer to? Also, "consraints" -> "constraints"
> 
> - Section 2.5.1. In contrast to what the text says, the 'constructed' RDF graphs do not correspond to Figure 1; the latter also includes an extra derivation component. I think Figure 1 should be simplified accordingly. Also, to make the life of the reader easier, the same bnode identifiers should be used and, as much as possible, to same graphical notation style as used in other Prov document (for entities, activities, etc).
> 
> - Section 2.5.3: I do not understand the necessity of this section. All these terms appear in Table 3 as direct mapping of terms; the SPARQL CONSTRUCT rules do not add anything to these. What do I miss?
> 
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Tuesday, 23 October 2012 15:42:59 UTC