Re: Review of the DC mapping document

Hi Ivan,
thanks a lot for your review, I'll raise an issue against the product in
the tracker.

Regarding your general comments, I agree on 1) and I have asked for some
more people
to review the document, I'll do another pass and fix what I can.

With respect to 2) I think that Kai wanted to create some discussion about
how should
we model dc entities in PROV. I will separate the issues to make them clear.

Thanks again,
Daniel

2012/8/6 Ivan Herman <ivan@w3.org>

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