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

Thanks a lot, Ivan!
I have reopened the issue and deal with it tomorrow.

Best,
Daniel

2012/10/23 Ivan Herman <ivan@w3.org>

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