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

Hi Ivan,
I have finally pushed a new version removing the buttons.
Since this was the last comment, I will go ahead and close the issue.

Thanks!!
Best,
Daniel

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

> Daniel,
>
> thank you very much.
>
> Actually... with the remark below, having that button may not be
> necessary. Or... What I thought you would be doing is to add a button to
> remove the qualified part only (but that may be difficult to do in a
> <pre>...</pre>). That may make sense. If that does not work, I would
> propose to remove the buttons altogether.
>
> But this is a detail. Otherwise, I am more than happy with all the
> answers. Thanks a lot.
>
> Ivan
>
> On Oct 25, 2012, at 07:06 , Daniel Garijo wrote:
>
> > Hi Ivan,
> > it's implemented and pushed now:
> > http://dvcs.w3.org/hg/prov/raw-file/622d39a3cc47/dc-note/Overview.html
> >
> > I have also added a paragraph explaining how the complex mappings are
> oprional:
> > "The complex mappings consist on a set of patterns defined to generate
> qualified
> > PROV statements from Dublin Core statements. This type of qualification
> may not
> > be always needed, and it is the choice of the implementor whether to use
> them or not
> > depending on the use case."
> >
> > Thanks,
> > Daniel
> >
> > 2012/10/24 Ivan Herman <ivan@w3.org>
> >
> > On Oct 24, 2012, at 10:01 , Daniel Garijo wrote:
> >
> > > Hi Ivan,
> > > I have addressed all your issues except one and pushed a new version:
> > > http://dvcs.w3.org/hg/prov/raw-file/9452e991fa97/dc-note/Overview.html
> > >
> > > The only issue I haven't addressed is this one:
> > > "- 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."
> > >
> > > The qualified structures are very similar (instead of the role, they
> qualify with the date),
> > > but in the early feedback some people complained about not having them
> in the document.
> > >
> >
> > Aha. My understanding is that applications may use them as a hook to add
> additional properties to the translation, so maybe it is a good idea to
> show them, but making it clear that this is an optional pattern that can be
> used. My purpose is not to give the impression that the qualified
> structures are a must, ie, for simple things a simple pattern suffices.
> >
> > > What I could do is to include a button to hide all these patterns by
> default, showing
> > > them on demand. Would that work for you?
> > >
> >
> > Yes, that would be fine with me.
> >
> > Thank you!
> >
> > Ivan
> >
> > > Best,
> > > Daniel
> > >
> > > 2012/10/23 Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > ----
> > 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
> >
> >
> >
> >
> >
> >
> >
>
>
> ----
> 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
>
>
>
>
>
>
>