Ivan Herman Feedback On DC Note

New version of the DC-Note (23-Oct-2012): https://dvcs.w3.org/hg/prov/raw-file/208b77ed4e13/dc-note/Overview.html

Original feedback by Ivan, with intervealed responses: (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...

We have rephrased many of the wording to make it easier to read. We have also passed the document trhough a spell checker and asked several people for feedback. Hopefully the new version addresses your concerns.

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

We left a couple of open questions because we were looking for feedback for discussion from the DC and PROV communities. In the current version we have revisited them, discussed them and rephrased them appropriately.

See my more detailed comments below
- 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 dc prefix,
while dct or dcterms prefix is used for the terms."

Fixed

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.

Done

- 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
"Based on this definition…
until
has been used by its owners."
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…)

Fixed

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

We have rephrased this in the document.

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

Removed

- Section 1.1: just to be careful: the prov prefix will map to .../ns/prov-o, eventually, right?

This was taken from the ontology document. If it changes, we will change it here as well.

- In 2.1, perultimate paragraph: "partt" -> "part"

Fixed

- Right before 2.2: "Clean-up. Based on the context-free mapping…": Editorially, I do not understand this sentence.

This phrase has been removed.

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

We have removed most of them and rephrased the rest.

- First paragraph section 2.2: "it is not clear, how" -> "it is not clear how"

Fixed

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

Rephrased.

- Section 2.2: "1):" and "2):" remove the ':' characters

Done

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

All the questions have been taken out or rephrased them to state them as the decissions we took in our discussions.

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

We have added graphs explaining both approaches.

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

Done

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

You are right. We have separated the 2 inverse relationships in a separate table.

- 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

We have rephrased this three explanations in the new version of the document.

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

Rephrased explaining the differences between entity handling in PROV and DC. Also, we have added why certain modelings would not be compliant to the PROV 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).

Thanks for spotting this. The figure was right, but the constructed code had a couple of bnodes missing. We have also renamed everything to make it easier to read.

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

You are right, we have removed it from the document.