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

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