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

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?

Received on Monday, 6 August 2012 17:47:35 UTC